Interoperability Specification (IOS) for MSC Pool Network

TIA-1180

March 2010

NOTICE TIA Engineering Standards and Publications are designed to serve the public interest through eliminating misunderstandings between manufacturers and purchasers, facilitating interchangeability and improvement of products, and assisting the purchaser in selecting and obtaining with minimum delay the proper product for their particular need. The existence of such Standards and Publications shall not in any respect preclude any member or non-member of TIA 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 or Publication. This Standard does not purport to address all safety problems associated with its use or all applicable 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 ASSOCIATION Standards 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.

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 copyright permission 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 a license agreement. For information, contact: IHS 15 Inverness Way East Englewood, CO 80112-5704 or call U.S.A. and Canada (1-800-525-7052) International (303-790-0600)

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 or optional elements (as defined in the TIA Engineering Manual, 4th 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 OR APPROPRIATENESS 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.

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.

Revision History Date December 2009 Publication A.S0018-0 v1.0 Description Initial revision. For features supported, refer to section 1.1.

1 2 3 4

(This page intentionally left blank)

TIA-1180
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 1.1 1.1.1 1.1.2 1.1.3 1.2 1.2.1 1.2.2 1.3 1.3.1 1.3.2 1.4 1.4.1 Introduction...................................................................................................................................1-1 Overview.......................................................................................................................................1-1 Purpose..........................................................................................................................................1-1 Scope.............................................................................................................................................1-1 Document Convention ..................................................................................................................1-1 References.....................................................................................................................................1-1 Normative References...................................................................................................................1-1 Informative References.................................................................................................................1-2 Terminology..................................................................................................................................1-2 Acronyms......................................................................................................................................1-2 Definitions ....................................................................................................................................1-3 MSC Pool Network IOS Architecture Reference Model..............................................................1-3 Protocol-based MSC Pool Network IOS Architecture Reference Model.....................................1-3 1.4.1.1 1.4.1.2 1.4.2 1.5 1.6 1.6.1 1.6.2 1.6.3 1.6.4 1.6.5 1.7 1.8 2 2.1 2.1.1 2.1.2 2.2 2.2.1 2.2.2 2.3 1.4.2.1 Protocol-based MSC Pool Interfaces ..........................................................................1-4 Protocol-based MSC Pool Architectural Principles....................................................1-5 OA&M-based MSC Pool Architectural Principles .....................................................1-6

OA&M-based MSC Pool Network IOS Architecture Reference Model ......................................1-5 Assumptions..................................................................................................................................1-6 Protocol-based MSC Pool Feature Description ............................................................................1-6 MSC Pool Network Concepts.......................................................................................................1-6 Load Distribution ..........................................................................................................................1-6 Network Reference Identifier .......................................................................................................1-9 Load Redistribution ......................................................................................................................1-9 A1p Security ...............................................................................................................................1-10 OA&M-based MSC Pool Feature Description ...........................................................................1-10 Compatibility with IOS Standards ..............................................................................................1-10 Signaling Flows for Protocol-based MSC Pool ............................................................................2-1 Registration ...................................................................................................................................2-1 Normal Registration......................................................................................................................2-1 Registration After Re-distribution MS Initiated ........................................................................2-2 Call Origination ............................................................................................................................2-3 Call Origination (Normal Case)....................................................................................................2-3 Call Origination After Re-distribution..........................................................................................2-4 Call Termination ...........................................................................................................................2-5

TIA-1180
1 2 3 4 5 6 7 8 9 10 11 12

2.3.1 2.3.2 2.4 2.4.1 2.4.2 2.5 2.5.1 2.5.2 2.5.3 2.5.4

Call Termination (Normal Case) ..................................................................................................2-5 Call Termination Without Tag Parameter (Exception Case) ........................................................2-6 Handoff .........................................................................................................................................2-6 Handoff Intra-MSC Pool...............................................................................................................2-6 Handoff Between MSC Pool and Non-MSC Pool MSCes ...........................................................2-7 Facility Management ....................................................................................................................2-8 Uplink Facility Management Messages........................................................................................2-8 Downlink Facility Management Messages ...................................................................................2-8 Uplink Reset Message...................................................................................................................2-9 Downlink Reset Message..............................................................................................................2-9 MSCe Selection Method Based on IMSI (Informative)......................................................... A-1

Annex A

ii

TIA-1180

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 Figure 1.4.1-2 Figure 1.4.2-1 Figure 1.6.3-1 Figure 1.6.3-2 Figure 2.1.1-1 Figure 2.1.2-1 Figure 2.2.1-1 Figure 2.2.2-1 Figure 2.3.1-1 Figure 2.3.2-1 Figure 2.4.1-1 Figure 2.5.1-1 Figure 2.5.2-1 Figure 2.5.3-1 Figure 2.5.4-1 Protocol-based MSC Pool Network Arch. Reference Model for A1/A2 Interfaces (LMSD Step 1) ............................................................................................1-4 Protocol-based MSC Pool Network Arch. Reference Model for A1p/A2p Interfaces (LMSD Step 2) ............................................................................................1-4 OA&M-based MSC Pool Network IOS Architecture Reference Model......................1-5 Identification of NRI within Tag IE .............................................................................1-9 Identification of NRI within Local Reference ..............................................................1-9 Normal Registration .....................................................................................................2-1 Registration After Re-distribution MS Initiated ........................................................2-2 Call Origination (Normal Case)....................................................................................2-3 Call Origination After Re-distribution..........................................................................2-4 Call Termination (Normal Case) ..................................................................................2-5 Call Termination Without Tag Parameter (Exception Case)........................................2-6 Handoff Intra-MSC Pool ..............................................................................................2-7 Uplink Facility Management Messages........................................................................2-8 Downlink Facility Management Messages...................................................................2-8 Uplink Reset Message ..................................................................................................2-9 Downlink Reset Message .............................................................................................2-9

iii

TIA-1180

1 2 3 4 5 6

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

iv

TIA-1180

1 2 3 4 5 6 7 8 9 10 11

Foreword
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.

TIA-1180

1 2 3 4

(This page intentionally left blank)

vi

TIA-1180

1 2 3

Introduction

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

4 5 6 7 8 9 10 11 12

1.1

Overview

This document includes a description of the interface protocols and procedures to support the following features and functions. Features and functions explicitly supported in this standard: MSC Pool network concepts Load Distribution Network Reference Identifier format Load Redistribution A1p Security considerations with MSC Pool 1.1.1 Purpose

13 14 15

The purpose of this document is to provide the architecture (distribution of functions), protocols and procedures to support the MSC Pool feature. 1.1.2 Scope

16 17 18 19 20

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 [2] and LMSD Step 2 per X.S0025 [3]. 1.1.3 Document Convention

21 22 23 24 25 26 27 28

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.

29 30 31 32

1.2

References

References are either normative or informative. A normative reference is used to include another document as a mandatory part of a 3GPP2 specification. Documents that provide additional non-essential information are included in the informative references section. 1.2.1 Normative References

33 34 35 36 37 38

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.

1-1

TIA-1180
1 2 3 4 5 6

[1] [2] [3] [4]

3GPP2: A.S0014-D v2.0, Interoperability Specification (IOS) for cdma2000 Access Network Interfaces Part 4 (A1, A1p, A2, and A5 Interfaces), August 2009. 3GPP2: X.S0012-0 v2.0, Legacy MS Domain Step 1, March 2004. 3GPP2: X.S0025-0 v1.0, Legacy MS Domain Step 2, February 2006. ITU-T: H.248.1, Gateway Control Protocol: Version 3, September 2005.

7 8 9

1.2.2 None.

Informative References

10 11

1.3

Terminology

This section contains definitions, symbols and abbreviations that are used throughout the document. 1.3.1 Acronyms 3rd Generation Partnership Project 2 Base Station Base Station Controller Base Station Management Application Part Circuit Identity Code Core Network Direct Transfer Application Part Home Location Register Information Element International Mobile Subscriber Identity Interoperability Specification Legacy MS Domain Media Gateway Mobile Station Mobile Switching Center Mobile Switching Center Emulator Network Reference Identifier Operations, Administration, and Maintenance Pool Area Radio Access Network Signaling Connection Control Part Serving Node Selection Function Signaling Connection Control Part User Adaptation Layer

12

3GPP2 BS BSC BSMAP CIC CN DTAP HLR IE IMSI IOS LMSD MGW MS MSC MSCe NRI OA&M PA RAN SCCP SNSF SUA
13

1-2

TIA-1180
1

1.3.2

Definitions

2 3

MSC Pool Network

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.

22 23 24 25

1.4

MSC Pool Network IOS Architecture Reference Model

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. 1.4.1 Protocol-based MSC Pool Network IOS Architecture Reference Model

26 27 28 29 30

MSC Pool messaging and call flows are based on the architecture reference models in Figure 1.4.1-1 and 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.

1-3

TIA-1180
A1p A2p

BSC

MGW MSC Pool Area

39

MSCe

27

MGW SNSF

39 48

MSCe

BSC

48

BSC
1 2 3

A1 A2

MSC

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

BSC

A1p A2p

MGW MSC Pool Area MGW

39

MSCe

zz

A2p

39 A1p

MSCe

BSC

A1p

SNSF

BSC
4 5 6

A1 A2

MSC

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

7 8

9 10 11

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.

1-4

TIA-1180
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

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. 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]. 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]. 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. 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.

39

zz 27

48

16 17

1.4.1.2

Protocol-based MSC Pool Architectural Principles

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. Virtual MGW capabilities are supported, at the option of the network operator. A BSC shall connect with one or more SNSFs. An SNSF shall connect with all the MSCes within the PA. All MSCes within the PA are assumed to be configured as Border MSCes of each other. OA&M-based MSC Pool Network IOS Architecture Reference Model

18 19 20 21 22

23 24 25

1.4.2

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

OA&M OA&M

Operations, Administration, and Maintenance

MSCe

MSCe

MGW

MGW

OA&M

IP

BS
26 27

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

1-5

TIA-1180
1

2 3 4 5 6 7 8

1.4.2.1

OA&M-based MSC Pool Architectural Principles

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. OA&M coordination dynamically moves a BS from one MSCe to a different MSCe. The interactions between the OA&M function and the BS and MSCe are outside the scope of this specification.

9 10 11 12

1.5

Assumptions

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

13 14

1.6

Protocol-based MSC Pool Feature Description

15 16 17 18 19

1.6.1

MSC Pool Network Concepts

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. 1.6.2 Load Distribution

20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

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. 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 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 shall route the message to the Selected Serving MSCe according to the NRI embedded in the Tag IE.

1-6

TIA-1180
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 37 38 39 40 41

If the MSCe triggers the MS to setup the signaling path (e.g., Call Termination) or the MSCe triggers a connectionless signaling transaction between the MSCe and the MS (e.g., Paging Request or Feature Notification), the MSCe shall include the NRI in the request message. The BSC shall include the same Tag IE in the corresponding response message. The SNSF shall derive the NRI from the response message and forward the response message to the Selected Serving MSCe according to the NRI. 3. If the SNSF can not derive NRI from the uplink A1/A1p message, the SNSF shall examine the IMSI to select an MSCe. If the MS sends a connectionless request message (e.g., data burst request) or a signaling path establishment request message (e.g., call origination request) toward the network, the 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 (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 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 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
Message Name Additional Service Request ADDS Deliver ADDS Deliver Ack ADDS Page Ack SUA Message CODT CODT CODT CLDT

NRI Source for A1p Uplink Messages

Source of the NRI SUA LR SUA LR SUA LR TAG Message Discriminator DTAP DTAP DTAP BSMAP

1-7

TIA-1180

Message Name ADDS Transfer Assignment Complete Assignment Failure Authentication Report Authentication Response Base Station Challenge Bearer Update Required Bearer Update Response BS Authentication Request BS Security Mode Request BS Service Request Clear Complete Clear Request CM Service Request CM Service Request Continuation Connect Event Notification Ack Feature Notification Ack Flash with Information Flash with Information Ack Handoff Commenced Handoff Complete Handoff Failure Handoff Performed Handoff Request Acknowledge Handoff Required Location Updating Request PACA Command Ack PACA Update PACA Update Ack Paging Response Parameter Update Confirm Privacy Mode Complete Radio Measurements for Position Response Rejection Reset Reset Ack

SUA Message CLDT CODT CODT CODT CODT CLDT CODT CODT CODT CODT CLDT CLDT CODT CODT CORE CODT CODT CLDT CLDT CODT CODT CODT CODT COREF CODT COAK CODT CORE CODT CLDT CLDT CORE CODT CODT CODT CODT CLDT CLDT CLDT

Source of the NRI IMSI SUA LR SUA LR SUA LR SUA LR TAG SUA LR SUA LR SUA LR SUA LR IMSI IMSI SUA LR SUA LR IMSI SUA LR SUA LR IMSI TAG SUA LR SUA LR SUA LR SUA LR SUA LR SUA LR SUA LR SUA LR IMSI SUA LR IMSI IMSI TAG SUA LR SUA LR SUA LR SUA LR TAG <none>
1

Message Discriminator BSMAP BSMAP BSMAP DTAP DTAP BSMAP DTAP BSMAP BSMAP BSMAP BSMAP BSMAP BSMAP BSMAP DTAP DTAP DTAP BSMAP BSMAP DTAP DTAP BSMAP BSMAP BSMAP BSMAP BSMAP BSMAP DTAP BSMAP BSMAP BSMAP DTAP DTAP BSMAP BSMAP DTAP BSMAP BSMAP BSMAP

<Layer 3 Address>

1-8

TIA-1180

Message Name Security Mode Response Service Release Service Release Complete SSD Update Response Status Response User Zone Update Request
1

SUA Message CODT CLDT CODT CODT CODT CODT CLDT CODT

Source of the NRI SUA LR TAG SUA LR SUA LR SUA LR SUA LR TAG SUA LR

Message Discriminator DTAP BSMAP DTAP DTAP DTAP DTAP BSMAP DTAP

Note 1: The NRI concept does not apply for the Reset message. 1.6.3 Network Reference Identifier

2 3 4 5 6 7 8 9

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. 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 NRI 5 Tag: 4 3 2 1 0 Octet 1 2 3 4 5

A1 Element Identifier

10

Figure 1.6.3-1 Identification of NRI within Tag IE 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

11 12 13

NRI
14

Figure 1.6.3-2 Identification of NRI within Local Reference 1.6.4 Load Redistribution

15 16 17 18 19 20 21 22

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

1-9

TIA-1180
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 6 7 8

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.

9 10 11 12

1.7

OA&M-based MSC Pool Feature Description

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.

13 14 15 16 17 18

1.8

Compatibility with IOS Standards

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

1-10

TIA-1180

1 2 3 4 5

Signaling Flows for Protocol-based MSC Pool

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] and X.S0025 [3] for those signaling messages and message sequences.

6 7

2.1

Registration

This section describes the call flows associated with MS registration in the MSC Pool. 2.1.1 Normal Registration

8 9

This scenario describes the call flow for normal registration in an MSC Pool.
BSC SNSF MSCe

1. Location U pdating R equest (IM S I) 2. Location U pdating R equest (IM S I) 3. Location U pdating A ccept 4. Location U pdating A ccept
10 11

Figure 2.1.1-1 Normal Registration 1. The SNSF receives a Location Updating Request message from the BSC. 2. The SNSF selects an MSCe as the Selected Serving MSCe based on the MSCe selection method, 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 signaling point contained in the Location Updating Request message. 4. The SNSF forwards the Location Updating Accept message to the BSC.

12 13 14 15 16 17 18 19

2-1

TIA-1180

1 2 3

2.1.2

Registration After Re-distribution MS Initiated

This scenario describes the call flow for registration after load re-distribution. It includes periodic registration and power off registration.
BSC SNSF H LR M S C e1 M S C e2

1. M S C e1 is off-loaded and O M & P instructs S N S F to initiate load re -distribution 2. Location U pdating R equest (IM S I) 3. Location U pdating R equest (IM S I) 4. R E G N O T (IM S I) 5. R E G C A N C (IM S I) 6. regcanc 7. regnot (M D N , P rofile) 8. Location U pdaing A ccept 9. Location U pdaing A ccept
4 5

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 redistribution has been initiated and the MS is in idle state when the event occurs. 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. 3. The SNSF allocates MSCe2 as the serving MSCe according to the MSCe selection algorithm with 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 includes the IMSI. 5. The HLR sends a REGCANC message to MSCe1 to cancel location, the message includes the IMSI. 6. MSCe1 acknowledges the HLR by sending a regcanc message. 7. HLR sends a regnot message to MSCe2 to push the subscribers profile to MSCe2. 8. MSCe2 returns a Location Updating Accept message to the SNSF according to the source signaling point contained in the Location Updating Request message. 9. The SNSF forwards the Location Updating Accept message to the BSC.

6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

2-2

TIA-1180
1 2

2.2

Call Origination

This section describes the call flows associated with MS call origination in the MSC Pool. 2.2.1 Call Origination (Normal Case)

3 4

This scenario describes the call flow for call origination in an MSC Pool.
BSC 1. C M S ervice R equest (IM S I) 2. C M S ervice R equest (IM S I) 3. A ssignm ent R equest (N R I) 3. A ssignm ent R equest (N R I) 5. A ssignm ent C om plete (N R I) 6. A ssignm ent C om plete (N R I) SNSF MSCe

5 6

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. 2. SNSF selects the Selected Serving MSCe based on the MSCe selection algorithm, using IMSI as the input. Then the SNSF forwards the CM Service Request message to the selected MSCe. 3. The MSCe sends an Assignment Request message to the SNSF according to the source signaling 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. 5. The BSC assign radio resource for the MS and returns an Assignment Complete message to the SNSF. 6. The SNSF forwards this and subsequent messages from the BSC to the MSCe based on the NRI derived from the existing SCCP/SUA connection (i.e., destination Local Reference of SCCP DT1/SUA CODT messages).

7 8 9 10 11 12 13 14 15 16 17 18

2-3

TIA-1180
1 2

2.2.2

Call Origination After Re-distribution

This scenario describes the call flow for call origination after load re-distribution.
BSC SNSF H LR M S C e1 M S C e2

1. M S C e1 is out of service and O M & P instructs S N S F to initiate load re -distribution 2. C M S ervice R equest (IM S I) 3. C M S ervice R equest (IM S I) 4. R E G N O T (IM S I) 5. R E G C A N C (IM S I) 6. regcanc 7. regnot (M D N , P rofile) 8. A ssignm ent R equest (N R I) 9. A ssignm ent R equest (N R I)
3 4

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. Re-distribution has been initiated and the MS is in idle state when the event occurs. 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 IMSI. 3. The SNSF selects MSCe2 as the Selected Serving MSCe as the configuration of the SNSF has been 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 includes the IMSI. 5. The HLR sends a REGCANC message to MSCe1 to cancel location, the message includes the IMSI. 6. MSCe1 acknowledges the HLR by sending a regcanc message. 7. The HLR sends a regnot message to MSCe2 to push the subscribers profile to MSCe2. 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 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 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).

5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

2-4

TIA-1180
1 2

2.3

Call Termination

This section describes the call flows associated with paging the MS in the MSC Pool. 2.3.1 Call Termination (Normal Case)

3 4

This scenario describes the call flow for call termination in an MSC Pool Area.
BSC SNSF 1. P aging R equest (N R I-1) 2. P aging R equest (N R I-1) 3. P aging R esponse (N R I-1) 4. P aging R esponse 5. A ssignm ent R equest (N R I-2) 6. A ssignm ent R equest (N R I-2) 7. A ssignm ent C om plete (N R I-2) 8. A ssignm ent C om plete 9. C onnect (N R I-2) 10 C onnect MSCe

5 6

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., NRI-1) to the SNSF according to the LAC of the MS. 2. The SNSF forwards the Paging Request message to the BSC. 3. The BSC returns a Paging Response message with the same Tag parameter to the SNSF. The SNSF 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 MSCe. 5. The MSCe sends an Assignment Request message to the SNSF and includes its NRI (i.e., NRI-2) in 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. 7. The BSC assigns radio resources for the MS and returns the Assignment Complete message with the NRI-2 to the SNSF. 8. The SNSF forwards the Assignment Complete message to the MSCe based on the NRI derived from 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 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 SCCP/SUA connection (i.e., destination Local Reference of the SCCP DT1/SUA CODT messages).

7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

2-5

TIA-1180
1 2 3 4 5

2.3.2

Call Termination Without Tag Parameter (Exception Case)

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.
BSC SNSF 1. P aging R equest (no Tag IE ) 2. P aging R equest (no Tag IE ) 3. P aging R esponse (IM S I) 4. P aging R esponse 5. N orm al call term ination procedures. MSCe

6 7

Figure 2.3.2-1 Call Termination Without Tag Parameter (Exception Case) 1. The MSCe sends a Paging Request message without a Tag parameter. 2. The SNSF forwards the Paging Request message to the BSC. 3. The BSC returns a Paging Response message without the Tag parameter to the SNSF as the 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 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.

8 9 10 11 12 13 14 15 16 17

18 19

2.4

Handoff

This section describes the call flows associated with handoff of the MS in the MSC Pool. 2.4.1 Handoff Intra-MSC Pool

20 21 22 23

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.

2-6

TIA-1180

BSC1

BSC2

S N S F1

S N S F2

MSCe

1. H andoff R equired 2. H andoff R equired 3. H andoff R equest 4. H andoff R equest 5. H andoff R equest A ck 6. H andoff R equest A ck 7. H andoff C om m and 8. H andoff C om m and
1 2

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 reasons, the source BS recommends a hard handoff to one or more cells in the domain of the target BS. The source BS (BSC1) sends a Handoff Required message with the list of cells toward the MSCe. 2. The SNSF (SNSF1) forwards the Handoff Required message from BSC1 to the MSCe based on the NRI derived from the existing SCCP/SUA connection (i.e., destination Local Reference of SCCP DT1/SUA CODT message). 3. The MSCe sends a Handoff Request message to the SNSF that is associated with the target BS (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 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. 6. SNSF2 locates the MSCe by the derived NRI and sends the Handoff Request Acknowledge message to the MSCe. 7. The MSCe prepares to switch the MS from the source BS to the target BS and sends a Handoff 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. 2.4.2 Handoff Between MSC Pool and Non-MSC Pool MSCes

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

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.

2-7

TIA-1180
1 2

2.5

Facility Management

This section describes the call flows associated with facility management messaging in the MSC Pool. 2.5.1 Uplink Facility Management Messages

3 4 5 6

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.
BSC SNSF MSCe

1. B lock (C IC ) 2. B lock (C IC ) 3. B lock A cknow ledge (C IC ) 4. B lock A cknow ledge (C IC )

7 8

Figure 2.5.1-1 Uplink Facility Management Messages 1. The BSC sends a Block message to the SNSF. 2. The SNSF sends the Block message to the MSCe according to the circuit identifier (CIC) of the Block message and the source signaling point code from the SCCP layer. 3. The MSCe returns the Block Acknowledge response message to the SNSF. 4. The SNSF sends the Block Acknowledge message to the BSC. 2.5.2 Downlink Facility Management Messages

9 10 11 12 13

14 15 16 17

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.
BSC SNSF MSCe

1. R eset C ircuit (C IC ) 2. R eset C ircuit (C IC ) 3. R eset C ircuit A cknow ledge (C IC ) 4. R eset C ircuit A cknow ledge (C IC )
18 19

Figure 2.5.2-1 Downlink Facility Management Messages 1. The MSCe sends a Reset Circuit message to the SNSF. 2. The SNSF sends the Reset Circuit message to the BSC. 3. The BSC sends a Reset Circuit Acknowledge message to the SNSF. 4. The SNSF sends the Reset Circuit Acknowledge message to the MSCe according to the CIC of the Reset Circuit Acknowledge message and the source signaling point code from the SCCP layer.

20 21 22 23 24

2-8

TIA-1180
1 2 3

2.5.3

Uplink Reset Message

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.
BSC SNSF M S C e1 M S C e2

1. R eset 2. R eset 3. R eset A cknow ledem ent 4. R eset 5. R eset A cknow ledgem ent 6. R eset A cknow ledgem ent
4 5

Figure 2.5.3-1 Uplink Reset Message 1. The BSC sends a Reset message to the SNSF. 2. The SNSF sends the Reset message to the MSCe1, the first entrance of MSCe list in this example against its configuration. 3. The MSCe1 returns a Reset Acknowledge message to the SNSF. 4. The SNSF sends the Reset message to the MSCe2 the last entrance of MSCe list in this example against its configuration. 5. The MSCe2 returns a Reset Acknowledge message to the SNSF. 6. The SNSF sends the Reset Acknowledge message to the BSC. 2.5.4 Downlink Reset Message

6 7 8 9 10 11 12 13

14 15 16

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.
BSC SNSF M S C e1 M S C e2

1. R eset 2. R eset A cknow ledgem ent 3. C M S ervice R equest 4. C M S ervice R equest 5. Flash w ith Info 6. S C C P/S U A inactivity test

Tr 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

2-9

TIA-1180
1 2 3 4 5 6 7 8 9 10 11 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 may release affected resources by means of the SCCP/SUA connection release mechanism (i.e., inactivity test). 3. In case the SNSF receives a new service request (e.g., CM Service Request message) before timer Tr expires, the SNSF shall regard MSCe1 as unavailable. 4. The SNSF routes the new service request message to another MSCe (i.e., MSCe2 in this example) in the pool according to the normal load distribution procedure. 5. If, before timer Tr expires, the SNSF receives from a BSC a message in the context of a current SCCP/SUA connection (e.g., Flash with Information) that would otherwise be routed to MSCe1, the SNSF discards the received message. 6. While timer Tr is running, active SCCP/SUA connections at the target BSC are released by means of 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.

2-10

TIA-1180

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)

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 the configuration table.
Token No. 0~399 400~599 900~999 MSCe ID 1 2 M Signaling Address 123 124 xyz

18 19 20 21 22 23 24 25 26 27 28 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 The MSCe goes out of service for maintenance If load balance is enabled, when load redistribution conditions are met 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.

A-1

TIA-1180

1 2 3 4 5

(This page intentionally left blank)

A-2