tia-1180_final

7/30/2019 TIA-1180_Final

1/38

7/30/2019 TIA-1180_Final

2/38

NOTICE

TIA Engineering Standards and Publications are designed to serve the public interest through

eliminating misunderstandings between manufacturers and purchasers, facilitatinginterchangeability and improvement of products, and assisting the purchaser in selecting and

obtaining with minimum delay the proper product for their particular need. The existence ofsuch Standards and Publications shall not in any respect preclude any member or non-member ofTIA from manufacturing or selling products not conforming to such Standards and Publications.

Neither shall the existence of such Standards and Publications preclude their voluntary use by

Non-TIA members, either domestically or internationally.

Standards and Publications are adopted by TIA in accordance with the American National

Standards Institute (ANSI) patent policy. By such action, TIA does not assume any liability to

any patent owner, nor does it assume any obligation whatever to parties adopting the Standard orPublication.

This Standard does not purport to address all safety problems associated with its use or allapplicable regulatory requirements. It is the responsibility of the user of this Standard to

establish appropriate safety and health practices and to determine the applicability of regulatory

limitations before its use.

(From Standards Proposal No. 3-0355.200, formulated under the cognizance of the TIA TR-45.4 -

Radio to Switching Technology - Mobile and Personal Communications Standards)

Published by

TELECOMMUNICATIONS INDUSTRY ASSOCIATIONStandards and Technology Department

2500 Wilson Boulevard

Arlington, VA 22201 U.S.A.

PRICE: Please refer to current Catalog of

TIA TELECOMMUNICATIONS INDUSTRY ASSOCIATION STANDARDS

AND ENGINEERING PUBLICATIONS

or call IHS, USA and Canada

(1-877-413-5187) International (303-397-2896)

or search online at http://www.tiaonline.org/standards/catalog/

All rights reserved

Printed in U.S.A.

7/30/2019 TIA-1180_Final

3/38

NOTICE OF COPYRIGHT

This document is copyrighted by the TIA.

Reproduction of these documents either in hard copy or soft copy (including

posting on the web) is prohibited without copyright permission. For copyrightpermission to reproduce portions of this document, please contact TIA Standards

Department or go to the TIA website (www.tiaonline.org) for details on how to

request permission. Details are located at:http://www.tiaonline.org/standards/catalog/info.cfm#copyright

OR

Telecommunications Industry Association

Standards & Technology Department

2500 Wilson Boulevard, Suite 300

Arlington, VA 22201 USA

+1(703)907-7700

Organizations may obtain permission to reproduce a limited number of copies by entering into alicense agreement. For information, contact:

IHS15 Inverness Way East

Englewood, CO 80112-5704 or call

U.S.A. and Canada (1-800-525-7052)

International (303-790-0600)

7/30/2019 TIA-1180_Final

4/38

7/30/2019 TIA-1180_Final

5/38

NOTICE OF DISCLAIMER AND LIMITATION OF LIABILITY

The document to which this Notice is affixed (the Document) has been prepared by one or more Engineering

Committees or Formulating Groups of the Telecommunications Industry Association (TIA). TIA is not the author

of the Document contents, but publishes and claims copyright to the Document pursuant to licenses and permission

granted by the authors of the contents.

TIA Engineering Committees and Formulating Groups are expected to conduct their affairs in accordance with the

TIA Engineering Manual (Manual), the current and predecessor versions of which are available at

http://www.tiaonline.org/standards/procedures/manuals/TIAs function is to administer the process, but not the

content, of document preparation in accordance with the Manual and, when appropriate, the policies and procedures

of the American National Standards Institute (ANSI). TIA does not evaluate, test, verify or investigate the

information, accuracy, soundness, or credibility of the contents of the Document. In publishing the Document, TIA

disclaims any undertaking to perform any duty owed to or for anyone.

If the Document is identified or marked as a project number (PN) document, or as a standards proposal (SP)

document, persons or parties reading or in any way interested in the Document are cautioned that: (a) the Document

is a proposal; (b) there is no assurance that the Document will be approved by any Committee of TIA or any other

body in its present or any other form; (c) the Document may be amended, modified or changed in the standards

development or any editing process.

The use or practice of contents of this Document may involve the use of intellectual property rights (IPR),

including pending or issued patents, or copyrights, owned by one or more parties. TIA makes no search or

investigation for IPR. When IPR consisting of patents and published pending patent applications are claimed and

called to TIAs attention, a statement from the holder thereof is requested, all in accordance with the Manual. TIA

takes no position with reference to, and disclaims any obligation to investigate or inquire into, the scope or validity

of any claims of IPR. TIA will neither be a party to discussions of any licensing terms or conditions, which are

instead left to the parties involved, nor will TIA opine or judge whether proposed licensing terms or conditions are

reasonable or non-discriminatory. TIA does not warrant or represent that procedures or practices suggested or

provided in the Manual have been complied with as respects the Document or its contents.

If the Document contains one or more Normative References to a document published by another organization

(other SSO) engaged in the formulation, development or publication of standards (whether designated as a

standard, specification, recommendation or otherwise), whether such reference consists of mandatory, alternate oroptional elements (as defined in the TIA Engineering Manual, 4 th edition) then (i) TIA disclaims any duty or

obligation to search or investigate the records of any other SSO for IPR or letters of assurance relating to any such

Normative Reference; (ii) TIAs policy of encouragement of voluntary disclosure (see Engineering Manual Section

6.5.1) of Essential Patent(s) and published pending patent applications shall apply; and (iii) Information as to claims

of IPR in the records or publications of the other SSO shall not constitute identification to TIA of a claim of

Essential Patent(s) or published pending patent applications.

TIA does not enforce or monitor compliance with the contents of the Document. TIA does not certify, inspect, test

or otherwise investigate products, designs or services or any claims of compliance with the contents of the

Document.

ALL WARRANTIES, EXPRESS OR IMPLIED, ARE DISCLAIMED, INCLUDING WITHOUT LIMITATION,

ANY AND ALL WARRANTIES CONCERNING THE ACCURACY OF THE CONTENTS, ITS FITNESS ORAPPROPRIATENESS FOR A PARTICULAR PURPOSE OR USE, ITS MERCHANTABILITY AND ITS

NONINFRINGEMENT OF ANY THIRD PARTYS INTELLECTUAL PROPERTY RIGHTS. TIA EXPRESSLY

DISCLAIMS ANY AND ALL RESPONSIBILITIES FOR THE ACCURACY OF THE CONTENTS AND

MAKES NO REPRESENTATIONS OR WARRANTIES REGARDING THE CONTENTS COMPLIANCE

WITH ANY APPLICABLE STATUTE, RULE OR REGULATION, OR THE SAFETY OR HEALTH EFFECTS

OF THE CONTENTS OR ANY PRODUCT OR SERVICE REFERRED TO IN THE DOCUMENT OR

PRODUCED OR RENDERED TO COMPLY WITH THE CONTENTS.

7/30/2019 TIA-1180_Final

6/38

TIA SHALL NOT BE LIABLE FOR ANY AND ALL DAMAGES, DIRECT OR INDIRECT, ARISING FROM

OR RELATING TO ANY USE OF THE CONTENTS CONTAINED HEREIN, INCLUDING WITHOUT

LIMITATION ANY AND ALL INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES

(INCLUDING DAMAGES FOR LOSS OF BUSINESS, LOSS OF PROFITS, LITIGATION, OR THE LIKE),

WHETHER BASED UPON BREACH OF CONTRACT, BREACH OF WARRANTY, TORT (INCLUDING

NEGLIGENCE), PRODUCT LIABILITY OR OTHERWISE, EVEN IF ADVISED OF THE POSSIBILITY OF

SUCH DAMAGES. THE FOREGOING NEGATION OF DAMAGES IS A FUNDAMENTAL ELEMENT OF

THE USE OF THE CONTENTS HEREOF, AND THESE CONTENTS WOULD NOT BE PUBLISHED BY TIA

WITHOUT SUCH LIMITATIONS.

7/30/2019 TIA-1180_Final

7/38

Revision History

Date Publication Description

December 2009 A.S0018-0 v1.0 Initial revision. For features supported, refer to section 1.1.

7/30/2019 TIA-1180_Final

8/38

1

2

3

4

(This page intentionally left blank)

7/30/2019 TIA-1180_Final

9/38

TIA-1180

i

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

Table of Contents

Foreword....................................................................................................................................................... v

1 Introduction...................................................................................................................................1-1

1.1 Overview.......................................................................................................................................1-1

1.1.1 Purpose..........................................................................................................................................1-1

1.1.2 Scope.............................................................................................................................................1-1

1.1.3 Document Convention ..................................................................................................................1-1

1.2 References.....................................................................................................................................1-1

1.2.1 Normative References...................................................................................................................1-1

1.2.2 Informative References.................................................................................................................1-2

1.3 Terminology..................................................................................................................................1-2

1.3.1 Acronyms......................................................................................................................................1-2

1.3.2 Definitions ....................................................................................................................................1-3

1.4 MSC Pool Network IOS Architecture Reference Model..............................................................1-3

1.4.1 Protocol-based MSC Pool Network IOS Architecture Reference Model.....................................1-3

1.4.1.1 Protocol-based MSC Pool Interfaces .......................................................................... 1-4

1.4.1.2 Protocol-based MSC Pool Architectural Principles....................................................1-5

1.4.2 OA&M-based MSC Pool Network IOS Architecture Reference Model ......................................1-5

1.4.2.1 OA&M-based MSC Pool Architectural Principles.....................................................1-6

1.5 Assumptions..................................................................................................................................1-6

1.6 Protocol-based MSC Pool Feature Description ............................................................................1-6

1.6.1 MSC Pool Network Concepts.......................................................................................................1-6

1.6.2 Load Distribution..........................................................................................................................1-6

1.6.3 Network Reference Identifier .......................................................................................................1-9

1.6.4 Load Redistribution ......................................................................................................................1-9

1.6.5 A1p Security ...............................................................................................................................1-10

1.7 OA&M-based MSC Pool Feature Description ...........................................................................1-10

1.8 Compatibility with IOS Standards ..............................................................................................1-10

2 Signaling Flows for Protocol-based MSC Pool ............................................................................2-1

2.1 Registration...................................................................................................................................2-1 2.1.1 Normal Registration......................................................................................................................2-1

2.1.2 Registration After Re-distribution MS Initiated ........................................................................2-2

2.2 Call Origination ............................................................................................................................ 2-3

2.2.1 Call Origination (Normal Case)....................................................................................................2-3

2.2.2 Call Origination After Re-distribution..........................................................................................2-4

2.3 Call Termination...........................................................................................................................2-5

7/30/2019 TIA-1180_Final

10/38

TIA-1180

ii

1

2

3

4

5

6

7

8

9

10

11

12

2.3.1 Call Termination (Normal Case) ..................................................................................................2-5

2.3.2 Call Termination Without Tag Parameter (Exception Case) ........................................................2-6

2.4 Handoff ......................................................................................................................................... 2-6

2.4.1 Handoff Intra-MSC Pool...............................................................................................................2-6

2.4.2 Handoff Between MSC Pool and Non-MSC Pool MSCes ...........................................................2-7

2.5 Facility Management .................................................................................................................... 2-8

2.5.1 Uplink Facility Management Messages........................................................................................2-8

2.5.2 Downlink Facility Management Messages...................................................................................2-8

2.5.3 Uplink Reset Message...................................................................................................................2-9

2.5.4 Downlink Reset Message..............................................................................................................2-9

Annex A MSCe Selection Method Based on IMSI (Informative)......................................................... A-1

7/30/2019 TIA-1180_Final

11/38

TIA-1180

iii

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

Table of Figures

Figure 1.4.1-1 Protocol-based MSC Pool Network Arch. Reference Model for A1/A2Interfaces (LMSD Step 1) ............................................................................................1-4

Figure 1.4.1-2 Protocol-based MSC Pool Network Arch. Reference Model for A1p/A2p

Interfaces (LMSD Step 2) ............................................................................................1-4

Figure 1.4.2-1 OA&M-based MSC Pool Network IOS Architecture Reference Model......................1-5

Figure 1.6.3-1 Identification of NRI within Tag IE .............................................................................1-9

Figure 1.6.3-2 Identification of NRI within Local Reference ..............................................................1-9

Figure 2.1.1-1 Normal Registration .....................................................................................................2-1

Figure 2.1.2-1 Registration After Re-distribution MS Initiated........................................................2-2

Figure 2.2.1-1 Call Origination (Normal Case)....................................................................................2-3

Figure 2.2.2-1 Call Origination After Re-distribution..........................................................................2-4

Figure 2.3.1-1 Call Termination (Normal Case) ..................................................................................2-5Figure 2.3.2-1 Call Termination Without Tag Parameter (Exception Case)........................................2-6

Figure 2.4.1-1 Handoff Intra-MSC Pool ..............................................................................................2-7

Figure 2.5.1-1 Uplink Facility Management Messages........................................................................2-8

Figure 2.5.2-1 Downlink Facility Management Messages...................................................................2-8

Figure 2.5.3-1 Uplink Reset Message ..................................................................................................2-9

Figure 2.5.4-1 Downlink Reset Message .............................................................................................2-9

7/30/2019 TIA-1180_Final

12/38

TIA-1180

iv

1

2

3

4

5

6

Table of Tables

Table 1.6.2-1 NRI Source for A1p Uplink Messages .........................................................................1-7

7/30/2019 TIA-1180_Final

13/38

TIA-1180

v

Foreword1

2

3

4

5

6

7

8

9

10

11

This foreword is not part of this standard.

This document describes the architecture (distribution of functions), protocols and procedures to support

the MSC Pool feature.

This document was produced by TSG-A of the Third Generation Partnership Project 2. This documentwas developed in accordance with the procedural guidelines of 3GPP2 and its Organizational Partners,

and represents the consensus position of these groups.

Note that there is one annex in this document. Annex A is informative and is not considered part of this

Standard.

7/30/2019 TIA-1180_Final

14/38

TIA-1180

vi

1

2

3

4


7/30/2019 TIA-1180_Final

15/38

TIA-1180

1-1

1 Introduction1

This document contains the procedures and call flows associated with MSC Pool support in the access

network.

2

3

1.1 Overview4

This document includes a description of the interface protocols and procedures to support the following

features and functions.

5

6

7 Features and functions explicitly supported in this standard:

MSC Pool network concepts8

Load Distribution9

Network Reference Identifier format10

Load Redistribution11

A1p Security considerations with MSC Pool12

1.1.1 Purpose13

The purpose of this document is to provide the architecture (distribution of functions), protocols and

procedures to support the MSC Pool feature.

14

15

1.1.2 Scope16

This document provides an interoperability specification for a network that supports the MSC Pool

feature. This document contains message procedures and formats necessary to obtain this interoperability.

Also, this release of the specification only applies to the Legacy Mobile Station Domain (LMSD) network,

both to LMSD Step 1 per X.S0012

17

18

19

20 [2] and LMSD Step 2 per X.S0025 [3].

1.1.3 Document Convention21

Shall and shall not identify requirements to be followed strictly to conform to the standard and fromwhich no deviation is permitted. Should and should not indicate that one of several possibilities is

recommended as particularly suitable, without mentioning or excluding others; that a certain course ofaction is preferred but not necessarily required; or (in the negative form) that a certain possibility or

course of action is discouraged but not prohibited. May and need not indicate a course of action

permissible within the limits of the standard. Can and cannot are used for statements of possibility

and capability, whether material, physical, or causal.

2223

24

25

26

27

28

1.2 References29

References are either normative or informative. A normative reference is used to include another doc-

ument as a mandatory part of a 3GPP2 specification. Documents that provide additional non-essential in-

formation are included in the informative references section.

30

31

32

1.2.1 Normative References33

The following standards contain provisions which, through reference in this text, constitute provisions of

this standard. At the time of publication, the editions indicated were valid. All standards are subject to

revision, and parties to agreements based upon this document are encouraged to investigate the possibility

of applying the most recent editions published by them. ANSI and TIA maintain registers of currently

valid national standards published by them.

34

35

36

37

38

7/30/2019 TIA-1180_Final

16/38

TIA-1180

1-2

2

6

[1] 3GPP2: A.S0014-D v2.0, Interoperability Specification (IOS) for cdma2000 Access Network1Interfaces Part 4 (A1, A1p, A2, and A5 Interfaces), August 2009.

[2] 3GPP2: X.S0012-0 v2.0,Legacy MS Domain Step 1, March 2004.3

[3] 3GPP2: X.S0025-0 v1.0,Legacy MS Domain Step 2, February 2006.4

[4] ITU-T: H.248.1, Gateway Control Protocol: Version 3, September 2005.5

1.2.2 Informative References7

None.8

9

1.3 Terminology10

This section contains definitions, symbols and abbreviations that are used throughout the document.11

1.3.1 Acronyms12

3GPP2 3rd Generation Partnership Project 2

BS Base Station

BSC Base Station Controller

BSMAP Base Station Management Application Part

CIC Circuit Identity Code

CN Core Network

DTAP Direct Transfer Application Part

HLR Home Location Register

IE Information Element

IMSI International Mobile Subscriber IdentityIOS Interoperability Specification

LMSD Legacy MS Domain

MGW Media Gateway

MS Mobile Station

MSC Mobile Switching Center

MSCe Mobile Switching Center Emulator

NRI Network Reference Identifier

OA&M Operations, Administration, and Maintenance

PA Pool Area

RAN Radio Access Network

SCCP Signaling Connection Control Part

SNSF Serving Node Selection Function

SUA Signaling Connection Control Part User Adaptation Layer

13

7/30/2019 TIA-1180_Final

17/38

TIA-1180

1-3

1.3.2 Definitions1

MSC Pool Network2

3 An MSC Pool Network is a network that supports the MSC Pool feature.

MSC Pool4

5 An MSC Pool is a group of MSCes to which a set of Base Station Controllers (BSCs) connect.

Network Reference Identifier6

7

8

9

10

11

The Network Reference Identifier (NRI) uniquely identifies an MSCe out of all the MSCes within a given

Pool Area (PA). The NRI is allocated by the core network (CN) entity and embedded in the Tag

Information Element (IE) or Local Reference ID. NRI is transparent to the access network and the Mobile

Station (MS). The Serving Node Selection Function (SNSF) can derive the NRI from uplink A1/A1p

messages.

Pool Area (PA)12

13

14

A Pool Area is a geographical area which consists of radio coverage of one or more BSCs. Within this

area, an MS can move without change of the serving MSCe.

Selected Serving MSCe15

16

17

An MSCe selected by the SNSF from an MSC Pool serves an MS for the life of its connection (idle and

active) within the PA even if the MS crosses a BSC boundary within the MSC Pool area.

Serving Node Selection Function (SNSF)18

19

20

21

The function used to assign specific network resources (i.e., MSCe) to serve an MS and subsequently

route signaling messages to the assigned network resource.

1.4 MSC Pool Network IOS Architecture Reference Model22

Architectural reference models are provided for protocol-based and Operations, Administration, and

Maintenance (OA&M)-based MSC Pools. In the figures, solid lines indicate bearer and dashed lines

indicate signaling.

23

24

25

1.4.1 Protocol-based MSC Pool Network IOS Architecture Reference Model26

MSC Pool messaging and call flows are based on the architecture reference models in Figure 1.4.1-1 and27

28

29

30

Figure 1.4.1-2 for the support of A1/A2 interfaces (Legacy MS Domain Step 1 architecture) and A1p/A2p

interfaces (Legacy MS Domain Step 2 architecture), respectively. This is a logical architecture that doesnot imply any particular physical implementation.

7/30/2019 TIA-1180_Final

18/38

TIA-1180

1-4

SNSF

BSC

BSC

MSCe

MSCe

4848

A1p

MSCPoolArea

MGW3927

MGW

A2

39

BSC MSCA1

A2p

1

2

3

Figure 1.4.1-1 Protocol-based MSC Pool Network Arch. Reference Model for A1/A2 Interfaces

(LMSD Step 1)

SNSF

BSC

BSC

MSCe

MSCe

A1pA1p

A1p

MSCPoolAreazz

MGW39

A2p

MGW

A2

39

BSC MSCA1

E

A2p

4

5

6

8

9

10

11

Figure 1.4.1-2 Protocol-based MSC Pool Network Arch. Reference Model for A1p/A2p Interfaces

(LMSD Step 2)

1.4.1.1 Protocol-based MSC Pool Interfaces7

The interfaces defined in this specification are described as follows.

A1p Reference Point A1p is the packet signaling interface between the cdma20001 Access

Network and the Legacy MS Domain as defined in A.S0014 [1]. This document does not

make changes to the existing reference point.

1 cdma2000

is the trademark for the technical nomenclature for certain specifications and standards of the Organizational

Partners (OPs) of 3GPP2. Geographically (and as of the date of publication), cdma2000

is a registered trademark of the

Telecommunications Industry Association (TIA-USA) in the United States.

7/30/2019 TIA-1180_Final

19/38

TIA-1180

1-5

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

17

21

A2p Reference Point A2p is the packet bearer stream interface between the cdma2000 Access

Network and the Media Gateway (MGW) as defined in A.S0014 [1]. This document does

not make changes to the existing reference point.

39 Reference Point 39 is between the MSCe and the MGW, which is based on ITU-T H.248

[4]. This document does not make changes to this existing reference point 39 as defined

in X.S0012 [2].

zz Reference Point zz is the signaling interface between two MSCes. This document doesnot make changes to this existing reference point zz as defined in X.S0025 [3].

27 Reference Point 27 is the MGW to Radio Access Network (RAN) circuit bearer interface.

This document does not make changes to this existing reference point as defined in

X.S0012 [2]. Reference Point 27 defines the A2 and A5 protocols.

48 Reference Point 48 is the MSCe-to-RAN signaling interface. This document does not

make changes to this existing reference point as defined in X.S0012 [2]. Reference Point

48 defines the A1 protocol.

1.4.1.2 Protocol-based MSC Pool Architectural Principles16

The architectural principles for the protocol-based MSC Pool are as follows:

Each MSCe can assign resources to a call supported on any BSC using an appropriate MGW.18

Virtual MGW capabilities are supported, at the option of the network operator.19

A BSC shall connect with one or more SNSFs. An SNSF shall connect with all the MSCes within the20PA.

All MSCes within the PA are assumed to be configured as Border MSCes of each other.22

1.4.2 OA&M-based MSC Pool Network IOS Architecture Reference Model23

Figure 1.4.2-1 is the architecture reference model for the OA&M-based MSC Pool network.24

25

Operations,

Administration,and

Maintenance

MSCe

MGW

BS

MSCe

MGW

IPOA&M

OA&M

OA&M

26

27 Figure 1.4.2-1 OA&M-based MSC Pool Network IOS Architecture Reference Model

7/30/2019 TIA-1180_Final

20/38

TIA-1180

1-6

1

3

8

1.4.2.1 OA&M-based MSC Pool Architectural Principles2

The architectural principles for the OA&M-based MSC Pool are as follows:

Each Base Station (BS) can be re-homed on multiple MSCe instances in the MSC pool.4

OA&M coordination dynamically moves a BS from one MSCe to a different MSCe.5

The interactions between the OA&M function and the BS and MSCe are outside the scope of this6specification.7

1.5 Assumptions9

1. MSC Pool SNSF operation is transparent to the messaging between the MSCe and BSC. The MSC10Pool feature makes no modifications to the 1x Interoperability Specification (IOS).11

12

1.6 Protocol-based MSC Pool Feature Description13

14

1.6.1 MSC Pool Network Concepts15

An MSC Pool network enables one BSC to have signaling connections with any MSCe within a Pool

Area (PA) with the aid of a Serving Node Selection Function (SNSF). When an MS enters a PA, the

SNSF selects a serving MSCe for the MS based on an MSCe selection algorithm. In the normal case, the

MS is served by the same serving MSCe as long as it is within the PA.

16

17

18

19

1.6.2 Load Distribution20

Regarding downlink signaling (A1/A1p) messages (messages traveling in the MSCe-to-BS direction),

the SNSF shall route such messages toward the BSC on the basis of lower protocol layer addressing (e.g.,

SS7 signaling point code) information that is available in the message to be routed.

21

22

23

24

25

26

27

28

29

30

31

32

33

35

36

37

38

39

40

42

Regarding uplink signaling (A1/A1p) messages (messages traveling in the BS-to-MSCe direction), the

SNSF shall distribute the load among the available MSCes within a given PA. This can be achieved by

deriving a Network Reference Identifier from uplink A1/A1p messages and determining the Selected

Serving MSCe according to the NRI, or by deriving the International Mobile Subscriber Identity (IMSI)

from the uplink A1/A1p messages and selecting an MSCe based on the IMSI. The NRI may be embedded

in the Tag IE of A1/A1p messages, or be embedded in the Local Reference of Signaling Connection

Control Part (SCCP) DT1/Signaling Connection Control Part User Adaptation Layer (SUA) CODT

messages. The NRI shall uniquely identify an MSCe within a given PA. The length and format of NRI are

as specified in section 1.6.3. The distinct classes of message routing behavior at the SNSF are described

as follows:

1. If the SNSF can derive NRI from the Local Reference of the uplink A1/A1p message (indicative that34an SCCP/SUA connection has been established), the SNSF shall route the message to the Selected

Serving MSCe according to the NRI embedded in the Local Reference. An MSCe shall include the

NRI in the Source Local Reference field of the response to an SCCP CR/SUA CORE message. Then,

subsequent uplink SCCP DT1/SUA CODT messages can be routed by the SNSF to the Selected

Serving MSCe according to the NRI in the SCCP/SUA connection information (i.e., Destination

Local Reference).

2. Otherwise, if the SNSF can derive NRI from the Tag IE of the uplink A1/A1p message, the SNSF41shall route the message to the Selected Serving MSCe according to the NRI embedded in the Tag IE.

7/30/2019 TIA-1180_Final

21/38

TIA-1180

1-7

10

11

12

14

15

16

17

18

19

20

21

22

23

25

26

27

28

29

30

32

33

34

35

36

37

38

39

40

41

If the MSCe triggers the MS to setup the signaling path (e.g., Call Termination) or the MSCe triggers1

a connectionless signaling transaction between the MSCe and the MS (e.g., Paging Request or2

Feature Notification), the MSCe shall include the NRI in the request message. The BSC shall include3

the same Tag IE in the corresponding response message. The SNSF shall derive the NRI from the4

response message and forward the response message to the Selected Serving MSCe according to the5

NRI.6

3. If the SNSF can not derive NRI from the uplink A1/A1p message, the SNSF shall examine the IMSI7

to select an MSCe. If the MS sends a connectionless request message (e.g., data burst request) or a8

signaling path establishment request message (e.g., call origination request) toward the network, the9

SNSF examines the IMSI within the uplink A1/A1p message and selects an MSCe as the Selected

Serving MSCe based on an implementation specific algorithm. Then the SNSF routes the message to

the Selected Serving MSCe.

4. In the specific case of the Reset message, when receiving a Reset message from an MSCe, the SNSF13(if the SNSF is not co-located with the BSC) shall respond immediately with a Reset Ack to theMSCe. The SNSF starts timer Tr to ensure that all the affected SCCP/SUA connections in the target

BSC are released before new traffic is distributed to the MSCe again. While timer T r is running,

active SCCP/SUA connections at the target BSC are released by means of the SCCP/SUA inactivitytest mechanism. If, while timer Tr is running, the SNSF derives the NRI of the reset MSCe from

received uplink BSAP messages, the SNSF: 1) routes new service requests (e.g., CM Service Request)

to another MSCe in the PA; and 2) discards connection-oriented messages that are received from the

BSC. If the SNSF is co-located with the BSC, the SNSF shall pass the message to the BSC via

internal interfaces. Regarding the Reset message sent by the BSC, the SNSF shall send the message to

each MSCe in the PA.

5. For facility management messages other than Reset, the SNSF obtains the network address of the24BSC and the circuit identifier from the received A1 message. The SNSF shall then route the message

to the Selected Serving MSCe according to a configured mapping between the obtained information

and the MSCe address. The SNSF shall await the arrival of the associated acknowledgement from the

MSCe or the BSC prior to sending an acknowledgement to the corresponding BSC or MSCe. This is

to ensure that the received acknowledgement is an indication that the MSCe or BSC responded to the

original message and not that the SNSF received the message.6. The optional capability of the BS to request a preferred terrestrial circuit in the CM Service Request31

message is not supported by the MSC Pool feature.

In any case of uplink message handling, the SNSF shall assert the network address (e.g., SS7 signaling

point code) of the source BSC as the source network address of the message that is transmitted to the

selected MSCe.

In the event of complete SNSF node failure, all of the BSs connected to the SNSF will be unable to

support traffic. In such an event, message type-specific recovery procedures currently specified in

A.S0014 [1] for timer expiration are invoked at the MSCe or BSC as appropriate.

Table 1.6.2-1 identifies the source of the NRI for each uplink A1p message, based on message

characteristics and SNSF routing behavior.Table 1.6.2-1 NRI Source for A1p Uplink Messages

Message Name SUA Message Source of the NRI Message Discriminator

Additional Service Request CODT SUA LR DTAP

ADDS Deliver CODT SUA LR DTAP

ADDS Deliver Ack CODT SUA LR DTAP

ADDS Page Ack CLDT TAG BSMAP

7/30/2019 TIA-1180_Final

22/38

TIA-1180

1-8


ADDS Transfer CLDT IMSI BSMAP

Assignment Complete CODT SUA LR BSMAP

Assignment Failure CODT SUA LR BSMAP

Authentication Report CODT SUA LR DTAP

CODT SUA LR DTAPAuthentication Response

CLDT TAG BSMAP

Base Station Challenge CODT SUA LR DTAP

Bearer Update Required CODT SUA LR BSMAP

Bearer Update Response CODT SUA LR BSMAP

BS Authentication Request CODT SUA LR BSMAP

BS Security Mode Request CLDT IMSI BSMAP

BS Service Request CLDT IMSI BSMAP

Clear Complete CODT SUA LR BSMAP

Clear Request CODT SUA LR BSMAP

CM Service Request CORE IMSI DTAP

CM Service Request

Continuation

CODT SUA LR DTAP

Connect CODT SUA LR DTAP

Event Notification Ack CLDT IMSI BSMAP

Feature Notification Ack CLDT TAG BSMAP

Flash with Information CODT SUA LR DTAP

Flash with Information Ack CODT SUA LR DTAP

Handoff Commenced CODT SUA LR BSMAP

Handoff Complete CODT SUA LR BSMAP

Handoff Failure COREF SUA LR BSMAP

Handoff Performed CODT SUA LR BSMAP

Handoff Request

Acknowledge

COAK SUA LR BSMAP

Handoff Required CODT SUA LR BSMAP

Location Updating Request CORE IMSI DTAP

PACA Command Ack CODT SUA LR BSMAP

PACA Update CLDT IMSI BSMAP

PACA Update Ack CLDT IMSI BSMAP

Paging Response CORE TAG DTAP

Parameter Update Confirm CODT SUA LR DTAP

Privacy Mode Complete CODT SUA LR BSMAP

Radio Measurements for

Position Response

CODT SUA LR BSMAP

CODT SUA LR DTAPRejection

CLDT TAG BSMAP

Reset CLDT 1 BSMAP

Reset Ack CLDT BSMAP

7/30/2019 TIA-1180_Final

23/38

TIA-1180

1-9


CODT SUA LR DTAPSecurity Mode Response

CLDT TAG BSMAP

Service Release CODT SUA LR DTAP

Service Release Complete CODT SUA LR DTAP

SSD Update Response CODT SUA LR DTAP

CODT SUA LR DTAPStatus Response

CLDT TAG BSMAP

User Zone Update Request CODT SUA LR DTAP

Note 1: The NRI concept does not apply for the Reset message.1

1.6.3 Network Reference Identifier2

This section specifies the format of the Network Reference Identifier (NRI) when placed within the Tag

IE and when placed within the Local Reference. The NRI is used for target node identification by the

SNSF when handling Direct Transfer Application Part (DTAP) or Base Station Management Application

Part (BSMAP) messages traveling in the uplink (BS-to-MSC) direction.

3

4

5

6

7

8

9

The NRI bits may be placed within the Tag IE as illustrated in Figure 1.6.3-1. Actual placement of theNRI within the Tag IE is an operator concern.

7 6 5 4 3 2 1 0 Octet

Tag: A1 Element Identifier 1

NRI 2

3

4

5

Figure 1.6.3-1 Identification of NRI within Tag IE10

11

12

13

The NRI bits may be placed within the Local Reference as illustrated in Figure 1.6.3-2. Actual placement

of the NRI within the Local Reference is an operator concern.

23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

NRI

Figure 1.6.3-2 Identification of NRI within Local Reference14

1.6.4 Load Redistribution15

There are situations where an MSCe in a PA may be out of service (e.g., when an MSCe is maintained or

upgraded by the operator). This entity is known as the failure MSCe. The re-distribution procedure can be

used to redistribute the load from the failure MSCe to other MSCe nodes in the PA in an orderly manner.

Load re-distribution does not require any specific functionality in the MS.

16

17

18

19

20

21

22

Re-distribution of MSs is initiated by the OM&P system. The OM&P system shall notify all SNSFs in the

PA which MSCe is going to be off-loaded and trigger all SNSFs to update configuration information. The

SNSF shall distribute the load based on the updated configuration thereafter.

7/30/2019 TIA-1180_Final

24/38

TIA-1180

1-10

1

2

3

4

Eventually, mobiles served by the failure MSCe are assigned to other MSCes in the PA when they

perform Periodic Location Update procedure. If conditions permit, the failure MSCe can initiate the

Ordered Registration procedure to trigger the MS to perform Location Update procedure.

When the failure MSCe is recovered, the load can be reallocated to the MSCe again in the same manner.

1.6.5 A1p Security5

The IOS RAN may be realized as a managed network. In this case, it is assumed that all interfaces arephysically secured. Additional security measures shall consider the SNSF as one part of the security

solution and the details are out of the scope of this standard.

6

7

8

1.7 OA&M-based MSC Pool Feature Description9

The OA&M-based MSC Pool feature provides the ability to re-home a base station from one MSCe to a

different MSCe dynamically. This ability to re-home a base station provides the operator the ability to

reconfigure their network in the case of MSCe failure, or for load re-distribution.

10

11

12

1.8 Compatibility with IOS Standards13

The Protocol-based MSC Pool Network IOS architecture reference model in section 1.4.1 includes

interfaces that also exist in the 1x architecture reference model (refer to A1/A1p and A2/A2p). This

specification reuses the 1x IOS transport requirements and interface definitions for these interfaces.

14

15

16

17

18

The OA&M-based MSC Pool architecture reference model in section 1.4.2 uses OA&M signaling

interfaces to dynamically control the homing of base stations on specific MSCes.

7/30/2019 TIA-1180_Final

25/38

TIA-1180

2-1

2 Signaling Flows for Protocol-based MSC Pool1

This section describes the interactions between network entities in various situations related to MSC Pool.

Signaling messages between the MSCe and the Home Location Register (HLR) and message sequences

shown in the call flows in this document are informative only. Refer to X.S0012

2

3

4

5

[2] and X.S0025 [3] for

those signaling messages and message sequences.

2.1 Registration6

This section describes the call flows associated with MS registration in the MSC Pool.7

2.1.1 Normal Registration8

This scenario describes the call flow for normal registration in an MSC Pool.9

BSC SNSF MSCe

1. Location Updating Request (IMSI)

3. Location Updating Accept


4. Location Updating Accept

10

11

14

15

17

19

Figure 2.1.1-1 Normal Registration

1. The SNSF receives a Location Updating Request message from the BSC.12

2. The SNSF selects an MSCe as the Selected Serving MSCe based on the MSCe selection method,13using IMSI as the input. Then the SNSF forwards the Location Updating Request message to the

MSCe.

3. The MSCe returns a Location Updating Accept message to the SNSF according to the source16signaling point contained in the Location Updating Request message.

4. The SNSF forwards the Location Updating Accept message to the BSC.18

7/30/2019 TIA-1180_Final

26/38

TIA-1180

2-2

2.1.2 Registration After Re-distribution MS Initiated1

This scenario describes the call flow for registration after load re-distribution. It includes periodic

registration and power off registration.

2

3

BSC SNSF MSCe2

4. REGNOT (IMSI)

MSCe1

5. REGCAN C (IMSI)


HLR

6. regcanc

9. Location Updaing A ccept

8. Location Updaing Accept

7. regnot (MDN , Profile)


1. MSCe1 is off-loaded and OM &P instructsSNS F to initiate load re-distribution

4

5

8

9

10

11

14

16

21

23

Figure 2.1.2-1 Registration After Re-distribution MS Initiated

1. The default MSCe of an MS (e.g., MSCe1 in this case) is off-loaded for some reason. The re-6distribution has been initiated and the MS is in idle state when the event occurs.7

Note: The redistribution is triggered by the OM&P system and the configuration of the MSCe

selection algorithm in the SNSF is updated by the OM&P. The interaction between the OM&P

system and the SNSF, and the interaction between the OM&P system and the MSCe is out of thescope of this document.

2. The SNSF receives a Location Updating Request message.12

3. The SNSF allocates MSCe2 as the serving MSCe according to the MSCe selection algorithm with13updated configuration, and then forwards the Location Updating Request message to MSCe2.

4. MSCe2 sends a REGNOT message to the HLR to request profile of the subscriber, the message15includes the IMSI.

5. The HLR sends a REGCANC message to MSCe1 to cancel location, the message includes the IMSI.17

6. MSCe1 acknowledges the HLR by sending a regcanc message.18

7. HLR sends a regnot message to MSCe2 to push the subscribers profile to MSCe2.19

8. MSCe2 returns a Location Updating Accept message to the SNSF according to the source signaling20point contained in the Location Updating Request message.

9. The SNSF forwards the Location Updating Accept message to the BSC.22

7/30/2019 TIA-1180_Final

27/38

TIA-1180

2-3

2.2 Call Origination1

This section describes the call flows associated with MS call origination in the MSC Pool.2

2.2.1 Call Origination (Normal Case)3

This scenario describes the call flow for call origination in an MSC Pool.4

BSC SNSF MSCe

1. CM Service Request (IMSI)

3. Assignment Request (NRI)



5. Assignment Com plete (NRI)

6. Assignment Com plete (NRI)

5

6

11

12

16

17

18

Figure 2.2.1-1 Call Origination (Normal Case)

1. The SNSF receives a CM Service Request message from the BSC, the message includes the IMSI.7

2. SNSF selects the Selected Serving MSCe based on the MSCe selection algorithm, using IMSI as the8input. Then the SNSF forwards the CM Service Request message to the selected MSCe.9

3. The MSCe sends an Assignment Request message to the SNSF according to the source signaling10point contained in the CM Service Request message and includes its NRI in the source Local

Reference of the SCCP/SUA message.

4. The SNSF forwards the Assignment Request message to the BSC.13

5. The BSC assign radio resource for the MS and returns an Assignment Complete message to the SNSF.14

6. The SNSF forwards this and subsequent messages from the BSC to the MSCe based on the NRI15derived from the existing SCCP/SUA connection (i.e., destination Local Reference of SCCP

DT1/SUA CODT messages).

7/30/2019 TIA-1180_Final

28/38

TIA-1180

2-4

2.2.2 Call Origination After Re-distribution1

This scenario describes the call flow for call origination after load re-distribution.2

BSC SNSF MSCe2

4. REGNOT (IMSI)

MSCe1

5. REGCAN C (IMSI)


HLR

6. regcanc



7. regnot (MDN , Profile)


1. MSCe1 is out of service and OM &P instructs

SNS F to initiate load re-distribution

3

4

7

8

9

11

13

14

16

20

22

23

25

26

27

Figure 2.2.2-1 Call Origination After Re-distribution

1. The Selected Serving MSCe of an MS (e.g., MSCe1 in this case) is out of service for some reason.5Re-distribution has been initiated and the MS is in idle state when the event occurs.6

Note: The redistribution is triggered by the OM&P system and the configuration of the MSCe

selection algorithm in the SNSF is updated. The interaction between the OM&P system and the SNSF,

and the interaction between the OM&P system and the MSCe is out of the scope of this document.

2. The SNSF receives a CM Service Request message from the MS via the BSC, which includes the10IMSI.

3. The SNSF selects MSCe2 as the Selected Serving MSCe as the configuration of the SNSF has been12updated for re-distribution by using IMSI as the input. Then the SNSF forwards the CM Service

Request message to the selected MSCe.

4. MSCe2 sends a REGNOT message to the HLR to request the profile of the subscriber, the message15includes the IMSI.

5. The HLR sends a REGCANC message to MSCe1 to cancel location, the message includes the IMSI.17

6. MSCe1 acknowledges the HLR by sending a regcanc message.18

7. The HLR sends a regnot message to MSCe2 to push the subscribers profile to MSCe2.19

Note: This step may occur any time after step 4.

8. MSCe2 sends an Assignment Request message to the SNSF according to the source signaling point21

contained in the CM Service Request message and includes its NRI in the source Local Reference ofthe SCCP/SUA message.

9. The SNSF forwards the Assignment Request message to the BSC. Subsequent messages from the24BSC are routed to the MSCe based on the NRI derived from the existing SCCP/SUA connection (i.e.,

destination Local Reference of the SCCP DT1/SUA CODT messages).

7/30/2019 TIA-1180_Final

29/38

TIA-1180

2-5

2.3 Call Termination1

This section describes the call flows associated with paging the MS in the MSC Pool.2

2.3.1 Call Termination (Normal Case)3

This scenario describes the call flow for call termination in an MSC Pool Area.4

BSC SNSF MSCe

1. Paging Request (NRI-1)

2. Paging Request (NRI-1)

3. Paging Response (NR I-1)

5. Assignment Request (NRI-2)

4. Paging Response

6. Assignment Request (NRI-2)

7. Assignment Com plete (NRI-2)

8. Assignment Com plete

9. Connect (NRI-2)

10 Connect

5

6

11

13

15

16

17

20

22

23

25

27

Figure 2.3.1-1 Call Termination (Normal Case)1. The MSCe sends a Paging Request message with the Tag parameter which includes its NRI (i.e.,7

NRI-1) to the SNSF according to the LAC of the MS.8

2. The SNSF forwards the Paging Request message to the BSC.9

3. The BSC returns a Paging Response message with the same Tag parameter to the SNSF. The SNSF10derives the NRI-1 from the Tag parameter.

4. The SNSF locates the MSCe by the derived NRI and sends the Paging Response message to the12MSCe.

5. The MSCe sends an Assignment Request message to the SNSF and includes its NRI (i.e., NRI-2) in14the source Local Reference of the SCCP CC/SUA COAK message.

Note: NRI-1 is embedded in the Tag IE and NRI-2 is embedded in the Local Reference, which is why

they are denoted as different NRIs. The actual value of NRI-2 may or may not be the same as NRI-1.

6. The SNSF forwards the Assignment Request message to the BSC.18

7. The BSC assigns radio resources for the MS and returns the Assignment Complete message with the19NRI-2 to the SNSF.

8. The SNSF forwards the Assignment Complete message to the MSCe based on the NRI derived from21the established SCCP/SUA connection (i.e., destination Local Reference of the SCCP DT1/SUA

CODT messages).

9. The MS answers the call and the BSC, upon receiving the Connect message from the MS, includes24the NRI-2 in the destination Local Reference of the SCCP/SUA message.

10.The SNSF forwards the Connect message to the MSCe based on the NRI derived from the established26SCCP/SUA connection (i.e., destination Local Reference of the SCCP DT1/SUA CODT messages).

7/30/2019 TIA-1180_Final

30/38

TIA-1180

2-6

2.3.2 Call Termination Without Tag Parameter (Exception Case)1

This scenario describes the call flow for call termination when the page response received includes no

Tag parameter. This may happen when the MSCe sending the Paging Request includes no Tag parameter

in the Paging Request message. Upon receipt of the Paging Response, the SNSF shall select the MSCe

based on the MSs IMSI.

2

3

4

5

6

7

11

13

14

15

17

Figure 2.3.2-1 Call Termination Without Tag Parameter (Exception Case)

1. The MSCe sends a Paging Request message without a Tag parameter.8

2. The SNSF forwards the Paging Request message to the BSC.9

3. The BSC returns a Paging Response message without the Tag parameter to the SNSF as the10corresponding Paging Request message contained no Tag parameter.

4. The SNSF selects an MSCe by the IMSI as no Tag parameter included in the received message and12sends the Paging Response message to the MSCe.

Note: In this call flow it is assumed the same MSCe is selected. If the same MSCe is not selected, it

will not be possible to progress the call termination, and step 5 will not occur.

5. For the subsequent procedures, please refer to section 2.3.1.16

2.4 Handoff18

This section describes the call flows associated with handoff of the MS in the MSC Pool.19

2.4.1 Handoff Intra-MSC Pool20

This scenario describes the call flow for handoff within a PA. In this scenario, the target BS (BSC2) is

connected to the MSC Pool by means of a different SNSF (SNSF2) from that which connects the source

BS (BSC1) to the MSC Pool.

21

22

23

7/30/2019 TIA-1180_Final

31/38

TIA-1180

2-7

BSC1 SNSF1 MSCe

3. Handoff Request

4. Handoff Request

BSC2 SNSF2

2. Handoff Required

5. Handoff Request Ack

7. Handoff Comm and

8. Handoff Command

1. Handoff Required

6. Handoff Request Ack

1

2

10

11

12

14

15

16

17

20

22

23

Figure 2.4.1-1 Handoff Intra-MSC Pool

1. Based on an MS report that it crossed a network specified threshold for signal strength or for other3reasons, the source BS recommends a hard handoff to one or more cells in the domain of the target4

BS. The source BS (BSC1) sends a Handoff Required message with the list of cells toward the MSCe.5

2. The SNSF (SNSF1) forwards the Handoff Required message from BSC1 to the MSCe based on the6NRI derived from the existing SCCP/SUA connection (i.e., destination Local Reference of SCCP7

DT1/SUA CODT message).8

3. The MSCe sends a Handoff Request message to the SNSF that is associated with the target BS9(SNSF2) and includes its NRI in the source Local Reference of the SCCP CR/SUA CORE message.

(In this case, the SNSF associated with the source BS is different from the SNSF that is associated

with the target BS.)

4. SNSF2 forwards the Handoff Request message to the target BS (BSC2). Upon receipt of the Handoff13Request message, the target BS allocates the appropriate radio resources as specified in the message

and connects the call. As the Handoff Request message can have multiple cell(s) specified, the target

BS can also choose to set up multiple cell(s) for the handoff request. The target BS sends null forwardtraffic channel frames to the MS.

5. The target BS sends a Handoff Request Acknowledge (SCCP CC/SUA COAK) message to SNSF2.18

6. SNSF2 locates the MSCe by the derived NRI and sends the Handoff Request Acknowledge message19to the MSCe.

7. The MSCe prepares to switch the MS from the source BS to the target BS and sends a Handoff21Command message to the SNSF (SNSF1) and includes its NRI in the source Local Reference of the

SCCP DT1/SUA CODT message.

8. SNSF1 forwards the Handoff Command to BSC1.24

2.4.2 Handoff Between MSC Pool and Non-MSC Pool MSCes25

The normal IOS handoff procedure is re-used in MSC Pool. It is assumed that each MSC within the MSC

Pool has the necessary provisioning and network connectivity to be able to perform inter-MSC handoff

signaling with neighbor MSCs outside the pool.

26

27

28

29

7/30/2019 TIA-1180_Final

32/38

TIA-1180

2-8

2.5 Facility Management1

This section describes the call flows associated with facility management messaging in the MSC Pool.2

2.5.1 Uplink Facility Management Messages3

This scenario describes the call flow for Uplink Facility Management in an MSC Pool. It is noted that

only the Block scenario is illustrated and the same principle can be applied to other uplink facility

management messages.

4

5

6

BSC SNSF MSCe

1. Block (CIC)

3. Block Acknowledge (CIC)

2. Block (CIC)

4. Block Acknowledge (CIC)

7

8

11

Figure 2.5.1-1 Uplink Facility Management Messages

1. The BSC sends a Block message to the SNSF.9

2. The SNSF sends the Block message to the MSCe according to the circuit identifier (CIC) of the Block10message and the source signaling point code from the SCCP layer.

3. The MSCe returns the Block Acknowledge response message to the SNSF.12

4. The SNSF sends the Block Acknowledge message to the BSC.13

2.5.2 Downlink Facility Management Messages14

This scenario describes the call flow for Downlink Facility Management in an MSC Pool. It is noted that

only the Reset Circuit scenario is illustrated and the same principle can be applied to other downlink

facility management messages.

15

16

17

BSC SNSF MSCe

3. Reset Circuit Acknowledge (CIC)

2. Reset Circuit (CIC)

4. Reset Circuit Acknowledge (CIC)

1. Reset Circuit (CIC)

18

19

24

Figure 2.5.2-1 Downlink Facility Management Messages

1. The MSCe sends a Reset Circuit message to the SNSF.20

2. The SNSF sends the Reset Circuit message to the BSC.21

3. The BSC sends a Reset Circuit Acknowledge message to the SNSF.22

4. The SNSF sends the Reset Circuit Acknowledge message to the MSCe according to the CIC of the23Reset Circuit Acknowledge message and the source signaling point code from the SCCP layer.

7/30/2019 TIA-1180_Final

33/38

TIA-1180

2-9

2.5.3 Uplink Reset Message1

This scenario describes the call flow for the uplink Reset message in an MSC Pool. This scenario can be

applied to both A1 and A1p Reset messages.

2

3

BSC SNSF MSCe2

1. Reset

5. Reset Acknowledgement

2. Reset

3. Reset Acknowledement

MSCe1

4. Reset


4

5

11

Figure 2.5.3-1 Uplink Reset Message

1. The BSC sends a Reset message to the SNSF.6

2. The SNSF sends the Reset message to the MSCe1, the first entrance of MSCe list in this example7against its configuration.8

3. The MSCe1 returns a Reset Acknowledge message to the SNSF.9

4. The SNSF sends the Reset message to the MSCe2 the last entrance of MSCe list in this example10against its configuration.

5. The MSCe2 returns a Reset Acknowledge message to the SNSF.12

6. The SNSF sends the Reset Acknowledge message to the BSC.13

2.5.4 Downlink Reset Message14

This scenario describes the call flow for the downlink Reset message in an MSC Pool. This scenario canbe applied to both A1 and A1p Reset messages.

15

16

BSC SNSF MSCe2

5. Flash with Info


1. Reset

MSCe1

4. CM Service Request

3. CM Service Request

6. SCCP/SUA inactivity testTr expires

17

18 Figure 2.5.4-1 Downlink Reset Message

1. MSCe1 sends a Reset message to the SNSF that is intended for delivery to a particular BSC.19

7/30/2019 TIA-1180_Final

34/38

TIA-1180

2-10

10

12

13

14

15

16

2. The SNSF sends a Reset Ack message to MSCe1. The SNSF starts timer Tr so that the target BSC1

may release affected resources by means of the SCCP/SUA connection release mechanism (i.e.,2

inactivity test).3

3. In case the SNSF receives a new service request (e.g., CM Service Request message) before timer Tr4

expires, the SNSF shall regard MSCe1 as unavailable.5

4. The SNSF routes the new service request message to another MSCe (i.e., MSCe2 in this example) in6 the pool according to the normal load distribution procedure.7

5. If, before timer Tr expires, the SNSF receives from a BSC a message in the context of a current8

SCCP/SUA connection (e.g., Flash with Information) that would otherwise be routed to MSCe1, the9

SNSF discards the received message.

6. While timer Tr is running, active SCCP/SUA connections at the target BSC are released by means of11

the SCCP/SUA inactivity test mechanism.

Note: In case the SNSF receives an uplink signaling message after timer T r expires, the SNSF shall

regard MSCe1 as available again and shall route the message to a selected serving MSCe (MSCe1, in

this example) according to the normal load distribution procedure.

7/30/2019 TIA-1180_Final

35/38

TIA-1180

A-1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

Annex A MSCe Selection Method Based on IMSI (Informative)1

This annex applies to the protocol-based MSC Pool solution.

When the Network Reference Identifier is not available, the SNSF uses another means to select an MSCe.

For example, if the A1/A1p connection establishment message and A1/A1p connectionless request

message doesnt include the NRI, the SNSF may derive the IMSI from those messages and use the

method described herein to select an MSCe.

First of all, the IMSI is converted to a Token No. according to the equation as follows.

Token No. = IMSI modulo N,

Where

IMSI is the decimal value of IMSI.

N is the total number of the Tokens for a given MSC Pool (e.g., 1000).

A Token denotes a certain number of MSs to be severed by a MSCe. Those MSs are grouped together. In

a given PA, each Token is allocated to only one MSCe while one MSCe can serve multiple Tokens of MS.

All Tokens are allocated to M MSCes where M denotes the number of MSCes in the MSC Pool. Each

SNSF maintains a configuration table with the same content. The following is an example of theconfiguration table.

Token No. MSCe ID Signaling Address

0~399 1 123

400~599 2 124

900~999 M xyz

18

19

20

21

22

23

24

25

29

30

31

32

33

When an SNSF uses the IMSI to select an MSCe, the MSCe ID is obtained by looking up the

configuration table with the Token No. converted from the IMSI. After the MSCe ID is determined, the

SNSF can route the message to the MSCe by its signaling address configured against the MSCe ID.

All SNSFs in a given MSC Pool use the same selection method and are configured with the same

configuration table, which guarantees the same MSCe being selected for a given subscriber when the

subscriber roams between different SNSF within the PA.

Load Redistribution happens in following scenarios:

The MSCe in the MSC Pool breaks down26

The MSCe goes out of service for maintenance27

If load balance is enabled, when load redistribution conditions are met28

Load redistribution is achieved via re-allocate those Tokens belonging to the affected MSCe to remaining

MSCes in the PA. The OM&P updates all SNSF configuration tables. If load balance is required, the

OM&P monitors the load of each MSCe in the PA and makes the decision to perform load balancing.

How the OM&P monitors an MSCes load and how the OM&P updates an SNSFs configuration table

are out of the scope of this standard.

7/30/2019 TIA-1180_Final

36/38

TIA-1180

A-2

1

2

3

4

5


7/30/2019 TIA-1180_Final

37/38

7/30/2019 TIA-1180_Final

38/38