Msc Pool Iot

© 2009, 3GPP2

3GPP2 and its Organizational Partners claim copyright in this document and individual Organizational Partners may copyright and issue documents or standards publications in individual Organizational Partner's name based on this document. Requests for reproduction of this document should be directed to the 3GPP2 Secretariat at [email protected]. Requests to reproduce individual Organizational Partner's documents should be directed to that Organizational Partner. See www.3gpp2.org for more information.

3GPP2 A.S0018-0 v1.0

December 2009

Interoperability Specification (IOS) for MSC Pool Network

Revision History

Date Publication Description

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

3GPP2 A.S0018-0 v1.0

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

3GPP2 A.S0018-0 v1.0

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

3GPP2 A.S0018-0 v1.0

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/A2 Interfaces (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-5

Figure 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

3GPP2 A.S0018-0 v1.0

iv

1

2

3

4

5

6

Table of Tables

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

3GPP2 A.S0018-0 v1.0

v

Foreword 1

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 document was 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.

3GPP2 A.S0018-0 v1.0

vi

1

2

3

4

(This page intentionally left blank)

3GPP2 A.S0018-0 v1.0

1-1

1 Introduction 1

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

2

3

1.1 Overview 4

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 concepts 8

Load Distribution 9

Network Reference Identifier format 10

Load Redistribution 11

A1p Security considerations with MSC Pool 12

1.1.1 Purpose 13

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 Scope 16

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 Convention 21

“Shall” and “shall not” identify requirements to be followed strictly to conform to the standard and from which 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 of action 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.

22

23

24

25

26

27

28

1.2 References 29

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 References 33

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

3GPP2 A.S0018-0 v1.0

1-2

2

6

[1] 3GPP2: A.S0014-D v2.0, Interoperability Specification (IOS) for cdma2000 Access Network 1

Interfaces – 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 References 7

None. 8

9

1.3 Terminology 10

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

1.3.1 Acronyms 12

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 Identity

IOS 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

3GPP2 A.S0018-0 v1.0

1-3

1.3.2 Definitions 1

MSC Pool Network 2

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

MSC Pool 4

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

Network Reference Identifier 6

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 MSCe 15

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 Model 22

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 Model 26

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

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 does not imply any particular physical implementation.

3GPP2 A.S0018-0 v1.0

1-4

SNSF

BSC

BSC

MSCe

MSCe

4848

A1p

MSC Pool Area

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

MSC Pool Area

zz

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 Interfaces 7

The interfaces defined in this specification are described as follows.

A1p Reference Point A1p is the packet signaling interface between the cdma2000®1 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.

3GPP2 A.S0018-0 v1.0

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 does not 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 Principles 16

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 the 20

PA.

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 Model 23

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

3GPP2 A.S0018-0 v1.0

1-6

1

3

8

1.4.2.1 OA&M-based MSC Pool Architectural Principles 2

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 this 6

specification. 7

1.5 Assumptions 9

1. MSC Pool SNSF operation is transparent to the messaging between the MSCe and BSC. The MSC 10

Pool feature makes no modifications to the 1x Interoperability Specification (IOS). 11

12

1.6 Protocol-based MSC Pool Feature Description 13

14

1.6.1 MSC Pool Network Concepts 15

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 Distribution 20

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 that 34

an 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 SNSF 41

shall route the message to the Selected Serving MSCe according to the NRI embedded in the Tag IE.

3GPP2 A.S0018-0 v1.0

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 triggers 1

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

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

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

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

NRI. 6

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

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

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

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 SNSF 13

(if the SNSF is not co-located with the BSC) shall respond immediately with a Reset Ack to the MSCe. 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 Tr is running, active SCCP/SUA connections at the target BSC are released by means of the SCCP/SUA inactivity test 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 the 24

BSC 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 Request 31

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

3GPP2 A.S0018-0 v1.0

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 DTAP Authentication 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 DTAP Rejection

CLDT TAG BSMAP

Reset CLDT <none>1 BSMAP

Reset Ack CLDT <Layer 3 Address> BSMAP

3GPP2 A.S0018-0 v1.0

1-9


CODT SUA LR DTAP Security 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 DTAP Status 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 Identifier 2

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 the NRI 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 IE 10

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 Reference 14

1.6.4 Load Redistribution 15

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.

3GPP2 A.S0018-0 v1.0

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 Security 5

The IOS RAN may be realized as a managed network. In this case, it is assumed that all interfaces are physically 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 Description 9

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 Standards 13

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.

3GPP2 A.S0018-0 v1.0

2-1

2 Signaling Flows for Protocol-based MSC Pool 1

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 Registration 6

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

2.1.1 Normal Registration 8

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, 13

using 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 source 16

signaling point contained in the Location Updating Request message.

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

3GPP2 A.S0018-0 v1.0

2-2

2.1.2 Registration After Re-distribution – MS Initiated 1

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. REGCANC (IMSI)


HLR

6. regcanc

9. Location Updaing Accept

8. Location Updaing Accept

7. regnot (MDN, Profile)


1. MSCe1 is off-loaded and OM &P instructs SNSF 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-6

distribution 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 the scope 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 with 13

updated 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 message 15

includes 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 subscriber’s profile to MSCe2. 19

8. MSCe2 returns a Location Updating Accept message to the SNSF according to the source signaling 20

point contained in the Location Updating Request message.

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

3GPP2 A.S0018-0 v1.0

2-3

2.2 Call Origination 1

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. Assignm ent Request (NRI)



5. Assignm ent Complete (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 the 8

input. 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 signaling 10

point 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 NRI 15

derived from the existing SCCP/SUA connection (i.e., destination Local Reference of SCCP DT1/SUA CODT messages).

3GPP2 A.S0018-0 v1.0

2-4

2.2.2 Call Origination After Re-distribution 1

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

BSC SNSF MSCe2

4. REGNOT (IMSI)

MSCe1

5. REGCANC (IMSI)


HLR

6. regcanc


8. Assignment Request (NRI)

7. regnot (MDN, Profile)


1. MSCe1 is out of service and OM &P instructs SNSF 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. 5

Re-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 the 10

IMSI.

3. The SNSF selects MSCe2 as the Selected Serving MSCe as the configuration of the SNSF has been 12

updated 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 message 15

includes 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 subscriber’s 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 point 21

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

9. The SNSF forwards the Assignment Request message to the BSC. Subsequent messages from the 24

BSC 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).

3GPP2 A.S0018-0 v1.0

2-5

2.3 Call Termination 1

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 (NRI-1)

5. Assignment Request (NRI-2)

4. Paging Response

6. Assignm ent Request (NRI-2)

7. Assignment Com plete (NRI-2)

8. Assignm ent Complete

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 SNSF 10

derives the NRI-1 from the Tag parameter.

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

MSCe.

5. The MSCe sends an Assignment Request message to the SNSF and includes its NRI (i.e., NRI-2) in 14

the 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 the 19

NRI-2 to the SNSF.

8. The SNSF forwards the Assignment Complete message to the MSCe based on the NRI derived from 21

the 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, includes 24

the 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 established 26

SCCP/SUA connection (i.e., destination Local Reference of the SCCP DT1/SUA CODT messages).

3GPP2 A.S0018-0 v1.0

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 MS’s IMSI.

2

3

4

5

BSC SNSF MSCe

1. Paging Request (no Tag IE)

2. Paging Request (no Tag IE)

3. Paging Response (IMSI)

4. Paging Response

5. Normal call term ination procedures. 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 the 10

corresponding 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 and 12

sends 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 Handoff 18

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

2.4.1 Handoff Intra-MSC Pool 20

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

3GPP2 A.S0018-0 v1.0

2-7

BSC1 SNSF1 MSCe

3. Handoff Request

4. Handoff Request

BSC2 SNSF2

2. Handoff Required

5. Handoff Request Ack

7. Handoff Com mand

8. Handoff Com mand

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 other 3

reasons, the source BS recommends a hard handoff to one or more cells in the domain of the target 4

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 the 6

NRI derived from the existing SCCP/SUA connection (i.e., destination Local Reference of SCCP 7

DT1/SUA CODT message). 8

3. The MSCe sends a Handoff Request message to the SNSF that is associated with the target BS 9

(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 Handoff 13

Request 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 forward traffic 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 message 19

to the MSCe.

7. The MSCe prepares to switch the MS from the source BS to the target BS and sends a Handoff 21

Command 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 MSCes 25

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

3GPP2 A.S0018-0 v1.0

2-8

2.5 Facility Management 1

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

2.5.1 Uplink Facility Management Messages 3

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 Block 10

message 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 Messages 14

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 the 23

Reset Circuit Acknowledge message and the source signaling point code from the SCCP layer.

3GPP2 A.S0018-0 v1.0

2-9

2.5.3 Uplink Reset Message 1

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 Acknowledgem ent

2. Reset

3. Reset Acknowledem ent

MSCe1

4. Reset

6. Reset Acknowledgement

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 example 7

against 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 example 10

against 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 Message 14

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

15

16

BSC SNSF MSCe2

5. Flash with Info

2. Reset Acknowledgem ent

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

3GPP2 A.S0018-0 v1.0

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 BSC 1

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 Tr 4

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) in 6

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 current 8

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

SNSF discards the received message.

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

the SCCP/SUA inactivity test mechanism.

Note: In case the SNSF receives an uplink signaling message after timer Tr 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.

3GPP2 A.S0018-0 v1.0

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 doesn’t 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 the configuration 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 down 26

The MSCe goes out of service for maintenance 27

If load balance is enabled, when load redistribution conditions are met 28

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 MSCe’s load and how the OM&P updates an SNSF’s configuration table are out of the scope of this standard.

3GPP2 A.S0018-0 v1.0

A-2

1

2

3

4

5

(This page intentionally left blank)