A30-20080825-xxx

1.1.1 TITLE:
MSC Pool Signaling flows.

SOURCE:
Zhiming Li Huawei Technologies
lizhiming@huawei.com
Xin Zhong Huawei Technologies
zhongxin@huawei.com
Zhaohui(Land) Zhang Huawei Technologies
spiderman@huawei.com

ABSTRACT:
This contribution proposes MSCe Pool signaling flows for Registration and Call Origination, Call termination
etc.

RECOMMENDATION:
For discussion and approval

Huawei Technologies grant a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other
copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright
and sell in Organizational Partner's name any Organizational Partner's standards publication even though it may include all or portions
of this contribution; and at the Organizational Partner's sole discretion to permit others to reproduce in whole or in part such
contribution or the resulting Organizational Partner's standards publication. Huawei Technologies are also willing to grant licenses
under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an
Organizational Partners standard which incorporates this contribution.

This document has been prepared by Huawei Technologies to assist the development of specifications by 3GPP2. It is proposed to the
Committee as a basis for discussion and is not to be construed as a binding proposal on Huawei Technologies. Huawei Technologies
specifically reserves the right to amend or modify the material contained herein and to any intellectual property of Huawei
Technologies other than provided in the copyright statement above.
3 Signaling Flows for MSC Pool
This section describes the interactions between network entities in various situations related to
MSC Pool. Signal messages between MSCe and HLR and message sequences shown in the message flows in
this document are informative only. Please refers to [x] for those signal messages and message sequence.

2

 A30-20080825-xxx

3.1 Registration

3.1.1 Normal registration

This scenario describes the call flow for normal registration of MSC Pool. The call flow illustrates
that two MSes with different IMSI, i.e. IMSI1 and IMSI2, register with two MSCes via the SNSF.

Figure 3.1.12-1 Normal Registration

a. The SNSF receives a Location Updating Request message from BSC.

b. The SNSF selects MSCe1 as the default MSCe based on the MSCe selection algorithm,
using IMSI1 as the input. Then the SNSF forwards the Location Updating Request
message to MSCe1
c. MSCe1 returns a Location Updating Accept message to the SNSF according to the source
signaling point contained in the Location Updating Request message.
d. The SNSF forwards the Location Updating Accept message to BSC.
e. The SNSF receives another Location Updating Request message from BSC.
f. The SNSF selects MSCe2 as the default MSCe based on the MSCe selection algorithm,
using IMSI2 as the input. Then the SNSF forwards the Location Updating Request
message to MSCe2
g. MSCe2 returns the Location Updating Accept message to the SNSF according to the
source signaling point contained in the Location Updating Request message.
h. SNSF forwards the Location Updating Accept message to BSC.

3.1.2 Registration after re-distribution-MS initiated

This scenario describes the call flow for registration after load re-distribution. It includes periodical
registration and power off registration.

3
 Figure 3.1.2-21 Registration after re-distribution- MS initiated

a. The default MSCe of an MS (e.g. MSCe1 in this case) is out of service for some reason.
The re-distribution has been initiated and the MS is in idle state when this the event
occurs.
Note: The redistribution is triggered by the OM&P system. The interaction between the
OM&P system and SNSF, and the interaction between the OM&P system and MSCe is
out of scope of this document.
b. The SNSF receives a timer based Location Updating request.
c. The SNSF allocates MSCe2 as the serving MSCe as the configuration of the SNSF has
been updated for re-distribution, and then forwards the Location Updating Request
message to MSCe2.
d. MSCe2 sends a REGNOT message to the HLR to request profile of the subscriber, the
message includes the IMSI.

4

 A30-20080825-xxx

e. The HLR sends a REGCANC message to MSCe1 to cancel location, the message
includes the IMSI.
f. MSCe1 acknowledge the HLR by sending a REGCNC message.
g. HLR sends a REGNOT message to MSCe2 to pushes subscribers profile to the MSCe2.
h. MSCe2 returns a Location Updating Accept message to the SNSF
i. The SNSF forwards the Location Updating Accept message to BSC.

5
3.2 De-Registration

1.2.1 De-Registration after re-distribution

Figure 3.1-2 Registration after re-distribution

a. The SNSF receives the Location Updating request for power off.
b. The SNSF allocates MSCe2 as the serving MSCe as the configuration of the SNSF has
been updated for re-distribution, and then forwards the Location Updating Request
message to MSCe2.
c. MSCe2 sends a REGNOT message to the HLR to request profile of the subscriber, the
message includes the IMSI and available type.
d. The HLR sends a REGCANC message to MSCe1 to cancel location, the message
includes the IMSI.
e. MSCe1 acknowledge the HLR by sending a REGCNC message.
f. HLR sends a REGNOT message to MSCe2 to pushes subscribers profile to the MSCe2.
g. MSCe2 returns a Location Updating Accept message to the SNSF
h. The SNSF forwards the Location Updating Accept message to BSC.

6

 A30-20080825-xxx

3.3 Call Origination

3.2.1 Call origination (normal case)
This scenario describes the call flow for call origination of MSC Pool.

Figure 3.32.1-2 Call Origination

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

7
 b. SNSF selects the default 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.
c. The MSCe sends an Assignment Request message to the SNSF
d. The SNSF forwards the Assignment Request message to the BSC.
e. The BSC assign radio resource for the MS and returns an Assignment Complete message
to the SNSF.
f. The SNSF forwards this and subsequent messages from the BSC to the MSCe based on
the existing SCCP connection.
g. MS releases the call. The SNSF receives a Clear Request message from the BSC
h. The SNSF forwards the Clear Request message to the MSCe on the established SCCP
connection.
i. The MSCe sends a Clear Command message to the SNSF.
j. The SNSF forwards the Clear Command message to the BSC.
k. The SNSF receives a Clear Complete message from the BSC
l. The SNSF forwards the Clear Complete message to the MSCe.

3.2.2 Call origination after re-distribution

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

Figure 3.2.2-1 Call Origination

8

 A30-20080825-xxx

a. The default MSCe of an MS(e.g. MSCe1 in this case) is out of service for some reason.
The 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. The interaction between the
OM&P system and SNSF, and the interaction between the OM&P system and MSCe is
out of scope of this document.
b. The SNSF receives a CM Service Request message from the MS via BSC, the message
includes the IMSI.
c. SNSF selects the MSCe2 as the default 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.
d. MSCe2 sends a REGNOT message to the HLR to request profile of the subscriber, the
message includes the IMSI.
e. The HLR sends a REGCANC message to MSCe1 to cancel location, the message
includes the IMSI.
f. MSCe1 acknowledge the HLR by sending a REGCNC message.
g. HLR sends a REGNOT message to MSCe2 to pushes subscribers profile to the MSCe2.
h. The MSCe2 sends an Assignment Request message to the SNSF
i. The SNSF forwards the Assignment Request message to the BSC. The subsequent
messages from BSC are routed to the MSCe based on the existing SCCP connection.

9
3.4 Call Termination
3.3.1 Call termination (normal case)
This scenario describes the call flow for call termination in MSC Pool Area.

Figure 3.43.1-3 Call Termination

10

 A30-20080825-xxx

a. The MSCe sends a Paging Request message with Tag parameter which contains the
MSCes identifier to the SNSF according to LAC of the MS.
b. The SNSF forwards the Paging Request message to the BSC.
c. The BSC returns a Paging Response message with the same Tag parameter to the SNSF.
The SNSF derives the MSCe Identifier from the Tag parameter.
d. The SNSF locates the MSCe by the derived MSCe Identifier and sends the Paging
Response message to the MSCe.
e. The MSCe sends an Assignment Request message to the SNSF
f. The SNSF forwards the Assignment Request to the BSC.
g. The BSC assigns radio resource for the MS and returns the Assignment Complete
message to the SNSF
h. The SNSF forwards this message to the MSCe based on the established SCCP
connection.
i. MS answers the call and the SNSF receives a Connect message from the BSC
j. The SNSF forwards the Connect message to the MSCe over the established SCCP
connection.

3.3.2 Call termination without Tag parameter

This scenario describes the call flow for call termination while the page response received includes no
Tag parameter. This may happen when the BSC sending the Paging Response has no Tag parameter
stored against the MS. In this case the SNSF shall select the MSCe based on the MSs IMSI.

Figure 3.3.2-1 Call Termination without Tag parameter

a. The MSCe sends a Paging Request message with Tag parameter which contains its
identifier to the SNSF according to LAC of the MS.
b. The SNSF forwards the Paging Request message to the BSC1.
c. The BSC2 returns a Paging Response message without the Tag parameter to the SNSF as
it has not received a Paging Request before.
d. The SNSF locates the MSCe by the IMSI as no Tag parameter included in the received
message and sends the Paging Response message to the MSCe.
e. The subsequent process please refer to 3.3.1.

11
3.3.3 Call termination after re-distribution
This scenario describes the call flow for call termination while load re-distribution occurs after page
response being sent. In this scenario the Paging Response sent from the BSC includes the stored Tag
parameter. The SNSF forward the Paging Response message to MSCe1 according to the Tag in the
paging response message.

Figure 3.3.3-1 Call Termination after load re-distribution with Tag received

a. The MSCe1 sends a Paging Request message with Tag parameter which contains the
MSCe1s identifier to the SNSF according to LAC of the MS.
b. The SNSF forwards the Paging Request message to the BSC.
c. The default MSCe of an MS(e.g. MSCe1 in this case) is to be out of service for
maintenance such as software update. In this situation MSCe1 can still work but has to
re-distribute its load to other MSCes in the PA. The re-distribution has been initiated
Note: The redistribution is triggered by the OM&P system. The interaction between the
OM&P system and SNSF, and the interaction between the OM&P system and MSCe is
out of scope of this document.
d. The BSC returns a Paging Response message with the same Tag parameter to the SNSF.
The SNSF derives the MSCe Identifier from the Tag parameter.
e. The SNSF locates the MSCe1 by the derived MSCe Identifier and sends the Paging
Response message to the MSCe1.
f. The subsequent process please refer to 3.3.1.

12