MSOFTX3000

HUAWEI MSOFTX3000 Mobile Softswitch Center V100R005C10
Feature Description
Issue Date Part Number
02 2007-06-10 31400597
Huawei Technologies Proprietary
Huawei Technologies Co., Ltd. provides customers with comprehensive technical support and service. For any assistance, please contact our local office or company headquarters.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base Bantian, Longgang Shenzhen 518129 People's Republic of China Website: Email: http://www.huawei.com [email protected]
Copyright Huawei Technologies Co., Ltd. 2007. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd. All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute the warranty of any kind, express or implied.
HUAWEI MSOFTX3000 Feature Description
Contents
Contents
Index ................................................................................................................................................ i-1
Issue 02 (2007-06-10)
Index
Index
A
Alert SC, 2-3 availability alarm for malicious short message, 30-3 authentication, 10-3 automatic device detection, 37-3 call barring service, 7-3 call completion, 5-3 call forwarding, 3-3 call simulation, 31-5 CAMEL4 service, 22-4 dialing test on designated TDM circuit, 35-3 early and late assignment feature, 12-3 ECT, 8-3 enhanced MSRN allocation feature, 11-4 IMSI-based announcement, 23-4 IN service performance measurement enhancement, 36-4 IN service triggering feature, 13-3 IP over E1, 24-4 IP QoS flow control, 25-3 load-based handover, 32-3 MNP feature, 14-3 multiparty, 6-3 O-CSI SMS, 26-3 ODB, 9-4 role-based and domain-based management, 29-7 service restriction, 34-4 short message service, 2-4 speech service, 1-4 union subscriber trace, 33-4 UP header redundancy data service, 27-3 VDB dynamic data backup, 28-4 CW, 5-2 call forwarding CFB, 3-2 CFNRc, 3-3 CFNRy, 3-2 CFU, 3-2 charging and CDR call barring service, 7-15 call completion, 5-17 call forwarding, 3-21 call simulation, 31-17 CAMEL4 service, 22-18 dialing test on designated TDM circuit, 35-11 ECT, 8-9 enhanced MSRN allocation feature, 11-14 IN service triggering feature, 13-14 MNP feature, 14-15 multiparty, 6-12 O-CSI SMS, 26-18 service restriction, 34-24 short message service, 2-15 speech service, 1-22
D
data configuration alarm for malicious short message, 30-7 authentication, 10-7 automatic device detection, 37-7 call barring service, 7-12 call completion, 5-12 call forwarding, 3-18 call simulation, 31-10 CAMEL4 service, 22-13 dialing test on designated TDM circuit, 35-9 early and late assignment feature, 12-17 ECT, 8-7 enhanced MSRN allocation feature, 11-9 IMSI-based announcement, 23-8 IN service performance measurement enhancement, 36-13 IN service triggering feature, 13-10 IP fax feature, 15-7 IP over E1, 24-11
C
call barring service BAIC, 7-3 BAOC, 7-2 BOIC, 7-2 BOIC-exHC, 7-2 call completion CH, 5-2
Issue 02 (2007-06-10)
i-1
Index
IP QoS flow control, 25-11 line identification, 4-9 load-based handover, 32-12 MNP feature, 14-9 multiparty, 6-10 O-CSI SMS, 26-10 ODB, 9-6 role-based and domain-based management, 29-10 service restriction, 34-9 short message service, 2-13 speech service, 1-21 union subscriber trace, 33-11 UP header redundancy data service, 27-15 VDB dynamic data backup, 28-14
ODB-BIC, 9-3 ODB-BOC, 9-3 ODB-POS, 9-4 ODB-ROAM, 9-3 ODB-SS, 9-3 Operation and Maintenance of License DLD LICENSE, 16-12 DMP LICENSE, 16-10 DSP ESN, 16-7 DSP LICENSE, 16-9 LOD LICENSE, 16-4 LST LICENSE, 16-6 ROL LICENSE, 16-5 STR LICCRC, 16-9 ULD LICENSE, 16-11
E
early and late assignment feature MS-originated call (late assignment), 12-5 MS-terminated call (early assignment), 12-6
P
performance measurement call simulation, 31-17 CAMEL4 service, 22-18 IMSI-based announcement, 23-13 IN service performance measurement enhancement, 36-19 load-based handover, 32-16 UP header redundancy data service, 27-19
F
feature description IP QoS flow control, 25-2 VDB dynamic data backup, 28-2
L
license control items control item, 16-12 resource control item, 16-15 license feature alarm, 16-19 effects of BAM operation, 16-20 invalidation and prevention, 16-17 license checks, 16-17 Upgrade, 16-20 line identification CLIP, 4-3 CLIR, 4-3 COLP, 4-3 COLR, 4-3 Line Identity, 4-2
R
reference authentication, 10-7 automatic device detection, 37-11 call barring service, 7-21 call completion, 5-19 call forwarding, 3-35 call simulation, 31-17 CAMEL4 service, 22-6, 22-21 charging and CDR, 11-15 dialing test on designated TDM circuit, 35-12 ECT, 8-13 IMSI-based announcement, 23-13 IN service performance measurement enhancement, 36-20 IN service triggering feature, 13-15 IP over E1, 24-20 IP QoS flow control, 25-18 license feature, 16-21 line identification, 4-14 load-based handover, 32-16 MNP feature, 14-16 multiparty, 6-14 O-CSI SMS, 26-18 ODB, 9-8 role-based and domain-based management, 25-18, 29-20 service interaction, 12-23
M
MOC, 1-3 MSRN allocation feature based on the LAI number, 11-3 based on the MSC number, 11-2 random allocation, 11-3 MTC, 1-3
O
ODB
i-2
Issue 02 (2007-06-10)
Index
service restriction, 34-25 short message service, 2-17 speech service, 1-26 union subscriber trace, 33-5, 33-14 UP header redundancy data service, 27-20 VDB dynamic data backup, 28-22
S
service description alarm for malicious short message, 30-2 authentication, 10-2 automatic device detection, 37-2 call barring service, 7-2 call completion, 5-2 call forwarding, 3-2 call simulation, 31-2 CAMEL4 service, 22-2 dialing test on designated TDM circuit, 35-2 early and late assignment feature, 12-2 ECT, 8-2 enhanced MSRN allocation feature, 11-2 IMSI-based announcement, 23-3 IN service performance measurement enhancement, 36-3 IN service triggering feature, 13-2 IP fax feature, 15-2 IP over E1, 24-2 license feature, 16-2 line identification, 4-2 load-based handover, 32-2 MNP feature, 14-2 multiparty, 6-2 O-CSI SMS, 26-2 ODB, 9-2 role-based and domain-based management, 29-3 service restriction, 34-2 short message service, 2-2 speech service, 1-2 union subscriber trace, 33-2 UP header redundancy data service, 27-2 service flow alarm for malicious short message, 30-5 authentication, 10-4 automatic device detection, 37-5 call barring service, 7-10 call completion, 5-7 call forwarding, 3-7 call simulation, 31-8 CAMEL4 service, 22-6 dialing test on designated TDM circuit, 35-5 early and late assignment feature, 12-9 ECT, 8-5 enhanced MSRN allocation feature, 11-7 IMSI-based announcement, 23-7
IN service performance measurement enhancement, 36-8 IP fax feature, 15-3 IP over E1, 24-8 line identification, 4-6 load-based handover, 32-7 MNP feature, 14-5 multiparty, 6-5 O-CSI SMS, 26-8 ODB, 9-5 role-based and domain-based management, 29-9 service restriction, 34-5 short message service, 2-6 speech service, 1-7 union subscriber trace, 33-5 UP header redundancy data service, 27-9 VDB dynamic data backup, 28-8 service interaction call barring service, 7-15 call completion, 5-18 call forwarding, 3-24 CAMEL4 service, 22-19 early and late assignment feature, 12-22 ECT, 8-12 IN service triggering feature, 13-14 IP QoS flow control, 25-18 line identification, 4-12 MNP feature, 14-16 multiparty, 6-13 ODB, 9-7 short message service, 2-16 speech service, 1-26 service interaction O-CSI SMS, 26-18 service interaction service restriction, 34-24 service management authentication, 10-7 automatic device detection, 37-10 call barring service, 7-13 call completion, 5-14 call forwarding, 3-18 call simulation, 31-11 CAMEL4 service, 22-17 early and late assignment feature, 12-21 ECT, 8-8 IN service performance measurement enhancement, 36-18 line identification, 4-11 load-based handover, 32-15 multiparty, 6-11 O-CSI SMS, 26-16 ODB, 9-7 short message service, 2-15 speech service, 1-22
Issue 02 (2007-06-10)
i-3
Index
union subscriber trace, 33-12 VDB dynamic data backup, 28-20 service management alarm for malicious short message, 30-9 SM MO, 2-3 SM MT, 2-2
W
working principle alarm for malicious short message, 30-4 authentication, 10-3 automatic device detection, 37-4 call barring service, 7-4 call completion, 5-4 call forwarding, 3-4 call simulation, 31-5 CAMEL4 service, 22-6 dialing test on designated TDM circuit, 35-4 early and late assignment feature, 12-4 ECT, 8-3 enhanced MSRN allocation feature, 11-5
IN service performance measurement enhancement, 36-5 IN service triggering feature, 13-3 IP fax feature, 15-2 IP over E1, 24-4 IP QoS flow control, 25-4 license feature, 16-2 line identification, 4-5 load-based handover, 32-4 MNP feature, 14-3 multiparty, 6-3 O-CSI SMS, 26-4 ODB, 9-5 role-based and domain-based management, 29-8 service restriction, 34-4 short message service, 2-5 speech service, 1-5 union subscriber trace, 33-4, 33-5 UP header redundancy data service, 27-3 VDB dynamic data backup, 28-4
i.
i-4
Issue 02 (2007-06-10)
Contents
Contents
About This Document.....................................................................................................................1 1 Speech Service ............................................................................................................................1-1
1.1 Service Description .....................................................................................................................................1-2 1.1.1 Function Code ...................................................................................................................................1-2 1.1.2 Definition ..........................................................................................................................................1-2 1.1.3 Benefits .............................................................................................................................................1-4 1.2 Availability ..................................................................................................................................................1-4 1.2.1 Requirements for NEs .......................................................................................................................1-4 1.2.2 Requirements for License..................................................................................................................1-4 1.2.3 Applicable Versions...........................................................................................................................1-4 1.3 Working Principle........................................................................................................................................1-5 1.3.1 MOC..................................................................................................................................................1-5 1.3.2 MTC ..................................................................................................................................................1-6 1.3.3 MMC .................................................................................................................................................1-7 1.4 Service Flow................................................................................................................................................1-7 1.4.1 MOC to Fixed Line Subscriber .........................................................................................................1-8 1.4.2 MTC from Fixed Line Subscriber ................................................................................................... 1-11 1.4.3 MMC ...............................................................................................................................................1-15 1.5 Data Configuration ....................................................................................................................................1-21 1.5.1 Telephony ........................................................................................................................................1-21 1.5.2 Emergency Call for Special Service................................................................................................1-21 1.5.3 Charging Flag of Emergency Call ...................................................................................................1-21 1.6 Service Management .................................................................................................................................1-22 1.6.1 For Carriers .....................................................................................................................................1-22 1.6.2 For Mobile Subscribers ...................................................................................................................1-22 1.7 Charging and CDR ....................................................................................................................................1-22 1.7.1 Generation of CDR..........................................................................................................................1-22 1.7.2 CDR for Ordinary Call ....................................................................................................................1-22 1.7.3 CDR for Emergency Call ................................................................................................................1-25 1.8 Service Interaction.....................................................................................................................................1-26 1.9 Reference...................................................................................................................................................1-26 1.9.1 Protocols and Specifications ...........................................................................................................1-26
Issue 02 (2007-02-15)
Contents
HUAWEI MSOFTX3000 Feature Description 1.9.2 Acronyms and Abbreviations ..........................................................................................................1-26
2 Short Message Service ..............................................................................................................2-1

2.1 Service Description .....................................................................................................................................2-2 2.1.1 Function Code ...................................................................................................................................2-2 2.1.2 Definition ..........................................................................................................................................2-2 2.1.3 Benefits .............................................................................................................................................2-3 2.2 Availability ..................................................................................................................................................2-4 2.2.1 Requirements for NEs .......................................................................................................................2-4 2.2.2 Requirements for License..................................................................................................................2-4 2.2.3 Applicable Versions...........................................................................................................................2-4 2.3 Working Principle........................................................................................................................................2-5 2.3.1 Networking Structure ........................................................................................................................2-5 2.3.2 Short Message Transfer Path.............................................................................................................2-6 2.4 Service Flows ..............................................................................................................................................2-6 2.4.1 MAP Flows Related to SMS .............................................................................................................2-6 2.4.2 SM MO Flow ....................................................................................................................................2-9 2.4.3 SM MT Flow.....................................................................................................................................2-9 2.4.4 Alert SMC Flows............................................................................................................................. 2-11 2.5 Data Configuration ....................................................................................................................................2-13 2.5.1 Data Configuration of the MSOFTX3000.......................................................................................2-13 2.5.2 Data Configuration of the HLR.......................................................................................................2-14 2.6 Service Management .................................................................................................................................2-15 2.6.1 For Carrier.......................................................................................................................................2-15 2.6.2 For Mobile Subscriber.....................................................................................................................2-15 2.7 Charging and CDR ....................................................................................................................................2-15 2.8 Service Interaction.....................................................................................................................................2-16 2.9 Reference...................................................................................................................................................2-17 2.9.1 Protocols and Specifications ...........................................................................................................2-17 2.9.2 Acronyms and Abbreviations ..........................................................................................................2-17
3 Call Forwarding Supplementary Service ..............................................................................3-1

3.1 Service Description .....................................................................................................................................3-2 3.1.1 Function Code ...................................................................................................................................3-2 3.1.2 Definition ..........................................................................................................................................3-2 3.1.3 Benefits .............................................................................................................................................3-3 3.2 Availability ..................................................................................................................................................3-3 3.2.1 Requirements for NEs .......................................................................................................................3-3 3.2.2 Requirements for License..................................................................................................................3-4 3.2.3 Applicable Versions...........................................................................................................................3-4 3.3 Working Principle........................................................................................................................................3-4 3.3.1 Functions of the NEs .........................................................................................................................3-4 3.3.2 Service Flow Inside the System ........................................................................................................3-4
ii
Issue 02 (2007-02-15)
Contents
3.4 Service Flow................................................................................................................................................3-7 3.4.1 CFU Service Flow.............................................................................................................................3-7 3.4.2 CFB Service Flow .............................................................................................................................3-8 3.4.3 CFNRy Service Flow ......................................................................................................................3-13 3.4.4 CFNRy Service Flow ......................................................................................................................3-15 3.5 Data Configuration ....................................................................................................................................3-18 3.5.1 MSOFTX3000 Data Configuration.................................................................................................3-18 3.5.2 HLR Configuration .........................................................................................................................3-18 3.6 Service Management .................................................................................................................................3-18 3.6.1 Operations by the Carriers...............................................................................................................3-19 3.6.2 Operations by the Subscribers .........................................................................................................3-19 3.7 Charging and CDR ....................................................................................................................................3-21 3.7.1 Charging Principle...........................................................................................................................3-21 3.7.2 Difference Between CFU and CCF in Judging an International Call..............................................3-22 3.7.3 CDR Creation Principles .................................................................................................................3-22 3.8 Service Interaction.....................................................................................................................................3-24 3.8.1 CFU .................................................................................................................................................3-24 3.8.2 CFB .................................................................................................................................................3-27 3.8.3 CFNRy ............................................................................................................................................3-30 3.8.4 CFNRc.............................................................................................................................................3-32 3.9 References .................................................................................................................................................3-35 3.9.1 Protocols and Specifications ...........................................................................................................3-35 3.9.2 Acronyms and Abbreviations ..........................................................................................................3-35
4 Line Identification Service .......................................................................................................4-1

4.1 Service Description .....................................................................................................................................4-2 4.1.1 Function Code ...................................................................................................................................4-2 4.1.2 Definition ..........................................................................................................................................4-2 4.1.3 Types .................................................................................................................................................4-3 4.1.4 Benefits .............................................................................................................................................4-4 4.2 Availability ..................................................................................................................................................4-4 4.2.1 Requirements for NEs .......................................................................................................................4-4 4.2.2 Requirements for License..................................................................................................................4-5 4.2.3 Applicable Versions...........................................................................................................................4-5 4.3 Working Principle........................................................................................................................................4-5 4.3.1 Service Data Management.................................................................................................................4-5 4.3.2 CLIP ..................................................................................................................................................4-5 4.3.3 CLIR..................................................................................................................................................4-5 4.3.4 COLP.................................................................................................................................................4-6 4.3.5 COLR ................................................................................................................................................4-6 4.4 Service Flow................................................................................................................................................4-6 4.4.1 CLIP ..................................................................................................................................................4-6
Issue 02 (2007-02-15)
iii
Contents
HUAWEI MSOFTX3000 Feature Description 4.4.2 CLIR..................................................................................................................................................4-7 4.4.3 COLP.................................................................................................................................................4-8 4.4.4 COLR ................................................................................................................................................4-8
4.5 Data Configuration ......................................................................................................................................4-9 4.5.1 Configuring Data at the MSOFTX3000 Side ....................................................................................4-9 4.5.2 Configuring Data at the HLR Side .................................................................................................. 4-11 4.6 Service Management ................................................................................................................................. 4-11 4.6.1 Opreations by Carriers..................................................................................................................... 4-11 4.6.2 Operations by Mobile Subscribers .................................................................................................. 4-11 4.7 Service Interaction.....................................................................................................................................4-12 4.7.1 CLIP ................................................................................................................................................4-12 4.7.2 CLIR................................................................................................................................................4-13 4.7.3 COLP...............................................................................................................................................4-13 4.7.4 COLR ..............................................................................................................................................4-14 4.8 Reference...................................................................................................................................................4-14 4.8.1 Protocols and Specifications ...........................................................................................................4-14 4.8.2 Acronyms and Abbreviations ..........................................................................................................4-15
5 Call Completion Supplementary Service..............................................................................5-1

5.1 Service Description .....................................................................................................................................5-2 5.1.1 Function Code ...................................................................................................................................5-2 5.1.2 Definition ..........................................................................................................................................5-2 5.1.3 Benefits .............................................................................................................................................5-3 5.2 Availability ..................................................................................................................................................5-3 5.2.1 Requirements for NEs .......................................................................................................................5-3 5.2.2 Requirements for License..................................................................................................................5-3 5.2.3 Applicable Versions...........................................................................................................................5-4 5.3 Working Principle........................................................................................................................................5-4 5.3.1 Service Data Management.................................................................................................................5-4 5.3.2 Working Principle of CW ..................................................................................................................5-4 5.3.3 Working Principle of CH...................................................................................................................5-5 5.4 Service Flow................................................................................................................................................5-6 5.4.1 Service Flow of CW ..........................................................................................................................5-6 5.4.2 Service Flow of CH.........................................................................................................................5-10 5.5 Data Configuration ....................................................................................................................................5-12 5.5.1 Configuring Data at the MSOFTX3000 Side ..................................................................................5-12 5.5.2 Configuring Data at the HLR Side ..................................................................................................5-14 5.6 Service Management .................................................................................................................................5-14 5.6.1 Overview .........................................................................................................................................5-14 5.6.2 Operations by Carriers.....................................................................................................................5-15 5.6.3 Operations by Mobile Subscribers ..................................................................................................5-15 5.7 Charging and CDR ....................................................................................................................................5-16
iv
Issue 02 (2007-02-15)
Contents
5.7.1 CW ..................................................................................................................................................5-16 5.7.2 CH ...................................................................................................................................................5-17 5.8 Service Interaction.....................................................................................................................................5-18 5.8.1 CW ..................................................................................................................................................5-18 5.8.2 CH ...................................................................................................................................................5-19 5.9 Reference...................................................................................................................................................5-19 5.9.1 Protocols and Specifications ...........................................................................................................5-19 5.9.2 Acronyms and Abbreviations ..........................................................................................................5-19
6 Multiparty Service .....................................................................................................................6-1

6.1 Service Description .....................................................................................................................................6-2 6.1.1 Function Code ...................................................................................................................................6-2 6.1.2 Definition ..........................................................................................................................................6-2 6.1.3 Benefits .............................................................................................................................................6-2 6.2 Availability ..................................................................................................................................................6-3 6.2.1 Requirements for NEs .......................................................................................................................6-3 6.2.2 Requirements for License..................................................................................................................6-3 6.2.3 Applicable Versions...........................................................................................................................6-3 6.3 Working Principle........................................................................................................................................6-3 6.3.1 Functions Realized by Network Elements.........................................................................................6-3 6.3.2 Service Data Management.................................................................................................................6-4 6.3.3 MPTY Invocation..............................................................................................................................6-4 6.3.4 MPTY Call Management ..................................................................................................................6-4 6.4 Service Flow................................................................................................................................................6-5 6.4.1 Setting up the MPTY Call .................................................................................................................6-5 6.4.2 Setting Up a Personal Communication with Remote Subscriber ......................................................6-6 6.4.3 Adding a Remote Subscriber.............................................................................................................6-7 6.4.4 Disconnecting a Remote Subscriber..................................................................................................6-8 6.5 Data Configuration ......................................................................................................................................6-9 6.5.1 Data Configuration at MSOFTX3000 Side .......................................................................................6-9 6.5.2 Data Configuration at UMG8900 Side............................................................................................6-10 6.6 Service Management ................................................................................................................................. 6-11 6.6.1 Carrier Operation............................................................................................................................. 6-11 6.6.2 Mobile Subscriber Operation .......................................................................................................... 6-11 6.7 Charging and CDR ....................................................................................................................................6-12 6.8 Service Interaction.....................................................................................................................................6-13 6.9 Reference...................................................................................................................................................6-14 6.9.1 Protocols and Specifications ...........................................................................................................6-14 6.9.2 Acronyms and Abbreviations ..........................................................................................................6-14
7 Call Barring Service ...................................................................................................................7-1

7.1 Service Description .....................................................................................................................................7-2 7.1.1 Function Code ...................................................................................................................................7-2
Issue 02 (2007-02-15)
Contents
HUAWEI MSOFTX3000 Feature Description 7.1.2 Definition ..........................................................................................................................................7-2 7.1.3 Types .................................................................................................................................................7-2 7.1.4 Benefits .............................................................................................................................................7-3
7.2 Availability ..................................................................................................................................................7-3 7.2.1 Requirements for NEs .......................................................................................................................7-3 7.2.2 Requirements for License..................................................................................................................7-3 7.2.3 Applicable Versions...........................................................................................................................7-4 7.3 Working Principle........................................................................................................................................7-4 7.3.1 Service Data Management.................................................................................................................7-4 7.3.2 BO .....................................................................................................................................................7-4 7.3.3 BI.......................................................................................................................................................7-8 7.4 Service Flow..............................................................................................................................................7-10 7.4.1 BO ...................................................................................................................................................7-10 7.4.2 BI..................................................................................................................................................... 7-11 7.5 Data Configuration ....................................................................................................................................7-12 7.5.1 Configuring Data at the MSOFTX3000 Side ..................................................................................7-12 7.5.2 Configuring Data at the HLR Side ..................................................................................................7-13 7.6 Service Management .................................................................................................................................7-13 7.6.1 Operations by Carriers.....................................................................................................................7-13 7.6.2 Operations by Mobile Subscribers ..................................................................................................7-13 7.7 Charging and CDR ....................................................................................................................................7-15 7.8 Service Interaction.....................................................................................................................................7-15 7.8.1 BAOC..............................................................................................................................................7-15 7.8.2 BOIC ...............................................................................................................................................7-15 7.8.3 BOIC-exHC.....................................................................................................................................7-17 7.8.4 BAIC ...............................................................................................................................................7-18 7.8.5 BIC-ROAM.....................................................................................................................................7-19 7.9 Reference...................................................................................................................................................7-21 7.9.1 Protocols and Specifications ...........................................................................................................7-21 7.9.2 Acronyms and Abbreviations ..........................................................................................................7-21
8 Explicit Call Transfer Service ..................................................................................................8-1

8.1 Service Description .....................................................................................................................................8-2 8.1.1 Function Code ...................................................................................................................................8-2 8.1.2 Definition ..........................................................................................................................................8-2 8.1.3 Benefits .............................................................................................................................................8-2 8.2 Availability ..................................................................................................................................................8-3 8.2.1 Requirements for NEs .......................................................................................................................8-3 8.2.2 Requirements for License..................................................................................................................8-3 8.2.3 Applicable Versions...........................................................................................................................8-3 8.3 Working Principle........................................................................................................................................8-3 8.3.1 Functions of Each NE .......................................................................................................................8-3
vi
Issue 02 (2007-02-15)
Contents
8.3.2 Service Data Management.................................................................................................................8-3 8.3.3 Invoking the ECT ..............................................................................................................................8-4 8.4 Service Flow................................................................................................................................................8-4 8.4.1 A-B Call Is on Hold and A-C Call Is in the Active State...................................................................8-4 8.4.2 A-B Call Is in the Active State and A-C Call Is in the Alerting State................................................8-5 8.5 Data Configuration ......................................................................................................................................8-7 8.5.1 Data Configuration on the MSOFTX3000 ........................................................................................8-7 8.5.2 Data Configuration on the UMG8900 ...............................................................................................8-7 8.6 Service Management ...................................................................................................................................8-8 8.6.1 Operation Mode.................................................................................................................................8-8 8.6.2 Operations by the Carriers.................................................................................................................8-8 8.6.3 Operations by the Mobile Subscribers ..............................................................................................8-8 8.7 Charging and CDR ......................................................................................................................................8-9 8.7.1 Introduction to the Charging Mode ...................................................................................................8-9 8.7.2 Independent Charging .......................................................................................................................8-9 8.7.3 Segmented Charging .......................................................................................................................8-10 8.8 Service Interaction.....................................................................................................................................8-12 8.9 Reference...................................................................................................................................................8-13 8.9.1 Protocols and Specifications ...........................................................................................................8-13 8.9.2 Acronyms and Abbreviations ..........................................................................................................8-14
9 ODB Service ................................................................................................................................9-1

9.1 Service Description .....................................................................................................................................9-2 9.1.1 Function Code ...................................................................................................................................9-2 9.1.2 Definition ..........................................................................................................................................9-2 9.1.3 Service Type ......................................................................................................................................9-3 9.1.4 Benefits .............................................................................................................................................9-4 9.2 Availability ..................................................................................................................................................9-4 9.2.1 Requirement for NEs.........................................................................................................................9-4 9.2.2 Requirement for License ...................................................................................................................9-4 9.2.3 Applicable Versions...........................................................................................................................9-5 9.3 Working Principle........................................................................................................................................9-5 9.4 Service Flow................................................................................................................................................9-5 9.4.1 Barring of Incoming Calls or MS MT...............................................................................................9-5 9.4.2 Barring of Outgoing Calls or MS MO...............................................................................................9-5 9.4.3 Barring of Roaming...........................................................................................................................9-6 9.4.4 Barring of Supplementary Services...................................................................................................9-6 9.4.5 Barring of Packet Services ................................................................................................................9-6 9.5 Data Configuration ......................................................................................................................................9-6 9.5.1 Data Configuration for MSOFTX3000 .............................................................................................9-6 9.5.2 Data Configuration for UMG8900 ....................................................................................................9-7 9.6 Service Management ...................................................................................................................................9-7
Issue 02 (2007-02-15)
vii
Contents
9.7 Charging and CDR ......................................................................................................................................9-7 9.8 Service Interaction.......................................................................................................................................9-7 9.9 Reference.....................................................................................................................................................9-8 9.9.1 Protocols and Specifications .............................................................................................................9-8 9.9.2 Acronyms and Abbreviations ............................................................................................................9-8
10 Authentication Feature..........................................................................................................10-1
10.1 Service Description .................................................................................................................................10-2 10.1.1 Function Code ...............................................................................................................................10-2 10.1.2 Definition ......................................................................................................................................10-2 10.1.3 Benefits .........................................................................................................................................10-2 10.2 Availability ..............................................................................................................................................10-3 10.2.1 Requirements for NEs ...................................................................................................................10-3 10.2.2 Requirements for License..............................................................................................................10-3 10.2.3 Applicable Versions.......................................................................................................................10-3 10.3 Working Principle....................................................................................................................................10-3 10.4 Service Flow............................................................................................................................................10-4 10.4.1 UMTS Authentication ...................................................................................................................10-4 10.4.2 GSM Authentication......................................................................................................................10-5 10.5 Data Configuration ..................................................................................................................................10-7 10.5.1 Data Configuration on MSOFTX3000 ..........................................................................................10-7 10.5.2 Data Configuration on HLR ..........................................................................................................10-7 10.6 Service Management ...............................................................................................................................10-7 10.6.1 Subscription of Authentication ......................................................................................................10-7 10.6.2 Query of Authentication ................................................................................................................10-7 10.7 Reference.................................................................................................................................................10-7 10.7.1 Protocols and Specifications .........................................................................................................10-7 10.7.2 Glossary, Acronyms and Abbreviations.........................................................................................10-8
11 Enhanced MSRN Allocation Feature .................................................................................11-1

11.1 Service Description.................................................................................................................................. 11-2 11.1.1 Function Code ............................................................................................................................... 11-2 11.1.2 Definition ...................................................................................................................................... 11-2 11.1.3 Benefits.......................................................................................................................................... 11-4 11.2 Availability............................................................................................................................................... 11-4 11.2.1 Requirements for NEs ................................................................................................................... 11-4 11.2.2 Requirements for License.............................................................................................................. 11-4 11.2.3 Applicable Versions ....................................................................................................................... 11-4 11.3 Working Principle.................................................................................................................................... 11-5 11.3.1 Functions of NEs ........................................................................................................................... 11-5 11.3.2 Processing in the System ............................................................................................................... 11-5 11.4 Service Flow............................................................................................................................................ 11-7 11.4.1 General Procedure of MSRN Allocation ....................................................................................... 11-7
viii
Issue 02 (2007-02-15)
Contents
11.4.2 Procedure for Random Allocation ................................................................................................. 11-8 11.5 Data Configuration .................................................................................................................................. 11-9 11.5.1 Configuring Data at the MSOFTX3000 Side ................................................................................ 11-9 11.5.2 Configuraing Data at the UMG8900 Side ................................................................................... 11-10 11.5.3 Configuration Examples .............................................................................................................. 11-10 11.6 Service Management ............................................................................................................................. 11-14 11.7 Charging and CDR ................................................................................................................................ 11-14 11.8 Service Interaction................................................................................................................................. 11-14 11.9 Reference............................................................................................................................................... 11-15 11.9.1 Protocols and Specifications........................................................................................................ 11-15 11.9.2 Acronyms and Abbreviations....................................................................................................... 11-15
12 Early and Late Assignment Feature....................................................................................12-1

12.1 Service Description .................................................................................................................................12-2 12.1.1 Function Code ...............................................................................................................................12-2 12.1.2 Definition ......................................................................................................................................12-2 12.1.3 Benefits .........................................................................................................................................12-3 12.2 Availability ..............................................................................................................................................12-3 12.2.1 Requirements for NEs ...................................................................................................................12-3 12.2.2 Requirements for License..............................................................................................................12-3 12.2.3 Applicable Version ........................................................................................................................12-3 12.3 Working Principle....................................................................................................................................12-4 12.3.1 MS-Originated Call (Early Assignment) .......................................................................................12-4 12.3.2 MS-Originated Call (Late Assignment).........................................................................................12-5 12.3.3 MS-Terminated Call (Early Assignment) ......................................................................................12-6 12.4 Service Flow............................................................................................................................................12-9 12.4.1 Early Resource Assignment for the Caller ....................................................................................12-9 12.4.2 Late Resource Assignment for the Caller .................................................................................... 12-11 12.4.3 Early Resource Assignment for the Callee ..................................................................................12-13 12.4.4 Late Resource Assignment for the Callee....................................................................................12-15 12.5 Data Configuration ................................................................................................................................12-17 12.5.1 MSOFTX3000 Data Configuration.............................................................................................12-17 12.5.2 HLR Data Configuration .............................................................................................................12-18 12.5.3 UMG8900 Data Configuration....................................................................................................12-18 12.5.4 Examples .....................................................................................................................................12-18 12.6 Service Management .............................................................................................................................12-21 12.6.1 Querying the Resource Assignment Mode ..................................................................................12-21 12.6.2 Changing the Resource Assignment Mode..................................................................................12-22 12.7 Charging and CDR ................................................................................................................................12-22 12.8 Service Interaction.................................................................................................................................12-22 12.9 Reference...............................................................................................................................................12-23 12.9.1 Protocols and Specifications .......................................................................................................12-23
Issue 02 (2007-02-15)
ix
Contents
HUAWEI MSOFTX3000 Feature Description 12.9.2 Acronyms and Abbreviations ......................................................................................................12-23
13 IN Service Triggering Feature .............................................................................................13-1

13.1 Service Description .................................................................................................................................13-2 13.1.1 Function Code ...............................................................................................................................13-2 13.1.2 Definition ......................................................................................................................................13-2 13.1.3 Benefits .........................................................................................................................................13-2 13.2 Availability ..............................................................................................................................................13-3 13.2.1 Requirement for NEs.....................................................................................................................13-3 13.2.2 Requirement for License ...............................................................................................................13-3 13.2.3 Applicable Versions.......................................................................................................................13-3 13.3 Working Principle....................................................................................................................................13-3 13.4 Service Flow..........................................................................................................................................13-10 13.5 Data Configuration ................................................................................................................................13-10 13.5.1 Data Configuration for MSOFTX3000 .......................................................................................13-10 13.5.2 Data Configuration for HLR9820 ...............................................................................................13-10 13.5.3 Data Configuration for UMG8900 ..............................................................................................13-10 13.5.4 Example....................................................................................................................................... 13-11 13.6 Service Management .............................................................................................................................13-14 13.7 Charging and CDR ................................................................................................................................13-14 13.8 Service Interaction.................................................................................................................................13-14 13.9 References .............................................................................................................................................13-15 13.9.1 Specifications ..............................................................................................................................13-15 13.9.2 Acronyms and Abbreviations ......................................................................................................13-15
14 MNP Feature ...........................................................................................................................14-1

14.1 Feature Description .................................................................................................................................14-2 14.1.1 Feature Code .................................................................................................................................14-2 14.1.2 Function Definition .......................................................................................................................14-2 14.1.3 Service Benefits.............................................................................................................................14-2 14.2 Availability ..............................................................................................................................................14-3 14.2.1 Related Network Elements............................................................................................................14-3 14.2.2 License Support.............................................................................................................................14-3 14.2.3 Version Support .............................................................................................................................14-3 14.3 Principle Description ...............................................................................................................................14-3 14.3.1 Functions of NEs...........................................................................................................................14-3 14.3.2 System Interior Processing............................................................................................................14-3 14.4 Service Flows ..........................................................................................................................................14-5 14.4.1 QoR Mode.....................................................................................................................................14-5 14.4.2 OR Mode.......................................................................................................................................14-6 14.4.3 AcQ Mode .....................................................................................................................................14-7 14.5 Data Configuration ..................................................................................................................................14-9 14.5.1 Data Configuration on the MSOFTX3000 ....................................................................................14-9
Issue 02 (2007-02-15)
Contents
14.5.2 Data Configuration on the UMG8900 ...........................................................................................14-9 14.5.3 Data Configuration Examples .......................................................................................................14-9 14.6 Service Management .............................................................................................................................14-15 14.7 Charging and CDR ................................................................................................................................14-15 14.8 Service Interaction.................................................................................................................................14-16 14.9 Reference...............................................................................................................................................14-16 14.9.1 Protocols and Specifications .......................................................................................................14-16 14.9.2 Acronyms and Abbreviations ......................................................................................................14-16
15 IP Fax Feature..........................................................................................................................15-1
15.1 Service Description .................................................................................................................................15-2 15.2 Working Principle....................................................................................................................................15-2 15.3 Benefits....................................................................................................................................................15-2 15.3.1 To Carriers.....................................................................................................................................15-2 15.3.2 To Mobile Subscribers...................................................................................................................15-2 15.4 Availability ..............................................................................................................................................15-2 15.4.1 Application ....................................................................................................................................15-2 15.4.2 Requirements for Software............................................................................................................15-3 15.4.3 Requirements for Hardware ..........................................................................................................15-3 15.5 Service Flow............................................................................................................................................15-3 15.5.1 Classification of Call Model..........................................................................................................15-3 15.5.2 Processing Flow ............................................................................................................................15-3 15.6 Data Configuration ..................................................................................................................................15-7 15.6.1 Configuring Data at the MSOFTX3000 Side ................................................................................15-7 15.6.2 Data Configuration Example.........................................................................................................15-9 15.7 Service Management .............................................................................................................................15-10 15.8 Charging and CDR ................................................................................................................................15-10 15.9 Service Interaction.................................................................................................................................15-10
16 License Feature .......................................................................................................................16-1

16.1 Service Description .................................................................................................................................16-2 16.1.1 Function Code ...............................................................................................................................16-2 16.1.2 Application Scope .........................................................................................................................16-2 16.2 Working Principle....................................................................................................................................16-2 16.2.1 Working Principle of License ........................................................................................................16-2 16.2.2 Running Status of License.............................................................................................................16-2 16.2.3 Invalidation of License..................................................................................................................16-3 16.2.4 Alerting Mechanism of License.....................................................................................................16-3 16.3 Operation and Maintenance of License ...................................................................................................16-4 16.3.1 LOD LICENSE (Loading a License) ............................................................................................16-4 16.3.2 ROL LICENSE (Rolling Back a License).....................................................................................16-5 16.3.3 LST LICENSE (Listing a License) ...............................................................................................16-6 16.3.4 DSP ESN (Displaying the System ESN) .......................................................................................16-7
Issue 02 (2007-02-15)
xi
Contents
HUAWEI MSOFTX3000 Feature Description 16.3.5 STR LICCRC (Starting CRC Check of License) ..........................................................................16-9 16.3.6 DSP LICENSE (Display Running License File Status) ................................................................16-9 16.3.7 DMP LICENSE (Dumping License File)....................................................................................16-10 16.3.8 ULD LICENSE (Uploading License File to FTP Server) ........................................................... 16-11 16.3.9 DLD LICENSE (Downloading License File from FTP Server)..................................................16-12
16.4 License Control Items............................................................................................................................16-12 16.4.1 Control Items...............................................................................................................................16-12 16.4.2 Resource Control Items ...............................................................................................................16-15 16.5 Other Precautions ..................................................................................................................................16-17 16.5.1 License Checks............................................................................................................................16-17 16.5.2 License Invalidation and Prevention ...........................................................................................16-17 16.5.3 License Alarms............................................................................................................................16-19 16.5.4 License Upgrading ......................................................................................................................16-20 16.5.5 Effects of BAM Operations on License ......................................................................................16-20 16.6 Reference...............................................................................................................................................16-21 16.6.1 Protocols and Specifications .......................................................................................................16-21 16.6.2 Acornyms and Abbreviations ......................................................................................................16-21
17 NE User Dynamic Monitoring Feature ..............................................................................17-1

17.1 Function Description ...............................................................................................................................17-2 17.1.1 Function Code ...............................................................................................................................17-2 17.1.2 Definition ......................................................................................................................................17-2 17.1.3 Standard Compliance ....................................................................................................................17-3 17.1.4 System Specifications....................................................................................................................17-3 17.1.5 Benefits .........................................................................................................................................17-4 17.1.6 Application Scenario .....................................................................................................................17-4 17.1.7 Application Limitations.................................................................................................................17-4 17.2 Availability ..............................................................................................................................................17-4 17.2.1 Requirements for NEs ...................................................................................................................17-4 17.2.2 Requirements for License..............................................................................................................17-5 17.2.3 Applicable Versions.......................................................................................................................17-5 17.2.4 Others ............................................................................................................................................17-5 17.3 Working Principle....................................................................................................................................17-5 17.3.1 Functions of NEs...........................................................................................................................17-5 17.3.2 Internal Processing of the System .................................................................................................17-6 17.3.3 External Interfaces.........................................................................................................................17-6 17.4 Service Flow............................................................................................................................................17-6 17.4.1 Monitoring Flow of Online User...................................................................................................17-6 17.4.2 Reporting Flow of User Operation ................................................................................................17-6 17.4.3 Disconnection Flow of User Operation .........................................................................................17-7 17.5 Function Maintenance .............................................................................................................................17-7 17.5.1 Overview .......................................................................................................................................17-7
xii
Issue 02 (2007-02-15)
Contents
17.5.2 Maintenance Operations................................................................................................................17-7 17.6 Service Management ............................................................................................................................. 17-11 17.7 Charging and CDR ................................................................................................................................ 17-11 17.8 Performance Measurement .................................................................................................................... 17-11 17.9 Service Interaction................................................................................................................................. 17-11 17.10 References ...........................................................................................................................................17-12 17.10.1 Standards and Specifications.....................................................................................................17-12 17.10.2 Glossary, Acronyms, and Abbreviations....................................................................................17-12 17.11 FAQ .....................................................................................................................................................17-12
18 SMS Notification for Call Failure Feature ........................................................................18-1

18.1 Service Description .................................................................................................................................18-2 18.1.1 Function Code ...............................................................................................................................18-2 18.1.2 Definition ......................................................................................................................................18-2 18.1.3 Benefits .........................................................................................................................................18-2 18.2 Availability ..............................................................................................................................................18-3 18.2.1 Requirements for NEs ...................................................................................................................18-3 18.2.2 Requirements for License..............................................................................................................18-3 18.2.3 Applicable Versions.......................................................................................................................18-3 18.3 Working Principle....................................................................................................................................18-3 18.3.1 Functions of Each NE....................................................................................................................18-3 18.3.2 Internal Processing ........................................................................................................................18-4 18.4 Service Flow............................................................................................................................................18-6 18.4.1 Prerequisites for Service Triggering..............................................................................................18-6 18.4.2 Service Triggering Point................................................................................................................18-7 18.4.3 Processing Flow After Service Triggering.....................................................................................18-8 18.5 Data Configuration ................................................................................................................................18-10 18.5.1 Data Configuration on the MSOFTX3000 ..................................................................................18-10 18.5.2 Data Configuration Sample .........................................................................................................18-10 18.6 Service Management ............................................................................................................................. 18-11 18.6.1 Operations by Carriers.................................................................................................................18-12 18.6.2 Operations by Subscribers...........................................................................................................18-13 18.7 Charging and Charging Data Record (CDR) .........................................................................................18-13 18.7.1 CDR of the SMMO .....................................................................................................................18-13 18.7.2 CDR of the SMMT......................................................................................................................18-13 18.7.3 Charging ......................................................................................................................................18-13 18.8 Service Interaction.................................................................................................................................18-13 18.8.1 Call Service .................................................................................................................................18-13 18.8.2 SM Service ..................................................................................................................................18-13 18.8.3 Call Forwarding Service..............................................................................................................18-13 18.8.4 Voice Mailbox Service ................................................................................................................18-14 18.9 Reference...............................................................................................................................................18-14
Issue 02 (2007-02-15)
xiii
Contents
HUAWEI MSOFTX3000 Feature Description 18.9.1 Protocols and Specifications .......................................................................................................18-14 18.9.2 Aronyms and Abbreviations ........................................................................................................18-14
19 Summer Time Feature of Wireless Time Zone ................................................................19-1

19.1 Feature Description .................................................................................................................................19-2 19.1.1 Function Code ...............................................................................................................................19-2 19.1.2 Definition ......................................................................................................................................19-2 19.1.3 Benefits .........................................................................................................................................19-3 19.2 Availability ..............................................................................................................................................19-3 19.2.1 Requirement for NEs.....................................................................................................................19-3 19.2.2 Requirement for License ...............................................................................................................19-3 19.2.3 Applicable Versions.......................................................................................................................19-3 19.3 Working Principle....................................................................................................................................19-4 19.4 Data Configuration ..................................................................................................................................19-5 19.4.1 Data Configuration for the MSOFTX3000 ...................................................................................19-5 19.4.2 Example.........................................................................................................................................19-6 19.5 Charging and CDR ..................................................................................................................................19-7 19.6 Service Interaction...................................................................................................................................19-8 19.7 Reference.................................................................................................................................................19-8 19.7.1 Protocols and Specifications .........................................................................................................19-8 19.7.2 Acronyms and Abbreviations ........................................................................................................19-8
20 Version Software Management Feature ............................................................................20-1

20.1 Service Description .................................................................................................................................20-2 20.1.1 Function Code ...............................................................................................................................20-2 20.1.2 Definition ......................................................................................................................................20-2 20.1.3 Benefits .........................................................................................................................................20-2 20.2 Availability ..............................................................................................................................................20-2 20.2.1 Requirements for NEs ...................................................................................................................20-2 20.2.2 License Support.............................................................................................................................20-3 20.2.3 Applicable Version ........................................................................................................................20-3 20.3 Working Principle....................................................................................................................................20-3 20.4 Patch Operation Flow ..............................................................................................................................20-4 20.5 Data Configuration ..................................................................................................................................20-6 20.5.1 Data Configuration at the MSOFTX3000 .....................................................................................20-6 20.5.2 Data Configuration at the UMG8900 Side ....................................................................................20-8 20.6 Service Management ...............................................................................................................................20-8 20.6.1 Uploading Patch to The M2000 Server .........................................................................................20-9 20.6.2 Operating Patch ...........................................................................................................................20-10 20.7 Charging and CDR ................................................................................................................................20-12 20.8 Service Interaction.................................................................................................................................20-12 20.9 Reference...............................................................................................................................................20-12
21 Configuration Rollback Feature..........................................................................................21-1

xiv
Issue 02 (2007-02-15)
Contents
21.1 Service Description .................................................................................................................................21-2 21.1.1 Function Code ...............................................................................................................................21-2 21.1.2 Definition ......................................................................................................................................21-2 21.1.3 Benefits .........................................................................................................................................21-3 21.2 Availability ..............................................................................................................................................21-3 21.2.1 Requirements for NEs ...................................................................................................................21-3 21.2.2 Requirements for License..............................................................................................................21-3 21.2.3 Applicable Versions.......................................................................................................................21-3 21.3 Working Principle....................................................................................................................................21-3 21.3.1 Basic Principle...............................................................................................................................21-3 21.3.2 State Transition..............................................................................................................................21-4 21.3.3 Validity Check ...............................................................................................................................21-6 21.4 Service Flow............................................................................................................................................21-7 21.5 Data Configuration ..................................................................................................................................21-9 21.5.1 Data Configuration on the MSOFTX3000 Side ............................................................................21-9 21.5.2 Configuration Preparations.......................................................................................................... 21-11 21.5.3 Configuration Steps.....................................................................................................................21-12 21.5.4 Data Configuration on the UMG8900 Side.................................................................................21-13 21.6 Service Management .............................................................................................................................21-13 21.6.1 Rollback Commands ...................................................................................................................21-13 21.6.2 Synchronization and Forcible Synchronization Commands........................................................21-14 21.6.3 Activation and Forcible Activation Commands...........................................................................21-17 21.6.4 Rollback and Forcible Rollback Commands ...............................................................................21-19 21.6.5 Cancellation and Confirmation Commands ................................................................................21-21 21.6.6 Query Commands........................................................................................................................21-23 21.7 Charging and CDR ................................................................................................................................21-27 21.8 Service Interaction.................................................................................................................................21-27 21.9 Reference...............................................................................................................................................21-27
22 CAMEL4 Service ....................................................................................................................22-1

22.1 Service Description .................................................................................................................................22-2 22.1.1 Function Code ...............................................................................................................................22-2 22.1.2 Definition ......................................................................................................................................22-2 22.1.3 System Specifications....................................................................................................................22-4 22.1.4 Benefits .........................................................................................................................................22-4 22.1.5 Application Scenario .....................................................................................................................22-4 22.1.6 Application Limitations.................................................................................................................22-4 22.2 Availability ..............................................................................................................................................22-4 22.2.1 Requirements for NEs ...................................................................................................................22-4 22.2.2 Requirement for License ...............................................................................................................22-5 22.2.3 Applicable Versions.......................................................................................................................22-5 22.2.4 Others ............................................................................................................................................22-5
Issue 02 (2007-02-15)
xv
Contents
22.3 Working Principle....................................................................................................................................22-6 22.3.1 Functions of NEs...........................................................................................................................22-6 22.3.2 Internal Processing of the System .................................................................................................22-6 22.3.3 External Interfaces.........................................................................................................................22-6 22.4 Service Flow............................................................................................................................................22-6 22.4.1 Conference Call.............................................................................................................................22-7 22.4.2 CAMEL4 IN RBT Service ............................................................................................................22-9 22.4.3 CAMEL4 Simultaneous Ringing ................................................................................................22-10 22.5 Data Configuration ................................................................................................................................22-13 22.5.1 Overview .....................................................................................................................................22-13 22.5.2 Data Configuration at the MSOFTX3000 Side ...........................................................................22-13 22.5.3 Data Configuration at the UMG8900 Side ..................................................................................22-13 22.5.4 Data Configuration Examples .....................................................................................................22-14 22.6 Service Management .............................................................................................................................22-17 22.7 Charging and CDR ................................................................................................................................22-18 22.8 Performance Measurement ....................................................................................................................22-18 22.8.1 Specifications ..............................................................................................................................22-18 22.8.2 Implementation Principle ............................................................................................................22-19 22.9 Service Interaction.................................................................................................................................22-19 22.9.1 Restriction Between the Supplementary Services .......................................................................22-19 22.9.2 Restriction Between Multiple CPH Operations in the CAMEL4 Service ...................................22-20 22.10 Reference.............................................................................................................................................22-21 22.10.1 Specifications ............................................................................................................................22-21 22.10.2 Glossary, Acronyms and Abbreviation ......................................................................................22-21 22.11 FAQ .....................................................................................................................................................22-23
23 IMSI-Based Announcement.................................................................................................23-1
23.1 Service Description .................................................................................................................................23-3 23.1.1 Function Code ...............................................................................................................................23-3 23.1.2 Definition ......................................................................................................................................23-3 23.1.3 System Specifications....................................................................................................................23-3 23.1.4 Benefits .........................................................................................................................................23-3 23.1.5 Application Scenario .....................................................................................................................23-4 23.1.6 Application Limitations.................................................................................................................23-4 23.2 Availability ..............................................................................................................................................23-4 23.2.1 Requirements for NEs ...................................................................................................................23-4 23.2.2 Requirements for License..............................................................................................................23-4 23.2.3 Applicable Versions.......................................................................................................................23-4 23.2.4 Others ............................................................................................................................................23-5 23.3 Working Principle....................................................................................................................................23-5 23.3.1 Functions of the NEs .....................................................................................................................23-5 23.3.2 Internal Processing of the System .................................................................................................23-5
xvi
Issue 02 (2007-02-15)
Contents
23.3.3 External Interfaces.........................................................................................................................23-7 23.4 Service Flow............................................................................................................................................23-7 23.5 Data Configuration ..................................................................................................................................23-8 23.5.1 Overview .......................................................................................................................................23-8 23.5.2 Data Configuration at the MSOFTX3000 Side .............................................................................23-8 23.5.3 Data Configuration at the UMG8900 Side ....................................................................................23-9 23.5.4 Data Configuration Examples .......................................................................................................23-9 23.5.5 Querying Tables of the IMSI-Based Announcement Service ......................................................23-10 23.6 Service Management .............................................................................................................................23-13 23.7 Charging and CDR ................................................................................................................................23-13 23.8 Performance Measurement ....................................................................................................................23-13 23.9 Interactions with Other Services............................................................................................................23-13 23.10 Reference.............................................................................................................................................23-13 23.10.1 Specifications ............................................................................................................................23-13 23.10.2 Acronyms and Abbreviations ....................................................................................................23-13 23.11 FAQ .....................................................................................................................................................23-13 23.11.1 Question 1..................................................................................................................................23-13 23.11.2 Question 2..................................................................................................................................23-14 23.11.3 Question 3..................................................................................................................................23-14
24 IP over E1 .................................................................................................................................24-1
24.1 Service Description .................................................................................................................................24-2 24.1.1 Function Code ...............................................................................................................................24-2 24.1.2 Definition ......................................................................................................................................24-2 24.1.3 System Specifications....................................................................................................................24-2 24.1.4 Benefits .........................................................................................................................................24-2 24.1.5 Application Scenario .....................................................................................................................24-3 24.1.6 Application Limitations.................................................................................................................24-3 24.2 Availability ..............................................................................................................................................24-4 24.2.1 Requirements for NEs ...................................................................................................................24-4 24.2.2 Requirements for License..............................................................................................................24-4 24.2.3 Applicable Versions.......................................................................................................................24-4 24.2.4 Others ............................................................................................................................................24-4 24.3 Working Principle....................................................................................................................................24-4 24.3.1 Functions Provided by NEs...........................................................................................................24-4 24.3.2 Internal Processing Flow of the System ........................................................................................24-5 24.3.3 External Interfaces.........................................................................................................................24-7 24.4 Service Flow............................................................................................................................................24-8 24.4.1 Inter-Office Call Flow Based on IP over E1..................................................................................24-8 24.4.2 Cross-MGW Call Flow Based on IP over E1 ..............................................................................24-10 24.5 Data Configuration ................................................................................................................................ 24-11 24.5.1 Overview of Data Configuration ................................................................................................. 24-11
Issue 02 (2007-02-15)
xvii
Contents
HUAWEI MSOFTX3000 Feature Description 24.5.2 Data Configuration at the MSOFTX3000 Side ........................................................................... 24-11 24.5.3 Data Configuration at the UMG8900 Side ..................................................................................24-13 24.5.4 Data Configuration Example.......................................................................................................24-17
24.6 Service Management .............................................................................................................................24-19 24.7 Charging and CDR ................................................................................................................................24-19 24.8 Performance Measurement ....................................................................................................................24-20 24.9 Service Interaction.................................................................................................................................24-20 24.10 Reference.............................................................................................................................................24-20 24.10.1 Specifications ............................................................................................................................24-20 24.10.2 Glossary, Acronyms, and Abbreviations....................................................................................24-20
25 IP QoS Flow Control .............................................................................................................25-1

25.1 Feature Description .................................................................................................................................25-2 25.1.1 Function Code ...............................................................................................................................25-2 25.1.2 Definition ......................................................................................................................................25-2 25.1.3 System Specifications....................................................................................................................25-2 25.1.4 Benefits .........................................................................................................................................25-3 25.1.5 Application Scenario .....................................................................................................................25-3 25.1.6 Application Limitations.................................................................................................................25-3 25.2 Availability ..............................................................................................................................................25-3 25.2.1 Requirements for NEs ...................................................................................................................25-3 25.2.2 Requirements for License..............................................................................................................25-4 25.2.3 Applicable Versions.......................................................................................................................25-4 25.2.4 Others ............................................................................................................................................25-4 25.3 Working Principle....................................................................................................................................25-4 25.3.1 Functions of NEs...........................................................................................................................25-4 25.3.2 Internal Processing of the System .................................................................................................25-5 25.3.3 External Interfaces.........................................................................................................................25-8 25.4 Service Flow............................................................................................................................................25-8 25.4.1 IP QoS Flow Control in Inter-Office Office Direction Mode for Outgoing Calls .........................25-9 25.4.2 IP QoS Flow Control in Inter-Office Gateway Pair Mode for Outgoing Calls..............................25-9 25.4.3 IP QoS Flow Control in Gateway Pair Mode for Intra-Office Calls............................................25-10 25.5 Data Configuration ................................................................................................................................ 25-11 25.5.1 Overview ..................................................................................................................................... 25-11 25.5.2 Data Configuration at the MSOFTX3000 Side ...........................................................................25-12 25.5.3 Data Configuration at the UMG8900 Side ..................................................................................25-15 25.5.4 Data Configuration Examples .....................................................................................................25-16 25.5.5 Operations by Carriers.................................................................................................................25-18 25.5.6 Operations by Mobile Subscribers ..............................................................................................25-18 25.6 Charging and CDR ................................................................................................................................25-18 25.7 Performance Measurement ....................................................................................................................25-18 25.7.1 Index Description ........................................................................................................................25-19
xviii
Issue 02 (2007-02-15)
Contents
25.7.2 Implementation Principle ............................................................................................................25-19 25.8 Service Interaction.................................................................................................................................25-19 25.9 References .............................................................................................................................................25-19 25.9.1 Standards and Specifications.......................................................................................................25-19 25.9.2 Acronyms and Abbreviations ......................................................................................................25-19 25.10 FAQ .....................................................................................................................................................25-20
26 O-CSI SMS ..............................................................................................................................26-1

26.1 Service Description .................................................................................................................................26-2 26.1.1 Function Code ...............................................................................................................................26-2 26.1.2 Definition ......................................................................................................................................26-2 26.1.3 Standard Compliance ....................................................................................................................26-2 26.1.4 System Specifications....................................................................................................................26-2 26.1.5 Benefits .........................................................................................................................................26-2 26.1.6 Application Scenario .....................................................................................................................26-2 26.1.7 Application Limitations.................................................................................................................26-3 26.2 Availability ..............................................................................................................................................26-3 26.2.1 Requirements for NEs ...................................................................................................................26-3 26.2.2 Requirements for License..............................................................................................................26-3 26.2.3 Applicable Versions.......................................................................................................................26-3 26.2.4 Others ............................................................................................................................................26-4 26.3 Working Principle....................................................................................................................................26-4 26.3.1 Functions of the NEs .....................................................................................................................26-4 26.3.2 Intenal System Processing.............................................................................................................26-4 26.3.3 External Interfaces.........................................................................................................................26-7 26.4 Service Flow............................................................................................................................................26-8 26.5 Data Configuration ................................................................................................................................26-10 26.5.1 Overview .....................................................................................................................................26-10 26.5.2 Data Configuration at the MSOFTX3000 Side ...........................................................................26-10 26.5.3 Data Configuration at the HLR Side ...........................................................................................26-13 26.5.4 Data Configuration Example.......................................................................................................26-13 26.5.5 Table Query Procedure of the O-CSI SMS..................................................................................26-14 26.6 Service Management .............................................................................................................................26-16 26.6.1 Operations by Carriers.................................................................................................................26-17 26.6.2 Operations by Subscribers...........................................................................................................26-18 26.7 Charging and CDR ................................................................................................................................26-18 26.7.1 Charging Principle.......................................................................................................................26-18 26.7.2 CDR.............................................................................................................................................26-18 26.8 Performance Measurement ....................................................................................................................26-18 26.9 Service Interaction.................................................................................................................................26-18 26.10 Reference.............................................................................................................................................26-18 26.10.1 Specifications ............................................................................................................................26-18
Issue 02 (2007-02-15)
xix
Contents
HUAWEI MSOFTX3000 Feature Description 26.10.2 Glossary, Acronyms, and Abbreviations....................................................................................26-19
26.11 FAQ .....................................................................................................................................................26-19
27 UP Header Redundancy Data Service................................................................................27-1

27.1 Service Description .................................................................................................................................27-2 27.1.1 Function Code ...............................................................................................................................27-2 27.1.2 Definition ......................................................................................................................................27-2 27.1.3 Benefits .........................................................................................................................................27-2 27.1.4 Application Scenario .....................................................................................................................27-2 27.1.5 Application Limitations.................................................................................................................27-2 27.2 Availability ..............................................................................................................................................27-3 27.2.1 Requirements for NEs ...................................................................................................................27-3 27.2.2 Requirements for License..............................................................................................................27-3 27.2.3 Applicable Versions.......................................................................................................................27-3 27.2.4 Others ............................................................................................................................................27-3 27.3 Working Principle....................................................................................................................................27-3 27.3.1 Functions of the NEs .....................................................................................................................27-3 27.3.2 Internal Processing of the System .................................................................................................27-4 27.3.3 External Interfaces.........................................................................................................................27-8 27.4 Service Flow............................................................................................................................................27-9 27.5 Data Configuration ................................................................................................................................27-15 27.5.1 Data Configuration at the MSOFTX3000 Side ...........................................................................27-15 27.5.2 Data Configuration at the UMG8900 Side ..................................................................................27-17 27.5.3 Data Configuration at the HLR Side ...........................................................................................27-17 27.5.4 Data Configuration Example.......................................................................................................27-17 27.6 Performance Measurement ....................................................................................................................27-19 27.7 Service Interaction.................................................................................................................................27-19 27.8 Reference...............................................................................................................................................27-20 27.8.1 Specifications ..............................................................................................................................27-20 27.8.2 Glossary, Acronyms, and Abbreviations......................................................................................27-20 27.9 FAQ .......................................................................................................................................................27-20
28 VDB Dynamic Data Backup ................................................................................................28-1

28.1 Feature Description .................................................................................................................................28-2 28.1.1 Function Code ...............................................................................................................................28-2 28.1.2 Function Definition .......................................................................................................................28-2 28.1.3 System Specification .....................................................................................................................28-3 28.1.4 Service Benefits.............................................................................................................................28-3 28.1.5 Application Scenario .....................................................................................................................28-3 28.1.6 Use Restriction ..............................................................................................................................28-3 28.2 Availability ..............................................................................................................................................28-4 28.2.1 Requirements for NEs ...................................................................................................................28-4 28.2.2 Requirements for License..............................................................................................................28-4
xx
Issue 02 (2007-02-15)
Contents
28.2.3 Applicable Versions.......................................................................................................................28-4 28.3 Working Principle....................................................................................................................................28-4 28.3.1 Functions Provided by NEs...........................................................................................................28-4 28.3.2 Internal System Processing ...........................................................................................................28-5 28.3.3 External Interfaces.........................................................................................................................28-8 28.4 Service Flow............................................................................................................................................28-8 28.4.1 Subscriber Data Backup FLow......................................................................................................28-8 28.4.2 Processing of Aging upon Dual-Homing Switchover .................................................................28-14 28.4.3 MT Flow Optimization upon Dual-Homing Switchover.............................................................28-14 28.5 Data Configuration ................................................................................................................................28-14 28.5.1 Overview .....................................................................................................................................28-14 28.5.2 Data Configuration at the MSOFTX3000 Side ...........................................................................28-15 28.5.3 Data Configuration at the UMG8900 Side ..................................................................................28-16 28.5.4 Example.......................................................................................................................................28-16 28.6 Service Management .............................................................................................................................28-21 28.7 Charging and CDR ................................................................................................................................28-22 28.8 Interaction with Other Services .............................................................................................................28-22 28.9 Reference...............................................................................................................................................28-22 28.9.1 Specifications ..............................................................................................................................28-22 28.9.2 Glossary, Acronyms, and Abbreviations......................................................................................28-23
29 Multi-Area Network Role-Based and Domain-Based Management Feature.............29-1

29.1 Service Description .................................................................................................................................29-3 29.1.1 Function Code ...............................................................................................................................29-3 29.1.2 Definition ......................................................................................................................................29-3 29.1.3 Standard Compliance ....................................................................................................................29-6 29.1.4 System Specifications....................................................................................................................29-6 29.1.5 Benefits .........................................................................................................................................29-6 29.1.6 Application Scenario .....................................................................................................................29-7 29.1.7 Application Limitations.................................................................................................................29-7 29.2 Availability ..............................................................................................................................................29-7 29.2.1 Requirements for NEs ...................................................................................................................29-7 29.2.2 Requirements for License..............................................................................................................29-8 29.2.3 Applicable Versions.......................................................................................................................29-8 29.2.4 Others ............................................................................................................................................29-8 29.3 Working Principle....................................................................................................................................29-8 29.3.1 Functions of NEs...........................................................................................................................29-8 29.3.2 System Internal Processing ...........................................................................................................29-8 29.3.3 External Interfaces.........................................................................................................................29-9 29.4 Service Flow............................................................................................................................................29-9 29.5 Data Configuration ................................................................................................................................29-10 29.5.1 Overview .....................................................................................................................................29-10
Issue 02 (2007-02-15)
xxi
Contents
HUAWEI MSOFTX3000 Feature Description 29.5.2 Data Configuration on the M2000...............................................................................................29-10 29.5.3 Data Configuration on the MSOFTX3000 ..................................................................................29-16 29.5.4 Data Configuration Example.......................................................................................................29-16
29.6 Service Management .............................................................................................................................29-19 29.7 Charging and CDR ................................................................................................................................29-19 29.8 Performance Measurement ....................................................................................................................29-20 29.9 Service Interaction.................................................................................................................................29-20 29.10 Reference.............................................................................................................................................29-20 29.10.1 Specifications ............................................................................................................................29-20 29.10.2 Acronyms and Abbreviations ....................................................................................................29-20 29.11 FAQ .....................................................................................................................................................29-20
30 Alarm for Malicious Short Messages .................................................................................30-1

30.1 Service Description .................................................................................................................................30-2 30.1.1 Function Code ...............................................................................................................................30-2 30.1.2 Definition ......................................................................................................................................30-2 30.1.3 Standard Compliance ....................................................................................................................30-2 30.1.4 System Specifications....................................................................................................................30-2 30.1.5 Benefits .........................................................................................................................................30-2 30.1.6 Application Scenario .....................................................................................................................30-2 30.1.7 Application Limitations.................................................................................................................30-3 30.2 Availability ..............................................................................................................................................30-3 30.2.1 Requirements for NEs ...................................................................................................................30-3 30.2.2 Requirements for License..............................................................................................................30-3 30.2.3 Applicable Versions.......................................................................................................................30-3 30.2.4 Others ............................................................................................................................................30-4 30.3 Working Principle....................................................................................................................................30-4 30.3.1 Functions of the NEs .....................................................................................................................30-4 30.3.2 Internal Processing of the System .................................................................................................30-4 30.3.3 External Interfaces.........................................................................................................................30-5 30.4 Service Flow............................................................................................................................................30-5 30.5 Data Configuration ..................................................................................................................................30-7 30.5.1 Overview .......................................................................................................................................30-7 30.5.2 Data Configuration at the MSOFTX3000 Side .............................................................................30-7 30.5.3 Data Configuration at the UMG8900 Side ....................................................................................30-8 30.5.4 Data Configuration Examples .......................................................................................................30-8 30.5.5 Data Table Relevant to the Alarm for Malicious Short Messages .................................................30-9 30.6 Service Management ...............................................................................................................................30-9 30.7 Service Interaction...................................................................................................................................30-9
31 Call Simulation.......................................................................................................................31-1
31.1 Service Description .................................................................................................................................31-2 31.1.1 Function Code ...............................................................................................................................31-2
xxii
Issue 02 (2007-02-15)
Contents
31.1.2 Definition ......................................................................................................................................31-2 31.1.3 System Specifications....................................................................................................................31-3 31.1.4 Benefits .........................................................................................................................................31-4 31.1.5 Application Scenario .....................................................................................................................31-4 31.1.6 Application Limitations.................................................................................................................31-4 31.2 Availability ..............................................................................................................................................31-5 31.2.1 Requirements for NEs ...................................................................................................................31-5 31.2.2 Requirements for License..............................................................................................................31-5 31.2.3 Applicable Versions.......................................................................................................................31-5 31.3 Working Principle....................................................................................................................................31-5 31.3.1 Functions of the NEs .....................................................................................................................31-5 31.3.2 Internal Processing of the System .................................................................................................31-8 31.4 Service Flow............................................................................................................................................31-8 31.4.1 Selection of LAI/GCI and Circuits................................................................................................31-8 31.4.2 Handling at the Trunk Side............................................................................................................31-9 31.5 Data Configuration ................................................................................................................................31-10 31.5.1 Configuration Description...........................................................................................................31-10 31.5.2 Data Configuration at the MSOFTX3000 Side ...........................................................................31-10 31.5.3 Data Configuration at the UMG8900 Side ..................................................................................31-10 31.5.4 Data Configuration Example.......................................................................................................31-10 31.6 Service Management ............................................................................................................................. 31-11 31.6.1 Creating a Call Simulation Task.................................................................................................. 31-11 31.6.2 Message Trace and Logs During the Call Simulation .................................................................31-14 31.6.3 Description of the Shortcut Menu of the Message Output Pane..................................................31-15 31.6.4 File Saving ..................................................................................................................................31-16 31.6.5 Operations by Carriers.................................................................................................................31-16 31.7 Charging and CDR ................................................................................................................................31-17 31.8 Performance Measurement ....................................................................................................................31-17 31.9 Service Interaction.................................................................................................................................31-17 31.10 Reference.............................................................................................................................................31-17 31.10.1 Specifications ............................................................................................................................31-17 31.10.2 Glossary, Acronyms, and Abbreviations....................................................................................31-17 31.11 FAQ .....................................................................................................................................................31-18
32 Load-Based Handover ...........................................................................................................32-1

32.1 Service Description .................................................................................................................................32-2 32.1.1 Function Code ...............................................................................................................................32-2 32.1.2 Definition ......................................................................................................................................32-2 32.1.3 System Specifications....................................................................................................................32-2 32.1.4 Benefits .........................................................................................................................................32-3 32.1.5 Application Scenario .....................................................................................................................32-3 32.1.6 Application Limitation ..................................................................................................................32-3
Issue 02 (2007-02-15)
xxiii
Contents
32.2 Availability ..............................................................................................................................................32-3 32.2.1 Requirements for NEs ...................................................................................................................32-3 32.2.2 Requirements for License..............................................................................................................32-4 32.2.3 Applicable Versions.......................................................................................................................32-4 32.2.4 Others ............................................................................................................................................32-4 32.3 Working Principle....................................................................................................................................32-4 32.3.1 Functions of the NEs .....................................................................................................................32-4 32.3.2 Internal Processing of the System .................................................................................................32-6 32.3.3 External Interface ..........................................................................................................................32-7 32.4 Service Flow............................................................................................................................................32-7 32.4.1 Intra-MSC Load-Based Handover From 3G to 2G System...........................................................32-7 32.4.2 Inter-MSC Load-Based Handover From 3G to 2G System...........................................................32-8 32.4.3 Intra-MSC Load-Based Handover From 2G to 3G System...........................................................32-9 32.4.4 Inter-MSC Load-Based Handover From 2G to 3G System...........................................................32-9 32.4.5 Intra-MSC Load-Based Handover in 2G System ........................................................................32-10 32.4.6 Inter-MSC Load-Based Handover in 2G System ........................................................................ 32-11 32.5 Data Configuration ................................................................................................................................32-12 32.5.1 Overview .....................................................................................................................................32-12 32.5.2 Data Configuration at the MSOFTX3000 Side ...........................................................................32-12 32.5.3 Data Configuration at the UMG8900 Side ..................................................................................32-13 32.5.4 Data Configuration Example.......................................................................................................32-13 32.5.5 Data Tables Related to Load-Based Handover ............................................................................32-14 32.6 Service Management .............................................................................................................................32-15 32.6.1 Operations by Carriers.................................................................................................................32-15 32.6.2 Operations by Subscribers...........................................................................................................32-16 32.7 Charging and CDR ................................................................................................................................32-16 32.8 Performance Measurement ....................................................................................................................32-16 32.9 Service Interaction.................................................................................................................................32-16 32.10 Reference.............................................................................................................................................32-16 32.10.1 Specifications ............................................................................................................................32-16 32.10.2 Acronyms and Abbreviations ....................................................................................................32-17 32.11 FAQ .....................................................................................................................................................32-17
33 Union Subscriber Trace ........................................................................................................33-1

33.1 Service Description .................................................................................................................................33-2 33.1.1 Function Code ...............................................................................................................................33-2 33.1.2 Definition ......................................................................................................................................33-2 33.1.3 Benefits .........................................................................................................................................33-3 33.1.4 Application Scenario .....................................................................................................................33-3 33.1.5 Application Limitation ..................................................................................................................33-3 33.1.6 Others ............................................................................................................................................33-3 33.2 Availability ..............................................................................................................................................33-4
xxiv
Issue 02 (2007-02-15)
Contents
33.2.1 Requirements for NEs ...................................................................................................................33-4 33.2.2 Requirements for License..............................................................................................................33-4 33.2.3 Applicable Version ........................................................................................................................33-4 33.3 Working Principle....................................................................................................................................33-4 33.3.1 Functions of NEs...........................................................................................................................33-4 33.3.2 Internal Processing of the System .................................................................................................33-5 33.3.3 External Interface ..........................................................................................................................33-5 33.4 Service Flow............................................................................................................................................33-5 33.4.1 Trace Flow of Activation Message Received from the HLR During Location Update/Data Recovery ..................................................................................................................................................................33-5 33.4.2 Trace Flow of Activation Message Sent by the HLR ....................................................................33-6 33.4.3 Trace Flow of Deactivation Trace Sent by the HLR......................................................................33-7 33.4.4 Trace Flow of the Initiation Call ...................................................................................................33-8 33.4.5 Trace Flow of the Termination Call...............................................................................................33-8 33.4.6 Trace Flow of the Originated Short Message ................................................................................33-9 33.4.7 Trace Flow of the Terminated Short Message ...............................................................................33-9 33.4.8 Trace Flow of Power-On/Location Update..................................................................................33-10 33.4.9 Trace Flow of Power-Off and Trace File Generated....................................................................33-10 33.5 Data Configuration ................................................................................................................................ 33-11 33.5.1 Overview ..................................................................................................................................... 33-11 33.5.2 Data Configuration at the MSOFTX3000 Side ........................................................................... 33-11 33.5.3 Data Configuration at the HLR Side ........................................................................................... 33-11 33.5.4 Data Configuration Examples ..................................................................................................... 33-11 33.5.5 Related Tables .............................................................................................................................33-12 33.6 Service Management .............................................................................................................................33-12 33.6.1 Operation by Carriers ..................................................................................................................33-12 33.6.2 Operations by Subscribers...........................................................................................................33-13 33.7 Charging and CDR ................................................................................................................................33-13 33.8 Performance Management.....................................................................................................................33-13 33.9 Service Interaction.................................................................................................................................33-14 33.10 Reference.............................................................................................................................................33-14 33.10.1 Specification..............................................................................................................................33-14 33.10.2 Glossary, Acronyms and Abbreviations.....................................................................................33-14
34 Service Restriction by Cell ...................................................................................................34-1

34.1 Service Description .................................................................................................................................34-2 34.1.1 Function Code ...............................................................................................................................34-2 34.1.2 Definition ......................................................................................................................................34-2 34.1.3 System Specifications....................................................................................................................34-3 34.1.4 Benefits .........................................................................................................................................34-3 34.1.5 Application Scenario .....................................................................................................................34-3 34.1.6 Application Limitations.................................................................................................................34-3 34.2 Availability ..............................................................................................................................................34-4
Issue 02 (2007-02-15)
xxv
Contents
HUAWEI MSOFTX3000 Feature Description 34.2.1 Requirement for NEs.....................................................................................................................34-4 34.2.2 Requirement for License ...............................................................................................................34-4 34.2.3 Applicable Version ........................................................................................................................34-4 34.2.4 Others ............................................................................................................................................34-4
34.3 Working Principle....................................................................................................................................34-4 34.3.1 Functions of the NEs .....................................................................................................................34-4 34.3.2 Service Implementation.................................................................................................................34-4 34.3.3 External Interfaces.........................................................................................................................34-5 34.4 Service Flow............................................................................................................................................34-5 34.4.1 Location Update Message Flow ....................................................................................................34-6 34.4.2 Originated Service Message Flow.................................................................................................34-6 34.4.3 Terminated Service Message Flow................................................................................................34-8 34.5 Data Configuration ..................................................................................................................................34-9 34.5.1 Overview .......................................................................................................................................34-9 34.5.2 Data Configuration at the MSOFTX3000 Side .............................................................................34-9 34.5.3 Data Configuration Examples .....................................................................................................34-17 34.6 Service Management .............................................................................................................................34-24 34.7 Charging and CDR ................................................................................................................................34-24 34.8 Performance Measurement ....................................................................................................................34-24 34.8.1 Index Description ........................................................................................................................34-24 34.8.2 Implementation Principle ............................................................................................................34-24 34.9 Service Interaction.................................................................................................................................34-24 34.9.1 Enhanced Roaming Restriction and ZC Roaming Restriction ....................................................34-25 34.10 Reference.............................................................................................................................................34-25 34.10.1 Specifications ............................................................................................................................34-25 34.10.2 Acronyms and Abbreviations ....................................................................................................34-25 34.11 FAQ .....................................................................................................................................................34-26
35 Dialing Test on Designated TDM Circuit.........................................................................35-1

35.1 Service Description .................................................................................................................................35-2 35.1.1 Function Code ...............................................................................................................................35-2 35.1.2 Definition ......................................................................................................................................35-2 35.1.3 Benefits .........................................................................................................................................35-3 35.1.4 Application Scenario .....................................................................................................................35-3 35.1.5 Application Limitations.................................................................................................................35-3 35.2 Availability ..............................................................................................................................................35-3 35.2.1 Requirements for NEs ...................................................................................................................35-3 35.2.2 Requirements for License..............................................................................................................35-3 35.2.3 Applicable Versions.......................................................................................................................35-3 35.3 Working Principle....................................................................................................................................35-4 35.3.1 Functions of NEs...........................................................................................................................35-4 35.3.2 Internal Processing of the System .................................................................................................35-4
xxvi
Issue 02 (2007-02-15)
Contents
35.4 Service Flow............................................................................................................................................35-5 35.4.1 Dialing Test on the Designated TDM Circuit for the Trunk Outgoing Call ..................................35-5 35.4.2 Dialing Test on the Designated TDM Circuit for the Intra-Office Call .........................................35-7 35.4.3 Dialing Test on the Designated TDM Circuit for the Incoming Call.............................................35-9 35.5 Data Configuration ..................................................................................................................................35-9 35.5.1 Configuration Description.............................................................................................................35-9 35.5.2 Data Configuration at the MSOFTX3000 Side .............................................................................35-9 35.5.3 Data Configuration at the UMG8900 Side ..................................................................................35-10 35.5.4 Data Configuration Examples .....................................................................................................35-10 35.6 Charging and CDR ................................................................................................................................ 35-11 35.7 Performance Measurement ....................................................................................................................35-12 35.8 Service Interaction.................................................................................................................................35-12 35.9 Reference...............................................................................................................................................35-12 35.9.1 Specifications ..............................................................................................................................35-12 35.9.2 Acronyms and Abbreviations ......................................................................................................35-12 35.10 FAQ .....................................................................................................................................................35-12
36 IN Service Performance Measurement Enhancement ....................................................36-1

36.1 Service Description .................................................................................................................................36-3 36.1.1 Function Code ...............................................................................................................................36-3 36.1.2 Definition ......................................................................................................................................36-3 36.1.3 System Specifications....................................................................................................................36-3 36.1.4 Denefits .........................................................................................................................................36-4 36.1.5 Application Scenrio .......................................................................................................................36-4 36.1.6 Application Limitations.................................................................................................................36-4 36.2 Availability ..............................................................................................................................................36-4 36.2.1 Requirements for NEs ...................................................................................................................36-4 36.2.2 Requirement for License ...............................................................................................................36-5 36.2.3 Applicable Versions.......................................................................................................................36-5 36.2.4 Others ............................................................................................................................................36-5 36.3 Working Principle....................................................................................................................................36-5 36.3.1 Functions of NEs...........................................................................................................................36-5 36.3.2 Internal Processing of the System .................................................................................................36-5 36.3.3 External Interfaces.........................................................................................................................36-8 36.4 Service Flow............................................................................................................................................36-8 36.4.1 Traffic for WIN User Calling Fixed User......................................................................................36-8 36.4.2 Traffic for WIN User Calling Other MSC User ............................................................................36-9 36.4.3 Traffic for Fixed User Calling WIN User.................................................................................... 36-11 36.4.4 Traffic for Other MSC User Calling WIN User ..........................................................................36-12 36.5 Data Configuration ................................................................................................................................36-13 36.5.1 Description ..................................................................................................................................36-13 36.5.2 Data Configuration at the MSOFTX3000 Side ...........................................................................36-14
Issue 02 (2007-02-15)
xxvii
Contents
HUAWEI MSOFTX3000 Feature Description 36.5.3 Data Configuration Examples .....................................................................................................36-14
36.6 Service Management .............................................................................................................................36-18 36.6.1 Operations by Carriers.................................................................................................................36-18 36.6.2 Operations by Subscribers...........................................................................................................36-18 36.7 Charging and CDR ................................................................................................................................36-18 36.8 Performance Measurement ....................................................................................................................36-19 36.8.1 Specification Descriprion ............................................................................................................36-19 36.8.2 Implementation Principle ............................................................................................................36-19 36.9 Service Interaction.................................................................................................................................36-20 36.10 Reference.............................................................................................................................................36-20 36.10.1 Specifications ............................................................................................................................36-20 36.10.2 Glossary, Acronyms, and Abbreviations....................................................................................36-20 36.11 FAQ .....................................................................................................................................................36-20
37 Automatic Device Detection ................................................................................................37-1

37.1 Service Description .................................................................................................................................37-2 37.1.1 Function Code ...............................................................................................................................37-2 37.1.2 Definition ......................................................................................................................................37-2 37.1.3 Standard Compliance ....................................................................................................................37-2 37.1.4 System Specifications....................................................................................................................37-2 37.1.5 Benefits .........................................................................................................................................37-2 37.1.6 Application Scenario .....................................................................................................................37-3 37.1.7 Application Limitations.................................................................................................................37-3 37.2 Availability ..............................................................................................................................................37-3 37.2.1 Requirements for NEs ...................................................................................................................37-3 37.2.2 Requirements for License..............................................................................................................37-3 37.2.3 Applicable Versions.......................................................................................................................37-3 37.2.4 Other..............................................................................................................................................37-3 37.3 Working Principle....................................................................................................................................37-4 37.3.1 Functions of the NEs .....................................................................................................................37-4 37.3.2 Internal Processing of the System .................................................................................................37-4 37.3.3 External Interfaces.........................................................................................................................37-5 37.4 Service Flow............................................................................................................................................37-5 37.5 Data Configuration ..................................................................................................................................37-7 37.5.1 Configuration Description.............................................................................................................37-7 37.5.2 Data Configuration at the MSOFTX3000 .....................................................................................37-7 37.5.3 Data Configuration Example.........................................................................................................37-8 37.5.4 Table Query Flow of ADD ............................................................................................................37-9 37.6 Service Management .............................................................................................................................37-10 37.6.1 Overview .....................................................................................................................................37-10 37.6.2 Operations by Carriers................................................................................................................. 37-11 37.6.3 Operations by Subscribers........................................................................................................... 37-11
xxviii
Issue 02 (2007-02-15)
Contents
37.7 Reference............................................................................................................................................... 37-11 37.7.1 Specifications .............................................................................................................................. 37-11 37.7.2 Acronyms and Abbreviations ...................................................................................................... 37-11 37.8 FAQ .......................................................................................................................................................37-12 37.8.1 Problem Description....................................................................................................................37-12 37.8.2 Cause of the Problem ..................................................................................................................37-12 37.8.3 Method ........................................................................................................................................37-12
38 Noise Suppression .................................................................................................................38-1

38.1 Service Description .................................................................................................................................38-2 38.1.1 Function Code ...............................................................................................................................38-2 38.1.2 Definition ......................................................................................................................................38-2 38.1.3 Standard Compliance ....................................................................................................................38-2 38.1.4 System Specifications....................................................................................................................38-3 38.1.5 Benefits .........................................................................................................................................38-3 38.1.6 Application Scenario .....................................................................................................................38-3 38.1.7 Application Limitations.................................................................................................................38-3 38.2 Availability ..............................................................................................................................................38-4 38.2.1 Requirements for NEs ...................................................................................................................38-4 38.2.2 Requirements for License..............................................................................................................38-4 38.2.3 Supporting Versions ......................................................................................................................38-4 38.2.4 Others ............................................................................................................................................38-4 38.3 Working Principle....................................................................................................................................38-4 38.3.1 Functions of NEs...........................................................................................................................38-4 38.3.2 Internal Processing ........................................................................................................................38-5 38.3.3 External Interfaces.........................................................................................................................38-5 38.4 Service Flow............................................................................................................................................38-5 38.5 Data Configuration ..................................................................................................................................38-6 38.5.1 Overview .......................................................................................................................................38-6 38.5.2 Configuration at the MSOFTX3000 Side......................................................................................38-7 38.5.3 Configuration on the UMG8900 Side ...........................................................................................38-7 38.5.4 Data Configuration Examples .......................................................................................................38-8 38.5.5 Table Query Flow of Noise Suppression Feature ..........................................................................38-9 38.5.6 Table Query Flow of Noise Suppression Feature ........................................................................38-10 38.6 Service Management ............................................................................................................................. 38-11 38.6.1 Operations by Carriers................................................................................................................. 38-11 38.6.2 Operations by Subscribers........................................................................................................... 38-11 38.7 Charging and CDR ................................................................................................................................ 38-11 38.8 Performance Measurement ....................................................................................................................38-12 38.9 Service Interaction.................................................................................................................................38-12 38.10 Reference.............................................................................................................................................38-12 38.10.1 Specifications ............................................................................................................................38-12
Issue 02 (2007-02-15)
xxix
Contents
HUAWEI MSOFTX3000 Feature Description 38.10.2 Glossary, Acronyms and Abbreviations.....................................................................................38-12
38.11 FAQ .....................................................................................................................................................38-13
39 TDM Circuit Selection Based on Service Type................................................................39-1

39.1 Service Description .................................................................................................................................39-2 39.1.1 Function Code ...............................................................................................................................39-2 39.1.2 Definition ......................................................................................................................................39-2 39.1.3 Standard Compliance ....................................................................................................................39-2 39.1.4 System Specifications....................................................................................................................39-2 39.1.5 Benefits .........................................................................................................................................39-3 39.1.6 Application Scenario .....................................................................................................................39-3 39.2 Availability ..............................................................................................................................................39-3 39.2.1 Requirements for NEs ...................................................................................................................39-3 39.2.2 Requirements for License..............................................................................................................39-3 39.2.3 Supporting Versions ......................................................................................................................39-3 39.2.4 Others ............................................................................................................................................39-4 39.3 Working Principle....................................................................................................................................39-4 39.3.1 Functions of the NEs .....................................................................................................................39-4 39.3.2 External Interface ..........................................................................................................................39-5 39.4 Data Configuration ..................................................................................................................................39-5 39.4.1 Overview of Configuration ...........................................................................................................39-5 39.4.2 Data Configuration at the MSOFTX3000 Side .............................................................................39-5 39.4.3 Configuration Examples................................................................................................................39-6 39.4.4 Data Configuration at the UMG8900 Side ..................................................................................39-10 39.5 Service Management .............................................................................................................................39-10 39.6 Charging and CDR ................................................................................................................................39-10 39.7 Performance Measurement ....................................................................................................................39-10 39.8 Service Interaction.................................................................................................................................39-10 39.9 FAQ .......................................................................................................................................................39-10
40 BICC and ISUP Route Allowed for the Same Office Direction....................................40-1
40.1 Service Description .................................................................................................................................40-2 40.1.1 Function Code ...............................................................................................................................40-2 40.1.2 Definition ......................................................................................................................................40-2 40.1.3 Standard Compliance ....................................................................................................................40-3 40.1.4 System Specifications....................................................................................................................40-3 40.1.5 Benefits .........................................................................................................................................40-4 40.1.6 Application Scenario .....................................................................................................................40-4 40.1.7 Application Limitations.................................................................................................................40-5 40.2 Availability ..............................................................................................................................................40-6 40.2.1 Requirements for NEs ...................................................................................................................40-6 40.2.2 Requirements for License..............................................................................................................40-6 40.2.3 Supporting Versions ......................................................................................................................40-6
xxx
Issue 02 (2007-02-15)
Contents
40.2.4 Others ............................................................................................................................................40-6 40.3 Working Principle....................................................................................................................................40-6 40.3.1 Functions of the NEs .....................................................................................................................40-6 40.3.2 Internal Processing of the System .................................................................................................40-6 40.3.3 External Interfaces.........................................................................................................................40-8 40.4 Service Flow............................................................................................................................................40-8 40.5 Data Configuration ..................................................................................................................................40-8 40.5.1 Overview .......................................................................................................................................40-8 40.5.2 Data Configuration at the MSOFTX3000 Side .............................................................................40-8 40.5.3 Data Configuration at the UMG8900 Side .................................................................................. 40-11 40.5.4 Data Configuration Examples .....................................................................................................40-12 40.6 Service Management .............................................................................................................................40-16 40.6.1 Operations by Carriers.................................................................................................................40-16 40.6.2 Operations by Mobile Subscribers ..............................................................................................40-16 40.7 Charging and CDR ................................................................................................................................40-16 40.8 Performance Measurement ....................................................................................................................40-16 40.9 Service Interaction.................................................................................................................................40-16 40.10 References ...........................................................................................................................................40-17 40.10.1 Standards and Specifications.....................................................................................................40-17 40.10.2 Acronyms and Abbreviations ....................................................................................................40-17 40.11 FAQ .....................................................................................................................................................40-17
Index ................................................................................................................................................ i-1
Issue 02 (2007-02-15)
xxxi
Figures
Figures
Figure 1-1 Networking model of the call from a mobile subscriber to a fixed line subscriber.........................1-8 Figure 1-2 Flow of the call from a mobile subscriber to a fixed line subscriber (1).........................................1-9 Figure 1-3 Flow of the call from a mobile subscriber to a fixed line subscriber (2).......................................1-10 Figure 1-4 Flow of the call from a fixed line subscriber to a mobile subscriber ............................................1-13 Figure 1-5 Networking model of a call from a mobile subscriber to another mobile subscriber....................1-15 Figure 1-6 Flow of the call from a mobile subscriber to another mobile subscriber (1).................................1-16 Figure 1-7 Flow of the call from a mobile subscriber to another mobile subscriber (2).................................1-17 Figure 1-8 Flow of the call from a mobile subscriber to another mobile subscriber (3).................................1-18 Figure 1-9 Process of generating CDRs when the mobile caller and callee are under the same VMSC ........1-23 Figure 1-10 Process of generating CDRs when the mobile caller and callee are under different VMSCs .....1-23 Figure 1-11 Process of generating CDRs when a mobile subscriber calls a fixed line subscriber..................1-23 Figure 1-12 Process of generating CDRs when a fixed line subscriber calls a mobile subscriber .................1-24 Figure 1-13 Process of generating CDRs when the mobile caller and callee are in different wireless networks .........................................................................................................................................................................1-25 Figure 2-1 Location of the SMC in a mobile network......................................................................................2-5 Figure 2-2 MAP_SEND_ROUTING_INFO_FOR_SM flow...........................................................................2-7 Figure 2-3 MAP_REPORT_SM_DELIVERY_STATUS flow.........................................................................2-7 Figure 2-4 MAP_READY_FOR_SM flow ......................................................................................................2-8 Figure 2-5 MAP_ALERT_SERVICE_CENTRE flow .....................................................................................2-8 Figure 2-6 SM MO flow...................................................................................................................................2-9 Figure 2-7 SM MT flow .................................................................................................................................2-10 Figure 2-8 Flow of alert SMC mobile station reachable.............................................................................. 2-11 Figure 2-9 Flow of alert SMC memory of MS ready ..................................................................................2-12 Figure 2-10 Flow of alert SMC SMS succeeds ...........................................................................................2-13 Figure 3-1 GMSC-originated call forwarding service flow..............................................................................3-5 Figure 3-2 VMSC-originated call forwarding service flow..............................................................................3-6 Figure 3-3 CFU service flow for a call forwarded to a PSTN subscriber.........................................................3-7
xxxii
Issue 02 (2007-02-15)
Figures
Figure 3-4 CFU service flow for a call forwarded to a mobile subscriber........................................................3-8 Figure 3-5 NDUB service flow for a call forwarded to a PSTN subscriber .....................................................3-9 Figure 3-6 UDUB service flow for a call forwarded to a PSTN subscriber ...................................................3-10 Figure 3-7 NDUB service flow for a call forwarded to a mobile subscriber .................................................. 3-11 Figure 3-8 UDUB service flow for a call forwarded to a mobile subscriber ..................................................3-12 Figure 3-9 CFNRy service flow for a call forwarded to a PSTN subscriber ..................................................3-13 Figure 3-10 CFNRy service flow for a call forwarded to a mobile subscriber. ..............................................3-14 Figure 3-11 CFNRc service flow for call forwarded to a PSTN subscriber ...................................................3-16 Figure 3-12 CFNRc service flow for the mobile forwarded-to subscriber .....................................................3-17 Figure 3-13 Charging of the call forwarding services ....................................................................................3-22 Figure 4-1 CLIP service flow ...........................................................................................................................4-6 Figure 4-2 CLIR service flow...........................................................................................................................4-7 Figure 4-3 COLP service flow..........................................................................................................................4-8 Figure 4-4 COLR service flow .........................................................................................................................4-8 Figure 5-1 Service flow when a subscriber accepts a waiting call ...................................................................5-7 Figure 5-2 Service flow when a subscriber rejects a waiting call.....................................................................5-9 Figure 5-3 Service flow for holding and retrieving a call...............................................................................5-10 Figure 5-4 Service flow for alternating from the A-B call to the A-C call ..................................................... 5-11 Figure 6-1 Setting up the MPTY call................................................................................................................6-6 Figure 6-2 Create a personal communication ...................................................................................................6-7 Figure 6-3 Add a remote subscriber..................................................................................................................6-7 Figure 6-4 Disconnect the remote subscriber by main controller .....................................................................6-8 Figure 6-5 Disconnect the remote subscriber by main controller .....................................................................6-9 Figure 7-1 Check flow of the VLR for the BAOC service ...............................................................................7-5 Figure 7-2 Check flow of the VLR for the BOIC service.................................................................................7-6 Figure 7-3 Check flow of the VLR for the BOIC-exHC service ......................................................................7-7 Figure 7-4 Check flow of the HLR for the BAIC service.................................................................................7-8 Figure 7-5 Check flow of the HLR for the BIC-ROAM service ......................................................................7-9 Figure 7-6 BO service flow ............................................................................................................................7-10 Figure 7-7 BI service flow.............................................................................................................................. 7-11 Figure 8-1 Invoking the ECT when A-B call is on hold and A-C call is in the active state..............................8-5 Figure 8-2 Invoking the ECT when C is in the alerting state............................................................................8-6 Figure 10-1 Flow of UMTS authentication ....................................................................................................10-4
Issue 02 (2007-02-15)
xxxiii
Figures
HUAWEI MSOFTX3000 Feature Description Figure 10-2 Flow of GSM authentication.......................................................................................................10-6 Figure 11-1 Simple MSRN allocation procedure............................................................................................ 11-6 Figure 11-2 General procedure of MSRN allocation ...................................................................................... 11-7 Figure 11-3 Procedure for random allocation ................................................................................................. 11-8 Figure 11-4 Mapping between the MSRN or HON allocation tables ............................................................. 11-9 Figure 12-1 MS-originated call (early assignment) ........................................................................................12-4 Figure 12-2 MS-originated call (late assignment) ..........................................................................................12-5 Figure 12-3 MS-terminated call (early assignment) .......................................................................................12-6 Figure 12-4 MS-terminated call (late assignment) .........................................................................................12-8 Figure 12-5 Early resource assignment for the caller ...................................................................................12-10 Figure 12-6 Late resource assignment for the caller.....................................................................................12-12 Figure 12-7 Early resource assignment for the callee...................................................................................12-14 Figure 12-8 Late resource assignment for the callee ....................................................................................12-16 Figure 13-1 Triggering IN service (T-CSI) .....................................................................................................13-4 Figure 13-2 Routing out the call directly to another office (T -CSI) ..............................................................13-5 Figure 13-3 Ignoring IN service (T-CSI) ........................................................................................................13-6 Figure 13-4 Triggering IN service (early forwarding with O-CSI).................................................................13-7 Figure 13-5 Routing out the call directly to another office (early forwarding with O-CSI) ...........................13-8 Figure 13-6 Ignoring IN service (early forwarding with O-CSI)....................................................................13-9 Figure 14-1 Networking of MNP service .......................................................................................................14-4 Figure 14-2 External network subscriber calls a ported out local network subscriber ...................................14-5 Figure 14-3 External network subscriber calls a subscriber ported in the Local Network but does not exist in the local network .............................................................................................................................................14-6 Figure 14-4 MNP service flow in OR mode ...................................................................................................14-7 Figure 14-5 Local network subscriber calls a ported out local network subscriber based on the IN..............14-8 Figure 14-6 Local network subscriber calls a ported out local network subscriber based on signaling .........14-8 Figure 17-1 Local Maintenance Monitor tabbed page....................................................................................17-2 Figure 17-2 User Monitor interface ................................................................................................................17-8 Figure 17-3 Subscribed NE List interface ......................................................................................................17-8 Figure 17-4 User Monitor interface ..............................................................................................................17-10 Figure 17-5 User Session interface 1............................................................................................................17-10 Figure 17-6 User Session interface 2............................................................................................................17-10 Figure 17-7 Filtering interface...................................................................................................................... 17-11 Figure 18-1 Processing flow of SMS notification for call failure triggered in the GMSC .............................18-5
xxxiv
Issue 02 (2007-02-15)
Figures
Figure 18-2 Processing flow of SMS notification for call failure generated in the VMSC ............................18-6 Figure 18-3 Triggering point of SMS notification for call failure in the GMSC ............................................18-7 Figure 18-4 Triggering point of SMS notification for call failure in the VMSC ............................................18-8 Figure 18-5 Processing flow after SMS notification for call failure is triggered............................................18-9 Figure 19-1 Synchronization relationship between the NTP server, BAM server, and the host.....................19-4 Figure 19-2 Time icon of Windows2000 operating system ............................................................................19-5 Figure 19-3 Adjusting clock for daylight saving changes...............................................................................19-6 Figure 20-1 Patch operation flow ...................................................................................................................20-5 Figure 21-1 Sketch of the active and the standby areas..................................................................................21-4 Figure 21-2 Illustration of state transition during configuration rollback.......................................................21-5 Figure 21-3 State transition of data in the standby area..................................................................................21-7 Figure 22-1 CAP message flow of the CAMEL4 third-party call ..................................................................22-8 Figure 22-2 CAP message flow of the IN RBT ............................................................................................22-10 Figure 22-3 CAP message flow of the simultaneous ringing with C answering the call first....................... 22-11 Figure 22-4 CAP message flow of the simultaneous ringing with B answering the call first.......................22-12 Figure 22-5 NC failure in the CAMEL4.......................................................................................................22-23 Figure 23-1 International roaming subscriber originates a call and the callee is power-off (the GMSC server and VMSC server are combined) ....................................................................................................................23-6 Figure 23-2 Service flow in the case of an abnormal call...............................................................................23-7 Figure 23-3 Table query flow in the IMSI-based announcement service .....................................................23-12 Figure 24-1 Internal processing of IP over E1 processing in the MSOFTX3000 ...........................................24-5 Figure 24-2 IP over E1 bearer adopted inter-office MGWs............................................................................24-6 Figure 24-3 IP over E1 bearer adopted by intra-office MGWs.......................................................................24-7 Figure 24-4 Inter-office call flow of forward fast...........................................................................................24-8 Figure 24-5 Inter-office call flow of forward delay ........................................................................................24-9 Figure 24-6 Inter-office call flow of backward delay ...................................................................................24-10 Figure 24-7 Setup of intra-office medium cluster.........................................................................................24-10 Figure 24-8 Typical networking of IP over E1 .............................................................................................24-17 Figure 25-1 Networking of the IP QoS flow control granularity....................................................................25-6 Figure 25-2 IP QoS processing flow in inter-office office direction mode.....................................................25-9 Figure 25-3 IP QoS processing flow in inter-office gateway pair mode for inter-office calls ......................25-10 Figure 25-4 IP QoS processing flow in gateway pair mode for intra-office calls......................................... 25-11 Figure 26-1 Internal processing of system when the sending of short message is allowed by the SCP .........26-5 Figure 26-2 Internal processing of system when the sending of short message is prohibited by the SCP .....26-6
Issue 02 (2007-02-15)
xxxv
Figures
HUAWEI MSOFTX3000 Feature Description Figure 26-3 Service flow when the sending of short message is allowed by the SCP....................................26-8 Figure 26-4 Service flow when the sending of short message is prohibited by the SCP..............................26-10 Figure 26-5 Procedure for querying the table to obtain the O-CSI SMS processing information ................26-15 Figure 26-6 Procedure for querying the table to obtain the location number in the INITIAL-DP message .26-16 Figure 27-1 Call flow when a narrowband trunk connects to a BICC trunk ..................................................27-4 Figure 27-2 Call flow when a narrowband trunk connects to a narrowband trunk (crossing multiple IP gateways).........................................................................................................................................................27-5 Figure 27-3 Call flow when the access side connects to a BICC trunk (TS61) ..............................................27-6 Figure 27-4 Call flow when the access side connects to a narrowband trunk (crossing multiple IP gateways) .........................................................................................................................................................................27-7 Figure 27-5 Call flow when the access side connects to a BICC trunk (TS62) ..............................................27-8 Figure 27-6 Service flow when a narrowband trunk connects to a BICC trunk (voice service switching to fax service) ..........................................................................................................................................................27-10 Figure 27-7 Service flow when a narrowband trunk connects to a narrowband trunk (crossing multiple IP gateways) (TS61) .......................................................................................................................................... 27-11 Figure 27-8 Service flow when the access side connects to a BICC trunk (using IP bearer between offices) (TS61) ...........................................................................................................................................................27-13 Figure 27-9 Service flow when the access side connects to a BICC trunk (TS62).......................................27-14 Figure 28-1 Dual-homing 1 + 1 mutual-aid networking model......................................................................28-5 Figure 28-2 Dual-homing N+1 backup networking model.............................................................................28-6 Figure 28-3 Block diagram of dual-homing backup.......................................................................................28-6 Figure 28-4 Registering a backup task for location update ............................................................................28-9 Figure 28-5 "Dirty" backup flow ..................................................................................................................28-10 Figure 28-6 Complete backup flow ..............................................................................................................28-10 Figure 28-7 Flow of location information backup........................................................................................ 28-11 Figure 28-8 Flow of status information backup............................................................................................28-12 Figure 28-9 Flow of authentication data backup ..........................................................................................28-12 Figure 28-10 Flow of synchronous deleting backup data .............................................................................28-13 Figure 29-1 Relationship between domains and resources.............................................................................29-6 Figure 29-2 Flowchart of the role-based and domain-based management service .........................................29-9 Figure 29-3 Create Domain .......................................................................................................................... 29-11 Figure 29-4 Bind User ..................................................................................................................................29-12 Figure 29-5 Bind NE ....................................................................................................................................29-13 Figure 29-6 Rename Domain........................................................................................................................29-14 Figure 29-7 Delete Domain ..........................................................................................................................29-16
xxxvi
Issue 02 (2007-02-15)
Figures
Figure 30-1 Processing of the NEs for the alarm for malicious short messages service ................................30-5 Figure 30-2 Process of the alarm for malicious short messages .....................................................................30-6 Figure 31-1 Example of the BAM log ............................................................................................................31-7 Figure 31-2 Detailed query result .................................................................................................................31-12 Figure 31-3 Specifying the querying conditions...........................................................................................31-12 Figure 31-4 Displayed query result ..............................................................................................................31-13 Figure 31-5 Call simulation node .................................................................................................................31-13 Figure 31-6 Specifying call simulation related parameters. .........................................................................31-14 Figure 31-7 Message output format..............................................................................................................31-14 Figure 31-8 Shortcut menu in the output pane..............................................................................................31-16 Figure 32-1 Flow of the intra-MSC handover ................................................................................................32-6 Figure 32-2 Flow of the inter-MSC handover ................................................................................................32-6 Figure 32-3 Intra-MSC load-based handover from 3G to 2G system.............................................................32-7 Figure 32-4 Inter-MSC load-based handover from 3G to 2G system.............................................................32-8 Figure 32-5 Intra-MSC load-based handover from 2G to 3G system.............................................................32-9 Figure 32-6 Inter-MSC load-based handover from 2G to 3G system...........................................................32-10 Figure 32-7 Intra-MSC load-based handover in the 2G network ................................................................. 32-11 Figure 32-8 Inter-MSC load-based handover in the 2G network .................................................................32-12 Figure 33-1 Trace flow of the activation message received from the HLR during location update/data recovery .........................................................................................................................................................................33-6 Figure 33-2 Trace flow of the activation message sent by the HLR...............................................................33-7 Figure 33-3 Flow of the deactivation trace sent by the HLR..........................................................................33-7 Figure 33-4 Trace flow of the initiation call ...................................................................................................33-8 Figure 33-5 Trace flow of the termination call ...............................................................................................33-8 Figure 33-6 Trace flow of the originated short message.................................................................................33-9 Figure 33-7 Trace flow of the terminated short message................................................................................33-9 Figure 33-8 Trace flow of power-on/location update ...................................................................................33-10 Figure 33-9 Trace flow of the power-off ......................................................................................................33-10 Figure 34-1 Location update message flow....................................................................................................34-6 Figure 34-2 Originated service message flow ................................................................................................34-7 Figure 34-3 Terminated service message flow ...............................................................................................34-8 Figure 35-1 Dialing test model on the designated TDM circuit. ....................................................................35-2 Figure 35-2 Processing flow inside the system...............................................................................................35-4
Issue 02 (2007-02-15)
xxxvii
Figures
HUAWEI MSOFTX3000 Feature Description Figure 35-3 Flow of the dialing test on the designated TDM circuit for the trunk outgoing call from the MS to the PSTN .........................................................................................................................................................35-6 Figure 35-4 Message flow of the dialing test on the designated TDM circuit for the intra-office call ...........35-8 Figure 36-1 Transiting a call out after caller IN service invoked in the local office.......................................36-6 Figure 36-2 Callee IN service invoked in the local office for a trunk incoming call......................................36-7 Figure 36-3 WIN user calling fixed user ........................................................................................................36-8 Figure 36-4 WIN user calling other MSC user without acquiring roaming number in the local office..........36-9 Figure 36-5 WIN user calling other MSC user with acquiring roaming number in the local office.............36-10 Figure 36-6 Fixed user calling WIN user ..................................................................................................... 36-11 Figure 36-7 Other MSC user calling WIN user ............................................................................................36-12 Figure 36-8 Special flow of the number regulation ......................................................................................36-13 Figure 37-1 Flow of the ADD service ............................................................................................................37-4 Figure 37-2 ADD message flow .....................................................................................................................37-5 Figure 37-3 Table query flow of the ADD service........................................................................................37-10 Figure 38-1 Networking of the system internal processing ............................................................................38-5 Figure 38-2 Service flow of the noise suppression feature.............................................................................38-6 Figure 38-3 Table query flow of noise suppression service (Support noise removing benefit local end).....38-10 Figure 38-4 Table query flow of noise suppression service (Support noise removing benefit peer end) ..... 38-11 Figure 39-1 TDM circuit selection based on the service type ........................................................................39-4 Figure 40-1 Current networking of China Mobile..........................................................................................40-3 Figure 40-2 Scenario 1 ...................................................................................................................................40-4 Figure 40-3 Scenario 2 ...................................................................................................................................40-5 Figure 40-4 Scenario 3 ...................................................................................................................................40-5
xxxviii
Issue 02 (2007-02-15)
Tables
Tables
Table 1-1 Function names and function codes in the speech service ................................................................1-2 Table 1-2 Definitions of functions in the speech service ..................................................................................1-2 Table 1-3 Benefits for carriers and mobile subscribers.....................................................................................1-4 Table 1-4 NEs involved in the speech service ..................................................................................................1-4 Table 1-5 Versions of the products that support the speech service ..................................................................1-5 Table 1-6 Differences between early assignment and late assignment ...........................................................1-20 Table 1-7 Configuration steps .........................................................................................................................1-21 Table 1-8 Interaction between the emergency call function and other services ..............................................1-26 Table 2-1 NEs required to realize the SMS.......................................................................................................2-4 Table 2-2 HUAWEI CS product versions that support the SMS.......................................................................2-4 Table 2-3 Functions of NEs in the transmission of SMs...................................................................................2-5 Table 2-4 Functions of NEs in the transmission of SMs...................................................................................2-6 Table 2-5 Interaction between the SMS and other services ............................................................................2-16 Table 3-1 Function code....................................................................................................................................3-2 Table 3-2 Definitions of the call forwarding services .......................................................................................3-2 Table 3-3 Benefits of the call forwarding services............................................................................................3-3 Table 3-4 Related NEs ......................................................................................................................................3-3 Table 3-5 Applicable versions...........................................................................................................................3-4 Table 3-6 Operation modes of the call forwarding service .............................................................................3-18 Table 3-7 CFU service operations...................................................................................................................3-19 Table 3-8 CFB service operations...................................................................................................................3-20 Table 3-9 CFNRy service operations ..............................................................................................................3-20 Table 3-10 CFNRc service operation..............................................................................................................3-20 Table 3-11 Operations applicable to all the call forwarding services..............................................................3-21 Table 3-12 All the CCF services .....................................................................................................................3-21 Table 3-13 CDR creation principles................................................................................................................3-23
Issue 02 (2007-02-15)
xxxix
Tables
HUAWEI MSOFTX3000 Feature Description Table 3-14 Interaction between the CFU and other services...........................................................................3-24 Table 3-15 Interaction Between CUG and Call Forwarding...........................................................................3-27 Table 3-16 Service interaction between the CFB and other services ..............................................................3-28 Table 3-17 Interaction between CFNRy and other services ............................................................................3-30 Table 3-18 Interaction between CFNRc and other services ............................................................................3-33 Table 4-1 Names and codes of functions ..........................................................................................................4-2 Table 4-2 Beneficiaries and description of the benefits ....................................................................................4-4 Table 4-3 NEs required by the line identification services ...............................................................................4-4 Table 4-4 Applicable versions of Huawei wireless core network products.......................................................4-5 Table 4-5 Operation modes of the line identification services........................................................................ 4-11 Table 4-6 CLIR service operation performed by mobile subscribers..............................................................4-12 Table 4-7 Interactions between the CLIP service and other services ..............................................................4-12 Table 4-8 Interactions between the CLIR service and other services .............................................................4-13 Table 4-9 Interactions between the COLP service and other services ............................................................4-13 Table 4-10 Interactions between the COLR service and other services..........................................................4-14 Table 5-1 Name and code of the function .........................................................................................................5-2 Table 5-2 Name and definition of the CW and CH services .............................................................................5-2 Table 5-3 Beneficiaries and description of the benefits ....................................................................................5-3 Table 5-4 NEs required by the call completion supplementary services...........................................................5-3 Table 5-5 Applicable versions of Huawei wireless core network products.......................................................5-4 Table 5-6 Related software parameters ...........................................................................................................5-13 Table 5-7 Operation modes of the call completion supplementary services ...................................................5-14 Table 5-8 Operations performed by mobile subscribers .................................................................................5-15 Table 5-9 Interactions between the CW service and other services ................................................................5-18 Table 5-10 Interactions between the CH service and other services ...............................................................5-19 Table 6-1 Network elements involved in MPTY features.................................................................................6-3 Table 6-2 Applicable versions of the MPTY.....................................................................................................6-3 Table 6-3 Operation method for MPTY service.............................................................................................. 6-11 Table 6-4 MPTY service operation (For mobile subscriber)........................................................................... 6-11 Table 6-5 Interactions between the MPTY and the other services ..................................................................6-13 Table 7-1 Name and code of the function .........................................................................................................7-2 Table 7-2 NEs required by the call barring services .........................................................................................7-3 Table 7-3 Applicable versions of Huawei wireless core network products.......................................................7-4
xl
Issue 02 (2007-02-15)
Tables
Table 7-4 Operation modes of the call barring supplementary services .........................................................7-13 Table 7-5 Operations performed by mobile subscribers .................................................................................7-13 Table 7-6 Interactions between the BAOC service and other services ...........................................................7-15 Table 7-7 Interactions between the BOIC service and other services .............................................................7-16 Table 7-8 Interactions between the BOIC-exHC service and other services ..................................................7-17 Table 7-9 Interactions between the BAIC service and other services .............................................................7-18 Table 7-10 Interactions between the BIC-ROAM service and other services.................................................7-19 Table 8-1 Function code of the ECT.................................................................................................................8-2 Table 8-2 Benefits of the ECT ..........................................................................................................................8-2 Table 8-3 Requirements for NEs.......................................................................................................................8-3 Table 8-4 Applicable versions...........................................................................................................................8-3 Table 8-5 Parameters of the related software....................................................................................................8-7 Table 8-6 ECT operation mode .........................................................................................................................8-8 Table 8-7 Scenarios of the ECT independent charging .....................................................................................8-9 Table 8-8 Scenarios of the ECT segmented charging ..................................................................................... 8-11 Table 8-9 Interaction between the ECT and other services.............................................................................8-12 Table 9-1 Name and function code of the ODB services ..................................................................................9-2 Table 9-2 NEs related with the ODB services ..................................................................................................9-4 Table 9-3 Versions that support the ODB services............................................................................................9-5 Table 9-4 Service interaction between ODB and other services .......................................................................9-7 Table 10-1 Function names and functions codes in the authentication and encryption ..................................10-2 Table 10-2 Benefits for carriers and mobile subscribers.................................................................................10-2 Table 10-3 NEs involved in the authentication and encryption ......................................................................10-3 Table 10-4 Versions of the products that support the authentication and encryption......................................10-3 Table 11-1 Name and code of the function ..................................................................................................... 11-2 Table 11-2 Beneficiaries and description of the benefits ................................................................................ 11-4 Table 11-3 NEs required by the enhanced MSRN allocation service ............................................................. 11-4 Table 11-4 Applicable versions of HUAWEI wireless core network products ............................................... 11-5 Table 12-1 Requirement for NEs ....................................................................................................................12-3 Table 12-2 Applicable versions.......................................................................................................................12-3 Table 13-1 Name and function code of the IN service triggering. ..................................................................13-2 Table 13-2 Processing modes of the IN services.............................................................................................13-2 Table 13-3 NEs related to the IN service triggering........................................................................................13-3
Issue 02 (2007-02-15)
xli
Tables
HUAWEI MSOFTX3000 Feature Description Table 13-4 Versions that support the IN service triggering.............................................................................13-3 Table 14-1 Related NEs of MNP feature ........................................................................................................14-3 Table 14-2 Product versions that support the MNP feature ............................................................................14-3 Table 15-1 Value options of Support FAX detection ......................................................................................15-8 Table 15-2 Value options of Support 2198 redundancy ..................................................................................15-8 Table 15-3 Value options of 2198 UP Mode ...................................................................................................15-8 Table 15-4 Value options of 2198 redundancy level .......................................................................................15-8 Table 15-5 Value options of 2198 redundancy CODEC type..........................................................................15-9 Table 15-6 Value options of BICC support red ...............................................................................................15-9 Table 16-1 Parameters of the command LOD LICENSE ...............................................................................16-4 Table 16-2 Parameters of the command LST LICENSE ................................................................................16-6 Table 16-3 Parameters of the command DSP ESN .........................................................................................16-8 Table 16-4 Parameters of the command DSP LICENSE ................................................................................16-9 Table 16-5 Parameters of the command DMP LICENSE .............................................................................16-10 Table 16-6 Parameters of the command ULD LICENSE ............................................................................. 16-11 Table 16-7 Alarms from host ........................................................................................................................16-19 Table 16-8 Alarms from BAM ......................................................................................................................16-19 Table 17-1 Function code of the NE user dynamic monitoring function ........................................................17-2 Table 17-2 Explanations of the Local Maintenance Monitor tabbed page......................................................17-3 Table 17-3 Specifications of the system..........................................................................................................17-4 Table 17-4 Description of benefits..................................................................................................................17-4 Table 17-5 NEs that are involved in this function...........................................................................................17-5 Table 17-6 Version that supports this function................................................................................................17-5 Table 18-1 Benefits of SMS notification for call failure.................................................................................18-2 Table 18-2 Requirements for NEs...................................................................................................................18-3 Table 18-3 Applicable versions.......................................................................................................................18-3 Table 18-4 Script for querying the License...................................................................................................18-10 Table 18-5 Script for setting MAP parameter ............................................................................................... 18-11 Table 18-6 Script for adding the content of SMS notification for call failure............................................... 18-11 Table 18-7 Script for configuring the processing for SMS notification for call failure ................................ 18-11 Table 19-1 Name and function code of the summer time feature ...................................................................19-2 Table 19-2 NEs related to the summer time feature of the wireless time zone ...............................................19-3 Table 19-3 Versions that support the summer time feature of the wireless time zone ....................................19-3
xlii
Issue 02 (2007-02-15)
Tables
Table 19-4 Alarms related to summer time .....................................................................................................19-5 Table 20-1 Network elements concerning with version software management features ................................20-3 Table 20-2 Applicable versions for the version software management features .............................................20-3 Table 20-3 MML command table for patch management ...............................................................................20-7 Table 21-1 Feature name and function code ...................................................................................................21-2 Table 21-2 Benefits of the configuration rollback feature ..............................................................................21-3 Table 21-3 Applicable versions that support the configuration rollback feature.............................................21-3 Table 21-4 Tables that support configuration rollback....................................................................................21-9 Table 21-5 List of configuration rollback commands ...................................................................................21-10 Table 21-6 Synchronization and forcible synchronization commands..........................................................21-14 Table 21-7 Activation and forcible activation commands.............................................................................21-17 Table 21-8 Rollback and forcible rollback commands..................................................................................21-19 Table 21-9 Cancellation and confirmation commands..................................................................................21-21 Table 21-10 Query commands ......................................................................................................................21-24 Table 22-1 Function name and function code in the CAMEL4 service ..........................................................22-2 Table 22-2 Added call functions in the CAMEL4 service ..............................................................................22-2 Table 22-3 Benefits for carriers and mobile subscribers.................................................................................22-4 Table 22-4 NEs required to implement the CAMEL4 feature ........................................................................22-5 Table 22-5 Versions of the Huawei UMTS products that support the CAMEL4 feature................................22-5 Table 22-6 New CSA Measurement..............................................................................................................22-18 Table 22-7 Modified WIN event measurement.............................................................................................22-18 Table 22-8 List of supplementary services supported in mode A .................................................................22-20 Table 23-1 Name and code of the function .....................................................................................................23-3 Table 23-2 System specifications....................................................................................................................23-3 Table 23-3 NEs required to implement the IMSI-based announcement service .............................................23-4 Table 23-4 Version of Huawei UMTS MSOFTX3000 that supports the IMSI-based announcement service 23-5 Table 23-5 Steps of data configuration on the MSOFTX3000........................................................................23-8 Table 23-6 Related tables in the IMSI-based announcement service............................................................23-10 Table 24-1 Function code about this service...................................................................................................24-2 Table 24-2 Benefits of this service to carriers and mobile subscribers ...........................................................24-2 Table 24-3 NEs related with IP over E1..........................................................................................................24-4 Table 24-4 Product versions that support IP over E1......................................................................................24-4 Table 25-1 NEs that are involved in this IP QoS flow control........................................................................25-3
Issue 02 (2007-02-15)
xliii
Tables
HUAWEI MSOFTX3000 Feature Description Table 25-2 Earliest version that implements the IP QoS flow control ............................................................25-4 Table 25-3 Software parameter setting for QoS flow control function .........................................................25-12 Table 26-1 Function code................................................................................................................................26-2 Table 26-2 Benefits of the O-CSI SMS service ..............................................................................................26-2 Table 26-3 NEs required to implement the O-CSI SMS .................................................................................26-3 Table 26-4 Versions of Huawei core network products that support the O-CSI SMS ....................................26-3 Table 26-5 Parameters in the Initial-DP message ...........................................................................................26-7 Table 26-6 Logical relationship to determine whether to allow the triggering of the O-CSI..........................26-9 Table 26-7 Parameter description of ADD SMOCSI .................................................................................... 26-11 Table 26-8 Parameter description of ADD LAIGCI (2G).............................................................................26-12 Table 26-9 Parameter description of ADD LAISAI (3G) .............................................................................26-13 Table 26-10 Tables related to the O-CSI SMS ..............................................................................................26-15 Table 26-11 interactions between the O-CSI SMS and other services..........................................................26-18 Table 27-1 Name and code of the function .....................................................................................................27-2 Table 27-2 NEs required to implement the UP header redundancy service ....................................................27-3 Table 27-3 Versions of the Huawei GSM/UMTS products that support the UP header redundancy service..27-3 Table 28-1 Function code................................................................................................................................28-2 Table 28-2 Concepts related to VDB dynamic data backup............................................................................28-2 Table 28-3 NEs required for the VDB dynamic data backup..........................................................................28-4 Table 28-4 Versions applicable to VDB dynamic data backup .......................................................................28-4 Table 29-1 Function code................................................................................................................................29-3 Table 29-2 Classification of resources ............................................................................................................29-3 Table 29-3 Benefits.........................................................................................................................................29-7 Table 29-4 NEs required for role-based and domain-based management feature...........................................29-7 Table 29-5 Versions applicable to role-based and domain-based management feature ..................................29-8 Table 30-1 Function code of the alarm for malicious short messages function ..............................................30-2 Table 30-2 Benefits of the alarm for malicious short messages function........................................................30-2 Table 30-3 NEs required to implement the alarm for malicious short messages ............................................30-3 Table 30-4 Versions of the Huawei CS products that support the alarm for malicious short messages .........30-3 Table 30-5 Commands involved in the alarm for malicious short messages ..................................................30-7 Table 31-1 Definitions of the functions ..........................................................................................................31-2 Table 31-2 System specifications of the call simulation .................................................................................31-3 Table 31-3 NEs related to call simulation .......................................................................................................31-5
xliv
Issue 02 (2007-02-15)
Tables
Table 31-4 Versions that support the call simulation ......................................................................................31-5 Table 31-5 Script for registering virtual subscriber ......................................................................................31-10 Table 31-6 Script for changing the virtual subscriber data ........................................................................... 31-11 Table 31-7 Script for querying the virtual subscriber information................................................................ 31-11 Table 31-8 Meanings of the message contents..............................................................................................31-15 Table 31-9 Description of the shortcut menu of the message output pane....................................................31-15 Table 32-1 Function code of load-based handover .........................................................................................32-2 Table 32-2 Specifications of the load-based handover service .......................................................................32-2 Table 32-3 Benefits of the load-based handover service.................................................................................32-3 Table 32-4 NEs required to implement load-based handover .........................................................................32-4 Table 32-5 The earliest version of the MSOFTX3000 that supports load-based handover ............................32-4 Table 32-6 Data tables related to load-based handover.................................................................................32-14 Table 32-7 Operation modes of load-based handover...................................................................................32-15 Table 33-1 Function name and function code in the union subscriber trace ...................................................33-2 Table 33-2 Movements of mobile subscribers ................................................................................................33-2 Table 33-3 Benefits for carriers ......................................................................................................................33-3 Table 33-4 NEs required to implement the union subscriber trace service .....................................................33-4 Table 33-5 Version of the Huawei UMTS products that support the union subscriber trace service ..............33-4 Table 33-6 Related tables of the union subscription trace.............................................................................33-12 Table 33-7 Operation modes of the union subscriber trace...........................................................................33-12 Table 34-1 Function code................................................................................................................................34-2 Table 34-2 Benefits.........................................................................................................................................34-3 Table 34-3 Earliest version applicable to local-based service restriction, cell-based charging, and service restriction by cell .............................................................................................................................................34-4 Table 34-4 Enabling or disabling command .................................................................................................34-10 Table 34-5 Commands to set non-preferential cell tariff ..............................................................................34-10 Table 34-6 Commands to set cell and location area relationship .................................................................. 34-11 Table 34-7 Commands to add ZC .................................................................................................................34-13 Table 34-8 Commands to edit location group ...............................................................................................34-14 Table 34-9 Commands to edit roaming-restricted groups .............................................................................34-15 Table 34-10 Commands to edit user group roaming right.............................................................................34-16 Table 35-1 Function name and function code in the dialing test on the designated TDM circuit ...................35-2 Table 35-2 Benefits for carriers ......................................................................................................................35-3 Table 35-3 NEs required to implement the dialing test on the designated TDM circuit .................................35-3
Issue 02 (2007-02-15)
xlv
Tables
HUAWEI MSOFTX3000 Feature Description Table 35-4 Versions of the Huawei UMTS products that support the dialing test on the designated TDM circuit .........................................................................................................................................................................35-4 Table 35-5 Related software parameters .......................................................................................................35-10 Table 36-1 Function name and function code in the IN service performance measurement enhancement.....36-3 Table 36-2 System specifications....................................................................................................................36-3 Table 36-3 Benefits for carriers ......................................................................................................................36-4 Table 36-4 NEs required to implement the IN service performance measurement enhancement...................36-4 Table 36-5 Version of the Huawei UMTS products that support the IN service performance measurement enhancement....................................................................................................................................................36-5 Table 36-6 Operation modes of the IN performance measurement enhancement ........................................36-18 Table 37-1 Name and code of the function .....................................................................................................37-2 Table 37-2 Beneficiaries and description of the benefits of the ADD service ................................................37-2 Table 37-3 Network elements involved in the ADD service...........................................................................37-3 Table 37-4 Versions supported by the ADD service........................................................................................37-3 Table 37-5 Operations of data configuration at the MSOFTX3000................................................................37-7 Table 37-6 Name and function of tables related to the ADD service..............................................................37-9 Table 37-7 Operation modes of the ADD service ......................................................................................... 37-11 Table 38-1 Function code of the noise suppression feature ............................................................................38-2 Table 38-2 NEs related to the noise suppression service ................................................................................38-4 Table 38-3 Versions supporting the noise suppression service .......................................................................38-4 Table 39-1 NE required to implement the function of TDM circuit selection based on service type .............39-3 Table 39-2 The version of the Huawei UMTS CS product that supports TDM circuit selection based on service type..................................................................................................................................................................39-4 Table 40-1 Function code of the BICC and ISUP route allowed for the same office direction service ..........40-2 Table 40-2 Key parameter used in this service ...............................................................................................40-3 Table 40-3 Benefits of the BICC and ISUP route allowed for the same office direction service....................40-4 Table 40-4 NE required to implement this service..........................................................................................40-6 Table 40-5 Version of Huawei MSOFTX3000 that supports the service ........................................................40-6
xlvi
Issue 02 (2007-02-15)
Contents
Contents
About This Document.....................................................................................................................1
Issue 02 (2007-06-10)
About This Document
About This Document

Purpose
The manual introduces the features of V100R005C10 of HUAWEI MSOFTX3000 Mobile SoftSwitch Center (hereinafter referred to as MSOFTX3000). This manual describes the definition, realization principle, service flow, data configuration and service interaction of each feature. The manual introduces the features of V100R005C10 of the MSOFTX3000. In this way, audiences can use the MSOFTX3000 more easily.
Related Versions
The following table lists the product versions related to this document. Product Name MSOFTX3000 Version V100R005C10
Intended Audience
This document is intended for: Market technical personnel Telecommunications management personnel Mobile network system engineer
Organization
This document consists of thirty seven chapters is organized as follows.
Issue 02 (2007-06-10)
About This Document
Chapter 1 Speech Service
Content This chapter describes the implementation principle, service flow, data configuration service management and the interception with other services of the speech services, such as phone service, emergency call, and special service emergency call. This chapter describes the implementation principle, service flow, data configuration service management and the interception with other services of the short message service. This chapter describes the implementation principle, service flow, and the interception with other services of the call forwarding supplementary service. This chapter describes the implementation principle, service flow, and the interception with other services of the line identification service. This chapter describes the implementation method and principle of the call completion supplementary service. This chapter describes the implementation method of the multiparty service. This chapter describes the implementation principle, service flow, and the interception with other services of the call barring service. This chapter describes the implementation method and principle of the explicit call transfer service. This chapter describes the feature of the OBD service. This chapter describes the implementation principle, service flow, data configuration and service management of the authentication feature. This chapter describes enhanced MSRN allocation methods supported by the system. This chapter describes the implementation principle, service flow, data configuration and service management of the call forwarding early and late assignment feature. This chapter describes the implementation principle, service flow, charging and CDR, and the interception with other services of the IN service triggering feature. This chapter describes the mobile number portability feature. This chapter describes the service flow, and data configuration of the IP fax feature.
Short Message Service
3 Call Forwarding Supplementary Service 4 Line Identification Service 5 Call Completion Supplementary Service 6 7 Multiparty Service Call Barring Service
8 Explicit Call Transfer Service 9 10 ODB Service Authentication Feature
11 Enhanced MSRN Allocation Feature 12 Early and Late Assignment Feature 13 IN Service Triggering Feature 14 15 MNP Feature IP Fax Feature
Issue 02 (2007-06-10)
About This Document
Chapter 16 License Feature
Content This chapter describes the implementation principle of the License feature, the O&M of the License files, the control items of the License, and the cautions of using the License. This chapter describes the implementation principle and data configuration of the NE user dynamic monitoring feature. This chapter describes the implementation principle, service flow, and the interception with other services of the SMS notification for call failure feature. This chapter describes the implementation principle of the summer time feature of wireless time zone, and its impacts on the charging and CDR. This chapter describes the management feature of the network management system to the MSOFTX3000 software version. This chapter describes the method of rolling back the data configuration of the system, to ensure the correctness of the data configuration, the time of the rollback, and the stability and safety of the system operation. This chapter describes the implementation principle, service flow, data configuration service management and the interception with other services of the CAMEL4 service. This chapter describes the implementation principle, service flow, data configuration service management and the interception with other services of the IMSI-based announcement. This chapter describes the implementation principle, service flow, data configuration service management and the interception with other services of the IP over E1. This chapter describes the implementation principle, service flow, data configuration service management and the interception with other services of the IP QoS flow control. This chapter describes the implementation principle, service flow, data configuration service management and the interception with other services of the O-CSI SMS. This chapter describes the implementation principle, service flow, data configuration service management and the interception with other services of the UP header redundancy data service. This chapter describes the implementation principle, service flow, data configuration service management and the interception with other services of the VDB dynamic data backup.
17 NE User Dynamic Monitoring Feature 18 SMS Notification for Call Failure Feature 19 Summer Time Feature of Wireless Time Zone 20 Version Software Management Feature 21 Configuration Rollback Feature
22
CAMEL4 Service
23 IMSI-Based Announcement
24
IP over E1
25
IP QoS Flow Control
26
O-CSI SMS
27 UP Header Redundancy Data Service
28 VDB Dynamic Data Backup
Issue 02 (2007-06-10)
About This Document
Chapter 29 Multi-Area Network Role-Based and Domain-Based Management Feature 30 Alarm for Malicious Short Messages
Content This chapter describes the implementation principle, service flow, data configuration service management and the interception with other services of the multi-area network role-based and domain-based management feature. This chapter describes the implementation principle, service flow, data configuration service management and the interception with other services of the alarm for malicious short messages. This chapter describes the implementation principle, service flow, data configuration service management and the interception with other services of the call simulation. This chapter describes the implementation principle, service flow, data configuration service management and the interception with other services of the load-based handover. This chapter describes the implementation principle, service flow, data configuration service management and the interception with other services of the union subscriber trace. This chapter describes the implementation principle, service flow, data configuration service management and the interception with other services of the service restriction by cell. This chapter describes the implementation principle, service flow, data configuration service management and the interception with other services of the dialing test on designated TDM circuit. This chapter describes the implementation principle, service flow, data configuration service management and the interception with other services of the IN service performance measurement enhancement. This chapter describes the implementation principle, service flow, data configuration service management and the interception with other services of the automatic device detection. This chapter describes the implementation principle, service flow, data configuration service management and the interception with other services of the noise suppression. This chapter describes the implementation principle, service flow, data configuration service management and the interception with other services of the TDM circuit selection based on service type. This chapter describes the implementation principle, service flow, data configuration service management and the interception with other services of the BICC and ISUP route allowed for the same office direction.
31
Call Simulation
32
Load-Based Handover
33
Union Subscriber Trace
34 Service Restriction by Cell
35 Dialing Test on Designated TDM Circuit
36 IN Service Performance Measurement Enhancement 37 Automatic Device Detection
38
Noise Suppression
39 TDM Circuit Selection Based on Service Type
40 BICC and ISUP Route Allowed for the Same Office Direction
Issue 02 (2007-06-10)
About This Document
Conventions
Symbol Conventions
The symbols that may be found in this document are defined as follows. Symbol Description Indicates a hazard with a high level of risk that, if not avoided, will result in death or serious injury. Indicates a hazard with a medium or low level of risk which, if not avoided, could result in minor or moderate injury. Indicates a potentially hazardous situation that, if not avoided, could cause equipment damage, data loss, and performance degradation, or unexpected results. Indicates a tip that may help you solve a problem or save time. Provides additional information to emphasize or supplement important points of the main text.
General Conventions
Convention Times New Roman Boldface Italic Courier New Description Normal paragraphs are in Times New Roman. Names of files, directories, folders, and users are in boldface. For example, log in as user root. Book titles are in italics. Terminal display is in Courier New.
Command Conventions
Convention Boldface Italic [] { x | y | ... } [ x | y | ... ] Description The keywords of a command line are in boldface. Command arguments are in italics. Items (keywords or arguments) in square brackets [ ] are optional. Alternative items are grouped in braces and separated by vertical bars. One is selected. Optional alternative items are grouped in square brackets and separated by vertical bars. One or none is selected.
Issue 02 (2007-06-10)
About This Document
Convention { x | y | ... } *
Description Alternative items are grouped in braces and separated by vertical bars. A minimum of one or a maximum of all can be selected.
GUI Conventions
Convention Boldface > Description Buttons, menus, parameters, tabs, windows, and dialog titles are in boldface. For example, click OK. Multi-level menus are in boldface and separated by the ">" signs. For example, choose File > Create > Folder.
Keyboard Operation
Format Key Key 1+Key 2 Description Press the key. For example, press Enter and press Tab. Press the keys concurrently. For example, pressing Ctrl+Alt+A means the three keys should be pressed concurrently. Press the keys in turn. For example, pressing Alt, A means the two keys should be pressed in turn.
Key 1, Key 2
Mouse Operation
Action Click Double-click Drag Description Select and release the primary mouse button without moving the pointer. Press the primary mouse button twice continuously and quickly without moving the pointer. Press and hold the primary mouse button and move the pointer to a certain position.
Update History
Updates between document versions are cumulative. Therefore, the latest document version contains all updates made to previous versions.
Issue 02 (2007-06-10)
About This Document
Updates in Issue 02 (2007-6-10)

Second archive. The updated contents are as follows: The feature description of PCR is added.
Updates in Issue 01 (2007-2-15)

First release.
Issue 02 (2007-06-10)
Contents
Contents
1 Speech Service ............................................................................................................................1-1
1.1 Service Description .......................................................................................................................................1-2 1.1.1 Function Code......................................................................................................................................1-2 1.1.2 Definition .............................................................................................................................................1-2 1.1.3 Benefits ................................................................................................................................................1-4 1.2 Availability ....................................................................................................................................................1-4 1.2.1 Requirements for NEs..........................................................................................................................1-4 1.2.2 Requirements for License ....................................................................................................................1-4 1.2.3 Applicable Versions..............................................................................................................................1-4 1.3 Working Principle..........................................................................................................................................1-5 1.3.1 MOC ....................................................................................................................................................1-5 1.3.2 MTC.....................................................................................................................................................1-6 1.3.3 MMC....................................................................................................................................................1-7 1.4 Service Flow..................................................................................................................................................1-7 1.4.1 MOC to Fixed Line Subscriber ............................................................................................................1-8 1.4.2 MTC from Fixed Line Subscriber...................................................................................................... 1-11 1.4.3 MMC..................................................................................................................................................1-15 1.5 Data Configuration......................................................................................................................................1-21 1.5.1 Telephony...........................................................................................................................................1-21 1.5.2 Emergency Call for Special Service...................................................................................................1-21 1.5.3 Charging Flag of Emergency Call......................................................................................................1-21 1.6 Service Management ...................................................................................................................................1-22 1.6.1 For Carriers ........................................................................................................................................1-22 1.6.2 For Mobile Subscribers......................................................................................................................1-22 1.7 Charging and CDR ......................................................................................................................................1-22 1.7.1 Generation of CDR ............................................................................................................................1-22 1.7.2 CDR for Ordinary Call.......................................................................................................................1-22 1.7.3 CDR for Emergency Call ...................................................................................................................1-25 1.8 Service Interaction ......................................................................................................................................1-26 1.9 Reference ....................................................................................................................................................1-26 1.9.1 Protocols and Specifications ..............................................................................................................1-26 1.9.2 Acronyms and Abbreviations .............................................................................................................1-26
Issue 02 (2007-06-10)
Figures
Figures
Figure 1-1 Networking model of the call from a mobile subscriber to a fixed line subscriber ..........................1-8 Figure 1-2 Flow of the call from a mobile subscriber to a fixed line subscriber (1) ..........................................1-9 Figure 1-3 Flow of the call from a mobile subscriber to a fixed line subscriber (2) ........................................1-10 Figure 1-4 Flow of the call from a fixed line subscriber to a mobile subscriber ..............................................1-13 Figure 1-5 Networking model of a call from a mobile subscriber to another mobile subscriber .....................1-15 Figure 1-6 Flow of the call from a mobile subscriber to another mobile subscriber (1) ..................................1-16 Figure 1-7 Flow of the call from a mobile subscriber to another mobile subscriber (2) ..................................1-17 Figure 1-8 Flow of the call from a mobile subscriber to another mobile subscriber (3) ..................................1-18 Figure 1-9 Process of generating CDRs when the mobile caller and callee are under the same VMSC ..........1-23 Figure 1-10 Process of generating CDRs when the mobile caller and callee are under different VMSCs.......1-23 Figure 1-11 Process of generating CDRs when a mobile subscriber calls a fixed line subscriber ...................1-23 Figure 1-12 Process of generating CDRs when a fixed line subscriber calls a mobile subscriber ...................1-24 Figure 1-13 Process of generating CDRs when the mobile caller and callee are in different wireless networks ...........................................................................................................................................................................1-25
ii
Issue 02 (2007-06-10)
Tables
Tables
Table 1-1 Function names and function codes in the speech service..................................................................1-2 Table 1-2 Definitions of functions in the speech service ....................................................................................1-2 Table 1-3 Benefits for carriers and mobile subscribers.......................................................................................1-4 Table 1-4 NEs involved in the speech service ....................................................................................................1-4 Table 1-5 Versions of the products that support the speech service....................................................................1-5 Table 1-6 Differences between early assignment and late assignment .............................................................1-20 Table 1-7 Configuration steps...........................................................................................................................1-21 Table 1-8 Interaction between the emergency call function and other services................................................1-26
Issue 02 (2007-06-10)
iii
1 Speech Service
1
About This Chapter
The following table lists the contents of this chapter. Section 1.1 Service Description 1.2 Availability 1.3 Working Principle 1.4 Service Flow 1.5 Data Configuration 1.6 Service Management 1.7 Charging and CDR 1.8 Service Interaction 1.9 Reference Describes
Speech Service
The function code, function definition of this feature, and the benefits that carriers and mobile subscribers can obtain from this feature. The network elements (NEs) that are required for the feature, whether Licenses are required, and the version requirements of the NEs. The functions of the NEs, and networking requirements. The service flow of the network when providing this feature. The data configurations that are required on the MSOFTX3000 and the UMG8900. The service operations that carriers and mobile subscribers are required to implement when the network provides this feature. The charging and the generation of CDRs when the network provides this feature. The relationships and restrictions between this feature and other services or features. The protocols and specifications that this feature must comply with, and the acronyms and abbreviations of this chapter.
Issue 02 (2007-06-10)
1-1
1 Speech Service
1.1 Service Description

1.1.1 Function Code
Table 1-1 lists the mapping between function names and function codes in the speech service. Table 1-1 Function names and function codes in the speech service Name Telephony Emergency call Emergency call for special service Code WMFD-010101 WMFD-010102 WMFD-010103
1.1.2 Definition
The speech service is the elementary feature of a telecom network. The service consists of the functions such as telephony, emergency call, and emergency call for special service. Table 1-2 lists the definitions of these functions. Table 1-2 Definitions of functions in the speech service Name Telephony Definition This function enables mobile subscribers to communicate with the subscribers in the PSTN, ISDN and PLMN over telephones. When a mobile subscriber chooses the type of an emergency call on the menu of an MS/UE or dials 112, the call is connected to a record notification device. Then the device instructs the subscriber how to call the emergency center. The subscriber can make an emergency call without a SIM/USIM card. Compared with the telephony function, the processing of the emergency call does not include authentication and specific routing requirements. An emergency call is of higher priority than an ordinary call.
Emergency call
1-2
Issue 02 (2007-06-10)
1 Speech Service
Name Emergency call for special service
Definition When a mobile subscriber dials an emergency number for a special service, the call is connected to a corresponding special service center that is nearest to the base station. The special service center consists of the fire alarm center, bandit alarm center, first-aid center and traffic center. Such kind of call can generate alarms. Carriers can decide whether to charge the subscriber.
NOTE The difference between the emergency call for special service function and the emergency call function is that: When a CM service is required, the emergency call for a special service is considered as an ordinary call. The MSC processes the number as a special service number after analyzing the number. While for the emergency call function, there is a parameter indicating that this is an emergency call.
Note PSTN = public switched telephone network; ISDN = integrated services digital network; PLMN = public land mobile network; SIM = subscriber identity module; USIM = UMTS Subscriber identity module
The call involved in the speech service can be classified into mobile originated call (MOC) and mobile terminated call (MTC), depending on the role of a mobile subscriber in a call.
MOC
If a mobile subscriber makes a call, this call is an MOC. In an MOC, the MSC server/visitor location register (VLR) and media gateway (MGW) perform the following functions: Security control This step is optional. If you do not select it, the MSC server/VLR and MGW directly perform the following functions: Creating a user panel bearer at the caller side Checking subscription data Pointing to the route of the call to the destination
MTC
If a mobile subscriber receives a call, the call is an MTC. In the universal mobile telecommunications system (UMTS), all network elements (NEs) cooperate with each other to route the call to the mobile subscriber. During the setup of an MTC, the designated MSC server queries the location information of the callee in the home location register (HLR) to which the callee belongs, because only the HLR stores such information. If the caller is also a mobile subscriber, the MSC server/VLR to which the caller belongs initiates the query. If the caller is a fixed line subscriber, the gateway mobile switching center (GMSC) server initiates the query.
Issue 02 (2007-06-10)
1-3
1 Speech Service
1.1.3 Benefits
Table 1-3 lists the benefits for carriers and mobile subscribers. Table 1-3 Benefits for carriers and mobile subscribers Beneficiary Carriers Mobile subscribers Description The speech service increases the income of carriers. The speech service enables mobile subscribers to freely move around the PLMN, and make and receive calls in any place at any time. The service also enables mobile subscribers to make emergency calls without SIM/USIM cards.
1.2 Availability
1.2.1 Requirements for NEs
The speech service requires the cooperation of the user equipment (UE)/mobile station (MS), NodeB/base transceiver station (BTS), radio network controller (RNC)/base station controller (BSC), and core network (CN). For details, see Table 1-4. Table 1-4 NEs involved in the speech service UE/MS NodeB/BTS RNC/BSC MSC Server MGW SGSN VLR HLR
means the NE is required.
1.2.2 Requirements for License

No License is required to obtain the speech service, because the service is the elementary feature of the HUAWEI wireless core network.
1.2.3 Applicable Versions

Table 1-5 lists the versions of the HUAWEI circuited switched (CS) products that support the speech service.
1-4
Issue 02 (2007-06-10)
1 Speech Service
Table 1-5 Versions of the products that support the speech service Product MSC server MGW MSOFTX3000 UMG8900 Applicable version V100R002 and later V200R002 and later
1.3 Working Principle

The NEs in the PLMN cooperate with each other to implement MOCs or MTCs. MOCs and MTCs enable mobile subscribers to freely move around the global system for mobile communications (GSM)/UMTS, and make and receive calls in any place at any time.
1.3.1 MOC
The processing of the MSC/VLR to an MOC consists of the following aspects: MOC initiation MOC completion
MOC Initiation
MOC initiation is triggered by the Service request sent from the MS to the MSC/VLR over a radio access network (RAN). Based on the Service request, the following services are processed in MOC initiation: Telephone call and data call Emergency call Input controlled by subscribers Short message The security function is enabled in MOC initiation, based on the Service request. This means that the MSC server/VLR performs authentication, encryption/decryption, and/or temporary mobile subscriber identity (TMSI) reassignment. This function, however, can also not be enabled. Authentication The authentication function defines whether a mobile subscriber is authorized to access the PLMN. The function prevents invalid subscribers from using the services that the network provides. In the GSM and UMTS, the MS/UE, VLR/serving GPRS support node (SGSN) and HLR/authentication center (AuC) cooperate with each other to implement authentication. The MS and AuC calculate authentication parameters respectively. Then the VLR/SGSN compares the two results, to verify the validity of the MS/UE. In the UMTS, the UE can also verify the validity of the network.
Issue 02 (2007-06-10)
1-5
1 Speech Service
Encryption/Decryption In the UMTS, cipher key (CK) guarantees the confidentiality of access data. Secret signaling information and data information are encrypted. That is, logical channels are encrypted. Integrity key (IK) guarantees the integrity of signaling data. CK and IK are stored in the USIM and VLR/SGSN, and sent from the VLR/SGSN to the RNC with the security mode command. This helps to encrypt channels. The USIM can also send the CK and IK to the UE based on the requirements of the UE. That is, the UE stores a copy of the CK and IK. The VLR/SGSN must update the CK and IK at least once a day. In the GSM, encryption/decryption guarantees the information exchange through the wireless interface. Therefore, the MS and base station subsystem (BSS) are loaded with the same CK. TMSI reassignment The MSC server/VLR assigns a TMSI to a mobile subscriber periodically. This function is to prevent intruders from monitoring the signaling on wireless channels and identifying mobile subscribers. To guarantee the confidentiality, TMSI is reassigned at the right time. When a subscriber makes an emergency call without a SIM/USIM, international mobile station equipment Identity (IMEI), instead of TMSI or IMSI, is used to identify the subscriber. This means that the MSC server/VLR does not perform authentication, encryption/decryption and TMSI reassignment. Call setup between the calling MS/UE and the visited MSC server After the service acceptance message is received or the encryption is complete, the MS sends a Setup message to the visited MSC (VMSC) server. Then the VMSC server returns a Call Proceeding message to the calling MS/UE. Setup of a user panel bearer at the caller side The MSC server sends a Prepare Bearer request to the MGW, which assigns asynchronous transfer mode (ATM) resources dynamically. The MSC server then sends a Radio Access Bearer (RAB) Assignment message to the radio network subsystem originated (RNS-O). The RNS-O creates the ATM bearer resources at the access side together with the MGW through bearer establishment.
MOC Completion
The MSC/VLR checks subscription data and service compatibility. If the check is passed, the Connection request from the mobile subscriber is accepted. Then the originating MSC/VLR assigns service channels and occupies ground circuits, to continue the call.
1.3.2 MTC
An MTC is generated when a subscriber in the PSTN/ISDN/PLMN dials the MSISDN of a mobile subscriber. The processing for the MTC consists of the following aspects: Route information query MTC initiation and completion
Route Information Query

Route information is used to transfer a call to the MSC/VLR that is in the roaming domain of the mobile subscriber. To obtain the route information, the VMSC/GMSC initiates a query by the steps as follows:
1-6
Issue 02 (2007-06-10)
1 Speech Service
1. 2. 3. 4.
The MSC server begins to query after receiving an MSISDN. The MSC server queries the information of the callee in the HLR to which the callee belongs. The MSC translates the MSISDN and the results include the information of the HLR. The HLR requests the mobile station roaming number (MSRN) from the VLR. The HRL stores the current VLR number of the subscriber and dynamically updates the number, depending on the location of the subscriber. The HLR finds the VLR sequentially based on the mapping between the VLR and ISDN, and then requests the MSRN from the VLR. The VLR assigns a temporary MSRN to the callee. MSRN is only used to transfer the call from the GMSC or originating MSC to the VMSC/VLR that is in the roaming domain of the mobile subscriber. The MSRN is released when the call reaches the VMSC/VLR. During the requirement for the MSRN, the VMSC/VLR transfers the MSRN to the GMSC through the HLR. During the query, the HLR/AuC and VMSC/VLR check subscription data and service compatibility.
5. 6.
7.
MTC Initiation and Completion

After the call is routed to the VMSC/VLR, the MSC/VLR connects the call by the steps as follows if the number analysis result report accepts the MSRN assigned by the VLR. 1. The MSC/VLR must, in the location area, check the cell where the mobile subscriber locates. The MSC/VLR checks the cell by paging. If the mobile station responds to the paging, it means the mobile subscriber is detected. The MTC initiation begins. This means that the system performs authentication, encryption, TMSI reassignment and equipment control, if required. 2. The MSC/VLR assigns service channels, occupies ground circuits and plays ringing tones. If the mobile subscriber answers the phone, the MTC is complete. Now the call is connected and the MSC begins to collect the call detail records (CDRs) for charging the subscriber.
1.3.3 MMC
A mobile-to-mobile call (MMC) is between two mobile subscribers. An MMC can be considered as an MOC plus an MTC. The MOC takes place first, followed by the MTC. The originating MSC/VLR initiates and completes the MOC. The service MSC/VLR initiates and completes the MTC. The originating MSC/VLR also queries the route to the MS/UE. If the two mobile subscribers register with the same MSC/VLR and all service channels are exchanged in the same MSC/VLR, the service MSC/VLR initiates and completes the MOC and MTC. The service MSC/VLR queries the information of the callee in the HLR.
1.4 Service Flow

The flows in this section are applied to the telephony function and emergency call function. The difference between the two functions is that there is no requirement for authenticating the access of the MS in an emergency call.
Issue 02 (2007-06-10)
1-7
1 Speech Service
1.4.1 MOC to Fixed Line Subscriber

Figure 1-1shows the networking model of the call from a mobile subscriber to a fixed line subscriber. Figure 1-1 Networking model of the call from a mobile subscriber to a fixed line subscriber
MSC server/VLR
RNS-O MGW PSTN
UE-O
PSTN User
The flow of the call from a mobile subscriber to a fixed line subscriber consists of the following aspects: Authentication for the access of the caller Creation of a user panel bearer at the caller side Conversation between the MS/UE and a fixed line subscriber Call disconnection Figure 1-2 and Figure 1-3 show the flow of the call from a mobile subscriber to a fixed line subscriber.
1-8
Issue 02 (2007-06-10)
1 Speech Service
Figure 1-2 Flow of the call from a mobile subscriber to a fixed line subscriber (1)
UE-O RNS-O CM_Service_Req (Initial UE) MAP_SEND_AUTHENTICATION_INFO MAP_SEND_AUTHENTICATION_ INFO_ACK MSC server/VLR MGW HLR
Authentication for the access of the caller
AUTHENTICATION REQUEST AUTHENTICATION RESPONSE SECURITY MODE COMMAND(OPTION) SECURITY MODE COMPLETE(OPTION) COMMON ID CM_SERVICE_ACCEPT SETUP CALL PROCEEDING
PREP BEARER PREP BEARER RAB ASSIGNMENT REQUEST
Creation of a user panel bearer at the caller side
RADIO BEARER SETUP RADIO BEARER SETUP COMPLETE
BEARER ESTABLISHMENT RAB ASSIGNMENT RESPONSE RESERVE CIRCUIT RESERVE CIRCUIT
Issue 02 (2007-06-10)
1-9
1 Speech Service
Figure 1-3 Flow of the call from a mobile subscriber to a fixed line subscriber (2)
UE-O RNS-O (G)MSC Server IAI ACM ALERTING ANC CONNECT CONNECT ACK MGW PSTN
Conversation
DISCONNECT CLF RELEASE RELEASE COMPLETE RLG IU_RELEASE_COMM AND Call disconnection BEARER RELEASE IU_RELEASE_COMPL ETE RELEASE_TERM RELEASE_TERM RELEASE_TERM RELEASE_TERM
1.
The UE sends a CM Service request to the VMSC server. The CM Service request consists of the following parameters: Mobile identification Its values are as follows:

IMSI TMSI IMEI
classmark2 CKSN CM service request type Its values are as follows:
1-10
Issue 02 (2007-06-10)

1 Speech Service
MOC creation Emergency call creation Short message service Supplementary service Location service
CKSN stands for ciphering key sequence number. 2. The network may initiate authentication and encryption. During the process, the network may obtain authentication set from the HLR/AuC. The MSC/VLR must send a Command ID message to the RNS on not identifying the TMSI of the UE, to obtain the IMSI of the UE. Step 3 takes place immediately after step 1 if there is no security management, which consists of authentication, encryption, TMSI reassignment and identity obtaining. After the service acceptance message is received or the encryption is complete, the UE sends a Setup message to the VMSC server. After receiving the Setup message, the VMSC server returns a Call Proceeding message to the calling UE. A user panel bearer begins to be created at the caller side. The VMSC server sends a Prepare Bearer request to the MGW. The MGW assigns ATM resources dynamically and sends a Prepare Bearer response containing TerminationId (T1). The MSC server then sends an RAB Assignment message to the RNS-O. The RNS-O creates the ATM bearer resources at the access side together with the MGW through bearer establishment. The GMSC server sends an Initial Address Message with Information (IAI) message to the PSTN. The PSTN returns an Address Complete Message (ACM) message after receiving the IAI message, and sends the ringback tone for the calling MSC. After the callee hangs up, the called UE sends an ANC message to the network side. The PSTN stops sending the ringback tone. The caller and callee begin to talk on the phone. If the caller hangs up first, the calling UE sends a Disconnect message to the GMSC server.
3. 4. 5.
6. 7. 8. 9.
10. The GMSC server sends a Clear Forward Signal (CLF) message to the PSTN and instructs it to disconnect the connection. 11. The PSTN returns a Release Guard Signal (RLG) message to the GMSC server after disconnecting the connection. 12. The GMSC server releases transaction resources by sending a Release message to the calling UE. 13. The calling UE sends a Release Complete response after receiving the Release message. 14. The GMSC server releases resources on the user panel after sending two Release Termination messages to the MGW. The two messages are sent through the Iu interface and ISDN User Part (ISUP) trunk respectively.
1.4.2 MTC from Fixed Line Subscriber

The flow of the call from a fixed line subscriber to a mobile subscriber consists of the following aspects: Route information query
Issue 02 (2007-06-10)
1-11
1 Speech Service
Security control for the callee service channel assignment, ground circuit occupation and ringing tone playing Creation of a user panel bearer at the callee side Conversation between a fixed line subscriber and the MS/UE Release of signaling panel bearer Release of user panel bearer Figure 1-4shows the flow of the call from a fixed line subscriber to a mobile subscriber.
1-12
Issue 02 (2007-06-10)
1 Speech Service
Figure 1-4 Flow of the call from a fixed line subscriber to a mobile subscriber
UE (callee) RNS VMSC server MGW HLR SRI MAP_PROVIDE_ROAMING_NUMBER MAP_PROVIDE_ROAMING_NUMBER_ACK SRI ACK IAI(TUP) PAGING PAGING PAGE RESPONSE AUTHENTICATION REQUEST AUTHENTICATION RESPONSE SECURITY MODE COMMAND SECURITY MODE COMPLETE COMMON ID TMSI REALLOCATION COMMAND TMSI REALLOCATION COMPLETE RESERVE CIRCUIT RESERVE CIRCUIT SETUP CALL CONFIRMED PREPARE BEARER PREPARE BEARER RADIO BEARER SETUP RADIO BEARER SETUP COMPLETE BEAR ESTABLISHMENT RAB ASSIGNMENT RESPONSE ALERTING SENT TONE SENT TONE CONNECT STOP TONE STOP TONE CONNECT ACKNOWLEDGE CONNECT ACKNOWLEDGE ANC RAB ASSIGNMENT REQUEST GMSC server PSTN
IAI(TUP)
ACM
CALL DISCONNECT RELEASE RELEASE COMPLETE IU RELEASE COMMAND BEARER RELEASE IU RELEASE COMPLETE RELEASE_TERM RELEASE_TERM RELEASE_TERM RELEASE_TERM RLG
CLF
Issue 02 (2007-06-10)
1-13
1 Speech Service
1. 2.
The PSTN subscriber sends an IAI message containing the MSISDN of the callee to the GMSC server. The GMSC server determines the HLR that the callee belongs to by analyzing the MSISDN. The GMSC creates a signaling connection to the HLR and sends a request for routing. After receiving the request, the HLR checks the subscription data of the callee, and finds the VLR and MSC server to which the callee currently belongs. The HLR creates a signaling connection to the VLR based on the VLR number, and requests the MSRN of the callee. The VLR sends the MSRN of the callee to the HLR after finding the number. The HLR forwards the MSRN to the GMSC server. The GMSC server sends the IAI message to the VMSC server/VLR based on the MSRN. The VMSC server/VLR initiates paging to locate the callee after identifying the MSRN. After the VMSC server receives the paging response from the called UE, step 10 takes place immediately after step 8 if there is no requirement for authentication, encryption and TMSI reassignment.
3. 4. 5. 6. 7. 8. 9.
10. The network initiates authentication, encryption and TMSI reassignment. During the process, the network may obtain authentication set from the HLR/AuC. The MSC/VLR must send a Command ID message to the RNS on not identifying the TMSI of the UE, to obtain the IMSI of the UE. 11. The VMSC server sends a Setup message to the called UE. 12. The VMSC server creates the user panel bearer after receiving the Call Confirmed message from the called UE. 13. The MSC server sends a Prepare Bearer request to the MGW. The MGW assigns ATM resources dynamically and sends a Prepare Bearer response containing TerminationId. The MSC server then sends an RAB Assignment message to the RNS. The RNS creates the ATM bearer resources at the access side together with the MGW through bearer establishment. 14. A transmission control panel and user panel must be created during assignment. The RAN sends the RAB Assignment response only after receiving an acknowledgement message of the creation of the user panel. 15. The VMSC sever creates a user panel bearer at the caller side at the same time. The callee picks up the phone. 16. The MSC server sends an ACM message to the calling UE after receiving an Alerting message, and sends a Send Tone message to the MGW, instructing it to play the ringback tone. 17. The called UE sends a Connect message to the MSC server after the callee picks up the phone. The MSC server sends an ANC message to the calling UE after receiving the Connect message from the called UE. Meanwhile, the MSC server sends a Stop Tone message to the MGW, instructing it to stop playing the ringback tone. 18. The VMSC server forwards a Connect ACK message to the called UE after receiving the message from the calling UE. The caller and callee begin to talk on the phone. 19. If the callee hangs up first, the called UE sends a Disconnect message to the VMSC server. The VMSC server then sends a CLF message to the calling UE. 20. The calling UE sends an RLG message to the VMSC server after the caller hangs up. The VMSC server releases transaction resources by sending a Release message to the called UE. 21. The VMSC server sends an IU Release Command message on initiative, and begins to release the resources on the signaling panel.
1-14
Issue 02 (2007-06-10)
1 Speech Service
22. The VMSC server releases resources on the user panel after sending two Release Termination messages to the MGW. The two messages are sent through the Iu interface and ISUP trunk respectively.
1.4.3 MMC
Figure 1-5 shows the networking model of the call from a mobile subscriber to another mobile subscriber. The two subscribers are both in the local office. Figure 1-5 Networking model of a call from a mobile subscriber to another mobile subscriber
MSC server/VLR
RNS-O MGW
RNS-T
UE-O
UE-T
Figure 1-6, Figure 1-7and Figure 1-8 show the flow of the call from a mobile subscriber to another mobile subscriber.
Issue 02 (2007-06-10)
1-15
1 Speech Service
Figure 1-6 Flow of the call from a mobile subscriber to another mobile subscriber (1)
UE-O RNS-O CM_Service_Req (Initial UE) MAP_SEND_AUTHENTICATION_INFO MAP_SEND_AUTHENTICATION_INFO_ACK Security management (optional) AUTHENTICATION REQUEST AUTHENTICATION RESPONSE SECURITY MODE COMMAND(OPTION) SECURITY MODE COMPLETE(OPTION) COMMON ID CM_SERVICE_ACCEPT SETUP CALL PROCEEDING MSC server/VLR MGW HLR
PREP BEARER PREP BEARER RAB ASSIGNMENT REQUEST Creation of a user panel bearer at the caller side RADIO BEARER SETUP RADIO BEARER SETUP COMPLETE BEARER ESTABLISHMENT RAB ASSIGNMENT RESPONSE
1-16
Issue 02 (2007-06-10)
1 Speech Service
HLR MGW MSC server/VLR RNS-T UE-T
MAP_SEND_ROUTING_INFORMATION Obtaining the roaming number MAP_PROVIDE_ROAMING_NUMBER MAP_PROVIDE_ROAMING_NUMBER_ACK MAP_SEND_ROUTING_INFORMATION_AC K
PAGING
PAGING
PAGING RESPONSE AUTHENTICATION REQUEST Security management (optional) AUTHENTICATION RESPONSE SECURITY MODE COMMAND SECURITY MODE COMPLETE COMMON ID SETUP CALL CONFIRMED PREP BEARER PREP BEARER RAB ASSIGNMENT REQUEST
Creation of a user panel bearer at the callee side
RADIO BEARER SETUP RADIO BEARER SETUP COMPLETE
BEARER ESTABLISHMENT
RAB ASSIGNMENT RESPONSE
Issue 02 (2007-06-10)
1-17
1 Speech Service
UE-O RNS-O VMSC/GMSC ALERTING MGW RNC-T UE-T
SENDTONE SENDTONE CONNECT STOP TONE STOP TONE CONNECT CONNECT ACK
During the call
DISCONNECT RELEASE RELEASE COMPLETE IU_RELEASE_COMMAND
DISCONNECT
BEARER RELEASE IU_RELEASE_COMPLETE RELEASE_TERM RELEASE_TERM
RELEASE RELEASE COMPLETE IU_RELEASE_COMMAND
BEARER RELEASE IU_RELEASE_COMPLETE RELEASE_TERM RELEASE_TERM
1-18
Issue 02 (2007-06-10)
1 Speech Service
The MSC server is combined with the VLR. Therefore the B interface is an internal interface and the messages through the B interface are internal messages.
Flow at Caller Side (Early Assignment)

1. The UE sends a CM Service request to the MSC server. The CM Service request consists of the following parameters: mobile identification Its values are as follows

IMSI TMSI IMEI
classmark2 CKSN CM service request type Its values are as follows:

MOC creation Emergency call creation Short message service Supplementary service Location service
2.
The network may initiate authentication and encryption. During the process, the network may obtain authentication set from the HLR/AuC. Step 3 takes places immediately after step 1 if there is no security management, which consists of authentication, encryption, TMSI reassignment and identity obtaining. After the service acceptance message is received or the encryption is complete, the UE sends a Setup message to the MSC server. After receiving the Setup message, the MSC server returns a Call Proceeding message to the calling UE. A user panel bearer begins to be created at the caller side. The MSC server sends a Prepare Bearer request to the MGW. The MGW assigns ATM resources dynamically and sends a Prepare Bearer response containing TerminationId (T1). The MSC server then sends an RAB Assignment message to the RNS-O. The RNS-O creates the ATM bearer resources at the access side together with the MGW through bearer establishment. This step takes place together with step 5. The MSC server queries route information in the HLR. The HLR requests the MSRN from the VLR. The VLR initiates paging immediately after the MSC server requests the incoming call data from the VLR.
3.
4.
5. 6. 7.
The difference between early assignment and late assignment lies in the chance of assigning traffic channels (TCHs). For details, see Table 1-6.
Issue 02 (2007-06-10)
1-19
1 Speech Service
Table 1-6 Differences between early assignment and late assignment Early Assignment Chance of Assigning TCHs Caller Side Refers to assigning TCHs after the MSC sends a Call Proceeding message to the calling UE. Refers to assigning TCHs after the MSC receives the Call Confirmed message. Decreases call connection delay, thus improving the call connection ratio. Late Assignment Refers to assigning TCHs after the Alerting message.
Callee Side Advantages
Refers to assigning TCHs after the callee picks up the phone. Prevents TCHs from being occupied during ringing, thus improving the usage of TCHs.
Flow at Callee Side (Early Assignment)

1. 2. The MSC server receives a Paging response from the callee. The network may initiate authentication, encryption and TMSI reassignment. During the process, the network may obtain the authentication set from the HLR/AuC. If no authentication is required, step 3 takes place immediately after step 1. The MSC server sends a Setup message to the called UE. The MSC server creates user panel bearer after receiving a Call Confirmed message from the called UE. The creation process is similar to that of the ATM bearer at the caller side. A transmission control panel and user panel must be created during assignment. That is, Q.AAL2 must be created and ISUP must be initiated. The RAN sends the RAB Assignment response only after receiving an Establish Confirm message. The MSC server forwards an Alerting message to the calling UE after receiving the Alerting message from the called UE. The MSC server also sends a Send Tone message to the MGW and instructs it to play the ringback tone. The VMSC server forwards a Connect message to the calling UE after receiving the Connect message from the called UE. After receiving the Connect message, the MSC server sends a Stop Tone message to the MGW and instructs it to stop playing the ringback tone.
3. 4.
5. 6. 7.
8. 9.
10. The calling UE also sends a Connect ACK message to the MSC sever, which then forwards the message to the called UE. The caller and callee begin to talk on the phone.
Call Disconnection
1. 2. The caller hangs up first. At this moment, the calling UE sends a Disconnect message to the MSC server/VLR, which then forwards the message to the called UE. The called UE releases transaction resources by sending a Release message to the VMSC/GMSC, which then forwards the message to the calling UE and releases the transaction resources. The calling UE sends a Release Complete response after receiving the Release message.
3.
1-20
Issue 02 (2007-06-10)
1 Speech Service
4. 5.
The VMSC/GMSC sends an IU Release Command message on initiative, and begins to release the resources on the signaling panel. The VMSC/GMSC sends a Release Termination message to the MGW and releases resources on the user panel.
1.5 Data Configuration

1.5.1 Telephony
The telephony is the elementary function of the UMTS. The data to be configured involves the number analysis data. For how to configure the data, see the following manuals: HUAWEI MSOFTX3000 Mobile SoftSwitch Center Configuration Guide U-SYS UMG8900 Configuration Guide
1.5.2 Emergency Call for Special Service

At the MSOFTX3000 side, you can configure the type and number of an emergency call for special service on the local maintenance terminal. After the configuration, the system can obtain the called number based on the type of the emergency call. Table 1-7 lists the configuration steps. Table 1-7 Configuration steps Step 1 2 3 Operation Run LST ESRVCAT to list the types and numbers of emergency calls for special services. Run ADD ESRVCAT to add a type and number of an emergency call for a special service. Repeat step 2 to add more types and numbers.
The number of emergency call for special service is configured based on the local situation, when the speech service is opened. If a number has been configured, you do not have to configure it again.
1.5.3 Charging Flag of Emergency Call

Run MOD CNACLD to modify the charging flag of an emergency call. The TARIFF parameter defines whether to charge for an emergency call. The values of TARIFF are as follows: Charging indication No charging No indication
Issue 02 (2007-06-10)
1-21
1 Speech Service
1.6 Service Management

1.6.1 For Carriers
Carriers can provide and cancel the speech service through the HLR client. You do not have to subscribe to the emergency call service at the HLR client. The service is opened automatically when you open an account. The management of carriers to the speech service consists of the following aspects: Providing the speech service Canceling the speech service
For the details on configuration steps and parameter description, see the manuals relevant to the HLR.
1.6.2 For Mobile Subscribers

There is nothing for mobile subscribers to do to manage the speech service.
1.7 Charging and CDR

1.7.1 Generation of CDR
In each call, the MSOFTX3000 collects call data and generates CDRs. The CDRs are the basis for carriers to charge mobile subscribers. The MSOFTX3000 collects call data, generates original CDRs, and stores the CDRs in the bill pool. 1. 2. 3. 4. The MSOFTX3000 transfers the original CDRs to the iGateway Bill (iGWB) in real time. The iGWB processes the original CDRs and generates final CDRs. The iGWB transfers the final CDRs to the charging center. The PLMN carriers generate telecom CDRs based on the final CDRs.
The iGWB collects, stores, sorts and transforms the original CDRs generated by the MSOFTX3000. It also provides an access interface for the charging center. This ensures that the correct CDRs are transferred to the charging center in time. In addition, the iGWB transforms original CDRs to final CDRs based on subscriber requirements.
1.7.2 CDR for Ordinary Call

CDR for the Call Between Two Mobile Subscribers Under the Same VMSC
A and B are mobile subscribers under the same VMSC. A is the caller and B is the callee. Figure 1-9 shows the process of generating CDRs under this condition.
1-22
Issue 02 (2007-06-10)
1 Speech Service
Figure 1-9 Process of generating CDRs when the mobile caller and callee are under the same VMSC
A VMSC MOC MTC B
The VMSC generates two CDRs. One is for the MOC and the charged subscriber is A. The other is for the MTC and the charged subscriber is B.
CDR for the Call Between Two Mobile Subscribers Under Different VMSCs
A and B are mobile subscribers under two VMSCs, both of which belong to the local network. A is the caller and B is the callee. Figure 1-10 shows the process of generating CDRs under this condition. Figure 1-10 Process of generating CDRs when the mobile caller and callee are under different VMSCs
A VMSCA MOC VMSCB MOC B
VMSC A generates a CDR for the MOC and the charged subscriber is A. VMSC B generates a CDR for the MTC and the charged subscriber is B.
CDR for the Call from Mobile Subscriber to Fixed Line Subscriber
A is a mobile subscriber and B is a fixed line subscriber. The call from A to B involves the GMSC. The process of call connection is as follows: 1. 2. 3. VMSC A routes the call from A to the tandem MSC (TMSC). The TMSC forwards the call to the GMSC. The GMSC forwards the call to a switch in the fixed network.
Figure 1-11 shows the process of generating CDRs under this condition. Figure 1-11 Process of generating CDRs when a mobile subscriber calls a fixed line subscriber
B PSTN GMSC GWO TMSC TRANSIT VMSCA MOC A
VMSC A generates a CDR for the MOC and the charged subscriber is A.
Issue 02 (2007-06-10)
1-23
1 Speech Service
The TMSC generates a transit (TRANSIT) record, which is the reference for calculating the charge of occupied trunks in the local network. The GMSC generates a gateway outgoing (GWO) record, which is the reference for calculating the charge of occupied outgoing trunks between the wireless network and the fixed network. If the end office directly routes the call to the GMSC (without passing the TMSC), and then to the PSTN, no TRANSIT record is generated.
The TRANSIT record and GWO record are defined by MOD GBILLCTRL. That is, TRANSIT records can be generated not only by the TMSC, and GWO records can be generated not only by the GMSC. For example, in practice, if an end office directly connects to a switch in another network and acts as a gateway office, the end office can also generate GWO records after relevant data is configured.
CDR for the Call from Fixed Line Subscriber to Mobile Subscriber
A is a fixed line subscriber and B is a mobile subscriber. The call from A to B involves the GMSC. The process of call connection is as follows: 1. 2. 3. 4. The switch in the fixed network sends an IAI message to the GMSC. The GMSC obtains the MSRN of B. The GMSC routes the call to the TMSC after obtaining the MSRN. The TMSC routes the call to the VMSC.
Figure 1-12 shows the process of generating CDRs under this condition. Figure 1-12 Process of generating CDRs when a fixed line subscriber calls a mobile subscriber
A PSTN GMSC GWI TMSC TRANSIT VMSCA MTC B
The GMSC generates a gateway incoming (GWI) record, which is the reference for calculating the charge of occupied incoming trunks between the fixed network and the wireless network. The TMSC generates a TRANSIT record, which is the reference for calculating the charge of occupied trunks in the local network. VMSC B generates a CDR for the MTC and the charged subscriber is B. If the GMSC directly routes the call to the end office (without passing the TMSC), no TRANSIT record is generated.
The roaming record, TRANSIT record and GWO record are all defined by MOD GBILLCTRL.
1-24
Issue 02 (2007-06-10)
1 Speech Service
CDR for the Call Between Two Mobile Subscribers in Different Wireless Networks
Subscriber B belongs to the wireless network of carrier W. Subscriber A belongs to the wireless network of carrier Y. The switch in the network of carrier Y generates CDRs for A. The switch in the network of carrier W generates CDRs for B. The GMSCs in the two networks generate CDRs respectively for inter-network calculation. The call from A to B involves GMSC 1 and GMSC 2. The process of call connection is as follows: 1. 2. 3. VMSC 1 routes the call to GMSC 1. GMSC 1 routes the call to GMSC 2 that is in the network of carrier W. GMSC 2 routes the call to VMSC 2 after obtaining the MSRN.
Figure 1-13 shows the process of generating CDRs under this condition. Figure 1-13 Process of generating CDRs when the mobile caller and callee are in different wireless networks
GWI A VMSC1 MOC TMSC TRANSIT GMSC1 GWO ROAM GMSC2 VMSC2 MTC B
VMSC 1 generates a CDR for the MOC and the charged subscriber is A. VMSC 2 generates a CDR for the MTC and the charged subscriber is B. TMSC 1 generates a TRANSIT record. GMSC 1 generates a GWO record, which is the reference for calculating the charge of occupied outgoing trunks between the two wireless networks. GMSC 2 generates a GWI record, which is the reference for calculating the charge of occupied incoming trunks between the two wireless networks.
1.7.3 CDR for Emergency Call

After a mobile station successfully originates an emergency call, the MSC server at the caller side generates a CDR for the emergency call. The CDR consists of the source and destination of the call, and user identity. The CDR is stored in the iGWB and waits to be sent to the charging center. The CDR for an emergency call is of the same format as an MOC bill. Emergency call observation flag is set to True, and the service code is of an emergency call. If a subscriber makes an emergency call without a SIM/USIM, the network identifies the subscriber through IMEI.
Issue 02 (2007-06-10)
1-25
1 Speech Service
1.8 Service Interaction

Table 1-8 lists the interaction between the emergency call function and other services. Table 1-8 Interaction between the emergency call function and other services Services Emergency call and CLIR Emergency call and ODB Emergency call and CUG Interaction If the caller subscribes to the CLIR service, the calling number cannot be displayed on the phone of the callee. The ODB service does not prevent a subscriber from making an emergency call. The CUG service conflicts with the emergency call service.
Note: CLIR = calling line identification restriction; ODB = operator determined barring; CUG = closed user group
1.9 Reference
1.9.1 Protocols and Specifications
The reference of the speech service is as follows: 3GPP TS 22.101 4.6.0
1.9.2 Acronyms and Abbreviations

Acronym/Abbreviation CK CLIR CUG GMSC GSM HLR IK IMEI IMSI ISDN MOC Full Name Cipher Key Calling Line Identification Restriction Closed User Group Gateway Mobile Switching Center Global System for Mobile Communications Home Location Register Integrity Key International Mobile Station Equipment Identity International Mobile Station Identity Integrated Services Digital Network Mobile Originated Call
1-26
Issue 02 (2007-06-10)
1 Speech Service
Acronym/Abbreviation MSC MSISDN MSRN MTC PLMN PSTN SGSN SIM TMSI UE UMTS USIM VLR
Full Name Mobile Switching Center Mobile Station International ISDN Number Mobile Station Roaming Number Mobile Terminated Call Public Land Mobile Network Public Switched Telephone Network Serving GPRS Support Node Subscriber Identity Module Temp Mobile Subscriber Identifier User Equipment Universal Mobile Telecommunication Services UMTS Subscriber Identity Module Visitor Location Register
Issue 02 (2007-06-10)
1-27
Contents
Contents
2 Short Message Service ..............................................................................................................2-1
2.1 Service Description .......................................................................................................................................2-2 2.1.1 Function Code......................................................................................................................................2-2 2.1.2 Definition .............................................................................................................................................2-2 2.1.3 Benefits ................................................................................................................................................2-3 2.2 Availability ....................................................................................................................................................2-4 2.2.1 Requirements for NEs..........................................................................................................................2-4 2.2.2 Requirements for License ....................................................................................................................2-4 2.2.3 Applicable Versions..............................................................................................................................2-4 2.3 Working Principle..........................................................................................................................................2-5 2.3.1 Networking Structure...........................................................................................................................2-5 2.3.2 Short Message Transfer Path................................................................................................................2-6 2.4 Service Flows ................................................................................................................................................2-6 2.4.1 MAP Flows Related to SMS ................................................................................................................2-6 2.4.2 SM MO Flow .......................................................................................................................................2-9 2.4.3 SM MT Flow........................................................................................................................................2-9 2.4.4 Alert SMC Flows ............................................................................................................................... 2-11 2.5 Data Configuration......................................................................................................................................2-13 2.5.1 Data Configuration of the MSOFTX3000 .........................................................................................2-13 2.5.2 Data Configuration of the HLR..........................................................................................................2-14 2.6 Service Management ...................................................................................................................................2-15 2.6.1 For Carrier..........................................................................................................................................2-15 2.6.2 For Mobile Subscriber .......................................................................................................................2-15 2.7 Charging and CDR ......................................................................................................................................2-15 2.8 Service Interaction ......................................................................................................................................2-16 2.9 Reference ....................................................................................................................................................2-17 2.9.1 Protocols and Specifications ..............................................................................................................2-17 2.9.2 Acronyms and Abbreviations .............................................................................................................2-17
Issue 02 (2007-06-10)
Figures
Figures
Figure 2-1 Location of the SMC in a mobile network........................................................................................2-5 Figure 2-2 MAP_SEND_ROUTING_INFO_FOR_SM flow ............................................................................2-7 Figure 2-3 MAP_REPORT_SM_DELIVERY_STATUS flow...........................................................................2-7 Figure 2-4 MAP_READY_FOR_SM flow ........................................................................................................2-8 Figure 2-5 MAP_ALERT_SERVICE_CENTRE flow .......................................................................................2-8 Figure 2-6 SM MO flow.....................................................................................................................................2-9 Figure 2-7 SM MT flow ...................................................................................................................................2-10 Figure 2-8 Flow of alert SMC mobile station reachable ............................................................................... 2-11 Figure 2-9 Flow of alert SMC memory of MS ready ....................................................................................2-12 Figure 2-10 Flow of alert SMC SMS succeeds .............................................................................................2-13
ii
Issue 02 (2007-06-10)
Tables
Tables
Table 2-1 NEs required to realize the SMS ........................................................................................................2-4 Table 2-2 HUAWEI CS product versions that support the SMS ........................................................................2-4 Table 2-3 Functions of NEs in the transmission of SMs.....................................................................................2-5 Table 2-4 Functions of NEs in the transmission of SMs.....................................................................................2-6 Table 2-5 Interaction between the SMS and other services ..............................................................................2-16
Issue 02 (2007-06-10)
iii
2 Short Message Service
2
About This Chapter
Section 2.1 Service Description 2.2 Availability
Short Message Service
The following table lists the contents of this chapter. Describes The function code, function definition of this feature, and the benefits that carriers and mobile subscribers can obtain from this feature. The network elements (NEs) that are required for the feature, whether Licenses are required, and the version requirements of the NEs. The functions of the NEs, and networking requirements. The service flow of the network when providing this feature. The data configurations that are required on the MSOFTX3000 and the UMG8900. The service operations that carriers and mobile subscribers are required to implement when the network provides this feature. The charging and the generation of CDRs when the network provides this feature. The relationships and restrictions between this feature and other services or features. The protocols and specifications that this feature must comply with, and the acronyms and abbreviations of this chapter.
2.3 Working Principle 2.4 Service Flows 2.5 Data Configuration 2.6 Service Management
2.7 Charging and CDR 2.8 Service Interaction 2.9 Reference
Issue 02 (2007-06-10)
2-1

2.1.1 Function Code
Name Short message MO/PP (SMS-MO) Short message MT/PP (SMS-MT) Code WMFD-010201 WMFD-010202
2.1.2 Definition
The short message service (SMS) allows subscribers to send or receive information through the short message center (SMC).The information can be texts, pictures, and voices. "Short" means that the length of information sent in the SMS is short. A point to point (PTP) short message (SM) can have up to 140 bytes in size, that is, 160 ASCII characters or 70 Chinese characters. A broadcast SM can have 82 bytes per page, that is, 92 ASCII characters or 41 Chinese characters. A macro broadcast message can have up to 15 pages that are sent continuously. The PTP SMS allows subscribers to send or receive SMs at any time. The broadcast SMS allows subscribers to receive public information periodically and selectively. The SMSs fall into two categories: PTP SMSs and PTM SMSs. PTM is short for point to multipoint. The PTM SMSs mainly refers to the cell broadcast SMSs. The PTP SMSs fall into two categories: SM MT service (TS21) SM MO service (TS22) This chapter describes only the PTP SMSs. Name Mobile-Terminated Short Message (SM MT) Definition It refers to a process in which the SMC sends an SM to the mobile station (MS) and the MS returns a report indicating success or failure of the SMS. The following figure shows the process.
Short message delivery SMC report MS
2-2
Issue 02 (2007-06-10)
Name Mobile-Originated Short Message (SM MO)
Definition It refers to a process in which the MS sends an SM to another MS through the SMC and the SMC sends a report indicating success or failure of the SMS to the MS. The following figure shows the process.
Short message submission SMC report MS
Alert Service Centre (Alert SC)
Alert SMC Mobile Station Reachable If the SMS in the SM MT flow fails because of paging no reply or subscriber no answer, the SMC sends an SM status report to the HLR, containing the MSISDN of the callee and the address of the MO SMC. The HLR stores the information in the message waiting data (MWD) list and enables the Mobile Station Not Reachable Flag (MNRF).The VLR also enables the MNRF. At the same time, the SMC temporarily stores the SM that fails to be sent. When the MS makes or receives a call, or re-registers with the network through a location update, the VLR sends an SM ready alert with the cause as mobile subscriber reachable to the HLR if the VLR detects that the MS interacts with the network and the MNRF flag stored in the VLR indicates subscriber not reachable. Alert SMC Memory Ready If the SMS in the SM MT flow fails because of MS memory overflow, the SMC sends an SM status report to the HLR, containing the MSISDN of the callee and the address of the SMC. The HLR stores the information in the MWD list and enables the Mobile Station Memory Capacity Exceeded Flag (MCEF). At the same time, the SMC temporarily stores the SM that fails to be sent. If the MS deletes an SM and the memory released can be used to receive new messages, the MS sends a message indicating memory ready to the MSC server. Upon receipt of the message, the MSC server sends a message indicating memory of MS ready to the HLR. The HLR receives the message and checks the MCEF. The HLR sends an SM ready alert to the SMC specified in the MWD list.
2.1.3 Benefits
Beneficiary Carriers Description The SMS can help to provide value added services, information inquiry services, and services such as website SMS and pictures. It also expands service types and improves the average revenue per user (ARPU).
Issue 02 (2007-06-10)
2-3
Beneficiary Mobile subscribers
Description The SMS can be used to send information. It can also be used to receive information such as stock prices, weather reports, sports news, and bank accounts. This eases information query and makes subscribers feel closer to carriers.
2.2 Availability
The SMS is implemented through the interworking between the MS/UE, the radio access network (RAN), and the core network (CN). Table 2-1 lists the network elements (NEs) that are required to realize the SMS. Table 2-1 NEs required to realize the SMS MS/UE BTS/N odeB BSC/R NC MSC Server MGW SGSN VLR HLR SMC
MS = Mobile Station; UE = User Equipment, BTS = Base Transceiver Station; BSC = Base Station Controller; RNC = Radio Network Controller; MSC = Mobile Switching Center; MGW = Media Gateway; SGSN = Serving GPRS Support Node; VLR = Visitor Location Register; HLR = Home Location Register; SMC = Short Message Center
The symbol indicates that the NE is required.

The SMS is an optional feature of the radio access network (RAN) provided by Huawei Technologies Co., Ltd. (called Huawei in this manual). To use the SMS, both a License of the MSOFTX3000 and that of the SMC are required.

Table 2-2 lists the HUAWEI circuit switched (CS) domain product versions that support the SMS. Table 2-2 HUAWEI CS product versions that support the SMS NE MSC server MGW Product MSOFTX3000 UMG8900 Applicable Version V100R002 and later versions V200R002 and later versions
2-4
Issue 02 (2007-06-10)

2.3.1 Networking Structure
As a service processing system independent of the GSM/UMTS network, the SMS system performs the following functions: Submitting, storing, and forwarding SMs Interworking with the PSTN, ISDN, and PSPDN to transmit SMs from external short message entities (ESMEs) such as manual stations and automatic stations The SMC, as the SMS system provided by Huawei, brings together functions of the SMS-GMSC, SMS-interworking MSC (IWMSC), and service center (SC). Figure 2-1 shows the location of the SMC in a mobile network. Figure 2-1 Location of the SMC in a mobile network
MSC/VLR SMC InfoX PSTN/ISDN/ PSPDN
RAN
HLR
SGSN
MSC/VLR: Mobile Switching Center/Visited Location Register SMC: Short Message Center RAN: Radio Access Network GGSN: Gateway GPRS Support Node ISDN: Integrated Services Digital Network
GGSN
Internet
HLR: Home Location Register Infox: Infox Integrated Gateway SGSN: Serving GPRS Support Node PSTN: Public Switched Telephone Network PSPDN: Packet Switched Public Data Network
In a CS core network, the NEs related to the SMS system are the MSC, VLR, SGSN, and HLR. Table 2-3 lists the functions of the NEs in the transmission of SMs. Table 2-3 Functions of NEs in the transmission of SMs NE MSC Function After an SM is sent from the MS to the MSC through the RAN, the MSC forwards the SM to the SMC. After an SM is sent from the SMC to the MSC, the MSC obtains the routing and subscriber information from the VLR and forwards the SM to the MS through the RAN.
Issue 02 (2007-06-10)
2-5
NE VLR
Function It authenticates the subscriber to whom the SMC sends an SM. It provides routing for the MSC when the SMC sends an SM to the subscriber through the MSC.
SGSN
When an SM sent by the MS reaches the SGSN through the RAN, the SGSN forwards it to the SMC. After receiving an SM sent from the SMC, the SGSN forwards it to the MS through the RAN.
HLR
Before the SMC sends an SM, the HLR searches the MSC that serves the subscriber. If authentication is required when the MSC sends an SM, the MSC requests the authentication set from the VLR. If there is no authentication set in the VLR, the MSC requests it from the HLR. In all other cases, the MSC does not request basic subscriber information from the HLR when sending an SM.
2.3.2 Short Message Transfer Path

When different network access modes are used, the SM transfer paths are different. Table 2-4 lists the details. Table 2-4 Functions of NEs in the transmission of SMs Network Access Mode SGSN Short Message Transfer Path GMSC -> SGSN -> MS If the SGSN fails to forward an SM to the MS, the GMSC sends it to the VMSC. This is similar to the transfer means used in the GSM network. MSC GMSC -> VMSC -> MS
2.4 Service Flows

An SM can be transferred through the packet switched (PS) section described signaling flows of the CS domain only. domain or the CS domain. This
2.4.1 MAP Flows Related to SMS

MAP_SEND_ROUTING_INFO_FOR_SM
The flow is started by the GMSC to query the location information (MSC number or SGSN number) of the subscriber from the HLR. Thus, the SM can be routed to the MSC or SGSN. Figure 2-2 shows the flow.
2-6
Issue 02 (2007-06-10)
Figure 2-2 MAP_SEND_ROUTING_INFO_FOR_SM flow
GMSC
HLR
MAP_SEND_ROUTING_INFO_FOR_SM
MAP_SEND_ROUTING_INFO_FOR_SM_ACK
If the GMSC supports the general packet radio service (GPRS), the HLR may return two numbers: an SGSN number and an MSC number. If the GMSC does not support the GPRS, the HLR returns one number and whether the number is an SGSN number or an MSC number is determined by MOD SMDP.
MAP_REPORT_SM_DELIVERY_STATUS
The flow is started by the GMSC to inform the HLR whether the SM sending succeeds or fails. Figure 2-3 shows the flow. If the message sending succeeds, the HLR clears the MNRF and MCEF of the subscriber and starts the Alert_Service_Centre flow to the SMC specified in the MWD list. If the message sending fails, the HLR saves the address of the SMC or the cause of MS not reachable to the MWD list. Figure 2-3 MAP_REPORT_SM_DELIVERY_STATUS flow
GMSC
HLR
MAP_REPORT_SM_DELIVERY_STATUS
MAP_REPORT_SM_DELIVERY_STATUS _ACK
MAP_READY_FOR_SM
The flow is started by the VLR/SGSN to inform the HLR that the MS memory is ready. Upon receipt of the message, the HLR clears the MCEF and starts the
Issue 02 (2007-06-10)
2-7
MAP_ALERT_SERVICE_CENTRE flow to the SMC if the address of the SMC exists in the MWD list. If the HLR detects that the MCEF and the MNFG/MNRG of the subscriber are not enabled, which shows that the MAP_REPORT_SM_DELIVERY message is not sent to the HLR, the HLR sets a timer. After the message is received, the HLR sets the flag bits of the MCEF and the MNFG/MNRG to 0. Figure 2-4 shows the flow. Figure 2-4 MAP_READY_FOR_SM flow
VLR/SGSN
HLR
MAP_READY_FOR_SM
MAP_READY_FOR_SM _ACK
MAP_ALERT_SERVICE_CENTRE
When processing the MAP_READY_FOR_SM flow, location update flow, or GPRS location update flow, the HLR starts the MAP_ALERT_SERVICE_CENTRE flow to the SMC and informs the SMC to resend the SM to the subscriber if the MNRF/MNRG of the subscriber is not reachable and the address of the SMC exists in the MWD list. Figure 2-5 shows the flow. Figure 2-5 MAP_ALERT_SERVICE_CENTRE flow
HLR
SMC
MAP_ALERT_SERVICE_CENTRE
MAP_ALERT_SERVICE_CENTRE_ACK
As the SMC provides the functions of an IWMSC, the MAP_Alert_Service_Centre message is sent from the HLR to the IWMSC logically.
2-8
Issue 02 (2007-06-10)
2.4.2 SM MO Flow
In the SM MO flow, a subscriber uses the MS to send an SM to the SMC. Figure 2-6 shows an SM MO flow. Figure 2-6 SM MO flow
MS
1. ShortMessage (RP_Data)
VMSC/SGSN
VLR
SMC
2.SEND_INFO_FOR_MO_SMS (*)
7.ShortMessage Error (RP_ERROR)
3.SEND_INFO_FOR_MO_SMS_ACK (*) 4.MO_FORWARD_SHORT_MESSAGE (RP_DATA) 5.MO_FORWARD_SHORT_MESSAGE_ACK (RP_ACK)
6.Short Message Acknowledgement(RP_ACK)
The messages with "(*)" are applicable to the MSC only, not the SGSN.
1. 2. 3. 4.
The MS sends an SM to the VMSC server or the SGSN through the A/Iu interface. Upon receipt of the SMS request, the VMSC server sends a subscriber data check request to the VLR based on the MSISDN of the MS. The VLR checks the subscription information and whether the local office supports the SMS, and sends the result to the VMSC server. The VMSC server analyzes the result. If the local office does not support SM MO, or it registers the outgoing call barring service, the VMSC server directly sends a reject message (RP_ERROR) to the MS. Otherwise, the VMSC server obtains the address of the SMC from the SM MO and transparently transmits the SM MO to the SMC. Upon receipt of the request, the SMC checks whether the data is valid. If yes, the SMC sends a message to the VMSC server or the SGSN to acknowledge the transparent transmission of the SM MO. Upon receipt of the message, the VMSC server or the SGSN sends the result of SM MO sending to the MS.
5.
6.
2.4.3 SM MT Flow
In an SM MT flow, the SMC sends an SM to the MS. Figure 2-7 shows an SM MT flow.
Issue 02 (2007-06-10)
2-9
Figure 2-7 SM MT flow

MS VMSC/ SGSN VLR HLR
(1) SEND_ROUTING_INFO_FOR_SM (2) SEND_ROUTING_INFO_FOR_SM_ACK (3).MT_FORWARD_SHORT_MESSAGE (RP_DATA) (4) SEND_INFO_FOR_MT_SMS (*)
(5) PAGE/SEARCH_FOR_MOBILE_SUBSCRIBER (*)
SMC
(6)Page (7) Page response

(8) PROCESS_ACCESS_REQUEST_ACK/ SEARCH_FOR_MOBILE_SUBSCRIBER_ACK (*)
(9) SEND_INFO_FOR_MT_SMS_ACK (*)

(10).Short Message (RP_DATA)
(11) Short Message Acknowledgemen t (RP_ACK)
(12) MT_FORWARD_SHORT_MESSAGE_ACK(RP_ACK)
The messages with "(*)" are applicable to the MSC only, not the SGSN.
1. 2.
Upon receipt of the SM MT, the SMC obtains the called number and uses it to request the routing information from the HLR. Upon receipt of the routing information, the HLR returns a response.
When the priority of the SM MT is high, the HLR returns a normal response to the SMC even if the MNRF and the MCEF are enabled.
The HLR searches the information of the subscriber in the database and returns a message with a failure cause to the SMC if one of the following occurs: The subscriber does not exist. Roaming is not allowed. Carrier determined call barring barring of all incoming calls or SMs MT The SM MT service is not supported. The MNRF is enabled. The MCEF is enabled. The subscriber is deleted by the MSC server/VLR to which the subscriber roams. If none of the preceding events occurs, the HLR sends the MSC number or the SGSN number to the SMC. 3. 4. 5. By using the MSC number, the SMC sends a transparent transmission request to the VMSC server. Upon receipt of the request, the VMSC server sends a request for checking SM MT subscriber data to the VLR. The VLR checks the subscription data and mobility management status:
2-10
Issue 02 (2007-06-10)
If the subscriber cannot be paged because the subscriber does not support SM MT, the handset is powered off, the MNRF is enabled, or the roaming is not allowed, the VMSC server sends a failure response to the SMC. If the location area of the MS is known, the VMSC server starts paging the MS in the specific location area. If the location area of the MS is unknown, the VMSC server starts paging the entire area controlled by the MSC server.
6. 7. 8.
The VMSC server pages the MS. The MS sends a response to the VMSC server. (8)(9)(10): Upon receipt of the response, the VMSC server starts the subscriber access process. After the process is complete, the VMSC server sends the SM to the MS through the Iu interface. (11)(12): After receiving the result from the MS, the VMSC server sends it to the SMC.
9.
10. If there are multiple SMs, that is, the RP-MMS exists in the transparent transmission request, the connections are maintained and (3), (10), (11), and (12) are repeated. 11. If no additional message is to be sent, all connections are released.
2.4.4 Alert SMC Flows

There are two scenarios: The activated MS re-alerts the SMC after the SMS fails because of mobile subscriber not reachable. The MS alerts the SMC when its memory is ready.
Alert SMC Mobile Station Reachable

Figure 2-8 shows the flow. Figure 2-8 Flow of alert SMC mobile station reachable
MS MSC/ SGSN VLR HLR SMC
(1) CM Service Req (**), Page resp or Location Updating
(2) Process_Access_Request/ Update_Location_Area (*) (3) Ready_For_SM/ Update_Location (4) Ready_for_SM_ack (5) Alert SC (6) Alert SC ack
The flow (2) is not applicable to the SGSN.
Alert SC: Alert_Service_Centre
Issue 02 (2007-06-10)
2-11
1. 2.
The MS makes or receives a call or updates the location to re-connect with the network. The MSC server sends an access request to the VLR if the MS makes or receives a call. Or the MSC server checks the data of the subscriber who updates the location if the MS updates the location. The VLR checks subscriber data. If the VLR detects that the MNRF of the subscriber is enabled, the VLR clears the MNRF and informs the HLR that the SM is ready with the cause as mobile subscriber reachable. The VLR directly sends a location update request to the HLR in the case of a location update flow. If the HLR receives the SM ready alert, it checks the dynamic data of the subscriber. If the MNRF is enabled, the HLR clears it, sends an Alert_Service_Centre message to the SMC, and sends a message to the VLR to acknowledge the sending of the SM ready alert. If the HLR receives a location update request and the MNRF in the dynamic data of the subscriber is enabled, the HLR clears the MNRF, sends an Alert_Service_Centre message to the SMC, and continues the location update flow.
The HLR sends the Alert_Service_Centre message to all SMCs specified in the MWD list. The HLR sends the Alert_Service_Centre message only when the MCEF of the MS is set to False.
3.
4.
5.
Upon receipt of the Alert_Service_Centre message, the SMC returns a response and tries to send SMs again.
Alert SMC Memory of MS Ready

Figure 2-9 shows the flow. Figure 2-9 Flow of alert SMC memory of MS ready
MS MSC/ SGSN HLR SMC
(1) SM memory capacity available
(2) READY_FOR_SM
(3) READY_FOR_SM_ACK (4) SM memory capacity available (5) ALERT_SERVICE_CENTRE
(6) ALERT_SERVICE_CENTRE_ACK
1. 2.
The MS sends a memory ready message to the MSC server through the Iu interface. The MSC server sends an SM ready message with the cause as memory of MS ready to the HLR.
2-12
Issue 02 (2007-06-10)
3.
Upon receipt of the message, the HLR checks the dynamic data of the subscriber. If the MCEF of the subscriber is enabled, the HLR clears it, sends an Alert_Service_Centre message to the MSC server, and sends an SM ready message to the VLR. Upon receipt of the message, the MSC server returns a response to the MS. Upon receipt of the Alert_Service_Centre message, the SMC returns a response and tries to resend the SM. The timing of the SM resending upon SMS failure is controlled by the SMC through the resending interval setting.
4.
Alert SMC SMS Succeeds

If the SMS succeeds, the HLR clears the MNRF and the MCEF and starts the Alert_Service_Centre flow to the SMC whose address is in the MWD list. Figure 2-10 shows the flow. Figure 2-10 Flow of alert SMC SMS succeeds
GMSC HLR SMC
(1) REPORT_SM_DELIVERY_STATUS (Successful Transfer)
(2) REPORT_SM_DELIVERY_ STATUS_ACK (3) ALERT_SERVICE_CENTRE
(4) ALERT_SERVICE_CENTRE_ACK
1. 2. 3. 4.
The GMSC server sends an SMS succeeds message to the HLR. Upon receipt of the message, the HLR returns a response. The HLR sends an Alert_Service_Centre message to the SMC. The SMC returns an Alert_Service_Centre_ACK message to the HLR.

The SMS is implemented through the signaling system. Therefore, you must configure data only on the MSC server and the HLR, not on the MGW.
2.5.1 Data Configuration of the MSOFTX3000

To implement the SMS, you must configure the signaling and service data of the MSOFTX3000 for interworking with the SMC.
Issue 02 (2007-06-10)
2-13
Adding MTP Data

To add MTP data, proceed as follows: Step 1 Add an MTP destination signaling point (DSP) by using ADD N7DSP. Step 2 Add an MTP linkset by using ADD N7LKS. Step 3 Add an MTP route by using ADD N7RT. Step 4 Add an MTP link by using ADD N7LNK. ----End
For details about the configuration steps and parameter descriptions, refer to the HUAWEI MSOFTX3000 Mobile SoftSwitch Center Configuration Guide.
Adding SCCP Data

To add SCCP data, proceed as follows: Step 1 Add an SCCP DSP by using ADD SCCPDSP. Set Network indicator to a value based on the actual requirements from the SMC to the SCCP DSP. You can set it to National network, for example. Step 2 Add an SCCP sub-system number by using ADD SCCPSSN. Add the MSC and SCCP management subsystem (SCMG) to the remote SMC. The local MSC, VLR, SCMG are already configured in the office information data. Therefore, run LST SCCPSSN to list the values and there is no need to configure the data again. Step 3 Add an SCCP GT group by using ADD SCCPGTG. Specify the GT group to which the SCCP GT group belongs during the configuration. Step 4 Add an SCCP global title by using ADD SCCPGT. Select a general global title. Select a network indicator based on the actual requirements. Set Numbering Plan to ISDN/telephony numbering Plan. Enter an SMC number such as 8613900007 as the GT address information. ----End
Setting MAP Feature Configuration

Step 1 Run LST MAPACCFG to see whether Support SMMO function and Support SMMT function are set to Yes. Step 2 If not, run SET MAPACCFG to set them to Yes. ----End
2.5.2 Data Configuration of the HLR

To implement the SMS, you must configure the signaling and service data of the HLR for interworking with the SMC.
For details about the configuration steps and parameter descriptions, refer to related HLR manuals.
2-14
Issue 02 (2007-06-10)

2.6.1 For Carrier
The following operations can be performed on an HLR client: Enable or Disable the SMS. List the path of an SM. Modify the path of an SM.
For details, refer to related operation manuals of the HLR.
2.6.2 For Mobile Subscriber

The address of the SMC can be configured.

Difference Between SMS CDR and Voice Call CDR
In an SMS call detail record (CDR), ordinary subscriber. there is no difference between an IN subscriber and an
The SMS uses signaling or voice channels to send characters. An SMS CDR, different from an ordinary voice call CDR, contains the following elements: Number of bytes: It indicates the actual number of bytes of the UserPart in an SM. It is the actual length of an SM after decoding. Address of SMC: It indicates which SMC is used for communication.
SMS CDR of Caller

If an SM is successfully sent to the SMC, the VMSC server that serves the subscriber who sends an SM generates an SMS CDR for the caller. The SMS CDR contains the IMSI and MSISDN of the caller, the number of the caller, the SMC address in E.164 format, the charging flag, the additional charging flag, and the content of the SM. The CDR files are saved in the iGWB. Based on FTAM or FTP, the iGWB sends the CDR files to the billing center through the TCP/IP connection. FTAM is short for File Transfer Access and Management Protocol.
SMS CDR of Callee

When a subscriber receives an SM, the VMSC server that serves the subscriber generates an SMS CDR for the callee. The SMS CDR contains the IMSI and MSISDN of the callee, the number of the caller, the SMC address in E.164 format, the charging flag, the additional charging flag, and the content of the SM.
Issue 02 (2007-06-10)
2-15
The CDR files are saved in the iGWB. Based on FTAM or FTP, the iGWB sends the CDR files to the billing center through the TCP/IP connection.

Table 2-5 shows how the SMS interacts with other services. Table 2-5 Interaction between the SMS and other services Service Call barring Interaction The SM MO service is related to the following services: Barring of all outgoing calls (BAOC) Barring of outgoing international calls (BOIC) Barring of outgoing international calls except those directed to the home PLMN (BOIC-exHC) The SM MT service is related to the following services: Barring of all incoming calls (BAIC) Barring of incoming calls when roaming outside the home PLMN country (BICRoam) Call forwarding Hot billing It does not interact with the SMS. It interacts with the SM MO service. When a subscriber subscribes to the hot billing service, a hot billing flag is generated for each SM sent or received. The hot billing flag provides the charging data for all services of a subscriber. It is immediately sent to the billing center. Handover No SM can be sent during an intra-MSC or inter-MSC handover. An SM can be sent after the handover is complete. A handover request is rejected when an SM is being transmitted. The handover continues after the transmission of an SM is complete. IMSI attach/IMSI detach It interacts with the SM MT service. When the VLR sets the subscriber to IMSI detach, the subscriber is not reachable. If the SM is sent to a subscriber who is in IMSI detach state, the SM is stored in the SMC. After the IMSI is attached, the SMC tries to resend the SM.
2-16
Issue 02 (2007-06-10)
2.9 Reference
MNRF: Mobile station Not Reachable Flag MNRG: Mobile station Not Reachable for GPRS flag GPRS MNRR: Mobile station Not Reachable Reason MCEF: Memory Capability Exceed Flag MWD-List: Message Waiting Data-List

Acronym/Abbreviation ARPU BAIC BAOC BICRoam BOIC BOIC-exHC Full Name Average Revenue Per User Barring of All Incoming Calls Barring of All Outgoing Calls Barring of Incoming Calls when Roaming Outside the Home PLMN Country Barring of Outgoing International Calls Barring of Outgoing International Calls except those directed to the Home PLMN Country External Short Message Entity Gateway GPRS Support Node Gateway Mobile Switching Center General Packet Radio Service Global System for Mobile Communications Home Location Register Integrated Services Digital Network Mobile Station Mobile Switching Center Mobile Station International ISDN Number Packet Switched Public Data Network Public Switched Telephone Network Radio Access Network Serving GPRS Support Node
ESME GGSN GMSC GPRS GSM HLR ISDN MS MSC MSISDN PSPDN PSTN RAN SGSN
Issue 02 (2007-06-10)
2-17
Acronym/Abbreviation SMC SM MT SM MO SMS UMTS
Full Name Short Message Center Mobile-Terminated Short Message Mobile-Originated Short Message Short Message Service Universal Mobile Telecommunication Services
2-18
Issue 02 (2007-06-10)
Contents
Contents
3 Call Forwarding Supplementary Service ..............................................................................3-1
3.1 Service Description .......................................................................................................................................3-2 3.1.1 Function Code......................................................................................................................................3-2 3.1.2 Definition .............................................................................................................................................3-2 3.1.3 Benefits ................................................................................................................................................3-3 3.2 Availability ....................................................................................................................................................3-3 3.2.1 Requirements for NEs..........................................................................................................................3-3 3.2.2 Requirements for License ....................................................................................................................3-4 3.2.3 Applicable Versions..............................................................................................................................3-4 3.3 Working Principle..........................................................................................................................................3-4 3.3.1 Functions of the NEs............................................................................................................................3-4 3.3.2 Service Flow Inside the System ...........................................................................................................3-4 3.4 Service Flow..................................................................................................................................................3-7 3.4.1 CFU Service Flow................................................................................................................................3-7 3.4.2 CFB Service Flow................................................................................................................................3-8 3.4.3 CFNRy Service Flow .........................................................................................................................3-13 3.4.4 CFNRy Service Flow .........................................................................................................................3-15 3.5 Data Configuration......................................................................................................................................3-18 3.5.1 MSOFTX3000 Data Configuration....................................................................................................3-18 3.5.2 HLR Configuration ............................................................................................................................3-18 3.6 Service Management ...................................................................................................................................3-18 3.6.1 Operations by the Carriers .................................................................................................................3-19 3.6.2 Operations by the Subscribers............................................................................................................3-19 3.7 Charging and CDR ......................................................................................................................................3-21 3.7.1 Charging Principle .............................................................................................................................3-21 3.7.2 Difference Between CFU and CCF in Judging an International Call ................................................3-22 3.7.3 CDR Creation Principles....................................................................................................................3-22 3.8 Service Interaction ......................................................................................................................................3-24 3.8.1 CFU....................................................................................................................................................3-24 3.8.2 CFB....................................................................................................................................................3-27 3.8.3 CFNRy ...............................................................................................................................................3-30 3.8.4 CFNRc ...............................................................................................................................................3-32
Issue 02 (2007-06-10)
Contents
3.9 References ...................................................................................................................................................3-35 3.9.1 Protocols and Specifications ..............................................................................................................3-35 3.9.2 Acronyms and Abbreviations .............................................................................................................3-35
ii
Issue 02 (2007-06-10)
Figures
Figures
Figure 3-1 GMSC-originated call forwarding service flow................................................................................3-5 Figure 3-2 VMSC-originated call forwarding service flow................................................................................3-6 Figure 3-3 CFU service flow for a call forwarded to a PSTN subscriber...........................................................3-7 Figure 3-4 CFU service flow for a call forwarded to a mobile subscriber .........................................................3-8 Figure 3-5 NDUB service flow for a call forwarded to a PSTN subscriber .......................................................3-9 Figure 3-6 UDUB service flow for a call forwarded to a PSTN subscriber .....................................................3-10 Figure 3-7 NDUB service flow for a call forwarded to a mobile subscriber.................................................... 3-11 Figure 3-8 UDUB service flow for a call forwarded to a mobile subscriber....................................................3-12 Figure 3-9 CFNRy service flow for a call forwarded to a PSTN subscriber ....................................................3-13 Figure 3-10 CFNRy service flow for a call forwarded to a mobile subscriber. ................................................3-14 Figure 3-11 CFNRc service flow for call forwarded to a PSTN subscriber .....................................................3-16 Figure 3-12 CFNRc service flow for the mobile forwarded-to subscriber .......................................................3-17 Figure 3-13 Charging of the call forwarding services ......................................................................................3-22
Issue 02 (2007-06-10)
iii
Tables
Tables
Table 3-1 Function code .....................................................................................................................................3-2 Table 3-2 Definitions of the call forwarding services.........................................................................................3-2 Table 3-3 Benefits of the call forwarding services .............................................................................................3-3 Table 3-4 Related NEs ........................................................................................................................................3-3 Table 3-5 Applicable versions ............................................................................................................................3-4 Table 3-6 Operation modes of the call forwarding service ...............................................................................3-18 Table 3-7 CFU service operations ....................................................................................................................3-19 Table 3-8 CFB service operations.....................................................................................................................3-20 Table 3-9 CFNRy service operations ................................................................................................................3-20 Table 3-10 CFNRc service operation................................................................................................................3-20 Table 3-11 Operations applicable to all the call forwarding services ...............................................................3-21 Table 3-12 All the CCF services .......................................................................................................................3-21 Table 3-13 CDR creation principles .................................................................................................................3-23 Table 3-14 Interaction between the CFU and other services ............................................................................3-24 Table 3-15 Interaction Between CUG and Call Forwarding.............................................................................3-27 Table 3-16 Service interaction between the CFB and other services................................................................3-28 Table 3-17 Interaction between CFNRy and other services..............................................................................3-30 Table 3-18 Interaction between CFNRc and other services..............................................................................3-33
iv
Issue 02 (2007-06-10)
3 Call Forwarding Supplementary Service
Call Forwarding Supplementary Service
About This Chapter

The following table lists the contents of this chapter. Section 3.1 Service Description Describes The function code, function definition of this feature, and the benefits that carriers and mobile subscribers can obtain from this feature. The network elements (NEs) that are required for the feature, whether Licenses are required, and the version requirements of the NEs. The functions of the NEs, and networking requirements. The service flow of the network when providing this feature. The data configurations that are required on the MSOFTX3000 and the UMG8900. The service operations that carriers and mobile subscribers are required to implement when the network provides this feature. The charging and the generation of CDRs when the network provides this feature. The relationships and restrictions between this feature and other services or features. The protocols and specifications that this feature must comply with, and the acronyms and abbreviations of this chapter.
3.2 Availability
3.3 Working Principle 3.4 Service Flow 3.5 Data Configuration 3.6 Service Management
3.7 Charging and CDR 3.8 Service Interaction 3.9 References
Issue 02 (2007-06-10)
3-1

3.1.1 Function Code
Table 3-1 lists the function codes of the call forwarding services. Table 3-1 Function code Name Call forwarding (CF) supplementary service Call forwarding unconditional (CFU) Call forwarding on mobile subscriber busy (CFB) Call forwarding on no reply (CFNRy) Call forwarding on mobile subscriber not reachable (CFNRc) Code WMFD-020100 WMFD-020101 WMFD-020102 WMFD-020103 WMFD-020104
3.1.2 Definition
Call forwarding service is used to forward the calls to a mobile subscriber to the third party according to the requirements of the carriers, the network, or the subscriber. Call forwarding services are divided into CFU, CFB, CFNRy, and CFNRc. Here, the third party can be a subscriber in the PLMN, PSTN, ISDN networks, or a service platform such as the voice mailbox. Table 3-2 lists the definitions of the call forwarding services. Table 3-2 Definitions of the call forwarding services Name CFU CFB Definition All the calls to a mobile subscriber are forwarded unconditionally to the third party. The calls to a mobile subscriber are forwarded to the third party if the subscriber is busy. The CFB can be further divided into: Network determined user busy (NDUB) User determined user busy (UDUB) CFNRy The calls to a mobile subscriber are forwarded to the third party if the no reply timer expires.
3-2
Issue 02 (2007-06-10)
Name CFNRc
Definition If the wireless connection between the network and a called mobile subscriber fails, the calls to the mobile subscriber are forwarded to the third party. The triggering conditions of the CFNRc service includes mainly: The mobile subscriber does not respond to the paging. The wireless channel allocation fails. The mobile station is powered off. The forwarding may occur in the network where the caller resides or the network that the callee resides.
3.1.3 Benefits
Table 3-3 lists the benefits of the call forwarding services. Table 3-3 Benefits of the call forwarding services Beneficiary Carrier Description The service can both bring added value to the carrier and improve the call connection success rate. A subscriber can activate or deactivate the call forwarding services provided by the system through the mobile phones. In this way, the subscriber can select the terminal and the site for answering a call. The call quality is improved consequently.
Subscriber
3.2 Availability
The MSC server, the VLR, and the HLR work together to implement the call forwarding services. Table 3-4 lists the related NEs. Table 3-4 Related NEs UE/MS NodeB/ BTS RNC/B SC MSC Server MGW SGSN VLR HLR
Issue 02 (2007-06-10)
3-3
The symbol represents that the NE is required to implement the service.

Call forwarding is a basic service of HUAWEI wireless core network. You can use the service without acquiring a license.

Table 3-5 lists the applicable versions of the call forwarding service. Table 3-5 Applicable versions Product MSC Server MGW MSOFTX3000 UMG8900 Applicable Version V100R002 and later versions V200R002 and later versions

3.3.1 Functions of the NEs
The MSC server, the MGW, and the VLR work together to implement functions such as signaling processing, data analysis, announcement playing, and billing. The MSC server and the MGW work together to implement the announcement playing function. The MGW is mainly used to load the announcement files related to the call forwarding services. PSTN switches are used to process the calls forwarded to them and then route the calls to the destination PSTN terminal. Two steps need to be implemented on the HLR to ensure the normal operation of the call forwarding services: Call forwarding registration FTNs are analyzed and rectified in this step. Call forwarding triggering analysis The system determines which service to be triggered in this process. For example, the system may determine whether to trigger the CFU or the CFNRc service and return the FTN to the GMSC.
3.3.2 Service Flow Inside the System

Based on the call forwarding types, the service flow inside the system can be divided into GMSC-originated forwarding and VMSC-originated forwarding.
3-4
Issue 02 (2007-06-10)
GMSC-Originated Forwarding
The call forwarding services originated by the GMSC server after it has obtained the subscriber information from the HLR consists of: CFU CFNRc (when the called mobile subscriber is roaming in an area forbidding call forwarding or when the VLR number is unavailable.) Figure 3-1 shows the GMSC-originated call forwarding service flow. Figure 3-1 GMSC-originated call forwarding service flow
Caller
(6) (5) (2) (3) HLR (4) (G)MSC Server Callee (1)
Forwarded-to subscriber
The GMSC-originated call forwarding service flow is as follows: 1. 2. 3. 4. An incoming call to the callee is routed to the GMSC server. The GMSC server requests the routing information from the HLR of the callee. The HLR checks the authentication and subscription information of the callee. If the callee has subscribed to the CFU service or if the callee has subscribed to the CFNRc service and the call forwarding conditions are met, the HLR does not returns the MSRN but the forwarded to number (FTN) and the call forwarding causes directly to the GMSC server. The GMSC server determines the target subscriber based on the FTN and sends forwarding notification (if the callee has subscribed to the service to notify the caller when forwarding occurs) to the caller. The GMSC server sets up the call to the forwarded-to subscriber based on the FTN.
5.
6.
VMSC-Originated Forwarding
The call forwarding services originated by the serving MSC of the callee (subscriber B) consists of: CFB CFNRy
Issue 02 (2007-06-10)
3-5
CFNRc (when wireless channel congestion occurs) Figure 3-2 shows the VMSC-originated call forwarding service flow. Figure 3-2 VMSC-originated call forwarding service flow
Caller
(5)
(1)
(2)
(3) (4) HLR GMSC Server Callee
(5) (6) (8)
(9)
VMSC VLR S erver
Forwarded-to subscriber
The VMSC-originated call forwarding service flow is as follows: 1. 2. 3. 4. 5. 6. An incoming call to the callee is routed to the GMSC server. The GMSC server requests the routing information from the HLR of the callee. The HLR checks the authentication and subscription information of the callee. The HLR obtains the MSRN of the callee from the VLR. The GMSC server requests the VMSC server of the callee to set up the call based on the MSRN. The VMSC server requests the subscription information of the callee from the VLR. The VLR returns the call forwarding service information to the VMSC server. For CFNRy, it also returns the value of the no reply timer. After receiving the subscription information of the callee, the VMSC server checks whether the conditions to trigger the call forwarding service are met. The triggering principles are as follows:

7.
The CFNRy service is triggered if the no reply timer expires. The CFB service is triggered if the callee is busy. The CFNRc service is triggered if the callee does not respond to the paging, the MS of the callee is powered off, or the channel allocation fails.
8.
If the conditions for triggering a call forwarding service are met, the VMSC server requests the FTN from the VLR.
3-6
Issue 02 (2007-06-10)
9.
The VMSC server sets up the call to the forwarded-to subscriber based on the FTN.
3.4 Service Flow

This chapter describes only the call forwarding which takes place before a MGW is selected. The user plane bearing is established after the call is forwarding to different target offices.
3.4.1 CFU Service Flow

In CFU service, the call is forwarded under any situation. information is stored in the HLR. The CFU service subscription
Forwarding to a PSTN Subscriber

Figure 3-3 shows the CFU service flow for a call forwarded to a PSTN subscriber. Figure 3-3 CFU service flow for a call forwarded to a PSTN subscriber
MSa/UEa GMSC Server Set-up Info request Info ack OR1:N Set-up Set-up HLRb MSC Server b PSTN
OR1:Y Notification
OR2:Y
Info req: Information request OR1: Forwarding requested
Info ack: Information acknowledge OR2: Notification to calling subscriber required
The CFU service flow for call forwarded to a PSTN subscriber is as follows: 1. 2. The GMSC sends the Info req message to the HLR. The HLR returns the Info ack message to the GMSC.
On detecting that the callee has subscribed to and activated the CFU, the HLR includes the FTN in the Info ack message and sends the message to the GMSC server. The GMSC server forwards the call based on the FTN. If the Info ack message contains the information element Notification to calling party, the GMSC server sends the notification to the caller. If the subscriber has not registered to the CFU service, the call is routed to MSC Server B normally.
Issue 02 (2007-06-10)
3-7
3.
If the call forwarding conditions are met, the GMSC server forwards the call to the PSTN subscriber based on the FTN directly.
Forwarding to a Mobile Subscriber

Figure 3-4 shows the CFU service flow for a call forwarded to a mobile subscriber. Figure 3-4 CFU service flow for a call forwarded to a mobile subscriber
MSa/UEa GMSC Server Set-up Info request Info ack (FTN) OR1:N OR1:Y Set-up Info request Info Set-up Notification OR2:Y ack HLRb MSC Server b HLRc MSC Server c
OR1: Forwarding requested Info request: Information request
OR2: Notification to calling subscriber required Info ack: Information acknowledge
The CFU service flow for a call forwarded to a mobile subscriber is as follows: 1. 2. 3. The GMSC sends the Info request message to the HLR. The HLR returns the Info ack message to the GMSC. On detecting that the callee has subscribed to the CFU, the HLR includes the FTN in the Info ack message and sends the message to the GMSC server. The GMSC server forwards the call based on the FTN. If the Info ack message contains the information element Notification to calling party, the GMSC server sends the notification to the caller. The GMSC server sends the Info request message to HLR C where the forwarded-to subscriber resides to request the routing information. HLR C sends the Info ack message containing the routing information to the GMSC server. After receiving the routing information, the GMSC sends the Set-up message to MSC server C. MSC server C is responsible for paging the target mobile subscriber.
4. 5. 6. 7.
3.4.2 CFB Service Flow

In CFB service, the call is forwarded in network determined user busy (NDUB) or user determined user busy (UDUB) conditions. UDUB refers to the situation that the callee rejects the call after the MS of the callee rings. NDUB refers to the situation that there is no available
3-8
Issue 02 (2007-06-10)
network resource. For the forwarded-to subscriber, the call is not affected if the CFB is activated.
Forwarding to a PSTN Subscriber in NDUB

Figure 3-5 shows the NDUB service flow for a call forwarded to a PSTN subscriber. Figure 3-5 NDUB service flow for a call forwarded to a PSTN subscriber
MSa/UEa GMSC Server HLRb VLRb MSC Serverb MSb LEc
Set-up Info req Info ack Set-up Info req Page MS
Busy Subscriber OR1:N Impossible Call Completion Connect to following address OR2:Y Notification OR3:Y
Release
Release
OR1:Y Notification
Set-up
Info req: Information request NDUB: Network Determined User Busy OR2: Notification to forwarding subscriber required
Info ack: Information acknowledge OR1: Call to be forwarded OR3: Notification to calling subscriber required
The NDUB service flow for a call forwarded to a PSTN subscriber is as follows: 1. 2. 3. 4. 5. 6. 7. MS A sends the Setup message to the GMSC server. The GMSC server sends the Info req message to HLR B. HLR B sends the Info ack message containing the MSRN to the GMSC server. The GMSC server sends the Set-up message to MSC server B. After receiving the Set-up message, MSC server B sends the Info request message to VLR B to request the information about MS B. VLR B sends the Page MS message containing the FTN to MSC server B. MSC server B sends a response message to VLR B and indicates that the call setup fails and the failure reason is subscriber busy through the information element user error in the response message.
Issue 02 (2007-06-10)
3-9
8. 9.
If the subscriber has not registered to the CFB service, the call fails. If the subscriber has registered to the CFB service, go to step 9. MSC server B sends the Set-up message to the PSTN subscriber based on the FTN.
Forwarding to a PSTN Subscriber in UDUB

Figure 3-6 shows the UDUB service flow for a call forwarded to a PSTN subscriber. Figure 3-6 UDUB service flow for a call forwarded to a PSTN subscriber
MSa/UEa GMSC Server HLRb VLRb MSC Serverb MSb LEc
Set-up Info req Info ack Set-up Info req Page MS Set-up UDUB Busy Subscriber OR1:N Impossible Call Completion Connect to following address OR2:Y
Release Release
OR1:Y Notification
Set-up
UDUB: User Determined User Busy OR1: Call to be forwarded Info-req: Information request
LEc: Local Exchange c OR2: Notification to calling subscriber required Info-ack: Information acknowledge
The UDUB service flow for a call forwarded to a PSTN subscriber is as follow: 1. 2. 3. 4. 5. 6. 7. MS A sends the Setup message to the GMSC server. The GMSC server sends the Info req message to HLR B. HLR B sends the Info ack message to the GMSC server. The GMSC server sends the Set-up message to MSC server B based on the routing information. After receiving the Set-up message, MSC server B sends the Info req message to VLR B to request the information about MS B. VLR B sends the Page MS message to MSC server B. After MS B responds to the paging, MSC server B sends the Set-up message to MS B. After MS B rings, the UDUB service is triggered if the callee rejects the call.
3-10
Issue 02 (2007-06-10)
8.
MSC server B sends response message to VLR B and indicates that the call setup fails and that the failure reason is subscriber busy through the information element user error in the response message. The Page MS message sent from VLR B to MSC server B contains the information related to the forwarding, for example, the FTN and whether the caller and the callee is notified when forwarding occurs.
9.
10. If the callee has not subscribed to and activated the CFB service, the call fails. Otherwise, go to step 12. 11. MSC server B sends the Set-up message to the PSTN forwarded-to subscriber based on the FTN.
Forwarding to a Mobile Subscriber in NDUB

Figure 3-7 shows the NDUB service flow for call forwarded to a mobile subscriber. Figure 3-7 NDUB service flow for a call forwarded to a mobile subscriber
MSa/UEa GMSC Serfer HLRb VLRb MSC Server b MSb HLRc MSC Server c
Set-up Info req Info ack Set-up Info req Page MS Busy Subscriber Impossible Call Completion Release Release OR1:N Connect to following address OR1:Y
Info-req Info-ack Set-up Notificatio n OR3:Y
Notificatio n
OR2:Y
Info req: Information request NDUB: Network Determined User Busy OR2: Notification to forwarding subscriber required
Info ack: Information acknowledge OR1: Call to be forwarded OR3: Notification to calling subscriber required
The NDUB service flow for a call forwarded to a mobile subscriber is similar to the NDUB service flow for a call forwarded to a PSTN subscriber. The only difference lies in the call forwarding flow. The NDUB service flow for mobile forwarded-to subscriber is as follows:
Issue 02 (2007-06-10)
3-11
After receiving the FTN, MSC server B requests the routing information (through the Info req message) from HLR C. After HLR C sends the routing information (through the Info ack message) to MSC server B, MSC server B sends the Set-up message to MSC server C.
Forwarding to a Mobile Subscriber in UDUB

Figure 3-8 shows the UDUB service flow for a call forwarded to a mobile subscriber. Figure 3-8 UDUB service flow for a call forwarded to a mobile subscriber
MSa/UEa GMSC Server HLRb VLRb MSC Server b MSb HLRc MSC Server c
Set-up Info req Info ack Set-up Info req Page MS Set-up Busy Subscriber OR1:N Release Release OR1:Y Connect to following address Impossible Call Completion UDUB
Info req Info ack
Notificatio n
Set-up OR2:Y
Info req: Information request UDUB: User Determined User Busy OR2: Notification to calling subscriber required
Info ack: Information acknowledge OR1: Call to be forwarded
The UDUB service flow for a call forwarded to mobile subscriber is similar to the UDUB service flow for a call forwarded to a PSTN subscriber. The only difference lies in the forwarding flow. The UDUB service flow for mobile forwarded-to subscriber is as follows: After receiving the FTN, MSC server B requests the routing information (through the Info req message) from HLR C. After HLR C sends the routing information (through Info ack) to MSC server B, MSC server B sends the Set-up message to MSC server C.
3-12
Issue 02 (2007-06-10)
3.4.3 CFNRy Service Flow

In CFNRy service, all the calls of the basic service and certain other services are forwarded.

Figure 3-9 shows the CFNRy service flow for call forwarded to a PSTN subscriber. Figure 3-9 CFNRy service flow for a call forwarded to a PSTN subscriber
MSa/UEa GMSC Server HLRb VLRb MSC Server b MSb LEc
Set-up Info req Info ack Set-up Info req Info ack Set-up Start timer Info-req Impossible Call Completion OR1:N Release Release Connect to OR1:Y following address OR2:Y Notification OR3:Y Set-up Call conf Time expires
Notification
Info req: Information request OR1: Call to be forwarded OR3: Notification to calling subscriber required
Info ack: Information acknowledge OR2: Notification to forwarding subscriber required Call conf: Call confirmation
The CFNRy service flow when the call is forwarded to a PSTN subscriber is as follow: 1. 2. 3. 4. 5. 6. MS A sends the Setup message to the GMSC server. The GMSC server sends the Info req message to HLR B. HLR B sends the Info ack message containing the routing information to the GMSC server. The GMSC server sends the Set-up message to MSC server B based on the routing information. MSC server B requests the information of MS B from VLR B. VLR B sends the Info ack message to MSC server B.
Issue 02 (2007-06-10)
3-13
7. 8. 9.
MSC server B pages MS B. After MS B responds to the paging, a no reply timer is started on MSC server B. If the callee does not answer the call after the no reply timer expires, MSC server B starts the call release process. At the same time, MSC server B notifies VLR B that the no reply timer expires through the Info req message.

10. VLR B determines whether to forward the call as follows: If there is no CFNRy service data, the call is released. If there is CFNRy service data, VLR B forwards the data to MSC server B, which routes the call to the forwarded-to subscriber.

Figure 3-10 shows the CFNRy service flow for a call forwarded to a mobile subscriber. Figure 3-10 CFNRy service flow for a call forwarded to a mobile subscriber.
Set-up Info req Info ack Set-up Info req Info ack Set-up Call Conf
Info Req Impossible Call Completion Connect to following address
Release Release
OR1:N
OR1:Y
Info req Info ack Set-up
Notificatio n
OR2:Y
Notification OR3:Y
Info-req: Information request Call conf: Call confirmation OR2: Notification to forwarding subscriber required
Info-ack: Information acknowledge OR1: Call to be forwarded OR3: Notification to calling subscriber required
The CFNRy service flow for a call forwarded to a mobile subscriber is as follows: 1. 2. The MS A sends the Setup message to the GMSC server. The GMSC server sends the Info req message to HLR B.
3-14
Issue 02 (2007-06-10)
3. 4. 5. 6. 7. 8.
HLR B sends the Info-ack message to the GMSC server. The GMSC server sends the Set-up message to MSC server B. MSC server B requests the information of MS B from VLR B. VLR B sends the Info ack message to MSC server B. MSC server B pages MS B. After MS B responds to the paging, a no reply timer is started on MSC server B. If the callee does not answer the call after the no reply timer expires, MSC server B starts the call release process. At the same time, MSC server B notifies VLR B through the Info req message. VLR B determines whether to forward the call as follows:

9.
If there is no CFNRy service data, the call is released. If there is CFNRy service data, VLR B forwards the data to MSC server B, which routes the call to the forwarded-to subscriber.
3.4.4 CFNRy Service Flow

The CFNRc service is triggered in the following situations: The callee does not respond to the paging. The MS of the callee is powered off. The channel allocation fails. The following CFNRc service flow takes the situation when the subscriber does not respond to the paging as an example.
In the following examples, the CFNRc service flow is initiated by the VMSC. The GMSC-initiated CFNRc service flow is similar to the GMSC-initiated CFU service flow. For detailed information, refer to section 3.4.1 CFU Service Flow.

Figure 3-11 shows the CFNRc service flow for a call forwarded to a PSTN subscriber when the callee does not respond to the paging.
Issue 02 (2007-06-10)
3-15
Figure 3-11 CFNRc service flow for call forwarded to a PSTN subscriber
MSa/UEa GMSC Server HLRb VLRb MSC Server b MSb LEc
Set-up Info req Info ack
Provide Roaming No Roaming No Set-up Info req Page MS Absent Subscriber Impossible Call OR1:N Completion Paging No response
Release Release OR1:Y Notification OR2:Y Connect to following address
Set-up
Info req: Information request OR1: Call to be forwarded LEc: Local Exchange c
The CFNRc service flow for a call forwarded to a PSTN subscriber when the callee does not respond to the call is as follows: 1. 2. 3. 4. 5. 6. 7. 8. 9. MS A or TE A sends the Set-up message to the GMSC server. The GMSC server sends the Info request message to HLR B. HLR B sends the Provide Roaming Information message to VLR B. VLR B provides the roaming number to HLR B. HLR B sends the Info ack message to the GMSC server. The GMSC server sends the Set-up message to MSC server B. MSC server B requests the information of MS B from VLR B. VLR B sends the Page MS message to MSC server B. MSC server B pages MS B. If MS B does not respond to the paging, MSC server B returns page response to VLR B indicating the reason for no response is Absent Subscriber.

10. VLR B determines whether to forward the call. If the forwarding conditions are not met, the call is released. If the forwarding conditions are met, the call is routed based on the CFNRc service data.
3-16
Issue 02 (2007-06-10)

Figure 3-12 shows the CFNRc service flow for the mobile forwarded-to subscriber when the callee does not respond to the paging. Figure 3-12 CFNRc service flow for the mobile forwarded-to subscriber
Set-up Info req Provide Roaming No Roaming No
Info ack Set-up
Info req Page MS Absent Subscriber Impossible Call Completion Paging No response
OR1:N Release Release OR1:Y
Connect to following address
Info req Info ack Set-up
Notification
OR2:Y
Info req: Information request OR1: Call to be forwarded
The CFNRc service flow for the mobile forwarded-to subscriber when the callee does not respond to the paging is as follows: 1. 2. 3. 4. 5. 6. 7. MS A or TE A sends the Set-up message to the GMSC server. The GMSC server sends the Info request message to HLR B. HLR B sends the Provide Roaming Number message to VLR B. The GMSC server sends the Set-up message to MSC server B. MSC server B sends Info req to VLR B. VLR B sends Page MS to MSC server B. MSC server B pages MS B. If MS B does not respond to the paging, MSC server B returns page response to VLR B with the reason of the no response as Absent Subscriber. VLR B determines whether to forward the call.

If the forwarding conditions are not met, the call is released. If the forwarding conditions are met, the call is routed based on the CFNRc service data.
Issue 02 (2007-06-10)
3-17

3.5.1 MSOFTX3000 Data Configuration
The data configuration of CF SS for the MSOFTX3000 is complex. Please refer to the HUAWEI MSOFTX3000 Mobile SoftSwitch Center Configuration Guide.
3.5.2 HLR Configuration

Refer to the corresponding operation manuals of the HLR products for detailed operations.

The management operations of the CF SS consists of provisioning, activation, deactivation and deregistration. The definition of each operation is as follows: Provisioning The operation is performed by the carriers. It makes a service available to the subscribers. Its reverse operation is withdrawal. Withdrawal The operation is performed by the carriers. It makes a service unavailable to the subscribers. Its reverse operation is provisioning. Registration The operation is performed by the carriers or the subscribers. The operation is mainly used to input some dedicated supplementary service information. For certain services, the registration process also activates the services. Its reverse operation is deregistration. Deregistration The operation is used to delete the information input in the HLR in the registration. Its reverse operation is registration. Activation The operation is performed by the service providers, the subscribers, or the system. The operation makes the service ready for provisioning. Its reverse operation is deactivation. Deactivation The operation is performed by the service providers, the subscribers, or the system. It is used to terminate the process started by the activation operation. Its reverse operation is activation. The call forwarding services are activated once they are registered. You need not to activate a call forwarding service separately. A call forwarding service should be first provided, and then registered before it can be used by the subscribers. The call forwarding service has two operation modes, as shown in Table 3-6. Table 3-6 Operation modes of the call forwarding service Mode Carrier Site HLR Service Provisioning, withdrawal, registration, and deregistration. withdrawal, registration,
3-18
Issue 02 (2007-06-10)
Mode Subscriber
Site MS
Service Registration, activation, deactivation, and deregistration.
3.6.1 Operations by the Carriers

Through operations in the HLR, the carriers can control the provisioning, withdrawal, registration, and deregistration of the call forwarding services.
3.6.2 Operations by the Subscribers

Prerequisites
The system has provided the call forwarding services to the subscribers.
Operation Steps
By dialing the service feature code through the MSs, mobile subscribers can register, activate, deactivate, or deregister a service.
When registering an international FTN through the MS, you should add a symbol + before the country code. Otherwise the registration may fail. An example of the correct number format is as follows: +8613912345678.
Table 3-7 lists the procedures of CFU service operations. Table 3-7 CFU service operations Operation Registration (activating the service automatically) Deactivation: Activation Deregistration: Procedure The subscriber dials **21*FN# through the MS and then press the button used to send the information. Here, FN represents the FTN. The subscriber dials #21# through the MS and then press the button used to send the information. The subscriber dials *21# through the MS and then press the button used to send the information. The subscriber dials ##21# through the MS and then press the button used to send the information.
Table 3-8 lists the procedures of CFB service operations.
Issue 02 (2007-06-10)
3-19
Table 3-8 CFB service operations Operation Registration (activating the service automatically) Deactivation: Activation Deregistration: Procedure The subscriber dials **67*FN# through the MS and then press the button used to send the information. Here, FN represents the FTN. The subscriber dials #30.39kg through the MS and then press the button used to send the information. The subscriber dials *30.39kg through the MS and then press the button used to send the information. The subscriber dials ##30.39kg through the MS and then press the button used to send the information.
Table 3-9 lists the procedures of CFNRy service operations. Table 3-9 CFNRy service operations Operation Registration (activating the service automatically) Deactivation: Activation Deregistration: Procedure The subscriber dials **61*FN# through the MS and then press the button used to send the information. Here, FN represents the FTN. The subscriber dials #27.67kg through the MS and then press the button used to send the information. The subscriber dials *27.67kg through the MS and then press the button used to send the information. The subscriber dials ##27.67kg through the MS and then press the button used to send the information.
Table 3-10 lists the procedures of CFNRc service operations. Table 3-10 CFNRc service operation Operation Registration (activating the service automatically) Deactivation: Activation Procedure The subscriber dials **62*FN# through the MS and then press the button used to send the information. Here, FN represents the FTN. The subscriber dials #28.12kg through the MS and then press the button used to send the information. The subscriber dials *28.12kg through the MS and then press the button used to send the information.
3-20
Issue 02 (2007-06-10)
Operation Deregistration:
Procedure The subscriber dials ##28.12kg through the MS and then press the button used to send the information.
Table 3-11 lists the procedures of operations applied to all the call forwarding services. Table 3-11 Operations applicable to all the call forwarding services Operation Registration (for all the call forwarding services) Procedure The subscriber dials **002*DN*T# through the MS and then press the button used to send the information. Here, DN represents the FTN. T represents the value of the no reply timer. It ranges from 5 to 30 seconds. The subscriber dials ##002# through the MS and then press the button used to send the information.
Deregistration (for all the call forwarding services)
Table 3-12 All the CCF services Operation Registration (for all the CCF services) Procedure The subscriber dials **004*DN*T# through the MS and then press the button used to send the information. Here, DN represents the FTN. T represents the value of the no reply timer. It ranges from 5 to 30 seconds. The subscriber dials ##004# through the MS and then press the button used to send the information.
Deregistration:

3.7.1 Charging Principle
Assume that the caller is A, the callee is B, and the forwarded-to subscriber is C. After querying the information and status of subscriber B, the originating MSC (or GMSC) routes the call to the office where the subscriber C resides, as shown in Figure 3-13.
Issue 02 (2007-06-10)
3-21
Figure 3-13 Charging of the call forwarding services

Subscriber A MSC A MSC B Subscriber B
GMSC
MSC C
Subscriber C
Charging Principle: Subscriber B, who has initiated the call forwarding, is charged as a caller, not as a callee. A separate CDR is created for the call forwarding service. In the CDR, B is the caller, C is the callee, and A is the third party.
3.7.2 Difference Between CFU and CCF in Judging an International Call

Call Forwarding (CF) refers to all the call forwarding services. Conditional Call Forwarding (CCF) consists of CFB, CFNRy, and CFNRc. In CFU, the MSC server within the country initiates the call forwarding and sends the Set-up message to the MSC where the forwarded-to subscriber resides. In CCF, the MSC server that the subscriber roams to initiates the call forwarding and sends the Set-up message to the MSC where the forwarded-to subscriber resides. Therefore, CFU and CCF define international numbers differently for the charging of international roaming. In the CFU service, an FTN is considered as an international number if it is not a number within the country. In the CCF service, an FTN is considered as an international number if it is not a number within the country where the callee roams to.
The CFNRc service initiated by the GMSC judges an international number in the same way as the CFU service.
3.7.3 CDR Creation Principles

Assume that the caller is A, the callee is B, and the forwarded-to subscriber is C. The CDR creation principles are shown in Table 3-13.
3-22
Issue 02 (2007-06-10)
Table 3-13 CDR creation principles Subscriber Type A, B, and C are GSM/UMTS subscribers and belong to the same MSC. CDR Creation Principle For subscriber A: The MSC creates a Mobile Originated Call (MOC) CDR with the A as the caller, B as the callee, and C as the third party. For subscriber B: The MSC creates a call forwarding CDR, with B as the caller, C as the callee, and A as the third party. The service feature indication is CALL_FORWARD_OTHER. For subscriber C: The MSC creates a Mobile Terminated Call (MTC) CDR with B as the caller, C as the callee, and A as the third party. A and B are GSM/UMTS subscribers and C is a PSTN subscriber. For subscriber A: The MSC where A resides creates a Mobile Originated Call (MOC) CDR, with A as the caller, B as the callee, and C as the third party. For subscriber B: The MSC where B resides creates a call forwarding CDR, with B as the caller, C as the callee, and A as the third party. The service feature indication is CALL_FORWARD_OTHER. The GSM or UMTS gateway creates a GWO CDR with B as the caller and C as the callee. A is a PSTN subscriber and B and C are GSM/UMTS subscribers. For subscriber C: The MSC where C resides creates a Mobile Terminated Call (MTC) CDR with B as the caller, C as the callee, and A as the third party. For subscriber B: The GSM or UMTS gateway creates a call forwarding CDR, with B as the caller, C as the callee, and A as the third party. The service feature indication is CALL_FORWARD_OTHER. A ROAM CDR with A as the caller and B as the callee is created at the GSM or UMTS gateway for trunk charging. A and C are PSTN subscribers and B is a GSM or UMTS subscriber. A ROAM CDR with A as the caller and B as the callee is created at the GSM or UMTS incoming gateway for trunk charging. The GSM or UMTS GWI creates a call forwarding CDR for B, with B as the caller, C as the callee, and A as the third party. The service feature indication is CALL_FORWARD_OTHER. The GSM or UMTS GWO creates a GWO CDR with B as the caller and C as the callee for trunk charging.
Issue 02 (2007-06-10)
3-23
To create gateway CDRs, you need to set the General Bill Control table as follows: Execute the MOD GBILLCTRL command and select GWO and GWI in Ticket Control Flag. To create ROAM CDRs, you need to set the General Bill Control as follows: Execute the MOD GBILLCTRL command and select ROAM in Ticket Control Flag.

This section describes the interaction between the call forwarding services and other services.
3.8.1 CFU
Table 3-14 lists the interaction between the CFU and other services. Table 3-14 Interaction between the CFU and other services Service CFU and CLIP Interaction The number of the caller is presented to the forwarded-to subscriber if: The call is forwarded. The forwarded-to subscriber subscribes to the CLIP service. The caller does not activate CLIP service. CFU and CLIR The CFU has no interaction with the CLIR. That is, if the caller subscribes to and activates CLIR, the forwarded-to subscriber cannot display the MSISDN of the caller unless the forwarded-to subscriber has the override capability. CFU and COLP If the callee forwards a call without notifying the caller, the caller cannot receive the call forwarding notification. When the call is answered, the number of the forwarded-to subscriber is not presented to the caller unless the forwarded-to subscriber has the override capability. In other cases, CFU has no interaction with COLP. CFU and COLR The CFU and the COLR have the following interactions: If the forwarded-to subscriber subscribes to the COLR service, the forwarded-to number will not be sent to the caller in the call forwarding notification. If the caller subscribes to the COLR service and has the override capability, the forwarded-to number will not be included in the call forwarding notification. When the call is answered, however, the override capability can be invoked to display the forwarded-to number.
3-24
Issue 02 (2007-06-10)
Service CFU and CFB
Interaction The CFU has a higher priority over the CFB. The CFU and the CFB have the following interactions: If a subscriber activates the CFU first, the subscriber cannot activate the CFB at the same time. The system will prompt that the two services conflict. If a subscriber activates the CFB first, the subscriber can also activate the CFU. If a subscriber receives a call, and if the subscriber activates both the CFB and CFU, the call will be forwarded unconditionally to the forwarded-to number registered in the CFU instead of the forwarded-to number registered in CFB.
CFU and CFNRy
The CFU has a higher priority over the CFNRy. The CFU and the CFNRy have the following interactions: If a subscriber activates the CFU first, the subscriber cannot activate the CFNRy at the same time. The system will prompt that the two services conflict. If a subscriber activates the CFNRy first, the subscriber can also activate the CFU. If a subscriber receives a call, and if the subscriber activates both the CFB and CFNRy, the call will be forwarded unconditionally to the forwarded-to number registered in the CFU instead of the forwarded-to number registered in the CFNRy.
CFU and CFNRc
The CFU has a higher priority over the CFNRc. The CFU and the CFNRc have the following interactions: If a subscriber activates the CFU first, the subscriber cannot activate the CFNRc at the same time. The system will prompt that the two services conflict. If the subscriber activates the CFNRc first, the subscriber can also activate the CFU. If the subscriber receives a call, and if the subscriber activates both the CFB and CFNRc, the call will be forwarded unconditionally to the forwarded-to number registered in the CFU instead of the forwarded-to number registered in the CFNRc.
CFU and CW
The CFU has a higher priority over the CW. When the callee is busy, and when both the CW and CFU of the subscriber are activated, the incoming calls of the subscriber will be forwarded unconditionally and the state of the call will not be changed.
Issue 02 (2007-06-10)
3-25
Service CFU and MPTY
Interaction The CFU has no interaction with the MPTY. For the caller: If a subscriber intends to set up MPTY with the subscriber that activates the CFU, the forwarded-to subscriber receives a notification and joins in the MPTY. For the forwarded-to subscriber: The forwarded-to subscriber can add an existing forwarded call to the MPTY.
CFU and CUG CFU and BAOC
See Table 3-15 for the interaction between the CFU and the CUG. The callee can not activate the CFU and the at the same time. If the callee activates the CFU, the BAOC cannot be activated. If the callee activates the BAOC, the CFU cannot be registered and activated.
CFU and BOIC
The CFU and the BOIC have the following interactions: If the callee activates the BOIC, registering of the CFU to an international number is rejected. If the callee registers an international number for the CFU, the callee cannot activate the BOIC.
CFU and BOIC-exHC
The CFUan the BOIN-exHC have the following interactions: If the callee activates the BOIC-exHC, the callee cannot register the CFU. If the subscriber activates the BOIC-exHC, the subscriber cannot register and activate the CFU service to the non-HPLMN numbers. If the subscriber activates the CFU forwarded to non-HPLMN numbers, the subscriber can not activate the BOIC-exHC.
CFU and BAIC
The callee cannot activate the CFU and the BAIC at the same time. If the callee activates the CFU, the callee cannot activate the BAIC. If the callee activates the BAIC, the callee cannot register and activate the CFU. If the call is forwarded to the subscriber who activates the BAIC, the call is rejected as any other incoming call.
CFU and BIC-ROAM
For the callee, the CFU has a higher priority over the BIC-ROAM. If the callee activates the BIC-ROAM, and if the callee registers or activates the CFU at the same time, the BIC-ROAM cannot be activated. If the callee activates the CFU, the callee cannot activate the BIC-ROAM at the same time. For the forwarded-to subscriber: If the call is forwarded to the subscriber who activates the BAIC, the call is rejected as any other incoming call.
3-26
Issue 02 (2007-06-10)
Table 3-15 Interaction Between CUG and Call Forwarding CUG Indication Type (from Network) Whether the Caller and Callee are in the Same CUG Attributes of the Callee CUG Subscribers not Allowed for Inter-Group Outgoing Calls InterGrou p Outgo ing Call Allow ed Inter-Group outgoing call not allowed Yes The call can be forwar ded. InterGroup Outgoing Call not Allowed CUG Subscribers Allowed for Inter-Group Outgoing Call Inte r-Gr oup Out goin g Call Allo wed The call can be forw arde d. Inter-Group Outgoing Call not Allowed Non-CUG Subscriber
The call is rejected.
The call is rejected
The call is rejected.
No Inter-Group outgoing call allowed Yes
The call is rejected. The call can be forwar ded. The call is rejected The call can be forw arde d. The call can be forwarded. The call can be forwarded.
No Normal call
The call is rejected. The call is rejected.
The call can be forwarded. The call can be forwarded. The call can be forwarded.
3.8.2 CFB
Table 3-16 describes the service interaction between the CFB and other services.
Issue 02 (2007-06-10)
3-27
Table 3-16 Service interaction between the CFB and other services Service CFB and CLIP Interaction The number of the caller is presented to the forwarded-to subscriber if: The call is forwarded. The caller does not activate the CLIR service. The forwarded-to subscriber subscribes to the CLIP service. CFB and CLIR The CFB has no interaction with the CLIR. That is, if the caller subscribes to and activates the CLIR, the number of the caller is presented to the forwarded-to subscriber unless the forwarded-to subscriber has the override capability. CFB and COLP If the callee forwards the call without notifying the caller, the caller cannot receive the call forwarding notification. When the call is answered, the number of the forwarded-to party is not presented to the caller unless the forwarded-to subscriber has the override capability. In other cases, the two services have no interaction. CFB and COLR The CFB and the COLR have the following interactions: If the forwarded-to subscriber subscribes to the COLR service, the forwarded-to number will not be sent to the caller in the call forwarding notification. If the caller subscribes to the COLR service and has the override capability, the forwarded-to number will not be included in the call forwarding notification. When the call is answered, however, the override capability can be invoked to display the forwarded-to number. CFB and CFU The CFU has a higher priority over the CFB. If a subscriber activates the CFU first, the subscriber cannot activate the CFB at the same time. The system will prompt that the two services conflict. If a subscriber activates the CFB first, the subscriber can also activate the CFU. If a subscriber receives a call, and if the both the CFB and CFU are activated , the call will be forwarded unconditionally to the forwarded-to number registered in the CFU instead of the forwarded-to number registered in the CFB. CFB and CW The CW has no interaction with the CFB. If the callee is busy owning to the network, the call will be processed as the CFB without notifying the callee. If the callee is busy, which is not caused by the network, the call will be connected to the callee. The callee decides whether to forward the call.
3-28
Issue 02 (2007-06-10)
Service CFB and MPTY
Interaction The CFU has no interaction with the MPTY. For the caller: If the callee intends to set up MPTY with the subscriber that activates the CFB, the forwarded-to subscriber receives a notification and joins in the MPTY. For the forwarded-to subscriber: The forwarded-to subscriber can use the forwarded call to set up the MPTY.
CFB and CUG CFB and AOC CFB and BAOC
See Table 3-12 for the interaction between the CFB and the CUG. The CFB has no interaction with the AOC. The callee cannot activate the CFB and the BAOC at the same time. If the callee activates the CFB, the BAOC cannot be activated in the same BSG. If the callee activates the BAOC, the CFB cannot be registered and activated in the same BSG.
CFB and BOIC
The CFB and the BOIC have the following interactions: If the callee activates BOIC, registering of the CFU and forwarded-to international number are rejected in the same BSG. If the callee activates the CFB forwarded to an international number (in the local PLMN), the callee cannot activates the BOIC in the same BSG. If the CFB is forwarded to a national number, and if the CFB and BOIC are activated at the same time, the CFB cannot be activated if the subscriber roams to other countries. If the subscriber roams back, the CFB can be activated.
CFB and BOIC-exHC
The CFB and the BOIC-exHC have the following interactions: In the same BSG, if the callee activates the BOIC-exHC, the CFB to a non-HPLMN international number cannot be registered or activated. In the same BSG, if the callee activates the CFB forwarded to a non-HPLMN international number, the BOIC-exHC cannot be activated. In the same BSG, if the callee activates the CFB forwarded to a national number or HPLMN number, the CFB and the BOIC-exHC can be activated in the same BSG. If the subscriber roams to other PLMN countries, the CFB cannot be activated. The CFB can be activated if the subscriber returns to HPLMN or the BOIC-exHC is deactivated.
Issue 02 (2007-06-10)
3-29
Service CFB and BAIC
Interaction The callee cannot activate the CFB and the BAIC at the same time. In the same BSG, if the subscriber activates the CFB, the BAIC cannot be activated. In the same BSG, if the subscriber activates the BAIC, the CFB cannot be registered and activated.
CFB and BIC-ROAM
For the callee: In the same BSG, if the callee activates BIC-ROAM, and if the BIC-ROAM is operational, CFB cannot be registered and activated. In the same BSG, if the callee activates BAIC, CFB cannot be registered and activated. In the same BSG, if the subscriber activates BIC-ROAM, but the BIC-ROAM is in the activation barring state, the subscriber can register and activate CFB. If the BIC-ROAM changes to operational, the CFB cannot be activated. In the same BSG, if the subscriber roams outside the HPLMN, and if the subscriber registers and activates the CFB and the CFB is operational, the subscriber cannot activate the BIC-ROAM. In the same BSG, if the subscriber registers and activates the CFB and the CFB is in the activation barring state, and if the subscriber roams in the HPLMN, the subscriber can activate the BIC-ROAM. For the forwarded-to subscriber: The call that is forwarded to the subscriber that activates the operational BIC-ROAM is rejected as any other incoming call.
3.8.3 CFNRy
Table 3-17 lists interaction between the CFNRy and other services. Table 3-17 Interaction between CFNRy and other services Service CFNRy and CLIP Interaction If a call is forwarded, the calling number is presented to the forwarded-to subscriber who has registered the CLIP, if the CLIP of the caller is not activated. If a call is forwarded, the calling number is not presented to the forwarded-to subscriber unless the forwarded-to subscriber has the override capability, if the caller has subscribed to and activated the CLIR. If the callee forwards a call without notifying the caller, the calling number is not presented to the forwarded-to subscriber unless the caller has the override capability.
CFNRy and CLIR
CFNRy and COLP
3-30
Issue 02 (2007-06-10)
Service CFNRy and COLR
Interaction If the forwarded-to subscriber has subscribed to the COLP, the forwarded-to number is not sent to the caller along with the forwarding notification. If the caller has subscribed to the COLP and has the override capability, the forwarded-to number is not contained in the forwarding notification received. The forwarded-to number, however, is presented to the caller through the override capability when the call is answered.
CFNRy and CFU
The CFU has higher priority over the CFNRy. If the CFU is activated, activating the CFNRy fails, prompting that a conflict occurs. If the CFNRy is activated, activating the CFU succeeds. When a call is made to a subscriber whose CFNRy and CFU are activated, the call is forwarded based on the CFU instead of the CFNRy.
CFNRy and CW
When a call is made to a subscriber whose CFNRy and CW are activated, the subscriber receives the CW prompt, and forwards the call if the call is not answered within a specific period of time. The CFNRy and MPTY do not affect each other. Assume that the caller wants to set up a MPTY call with the callee. If the CFNRy of the callee is activated, the forwarded-to subscriber receives a prompt and connects to the conference, if the call is not answered. The forwarded-to subscriber can add an existing forwarded call to a MPTY call.
CFNRy and MPTY
CFNRy and CUG CFNRy and BAOC
Table 3-15 lists interaction between the CFNRy and CUG. The CFNRy and BAOC cannot coexist. For the callee: In the same BSG, if the CFNRy is activated, the BAOC cannot be activated. In the same BSG, if the BAOC is activated, the CFNRy cannot be registered or activated.
CFNRy and BOIC
For the callee: In the same BSG, if the BOIC is activated, the CFNRy to an international number cannot be registered or activated. In the same BSG, if the CFNRy to an international number (from a HPLMN network) is activated, the BOIC cannot be activated. In the same BSG, if the CFNRy to a national number is activated, the BOIC can be activated; if the CFNRy to an international number is activated, the CFNRy cannot be activated. If the BOIC is then deregistered or activated to a national number, the CFNRy can be activated.
Issue 02 (2007-06-10)
3-31
Service CFNRy and BOIC-exHC
Interaction For the callee: In the same BSG, if the BOIC-exHC is activated, the CFNRy to an international number (except a HPLMN number) cannot be registered or activated. In the same BSG, if the CFNRy to a national number (except a HPLMN number) is activated, the BOIC-exHC cannot be activated. In the same BSG, if the CFNRy to a local number or HPLMN number is activated, the BOIC-exHC can be activated; if the CFNRy to another PLMN number is activated, the CFNRy cannot be activated. If the BOIC-exHC is then deregistered or activated to a HPLMN number, the CFNRy can be activated.
CFNRy and BAIC
For the callee: The CFNRy and BAOC cannot coexist. In the same BSG, if the CFNRy is activated, the BAIC cannot be activated. In the same BSG, if the BAIC is activated, the CFNRy cannot be registered or activated. For the forwarded-to subscriber: The call forwarded to a BAIC subscriber is rejected.
CFNRy and BIC-ROAM
For the callee: In the same BSG, if the BIC-ROAM is activated, the CFNRy cannot be registered or activated. In the same BSG, if the BIC-ROAM is not activated, the CFNRy can be registered and activated. But when the BIC-ROM is activated, the CFNRy automatically turns inactivated. In the same BSG, if the callee, whose CFNRy is registered and activated, roams outside of the HPLMN, the BIC-ROAM cannot be activated. In the same BSG, if the callee, whose CFNRy is not activated, roams inside of the HPLMN, the BIC-ROAM can be activated. For the forwarded-to subscriber: The call forwarded to a BIC-ROAM subscriber is rejected.
3.8.4 CFNRc
Table 3-18 lists interaction between CFNRy and other services.
3-32
Issue 02 (2007-06-10)
Table 3-18 Interaction between CFNRc and other services Service CFNRc and CLIP Interaction If a call is forwarded, the calling number is presented to the forwarded-to subscriber who has registered the CLIP, if the CLIP of the caller is not activated. If a call is forwarded, the calling number is not presented to the forwarded-to subscriber unless the forwarded-to subscriber has the override capability, if the caller has subscribed to and activated the CLIR. If the callee forwards a call without notifying the caller, the calling number is not presented to the forwarded-to subscriber unless the caller has the override capability. If the forwarded-to subscriber has subscribed to the COLP, the forwarded-to number is not sent to the caller along with the forwarding notification. If the caller has subscribed to the COLP and has the override capability, the forwarded-to number is not contained in the forwarding notification received. The forwarded-to number is presented to the caller through the override capability when the call is answered. CFNRc and CFU The CFU has higher priority over the CFNRc. If the CFU service is activated, activating the CFNRc fails, prompting that a conflict occurs. If the CFNRc is activated, activating the CFU succeeds. When a call is made to a subscriber whose CFNRc and CFU are activated, the call is forwarded based on the CFU instead of the CFNRc. CFNRc and MPTY The CFNRc and MPTY do not affect each other. Assumes that the caller wants to set up a MPTY call with the callee. If the CFNRc of the callee is activated, the forwarded-to subscriber receives a prompt, and connects to the conference if the callee is not reachable. The forwarded-to subscriber can add an existing forward call to a MPTY call. CFNRc and CUG CFNRc and AOC CFNRc and BAOC Table 3-15 lists interaction between the CFNRc and CUG. There is no interaction between CFNRc and AOC For the callee: In the BSG, the CFNRc and BAOC cannot coexist. In the same BSG, if the CFNRc is activated, the BAOC cannot be activated. In the same BSG, if the BAOC is activated, the CFNRc cannot be registered or activated.
CFNRc and CLIR
CFNRc and COLP
CFNRc and COLR
Issue 02 (2007-06-10)
3-33
Service CFNRc and BOIC
Interaction For the callee: In the same BSG, if the BOIC service is activated, the CFNRc to an international number cannot be registered or activated. In the same BSG, if the CFNRc to an international number (from a HPLMN network) is activated, the BOIC service cannot be activated. In the same BSG, if the CFNRc to a national number is activated, the BOIC can be activated; if the CFNRc to an international number is activated, the CFNR cannot be activated. If the BOIC is then deregistered or activated to a national number, the CFNRc can be activated.
CFNRc and BOIC-exHC
For the callee: In the same BSG, if the BOIC-exHC is activated, the CFNRc to an international number (except a HPLMN number) cannot be registered or activated. In the same BSG, if the CFNRc to a national number (except a HPLMN number) is activated, the BOIC-exHC cannot be activated. In the same BSG, if the CFNRc to a local number or HPLMN national number is activated, the BOIC-exHC can be activated; if the CFNRc to another PLMN number is activated, the CFNRc cannot be activated. If the BOIC-exHC service is then deregistered or activated to a HPLMN number, the CFNRc service can be activated.
CFNRc and BAIC
For the callee: The CFNRc and BAiC cannot coexist. In the same BSG, if the CFNRc is activated, the BAIC cannot be activated. In the same BSG, if the BAIC is activated, the CFNRc cannot be registered or activated. For the forwarded-to subscriber: The call forwarded to a BAIC subscriber is rejected.
3-34
Issue 02 (2007-06-10)
Service CFNRc and BIC-ROAM
Interaction For the callee: In the same BSG, if the BIC-ROAM is activated, the CFNRc cannot be registered or activated. In the same BSG, if the BIC-ROAM is registered but not activated, the CFNRc can be registered and activated. But when the BIC-ROM is activated, the CFNRy automatically turns inactivated. In the same BSG, if the callee, whose CFNRc is registered and activated, roams outside of the HPLMN, the BIC-ROAM cannot be activated. In the same BSG, if the callee, whose CFNRc is registered but not activated, roams inside of the HPLMN, the BIC-ROAM can be activated. For the forwarded-to subscriber: The call forwarded to a BIC-ROAM subscriber is rejected.
3.9 References
3GPP TS 22.082 V4.2.0 (2002-03) 3GPP TS 23.082 V4.3.0 (2002-06)

Acronym/Abbreviation CFU CFB CFNRy CFNRc Full Name Call Forwarding Unconditional Call Forwarding Busy Call Forwarding No Reply Call Forwarding on mobile subscriber Not Reachable
Issue 02 (2007-06-10)
3-35
Contents
Contents
4 Line Identification Service .......................................................................................................4-1
4.1 Service Description .......................................................................................................................................4-2 4.1.1 Function Code......................................................................................................................................4-2 4.1.2 Definition .............................................................................................................................................4-2 4.1.3 Types ....................................................................................................................................................4-3 4.1.4 Benefits ................................................................................................................................................4-4 4.2 Availability ....................................................................................................................................................4-4 4.2.1 Requirements for NEs..........................................................................................................................4-4 4.2.2 Requirements for License ....................................................................................................................4-5 4.2.3 Applicable Versions..............................................................................................................................4-5 4.3 Working Principle..........................................................................................................................................4-5 4.3.1 Service Data Management ...................................................................................................................4-5 4.3.2 CLIP.....................................................................................................................................................4-5 4.3.3 CLIR ....................................................................................................................................................4-5 4.3.4 COLP ...................................................................................................................................................4-6 4.3.5 COLR...................................................................................................................................................4-6 4.4 Service Flow..................................................................................................................................................4-6 4.4.1 CLIP.....................................................................................................................................................4-6 4.4.2 CLIR ....................................................................................................................................................4-7 4.4.3 COLP ...................................................................................................................................................4-8 4.4.4 COLR...................................................................................................................................................4-8 4.5 Data Configuration........................................................................................................................................4-9 4.5.1 Configuring Data at the MSOFTX3000 Side.......................................................................................4-9 4.5.2 Configuring Data at the HLR Side..................................................................................................... 4-11 4.6 Service Management ................................................................................................................................... 4-11 4.6.1 Opreations by Carriers ....................................................................................................................... 4-11 4.6.2 Operations by Mobile Subscribers ..................................................................................................... 4-11 4.7 Service Interaction ......................................................................................................................................4-12 4.7.1 CLIP...................................................................................................................................................4-12 4.7.2 CLIR ..................................................................................................................................................4-13 4.7.3 COLP .................................................................................................................................................4-13 4.7.4 COLR.................................................................................................................................................4-14
Issue 02 (2007-06-10)
Contents
4.8 Reference ....................................................................................................................................................4-14 4.8.1 Protocols and Specifications ..............................................................................................................4-14 4.8.2 Acronyms and Abbreviations .............................................................................................................4-15
ii
Issue 02 (2007-06-10)
Figures
Figures
Figure 4-1 CLIP service flow .............................................................................................................................4-6 Figure 4-2 CLIR service flow.............................................................................................................................4-7 Figure 4-3 COLP service flow............................................................................................................................4-8 Figure 4-4 COLR service flow ...........................................................................................................................4-8
Issue 02 (2007-06-10)
iii
Tables
Tables
Table 4-1 Names and codes of functions ............................................................................................................4-2 Table 4-2 Beneficiaries and description of the benefits ......................................................................................4-4 Table 4-3 NEs required by the line identification services .................................................................................4-4 Table 4-4 Applicable versions of Huawei wireless core network products ........................................................4-5 Table 4-5 Operation modes of the line identification services.......................................................................... 4-11 Table 4-6 CLIR service operation performed by mobile subscribers ...............................................................4-12 Table 4-7 Interactions between the CLIP service and other services................................................................4-12 Table 4-8 Interactions between the CLIR service and other services ...............................................................4-13 Table 4-9 Interactions between the COLP service and other services ..............................................................4-13 Table 4-10 Interactions between the COLR service and other services............................................................4-14
iv
Issue 02 (2007-06-10)
4 Line Identification Service
4
About This Chapter
Line Identification Service
The following table lists the contents of this chapter. Describes The function code, function definition of this feature, and the benefits that carriers and mobile subscribers can obtain from this feature. The network elements (NEs) that are required for the feature, whether Licenses are required, and the version requirements of the NEs. The functions of the NEs, and networking requirements. The service flow of the network when providing this feature. The data configurations that are required on the MSOFTX3000 and the UMG8900. The service operations that carriers and mobile subscribers are required to implement when the network provides this feature. The relationships and restrictions between this feature and other services or features. The protocols and specifications that this feature must comply with, and the acronyms and abbreviations of this chapter.
4.7 Service Interaction 4.8 Reference
Issue 02 (2007-06-10)
4-1

4.1.1 Function Code
Table 4-1 lists the names and codes of the functions. Table 4-1 Names and codes of functions Name CLIP CLIR COLP COLR Code WMFD-020301 WMFD-020302 WMFD-020303 WMFD-020304
Note: CLIP = Calling Line Identification Presentation; CLIR = Calling Line Identification Restriction; COLP = Connected Line Identification Presentation; COLR = Connected Line Identification Restriction
4.1.2 Definition
Line identification services are classified into two types: One is supplementary services that provide and restrict connected line identification for callers; the other is services that provide and restrict calling line identification for callees. Line Identity (LI) consists of the following information: ISDN/MSISDN number of subscriber Subaddress information (optional). The Public Land Mobile Network (PLMN) is not responsible for the content of subaddress. Calling Line Identity (CLI) identifies callers and Connected Line Identity (COL) identifies connected parties that refer to callees communicating with callers lastly. For common calls, connected parties indicate callees. For forwarding calls, forwarding target parties indicates callees. In some special applications, callers/callees are provided with additional CLI (aCLI) and additional COL (aCOL). When sending LI or additional Line Identity (aLI), the network additionally sends Presentation Indicator (PI) and Screening Indicator (SI): PI

Presentation allowed Presentation restricted Number not available due to interworking User provided, verified and passed User provided, not screened Network provided
SI

4-2
Issue 02 (2007-06-10)
In the Universal Mobile Telecommunications System (UMTS), if the PI value of a caller is Restrict providing, the network may send Cause of No CLI. Cause of No CLI

Unavailable Reject by user Interaction with other services Coin line or pay phone
4.1.3 Types
Line identification services are classified into CLIP, CLIR, COLP and COLR. Name CLIP Definition CLIP is a supplementary service provided for callees. The service provides calling line identification for callees. CLIP and CLIR are mutually exclusive. That is, when a callee activates the CLIP and the caller activates the CLIR, service conflict occurs. In general, the CLIR enjoys higher priority than the CLIP. Therefore, when service conflict occurs, the system processes according to the CLIR service. But if Override Category of the CLIP is Enable, the system processes according to the CLIP when service conflict occurs. CLIR CLIR is a supplementary service provided for callers. The service restricts that calling line identification is provided for callees. Carriers can provide the CLIR service for subscribers in permanent, temporary allowed and temporary restricted modes. Permanent mode: The CLIR service is invoked for every call. Temporary allowed mode: In default status, the CLIR service is not invoked. Subscribers can invoke the CLIR service temporarily through the menus of some mobile phones. Temporary restricted mode: In default status, the CLIR service is invoked. Subscribers can suppress the CLIR service temporarily through the menus of some mobile phones. COLP COLP is a supplementary service provided for callers. The service provides connected line identification for callers. COLP and COLR are mutually exclusive. That is, when a caller activates the COLP and the callee activates the COLR, service conflict occurs. In general, the COLR enjoys higher priority than the COLP. Therefore, when service conflict occurs, the system processes according to the COLR service. But if Override Category of the COLP is Enable, the system processes according to the COLP when service conflict occurs. COLR COLR is a supplementary service provided for callers. If a subscriber is a callee, the service restricts that connected line identification is provided for callers.
Issue 02 (2007-06-10)
4-3
4.1.4 Benefits
Table 4-2 lists the beneficiaries and description of the benefits. Table 4-2 Beneficiaries and description of the benefits Beneficiary Carriers Mobile subscribers Description The line identification services add values of services. After the CLIP service is provided, a subscriber can identify callers based on numbers presented by Mobile Station (MS) to determine whether to answer phones. Also, if the subscriber is unavailable to answer, the subscriber can reply later based on presented numbers. After the CLIR service is provided, a subscriber numbers is not presented on the MS of callee. Thus, the caller number can be kept secret. After the COLP service is provided, if a callee activates forwarding service and notifies the caller, forwarding number is presented on the MS of the caller. After the COLR service is provided, a called number is not presented on the MS of caller. After the COLR service is provided for a forwarding subscriber, forwarding number is not presented on the MS of caller.
4.2 Availability
Table 4-3 lists the network elements (NEs) required by the line identification services. Table 4-3 NEs required by the line identification services UE/MS NodeB/ BTS RNC/B SC MSC server MGW SGSN VLR HLR
Note: UE = user equipment; MS = mobile station; BTS = base transceiver station; RNC = radio network controller; BSC = base station controller; MSC = mobile switching center; MGW = media gateway; SGSN = serving GPRS support node; VLR = visitor location register; HLR = home location register
The symbol indicates that the corresponding NE is required. The hyphen - indicates that the corresponding NE is not required.
4-4
Issue 02 (2007-06-10)

The line identification services are basic services of Huawei wireless core network. No license is needed.

Table 4-4 lists the applicable versions of Huawei wireless core network products that the line identification services support. Table 4-4 Applicable versions of Huawei wireless core network products Product MSC server MSOFTX3000 Applicable Version V100R002 and later versions

4.3.1 Service Data Management
The HLR performs the following functions: Completes the management operations of carriers on service data. Modifies the subscription information that it stores. Updates the subscription information in the VLR by inserting subscriber data.
4.3.2 CLIP
The following section describes the working principle of the CLIP service: The Gateway MSC (GMSC) obtains CLI, PI, SI and possible aCLI, aPI and aSI from the VLR or incoming signaling, configures them in outgoing signaling and then sends them to the MSC of callee. Based on the earlier mentioned information and callee CLIP subscription information stored in the VLR, the MSC of callee determines whether to send CLI information to the callee.
4.3.3 CLIR
The following section describes the working principle of the CLIR service: A subscriber initiates a call. (For subscribers that subscribe CLIR temporary mode, the parameter whether to invoke the CLIR may be sent at that time.) The MSC of caller determines CLI, PI and SI in outgoing signaling based on CLIR subscription information stored in the VLR and CLI, PI and SI in A interface signaling. The MSC of caller sends corresponding CLI information in the outgoing signaling.
Issue 02 (2007-06-10)
4-5
4.3.4 COLP
The following section describes the working principle of the COLP service: When a callee answers the phone, the answer message sent by the MSC of callee to the MSC of caller carries COL, PI, SI and possible aCOL, aPI and aSI information. Based on COL, PI, SI and possible aCOL, aPI and aSI in incoming signaling, and caller COLP subscription information stored in the VLR, the MSC of caller sets the COL information to be sent to the caller. The MSC of caller sends answer message with COL information to the caller.
4.3.5 COLR
The following section describes the working principle of the COLR service: A callee answers the phone. The message sent to the MSC of callee carries COL, PI and SI. The MSC of callee sets COI, PI and SI to be sent to the MSC of caller based on callee COLR subscription information stored in the VLR and COL, PI and SI in A interface signaling. The MSC of callee sends answer message with COL, PI and SI to the MSC of caller.
4.4 Service Flow

4.4.1 CLIP
Figure 4-1 shows the CLIP service flow. Figure 4-1 CLIP service flow
MS/PSTN (G)MSC server HLRb MSC server b MS
SETUP(CLIPBN) or IAM(CLIPN,GN)
SRI PRN PRN ack SRI ack IAM(CLIPN,GN,CoNC) SETUP(CLIPBN,CoNC)
CLIPBN: Calling Party BCD Number CLIPN: Calling Party Number SRI: Send Routing Information ack: acknowledge
IAM: Initial Address Message GN: Generic number PRN: Provide Roaming Number CoNC: Cause of NO CLI
1.
If a caller is the MS, the MS sends the SETUP message to the MSC server. The parameter Calling Party BCD Number in the message contains CLI, PI and SI. If the
4-6
Issue 02 (2007-06-10)
caller is a fixed network subscriber, the Public Switched Telephone Network (PSTN) sends originated call message (such as the IAM message) to the GMSC server through trunk signaling. The parameter Calling Party Number in the originated call message contains CLI, PI and SI. In addition, the originated call message may contain parameters Generic number and Cause of NO CLI. The Generic number contains aCLI, aPI and aSI. 2. 3. 4. The (G)MSC server initiates the SRI operation to the HLRb. The HLRb initiates the PRN operation to the MSC server b (VLR). After obtaining the roaming number, the (G)MSC server transfers the originated call message to the MSC server b. The message contains the Calling Party Number and possible Generic number and Cause of NO CLI. The MSC server b sets Calling Party BCD Number and possible Cause of NO CLI in the SETUP message based on received CLI, PI and SI in the Calling Party Number, aCLI, aPI and aSI in the Generic number, Cause of NO CLI and CLIP subscription information. The MSC server b sends the SETUP message to the callee.
5.
6.
4.4.2 CLIR
Figure 4-2 shows the CLIR service flow. Figure 4-2 CLIR service flow
MS MSC server (G)MSC server
SETUP(CLIPBN,CLIR suppression or CLIR invocation) IAM(CLIPN,CoNC)
CLIPBN: Calling Party BCD Number CLIPN: Calling Party Number
IAM: Initial Address Message CoNC: Cause of NO CLI
1.
The MS sends the SETUP message to the GMSC server. The parameter Calling Party BCD Number in the message contains CLI, PI and SI. If CLIR service s in temporary allowed mode, when a subscriber invokes the CLIR service through the menu of mobile phone, the SETUP message contains the parameter CLIR invocation. If the CLIR service is in temporary restricted mode, when a subscriber shields the CLIR service through the menu of mobile phone, the SETUP message contains the parameter CLIR suppression. The MSC server sets Calling Party Number and possible Cause of NO CLI in originated call message (such as the IAM message) based on CLI, CLIR invocation, CLIR suppression and CLIR subscription information. The Calling Party Number contains CLI information. The MSC server sends the originated call message to called office.
If the SETUP message contains the parameter CLIR invocation and the subscriber does not subscribe the CLIR service, the MSC server directly end the call. If the call triggers some special application in the MSC server, the originated call message may contain the Generic number.
2.
3.
Issue 02 (2007-06-10)
4-7
4.4.3 COLP
Figure 4-3 shows the COLP service flow. Figure 4-3 COLP service flow
MS MSC server (G)MSC server PSTN/MS
ANM(CON number,GN) CONNECT(CON number)
CONNECT or ANM(CON number,GN)
CON: Connected GN: Generic number
ANM: Answer Message
1.
If a callee is the MS, when the MS answers, it sends the CONNECT message to the MSC server. Based on the callee COLR subscription information, the MSC server sets the value of Connected number in the answer message (such as the ANM message) sent to the MSC server of caller. The value of Connected number contains COL, PI and SI. If the call triggers some special application in the MSC server, the answer message may contain Generic number that contains aCOL, aPI and aSI information. If the callee is a fixed network subscriber, the GMSC server transparently transmits the received answer message (such as the ANM message). The answer message contains Connected number and possible Generic number. The (G)MSC server sends the answer message to the MSC server of caller. The MSC server sets the parameter Connected number in the CONNECT message based on received COL, PI, SI, possible aCOL, aPI and aSI, and COLP subscription information. The Connected number contains COL, PI and SI. The MSC server of caller sends the CONNECT message to the caller.
2. 3.
4.
4.4.4 COLR
Figure 4-4 shows the COLR service flow. Figure 4-4 COLR service flow
(G)MSC server MSC server MS
CONNECT ANM(CON number)
CON: Connected
ANM: Answer Message
4-8
Issue 02 (2007-06-10)
1. 2.
When the MS answers, it sends the Connect message to the MSC server. The MSC server sets the value of Connected number in the answer message (such as the ANM message) to be sent to calling office. The value of Connected number contains COL, PI and SI. The MSC server sends the answer message to the calling office.
3.

4.5.1 Configuring Data at the MSOFTX3000 Side
For the details of data configuration, see the HUAWEI MSOFTX3000 Mobile SoftSwitch Center Configuration Guide.
Enabling the Service

No additional data is required to enable the service.
Changing Caller Number Presentation

When the MSOFTX3000 acts as a landing office, it can change caller number presentation for different caller numbers, call sources and called numbers related to caller numbers. The change procedure is listed as follows: Step 1 If necessary, run ADD DNC to add number change format. Step 2 Run ADD CLIPRO to add a caller number and call source thus to change caller number presentation. Step 3 If necessary, run ADD CLCRPRO to add a called number related to the caller number thus to change caller number presentation. ----End The following table lists an example: Description Script For a caller number with call source name A and started with 60139, delete the prefix 60 when the caller number is presented. ADD DNC: DCN="DEL60", DCT=TYPE6, DCL=2; ADD CLIPRO: CSN="A", CLDCORNAME="DEL60"; CLIPFX=K'60139, CLIMAXLEN=13,
Changing Connected Number

When the MSOFTX3000 acts as an originating office, it can change connected numbers for different connected numbers and call sources. The change procedure is listed as follows: Step 1 If necessary, run ADD DNC to add number change format. Step 2 Run ADD AIDNUMPRO to add called number and call source thus to change connected number.
Issue 02 (2007-06-10)
4-9
----End The following table lists an example: Description Script For a connected number with call source name A and started with 755, add prefix 0 in front of it. ADD DNC: DCN="ADD0", DCT=TYPE1, ND=K'0; ADD AIDNUMPRO: CSCNAME="A", NUMTY=TY0, PFX=K'755, CDN="ADD0";
Related Software Parameters

Name P11 (TUP operation reserved parameter 4) Bit 0 Meaning It controls whether a caller number is allowed to be presented when No.1 signaling is incoming office or converted into No.7 signaling. It indicates whether to release when a subscriber has the CLIR request if the subscriber does not subscribe the CLIR service. It indicates whether the PI value in caller number parameter is set to CLI not available. It indicates whether the PI value in connected number parameter is set to COL not available. It controls the realization of COLR and CLIR functions. Value = 0: Allow a caller number to be presented. = 1: Not allow a caller number to be presented. Default Value 1
P51 (Call internal parameter 3) Bit 3
= 0: Not release. = 1: Release.
P123 (BICC operation reserved parameter 10) Bit 11 P123 (BICC operation reserved parameter 10) Bit 8 P140 (VLR software parameter) Bit 1
= 0: The PI value in caller number parameter is set to CLI not available. = 1: Process based on protocol. = 0: The PI value in connected number parameter is set to COL not available. = 1: Process based on protocol. = 0: Provide COLR and CLIR services based on subscriber subscription information. = 1: The VLR forces COLR and CLIR supplementary services are provided whether they are subscribed.
4-10
Issue 02 (2007-06-10)
Name P148 (Call internal parameter 13) Bit 1 and 0
Meaning It controls the realization of CLIP/CLIR function.
Value = 0: Set CLIR for all subscribers forcibly. = 1: Set CLIP for all subscribers forcibly. = 11: Determine the realization of CLIP/CLIR function based on 3GPP protocol.
Default Value 3
4.5.2 Configuring Data at the HLR Side

No data related to the service needs to be configured at the HLR side.

The line identification services have two operation modes, Table 4-5 Operation modes of the line identification services Operation Mode Operation by carriers Operation by mobile subscribers Operation Interface HLR MS Service Operations Provide the service. Withdraw the service. In temporary allowed mode, invoke the CLIR service. In temporary restricted mode, suppress the CLIR service. as listed in Table 4-5.
For supplementary line identification services, the services are activated when they are provided, and the services are deactivated when they are withdrawn.
4.6.1 Opreations by Carriers

For details, see the corresponding operation manual of the HLR.
4.6.2 Operations by Mobile Subscribers

Prerequisite
The system has provided the CLIR service in temporary allowed or temporary restricted mode for subscribers.
Issue 02 (2007-06-10)
4-11
Operations
On the MS, mobile subscribers can perform the operations listed in Table 4-6. Table 4-6 CLIR service operation performed by mobile subscribers Operation Type In temporary allowed mode, invoke the CLIR service. In temporary restricted mode, suppress the CLIR service. Step On the MS, dial "#31#DN", and then press the Send key. Of it, DN refers to a called number.
On the MS, dial "*31#DN", and then press the Send key. Of it, DN refers to a called number.
Subscribers can also perform the operations through the menus of some mobile phones. For details, see the user manuals of the mobile phones.

4.7.1 CLIP
Table 4-7 lists the interactions between the CLIP service and other services. Table 4-7 Interactions between the CLIP service and other services Service CLIP and CLIR Interaction In general, the CLIR service enjoys higher priority than the CLIP service. When a callee activates the CLIP service and the caller activates the CLIR service, the system processes according to the CLIR service. But if the CLIP property of the callee is OVERRIDE, the system processes according to the CLIP service. CLIP and CFU, CFB, CFNRy and CFNRc If the system provides the CLIP to a callee and the caller does not activate the CLIR service, when forwarding occurs, the caller number is presented to the callee according to the CLIP service. For example, subscriber A calls subscriber B. The call is forwarded to subscriber C. If C activates the CLIP service and A does not activate the CLIR service, the MS of C can present the number of A. CLIP and CW The CLIP and CW services are compatible. If a subscriber activates CLIP and CW service, calls are processed according to the CW service. In addition, the MS of the subscriber can present caller numbers.
4-12
Issue 02 (2007-06-10)
4.7.2 CLIR
Table 4-8 lists the interactions between the CLIR service and other services. Table 4-8 Interactions between the CLIR service and other services Service CLIR and CLIP Interaction In general, the CLIR service enjoys higher priority than the CLIP service. When a callee activates the CLIP service and the caller activates the CLIR service, the system processes according to the CLIR service. But if the CLIP property of the callee is OVERRIDE, the system processes according to the CLIP service. CLIR and CFU, CFB, CFNRy and CFNRc The CLIR and forwarding services are compatible. If a caller activates the CLIR service, the MS of forwarding target subscriber cannot present the caller number unless forwarded target subscriber activates the CLIP service and the property of CLIP is OVERRIDE. For example, subscriber A activates the CLIR service. A calls B. The call is forwarded to subscriber C. The MS of C cannot present the number of A.
4.7.3 COLP
Table 4-9 lists the interactions between the CLIP service and other services. Table 4-9 Interactions between the COLP service and other services Service COLP and COLR Interaction In general, the COLR service enjoys higher priority than the COLP service. When a caller activates the COLP service and the callee activates the COLR service, the system processes according to the COLR service. But if the COLP property of caller is OVERRIDE, the system processes according to the COLP service. COLP and MPTY If a subscriber activates both COLP and MPTY service. When the subscriber is a main controller, the COLP and MPTY services are compatible. When the subscriber is remote (participant of the MPTY service) the subscriber cannot receive COLP supplementary service information of other meeting participants.
Issue 02 (2007-06-10)
4-13
Service COLP and CFU, CFB, CFNRy and CFNRc
Interaction The COLP and forwarding services are compatible. If a caller activates the COLP service and the forwarded subscriber does not activate the COLR service, when the callee is forwarded, the callee notifies the caller. The MS of caller presents callee numbers. If the callee activates the forwarding service and selects not to notify the caller when forwarding occurs, the MS of caller cannot present the callee number unless the property of caller is OVERRIDE.
4.7.4 COLR
Table 4-10 lists the interactions between the COLR service and other services. Table 4-10 Interactions between the COLR service and other services Service COLR and COLP Interaction In general, the COLR service enjoys higher priority than the COLP service. When a caller activates the COLP service and the callee activates the COLR service, the system processes according to the COLR service. But if the COLP property of caller is OVERRIDE, the system processes according to the COLP service. COLR and CFU, CFB, CFNRy and CFNRc If a forwarded subscriber activates the COLR service, the forwarding notification does not provide the number of forwarded subscriber. If a caller activates the COLP service and the property of caller is OVERRIDE, the forwarding notification does not provide the number of forwarded subscriber, but the COLP service can be invoked to present callee numbers.
4.8 Reference
This following specifications and manuals are referred to: 3GPP TS 22.081 V4.1.0 3GPP TS 23.081 V4.1.0 3GPP TS 24.081 V4.1.0 3GPP TS 24.008 V4.15.0 3GPP TS 29.002 V4.15.0
4-14
Issue 02 (2007-06-10)
HUAWEI MSOFTX3000 Mobile SoftSwitch Center Configuration Guide HUAWEI HLR9820 Home Location Register Subscriber Management

Acronym/Abbreviation 3G 3GPP2 CLI COL CLIP CLIR COLP COLR Full Name The Third Generation 3rd Generation Partnership Project 2 Calling Line Identity Connected Line Identity Calling Line Identification Presentation Calling Line Identification Restriction Connected Line Identification Presentation Connected Line Identification Restriction
Issue 02 (2007-06-10)
4-15
Contents
Contents
5 Call Completion Supplementary Service..............................................................................5-1
5.1 Service Description .......................................................................................................................................5-2 5.1.1 Function Code......................................................................................................................................5-2 5.1.2 Definition .............................................................................................................................................5-2 5.1.3 Benefits ................................................................................................................................................5-3 5.2 Availability ....................................................................................................................................................5-3 5.2.1 Requirements for NEs..........................................................................................................................5-3 5.2.2 Requirements for License ....................................................................................................................5-3 5.2.3 Applicable Versions..............................................................................................................................5-4 5.3 Working Principle..........................................................................................................................................5-4 5.3.1 Service Data Management ...................................................................................................................5-4 5.3.2 Working Principle of CW.....................................................................................................................5-4 5.3.3 Working Principle of CH .....................................................................................................................5-5 5.4 Service Flow..................................................................................................................................................5-6 5.4.1 Service Flow of CW.............................................................................................................................5-6 5.4.2 Service Flow of CH ...........................................................................................................................5-10 5.5 Data Configuration......................................................................................................................................5-12 5.5.1 Configuring Data at the MSOFTX3000 Side.....................................................................................5-12 5.5.2 Configuring Data at the HLR Side.....................................................................................................5-14 5.6 Service Management ...................................................................................................................................5-14 5.6.1 Overview............................................................................................................................................5-14 5.6.2 Operations by Carriers .......................................................................................................................5-15 5.6.3 Operations by Mobile Subscribers .....................................................................................................5-15 5.7 Charging and CDR ......................................................................................................................................5-16 5.7.1 CW .....................................................................................................................................................5-16 5.7.2 CH......................................................................................................................................................5-17 5.8 Service Interaction ......................................................................................................................................5-18 5.8.1 CW .....................................................................................................................................................5-18 5.8.2 CH......................................................................................................................................................5-19 5.9 Reference ....................................................................................................................................................5-19 5.9.1 Protocols and Specifications ..............................................................................................................5-19 5.9.2 Acronyms and Abbreviations .............................................................................................................5-19
Issue 02 (2007-06-10)
Figures
Figures
Figure 5-1 Service flow when a subscriber accepts a waiting call .....................................................................5-7 Figure 5-2 Service flow when a subscriber rejects a waiting call.......................................................................5-9 Figure 5-3 Service flow for holding and retrieving a call.................................................................................5-10 Figure 5-4 Service flow for alternating from the A-B call to the A-C call ....................................................... 5-11
ii
Issue 02 (2007-06-10)
Tables
Tables
Table 5-1 Name and code of the function...........................................................................................................5-2 Table 5-2 Name and definition of the CW and CH services...............................................................................5-2 Table 5-3 Beneficiaries and description of the benefits ......................................................................................5-3 Table 5-4 NEs required by the call completion supplementary services ............................................................5-3 Table 5-5 Applicable versions of Huawei wireless core network products ........................................................5-4 Table 5-6 Related software parameters.............................................................................................................5-13 Table 5-7 Operation modes of the call completion supplementary services.....................................................5-14 Table 5-8 Operations performed by mobile subscribers ...................................................................................5-15 Table 5-9 Interactions between the CW service and other services ..................................................................5-18 Table 5-10 Interactions between the CH service and other services.................................................................5-19
Issue 02 (2007-06-10)
iii
5 Call Completion Supplementary Service
Call Completion Supplementary Service
About This Chapter

The following table lists the contents of this chapter. Section 5.1 Service Description Describes The function code, function definition of this feature, and the benefits that carriers and mobile subscribers can obtain from this feature. The network elements (NEs) that are required for the feature, whether Licenses are required, and the version requirements of the NEs. The functions of the NEs, and networking requirements. The service flow of the network when providing this feature. The data configurations that are required on the MSOFTX3000 and the UMG8900. The service operations that carriers and mobile subscribers are required to implement when the network provides this feature. The charging and the generation of CDRs when the network provides this feature. The relationships and restrictions between this feature and other services or features. The protocols and specifications that this feature must comply with, and the acronyms and abbreviations of this chapter.
5.2 Availability
Issue 02 (2007-06-10)
5-1

5.1.1 Function Code
Table 5-1 lists the name and code of the function. Table 5-1 Name and code of the function Name Call completion supplementary services Code WMFD-020400
5.1.2 Definition
The call completion supplementary services provide two services: call waiting (CW) and call hold (CH). Subscribers can choose either one to process two calls at the same time. Table 5-2 lists the name and definition of the CW and CH services. Table 5-2 Name and definition of the CW and CH services Name CW Definition The CW service enables a mobile subscriber to be notified of an incoming call notification under the following conditions: There is no idle service channel for the incoming call. The subscriber is in conversation, or has a call on hold. The subscriber can determine to accept, reject, or ignore the incoming call. The caller receives notifications during call waiting. For one subscriber, only one waiting call is allowed, and the system disconnects the subsequent incoming calls instantly. CH The CH service enables a mobile subscriber to interrupt the current call temporarily, and retrieve the call later if required. When the call is interrupted, the system reserves the traffic channel allocated for the call. When a call is on hold, and no active call is set up, a subscriber can: Retrieve the held call. Set up an active call. Disconnect the held call. When a call is on hold, and an active call is set up, the subscriber can: Alternate from one call to the other. Disconnect the active call. Disconnect the held call. Disconnect both the active call and the held call. For one subscriber, only one held call is allowed.
5-2
Issue 02 (2007-06-10)
5.1.3 Benefits
Table 5-3 lists the beneficiaries and description of the benefits. Table 5-3 Beneficiaries and description of the benefits Beneficiary Carriers Mobile subscribers Description The call completion supplementary services add values of services, and improve the call completion rate. Subscribers can activate and deactivate the CW service freely. This indicates that subscribers can control the CW service flexibly. After the CW service is activated, a subscriber can answer another call in conversation. Therefore, the subscriber can select the one that is more important. When the CH service is activated, a subscriber can hold the current call, and answer another call. This minimizes the possibility of missing calls, and improves the call completion rate.
5.2 Availability
Table 5-4 lists the network elements (NEs) required by the call completion supplementary services. Table 5-4 NEs required by the call completion supplementary services UE/MS Node B/BTS RNC/BSC MSC server MGW SGSN VLR HLR

The call completion supplementary services are basic services of Huawei wireless core network. No license is required.
Issue 02 (2007-06-10)
5-3

Table 5-5 lists the applicable versions of Huawei wireless core network products that the call completion supplementary services support. Table 5-5 Applicable versions of Huawei wireless core network products Product MSC server MGW MSOFTX3000 UMG8900 Applicable Version V100R002 and later versions V100R002 and later versions

Management on Service Data
The HLR performs the following functions: Completes the management operations of carriers on service data Modifies the subscription information stored in the HLR Updates the subscription information in the VLR by inserting subscriber data
Activation and Deactivation of CW

When a subscriber initiates the activation or deactivation operation, the MSC transparently sends the operation message to the HLR. The HLR modifies the subscription information stored in the HLR based on the message, and then updates the subscription information in the VLR by inserting subscriber data. For the CH service, there is no activation or deactivation operation.
5.3.2 Working Principle of CW

The following section describes the working principle of the CW service. When subscriber B is in conversation, the MSC receives a call from C to B (a C-B call). The MSC queries the subscription information of B. If the CW service is activated for B, the MSC processes the CW service. The MSC sends a SETUP message for setting up the C-B call to the MS. The message carries a CW indication. Currently, an A-B call is active or on hold. Therefore, the MS informs B of the incoming call based on the CW indication. At the same time, the MS sends a response to the MSC, indicating that B is busy. After receiving the response, the MSC waits for the ALERTING message from the callee.
5-4
Issue 02 (2007-06-10)
Upon receiving the ALERTING message, the MSC starts the CW timer T2 and the no-reply timer T3. The MSC then waits for the answer of B. At the same time, the MSC sends an ALERTING or ACM message to C, carrying the CW indication. Before B answers or disconnects the call, the MSC of B plays an announcement to C, instructing C to wait for the call. If B answers before T2 and T3 time out, the MS sends a CONNECT message to the MSC for connecting the C-B call. The MSC sends a response to the MS, and sends an acknowledge to C, indicating that the C-B call is set up. If B rejects the call before T2 and T3 time out, the MSC follows the normal flow to disconnect the waiting call. If T2 or T3 times out, the MSC sends a DISCONNECT message to B and C respectively, instructing them to release the C-B call.
5.3.3 Working Principle of CH

Overview
The following sections describe the working principle of the CH service, including two parts Holding a call Retrieving a call
Holding a Call
The following section describes the working principle for holding a call. 1. 2. 3. 4. A holds the call when A is in conversation with B. MS A sends a HOLD request to the MSC. The MSC queries the subscription information of A. If the CH service is activated for A, the MSC processes the CH service. The MSC determines whether to accept the request for the CH service based on the CH activation indication and other factors, for example, whether there is a held call. If the MSC rejects the request, it returns a HOLD REJECT message to MS A. The conversation between A and B continues. If the MSC accepts the request, it returns a HOLD ACKNOWLEDGE message to MS A, reserves the channel allocated for the current call, and sends a message to B or the MSC of B at the same time to notify B.
5.
Retrieving a Call
The following section describes the working principle for retrieve a call. 1. 2. 3. 4. A retrieves the A-B call. MS A sends a RETRIEVE request to the MSC. If the MSC rejects the request, it returns a RETRIEVE REJECT to MS A. The conversation between A and B continues. If the MSC accepts the requests, it returns a RETRIEVE ACKNOWLEDGE message to MS A, retrieves the connection of the original channel, and sends a message to B or the MSC of B at the same time to notify B.
Issue 02 (2007-06-10)
5-5
5.
If an A-C call is active, A returns a HOLD ACKNOWLEDGE message to the MS before 4, converts the active call to a held call, and sends a message to C and the MSC of C at the same time.
5.4 Service Flow

5.4.1 Service Flow of CW
Accepting a Waiting Call
The following section describes the flow of the CW service under the following conditions: The CW service is activated for B. An A-B call is active. The fixed network subscriber C calls B. B accepts the waiting call. Figure 5-1 shows the call flow.
5-6
Issue 02 (2007-06-10)
Figure 5-1 Service flow when a subscriber accepts a waiting call

PSTN C GMSC server HLR B MSC server B MS B
CALL A-B ACTIVE IAM SRI PRN PRN ack SRI ack IAM SETUP Call CONFIRMED ALERTING ACM ACM B wants to connect the waiting call. CONNECT CONNECT ack ANM ANM CALL B-C ACTIVE
IAM: Initial Address Message PRN: Provide Roaming Number ANM: Answer Message
SRI: Send Routing Information ACM: Address Complete Message ack: Acknowledge
The service flow when a subscriber accepts a waiting call is as follows: 1. 2. 3. 4. 5. 6. The PSTN subscriber C sends an IAM message to the gateway mobile switching center (GMSC) server. The GMSC server forwards the IAM message to MSC server B after obtaining the mobile station roaming number (MSRN) of MS B by sending an SRI request. MSC server B sends a SETUP message to MS B. The value of the Signal Information element in the message is 7 (call waiting tone on). MS B returns a CALL CONFIRMED message. The value of the Cause information element in the message is 17 (user busy). MSC server B allocates channels with the BSC or RNC. MS B sends an ALERTING message.
Issue 02 (2007-06-10)
5-7
7.
MSC server B sends an ACM message to the GMSC server, carrying a CW indication. MSC server B then follows the indication to play an announcement to C, instructing C to wait for the call. If B answers, MS B sends a CONNECT message to MSC server B. MSC server B returns a CONNECT ack message to MS B.
8. 9.
10. MSC server B sends an ANM message to the GMSC server, instructing C to answer. 11. The B-C call is set up.
The transaction identifier of the signaling messages for the B-C call is different from that for the A-B call. Thus MS B and MSC server B can identify the signaling messages.
Rejecting a Waiting Call

The following section describes the flow of the CW service under the following conditions: The CW service is activated for B. An A-B call is active. The fixed network subscriber C calls B. B rejects the waiting call. Figure 5-2 shows the call flow.
5-8
Issue 02 (2007-06-10)
Figure 5-2 Service flow when a subscriber rejects a waiting call

PSTN C GMSC server HLR B MSC server B MS B
CALL A-B ACTIVE IAM SRI PRN PRN ack SRI ack IAM SETUP CALL CONFIRMED ALERTING ACM ACM B rejects the call from C. DISCONNECT RELEASE REL REL RLC RLC RELEASE COMPLETE
IAM: Initial Address Message PRN: Provide Roaming Number REL: Release RLC: Release Complete
SRI: Send Routing Information ACM: Address Complete Message ack: Acknowledge
The service flow when a subscriber rejects a waiting call is as follows: 1. 2. 3. 4. 5. 6. 7. The PSTN subscriber C sends an IAM message to the GMSC server. The GMSC server forwards the IAM message to MSC server B after obtaining the MSRN of MS B by sending an SRI request. MSC server B sends a SETUP message to MS B. The value of the Signal Information element in the message is 7 (call waiting tone on). MS B returns a CALL CONFIRMED message. The value of the Cause information element in the message is 17 (user busy). MSC server B allocates channels with the BSC or RNC. MS B sends an ALERTING message. MSC server B sends an ACM message to the GMSC server, carrying a CW indication. MSC server B then follows the indication to play an announcement to C, instructing C to wait for the call. If B rejects the call, MS B sends a DISCONNECT message to MSC server B. The value of the Cause information element in the message is 17 (user busy).
8.
Issue 02 (2007-06-10)
5-9
9.
MSC server B returns a RELEASE message to release the B-C call.
10. MS B returns a RELEASE COMPLETE message, indicating that the release of the B-C call is complete at the MS side. 11. MSC server B sends an REL message to the GMSC server for call release. The value of the Cause information element is 17 (user busy). 12. The GMSC server returns an RLC message, indicating that the call release is complete.
The transaction identifier of the signaling messages for the B-C call is different from that for the A-B call. Thus MS B and MSC server B can identify the signaling messages.
5.4.2 Service Flow of CH

Holding and Retrieving a Call
The following section describes the service flow for holding and retrieving a call under the following conditions: The CH service is activated for A. An A-B call is active. B is a mobile subscriber. Figure 5-3 shows the service flow. Figure 5-3 Service flow for holding and retrieving a call
MS A MSC server A MSC server B MS B
CALL A-B ACTIVE A wants to hold the A-B call. HOLD HOLD ack CPG FACILITY CALL A-B on HOLD
A wants to retrieve the A-B call. RETRIEVE RETRIEVE ack CPG FACILITY CALL A-B ACTIVE
CPG: Call Progress
ack: Acknowledge
5-10
Issue 02 (2007-06-10)
The service flow for holding and retrieving a call is as follows: 1. 2. 3. 4. When A wants to hold the current A-B call, MS A sends a HOLD message to MSC server A, requesting MSC server A to hold the call. MSC server A accepts the request, and returns a HOLD ack message to MS A. MSC server A sends a CPG message to MSC server B, carrying a notification for remote hold. MSC server B sends a FACILITY message to MS B. In the message, the invoke component is NotifySS, in which CallOnHold-indicator is callOnHold. The message is used to inform MS B that the call is on hold. When A wants to retrieve the A-B call, MS A sends a RETRIEVE message to MSC server A, requesting MSC server A to retrieve the call. MSC server A accepts the request, and returns a RETRIEVE ack message to MS A. MSC server A sends a CPG message to MSC server B, carrying a notification for remote retrieve. MSC server B sends a FACILITY message to MS B. In the message, the invoke component is NotifySS, in which CallOnHold-indicator is callRetrieved. The message is used to inform MS B that the call is retrieved.
5. 6. 7. 8.
Alternating from One Call to the Other

The following section describes the service flow for alternating from one call to the other under the following conditions: The CH service is activated for A. An A-B call is active. An A-C call is on hold. B and C are mobile subscribers. Figure 5-4 shows the service flow for alternating from the A-B call to the A-C call. Figure 5-4 Service flow for alternating from the A-B call to the A-C call
MS A MSC server A MSC server B Call A-B active, call A-C on hold A wants to alternate from the A-B call to the A-C call. HOLD RETRIEVE HOLD ack CPG RETRIEVE ack CPG FACILITY Call A-B on hold, call A-C active FACILITY MS B MSC server C MSC
CPG: Call Progress
ack: Acknowledge
Issue 02 (2007-06-10)
5-11
The service flow for alternating from the A-B call to the A-C call is as follows: 1. When A wants to alternate from the A-B call to the A-C call, MS A sends a HOLD request to MSC server A for holding the A-B call, and a RETRIEVE request for retrieving the A-C call. MSC server A accepts the request, and returns a HOLD ack message to MS A. MSC server A sends a CPG message to MSC server B, carrying a notification for remote hold. MSC server B sends a FACILITY message to MS B. In the message, the invoke component is NotifySS, in which CallOnHold-indicator is callOnHold. The message is used to inform MS B that the call is on hold. MSC server A accepts the request, and returns a RETRIEVE ack message to MS A. MSC server A sends a CPG message to MSC server C, carrying a notification for remote retrieve. MSC server C sends a FACILITY message to MS C. In the message, the invoke component is NotifySS, in which CallOnHold-indicator is callRetrieved. The message is used to inform MS B that the call is retrieved.
The transaction identifier of the signaling messages for the A-C call is different from that for the A-B call. Thus MS A and MSC server A can identify the signaling messages.
2. 3. 4.
5. 6. 7.

Overview
For the details of data configuration, see HUAWEI MSOFTX3000 Mobile SoftSwitch Center Configuration Guide.

Generating CDRs
The command MOD GBILLCTRL is used to generate the call detail records (CDRs) of the CW and CH services.

Table 5-6 lists the related software parameters.
5-12
Issue 02 (2007-06-10)
Table 5-6 Related software parameters Name P19 (ISUP Operation Reserved Parameter 2) Bit 0 Meaning It determines whether to play the call waiting tone. Value = 0: If the callee who has registered with the CW service is busy, the caller hears the call waiting tone. When A and B are in conversation, C calls B. If the caller A has not registered with the call forwarding service, an ALERTING message containing FACILITY-IE is sent to inform C of the CW service. If A has registered with the call forwarding service, an ALERTING message containing FACILITY-IE is sent to inform C of the CW service. When the CW service interacts with the ring back tone (RBT) service, the caller hears the call waiting tone if the callee is in the same office. The caller hears the tone from another office if the callee is in another office. = 1: If the callee who has registered with the CW service is busy, the caller hears the ringback tone. When A and B are in conversation, C calls B. If the caller A has not registered with the call forwarding service, no ALERTING message containing FACILITY-IE is sent to inform C of the CW service. If A has registered with the call forwarding service, an ALERTING message containing FACILITY-IE is sent to inform C of the CW service. When the CW service interacts with the RBT service, the caller hears the RBT. P20 (ISUP Operation Reserved Parameter 3) Bit 4 It determines whether to play the call hold tone. = 0: Play the ringback tone. = 1: Play the call hold tone. 1 Default Value 1
Issue 02 (2007-06-10)
5-13
Name P129 (CHG Parameter 1) Bit 7
Meaning It determines whether to generate intermediate CDRs or event CDRs when the times of the handover or supplementary service operations exceed the limit. It determines whether to generate event CDRs when the subscriber, in call active state, invokes the CW service.
Value = 0: Generate intermediate CDRs. = 1: Generate event CDRs.
Default Value 1
P130 (CHG Parameter 2) Bit 10
= 0: Generate event CDRs. = 1: Not generate event CDRs.


5.6.1 Overview
The call completion supplementary services have two operation modes, as listed in Table 5-7. Table 5-7 Operation modes of the call completion supplementary services Operation Mode Operations by carriers Operation Interface HLR Service Operations Provide the service. Withdraw the service. Activate the service (for the CW service only). Deactivate the service (for the CW service only).
5-14
Issue 02 (2007-06-10)
Operation Mode Operations by mobile subscribers
Operation Interface MS
Service Operations Activate the service (for the CW service only). Deactivate the service (for the CW service only). Release and reject a waiting call. Hold an active call, and accept a waiting call. Set up a call, and hold the original active call. Accept a waiting call, and hold an active call. Alternate from an active call to a held call. Retrieve a held call, and release an active call. Release a held call. Release both the active call and the held call.
For the CH service, the service is activated when it is provided, and the service is deactivated when it is withdrawn.
5.6.2 Operations by Carriers


Prerequisite
The CW or CH service is provided for mobile subscribers.
Operations
On the MS, mobile subscribers can perform the operations listed in Table 5-8. Table 5-8 Operations performed by mobile subscribers Service Type CW CW Operation Type Activate the CW service. Deactivate the CW service. Step On the MS, dial "43#", and then press the Send key. On the MS, dial "#43#", and then press the Send key.
Issue 02 (2007-06-10)
5-15
Service Type CW
Operation Type Release and reject a waiting call. Release an active call, and answer a waiting call. Hold an active call, and accept a waiting call. Set up a call, and hold the original active call. Alternate from an active call to a held call. Retrieve a held call, and release an active call. Release a held call. Release both the active call and the held call.
Step On the MS, dial "0", and then press the Send key.
CW
On the MS, dial "1", and then press the Send key.
CW
CH
On the MS, dial the called number of the new call, and then press the Send key. On the MS, dial "2", and then press the Send key.
CH
CH
CH CH
On the MS, dial "0", and then press the Send key. On the MS, press the Release key.
Subscribers can also perform the operations through the menus of some mobile phones. For details, see the user manuals of the mobile phones.

5.7.1 CW
The MSOFTX3000 provides two ways to generate CDRs for the CW service: Independent charging Segment charging Independent charging means that the MSOFTX3000 generates the following CDRs: The event CDR containing the CW indicator and time stamp based on the CW notification The original MOC or MTC CDR for the whole A-B call
5-16
Issue 02 (2007-06-10)
The integrated Gateway Bill (iGWB) integrates the event CDR into the supplementary service domain of the original mobile originated call (MOC) or mobile terminated call (MTC) CDR to generate the final MOC or MTC CDR. Segment charging means that the MSOFTX3000 generates an intermediate MOC or MTC CDR at the time when a CW notification is generated. The billing center combines the group of CDRs, and processes other charging. The CW indicator and time stamp are in the last CDR. The MSOFTX3000 controls the mode for generating CDRs and the frequency for generating event or intermediate CDRs through the integrated CDR control tables of CHG Parameter 1 Bit 7. Usually, independent charging is adopted. The following gives an example of independent charging for the CW service. The scenario is as follows: A in the local office calls B in another office. C in another office calls A when A is in conversation with B. The supplementary service domain in the MOC CDR generated by the local office for the A-B call records the supplementary service operation. The supplementary service indicator is CW, and the time stamp is the time when a SETUP message is sent to A.
5.7.2 CH
The MSOFTX3000 provides two ways to generate CDRs for the CW service: Independent charging Segment charging Independent charging means that the MSOFTX3000 generates the following CDRs: The event CDR containing the CH indicator and time stamp based on the hold and retrieve operations The original MOC or MTC CDR for the whole call The iGWB integrates the event CDR into the supplementary service domain of the original MOC or MTC CDR to generate the final MOC or MTC CDR. Segment charging means that the MSOFTX3000 generates an intermediate MOC or MTC CDR at the time of the hold and retrieve operations. The billing center combines the group of CDRs and processes other charging. The CH indicator and time stamp are in the last CDR. The MSOFTX3000 controls the mode for generating CDRs, and the frequency for generating event or intermediate CDRs through the integrated CDR control tables of CHG Parameter 1 Bit 7. Usually, independent charging is adopted. The following gives an example of independent charging for the CH service. The scenario is as follows: A in the local office calls B in another office. A holds the call when A is in conversation with B. The supplementary service domain in the MOC CDR generated by the local office for the A-B call records the supplementary service operation. The supplementary service indicator is CH, and the time stamp is the time when A sends a HOLD message.
Issue 02 (2007-06-10)
5-17

5.8.1 CW
Table 5-9 lists the interactions between the CW service and other services. Table 5-9 Interactions between the CW service and other services Service CW and CFU Interaction The CFU service takes precedence over the CW service. When a callee who has both the CW and CFU services activated is called, the incoming call is forwarded unconditionally based on the CFU service, instead of being processed based on the CW service. CW and CFB The CW and CFB services are compatible. If the callee is NDUB, the system directly processes the incoming call based on the CFB service, without notifying the subscriber. If the callee is UDUB, the system notifies the subscriber, and the subscriber determines how to process the incoming call (process it based on the CFB or CW service). CW and CFNRy If both CFNRy and CW services are activated, a subscriber can receive the CW indication when serving as the callee. If the subscriber does not send any response before the expiry of the No Reply Condition timer, the call is processed based on the CFNRy service. If both CW and CH services are activated, a subscriber can use the CH service to answer a waiting call. If the subscriber is in conversation, and has a call on hold, the subscriber can still receive a CW indication, but cannot answer the call. If the subscriber is not in conversation, but has a call on hold, the subscriber can receive a CW indication. CW and CLIP The CLIP and CW services are compatible. If both CLIP and CW services are activated, the incoming call is processed based on the CW service, and the MS of the subscriber displays the number of the caller. The CW and MPTY services are compatible. If a subscriber has an active MPTY call, the subscriber can receive a CW indication when being called. When holding the MPTY call, the subscriber can answer the waiting call. CW and BAIC CW and BIC-ROAM The BAIC service takes precedence over the CW service. When the BAIC service is activated, the CW service cannot be activated. The activation of the BAIC service does not affect any waiting call. The BIC-ROAM service takes precedence over the CW service. When roaming out of the HPLMN, a subscriber cannot activate the CW service if the BIC-ROAM service is activated. The activation of the BIC-ROAM service does not affect any waiting call.
CW and CH
CW and MPTY
5-18
Issue 02 (2007-06-10)
Service
Interaction
Note: CFU = call forwarding unconditional; NDUB= network determined user busy; UDUB = user determined user busy; CFNRy = call forwarding no reply; CLIP = calling line identification presentation; MPTY = multiparty service; BAIC = barring of all incoming calls; BIC-ROAM = barring of incoming calls when roaming outside home PLMN country
5.8.2 CH
Table 5-10 lists the interactions between the CH service and other services. Table 5-10 Interactions between the CH service and other services Service CH and CW Interaction If both CW and CH services are activated, a subscriber can use the CH service to answer a waiting call. If the subscriber is in conversation, and has a call on hold, the subscriber can still receive a CW indication, but cannot answer the call. If the subscriber is not in conversation, but has a call on hold, the subscriber can receive a CW indication. CH and MPTY The CH and MPTY services are compatible. If both CH and MPTY services are activated, a subscriber can hold an active MPTY call, set up another call, and retrieve the MPTY call after the new call is complete.
5.9 Reference
This following specifications and manuals are referred to: 3GPP TS 22.083 V4.1.0 3GPP TS 23.083 V4.3.0 3GPP TS 23.083 V4.0.1 3GPP TS 24.008 V4.15.0 HUAWEI MSOFTX3000 Mobile SoftSwitch Center Configuration Guide HUAWEI HLR9820 Home Location Register Subscriber Management

Acronym/Abbreviation CW Full Name Call Waiting
Issue 02 (2007-06-10)
5-19
Acronym/Abbreviation CH
Full Name Call Hold
5-20
Issue 02 (2007-06-10)
Contents
Contents
6 Multiparty Service .....................................................................................................................6-1
6.1 Service Description .......................................................................................................................................6-2 6.1.1 Function Code......................................................................................................................................6-2 6.1.2 Definition .............................................................................................................................................6-2 6.1.3 Benefits ................................................................................................................................................6-2 6.2 Availability ....................................................................................................................................................6-3 6.2.1 Requirements for NEs..........................................................................................................................6-3 6.2.2 Requirements for License ....................................................................................................................6-3 6.2.3 Applicable Versions..............................................................................................................................6-3 6.3 Working Principle..........................................................................................................................................6-3 6.3.1 Functions Realized by Network Elements ...........................................................................................6-3 6.3.2 Service Data Management ...................................................................................................................6-4 6.3.3 MPTY Invocation ................................................................................................................................6-4 6.3.4 MPTY Call Management .....................................................................................................................6-4 6.4 Service Flow..................................................................................................................................................6-5 6.4.1 Setting up the MPTY Call....................................................................................................................6-5 6.4.2 Setting Up a Personal Communication with Remote Subscriber .........................................................6-6 6.4.3 Adding a Remote Subscriber................................................................................................................6-7 6.4.4 Disconnecting a Remote Subscriber ....................................................................................................6-8 6.5 Data Configuration........................................................................................................................................6-9 6.5.1 Data Configuration at MSOFTX3000 Side..........................................................................................6-9 6.5.2 Data Configuration at UMG8900 Side ..............................................................................................6-10 6.6 Service Management ................................................................................................................................... 6-11 6.6.1 Carrier Operation ............................................................................................................................... 6-11 6.6.2 Mobile Subscriber Operation ............................................................................................................. 6-11 6.7 Charging and CDR ......................................................................................................................................6-12 6.8 Service Interaction ......................................................................................................................................6-13 6.9 Reference ....................................................................................................................................................6-14 6.9.1 Protocols and Specifications ..............................................................................................................6-14 6.9.2 Acronyms and Abbreviations .............................................................................................................6-14
Issue 02 (2007-06-10)
Figures
Figures
Figure 6-1 Setting up the MPTY call .................................................................................................................6-6 Figure 6-2 Create a personal communication.....................................................................................................6-7 Figure 6-3 Add a remote subscriber ...................................................................................................................6-7 Figure 6-4 Disconnect the remote subscriber by main controller.......................................................................6-8 Figure 6-5 Disconnect the remote subscriber by main controller.......................................................................6-9
ii
Issue 02 (2007-06-10)
Tables
Tables
Table 6-1 Network elements involved in MPTY features...................................................................................6-3 Table 6-2 Applicable versions of the MPTY ......................................................................................................6-3 Table 6-3 Operation method for MPTY service ............................................................................................... 6-11 Table 6-4 MPTY service operation (For mobile subscriber) ............................................................................ 6-11 Table 6-5 Interactions between the MPTY and the other services....................................................................6-13
Issue 02 (2007-06-10)
iii
6 Multiparty Service
6
About This Chapter
Section 6.1 Service Description Describes 6.2 Availability
Multiparty Service
The following table lists the contents of this chapter.
Issue 02 (2007-06-10)
6-1

6.1.1 Function Code
Function Name Multiparty SS (MPTY) BOM WMFD-020500
6.1.2 Definition
The served mobile subscriber is the mobile subscriber who can invoke the MPTY. The served mobile subscriber, namely, the main controller, controls the MPTY when the MPTY is active. The remote party is the party except the served mobile subscriber in the MPTY calls.
The MPTY provides multiple call connections for one subscriber. That is to say, three or more than three subscribers can take part in a session at the same time. The maximum number of subscribers that the MSOFTX3000 can support through the MPTY is six. When a served mobile subscriber has an active call and an on-hold call, and when both calls are answered, the served mobile subscriber can invoke the MPTY to combine the two calls to an MPTY call. In this case, the served mobile subscriber can communicate with the remote subscriber. As for the MPTY calls, the served mobile subscriber can realize the following functions: Hold the MPTY call and resume the call in subsequent sessions. Initiate a new call and hold the MPTY call. When there is an MPTY call and a single call, alternate the two types of calls or add the single call to the MPTY call. Set up personal communications with the remote subscribers, namely, session separation. Disconnect a remote subscriber. Release an MPTY call.
6.1.3 Benefits
Beneficiary Carrier Mobile Subscriber Description The MPTY service can produce service increments. The user can hold a call conference as a main controller at any time. Multiple subscribers can discuss together, which make the communications more convenient.
6-2
Issue 02 (2007-06-10)
6.2 Availability
The MPTY features are realized by co-operations of the UE/MS, MS C Server, MGW, VLR and HLR, as listed in Table 6-1. Table 6-1 Network elements involved in MPTY features UE/MS NodeB/ BTS RNC/B SC MS C Server MGW SGSN VLR HLR
indicates the network elements involved.

The MPTY feature is an optional feature of HUAWEI wireless core network. The feature service can be obtained only after the MSOFTX3000 license is obtained.

The applicable versions of MPTY features for HUAWEI CN are as listed in Table 6-2. Table 6-2 Applicable versions of the MPTY Product MS C Server MGW MSOFTX3000 UMG8900 Applicable Version V100R002 and subsequent versions V200R002 and subsequent versions

6.3.1 Functions Realized by Network Elements
The functions of the NEs are as follows: The MS C server and the MGW cooperate with each other to process the MPTY service. The HLR stores and manages the subscriber data and service data. The HLR updates the subscription information stored in the VLR by inserting subscriber data.
Issue 02 (2007-06-10)
6-3

The HLR completes the service data management and modifies the stored subscription information of subscribers. The HLR updates the subscription information stored in the VLR by inserting subscriber data.
6.3.3 MPTY Invocation

When an on hold call (A-B) and an active call (A-C) are answered, subscriber A invokes the MPTY. To invoke the MPTY, perform the following steps: 1. 2. 3. 4. 5. 6. The MS A sends the FACILITY message to MS C, to instruct the subscriber A to invoke the MPTY. After the MS C receives the message, it queries the subscription information of A. If A subscribes to the MPTY, the MS C processes the MPTY service. The MS C applies the conference call resources that are used to connect subscriber A, B and C. The MS C responses to the MS A with a message. The MS C sends a message to subscriber B, indicating the call is resumed. The MS C sends messages to B and C, instructing them to set up the MPTY.
6.3.4 MPTY Call Management

Setting up Personal Communications with Remote Subscriber
When subscriber A has an active MPTY call (A-B-C), set up a personal communication to B. To set up personal communications with remote subscribers, perform the following steps: 1. 2. 3. 4. 5. The MS A sends the FACILITY message to the MS C, to instructing the subscriber A to set up a personal communication with B. After the MS C receives the message, it holds the MPTY call and activates the call A-B. The MS C response to MS A with a message. The MS C sends messages to other remote subscriber C subscribing the MPTY, instructing the subscriber to hold the call. A talks with B.
Adding a Remote Subscriber

When subscriber A has an active single call (A-D) and an on hold MPTY call (A-B-C), invoke the MPTY. To add a remote subscriber, perform the following steps; 1. 2. The MS A sends the FACILITY message to the MS C, to instruct the subscriber A to invoke the MPTY. After the MS C receives the message, it applies the call conference resources if the single call meets the requirements of joining the MPTY call. And then, the MS C connects A, B, C and D by using the call conference resources. The MS C responses to MS A with a message.
3.
6-4
Issue 02 (2007-06-10)
4. 5.
The MS C sends messages to subscriber B and C, to instruct them that the call is resumed and they can take part in the MPTY service. The MS C sends a message to D, instructing D to take part in the MPTY service.
If the single call (A-D) is an active call, the MPTY call (A-B-C) is an on hold call, then the MS C sends message to B and C to indicate the call is resumed and instruct B and C to join the MPTY service, and then sends message to D to instruct D to join the MPTY service.
Disconnecting a Remote Subscriber

Based on different active disconnecting parties, disconnecting a remote subscriber falls into the following two occasions: The served mobile subscriber disconnects a remote subscriber call. The remote subscriber disconnects a served mobile subscriber call. To disconnect a remote subscriber by a served subscriber, perform the following steps: 1. 2. 3. 4. The served mobile subscriber A sends disconnecting message to the MS C, to instruct MS C to disconnect the call A-D. After the MS C receives the message, it disconnects the connections related to remote subscribers and releases the idle call conference resources. The MS C sends message to A to release the call A-D between the MS C and the served mobile subscriber. The MS C sends message to the disconnected remote subscriber to release the call A-D between subscriber D and the MS C.
To disconnect the call between the remote subscriber and the served mobile subscriber, perform the following steps: 1. 2. 3. 4. The remote subscriber D sends disconnecting message to the MS C, to instruct the MS C to disconnect the call A-D. After the MS C receives the message, it disconnects the connections related to subscriber D and releases the idle call conference resources. The MS C sends message to the served mobile subscriber A to release the call A-D between the MS C and subscriber A. The MS C sends message to D to release the call A-D between subscriber D and the MS C.
6.4 Service Flow

6.4.1 Setting up the MPTY Call
The carrier provides the MPTY for subscriber A. The call A-B is on hold and the call A-C is active. The subscriber A, B and C are the MSs under the same MS C server. The procedure of setting up the MPTY call is shown as Figure 6-1.
Issue 02 (2007-06-10)
6-5
Figure 6-1 Setting up the MPTY call

MS A MS C Server MS B MS C
CALL A-B on HOLD CALL A-C ACTIVE A wants to build a mutiparty call FACILITY FACILITY FACILITY FACILITY FACILITY MPTY CALL ACTIVE
1. 2. 3.
If A wants to set up a multi-party call, the MS A sends a FACILITY message containing the BuildMPTY invoke component to the MS C server. The MS C server sends the FACILITY message to the MS A, indicating that the request of setting up MPTY is accepted. The MS C server sends the FACILITY message containing the NotifySS invoke component to the MS-B. The CallOnHold-indicator in the invoke component is callRetrieved, informing the MS-B that the call is resumed. The MS C server sends the FACILITY message containing the NotifySS invoke component to the MS-B. The invoke component contains the MPTYindicator. The MS C server sends the FACILITY message containing the NotifySS invoke component to the MS C. The invoke component contains the MPTYindicator.
4. 5.
6.4.2 Setting Up a Personal Communication with Remote Subscriber

The carrier provides the MPTY for subscriber A. The call A-B-C is the MPTY call. The subscriber A, B and C are the MSs under the same MS C server. The procedure of setting up the personal communication between A and B is shown as Figure 6-2.
6-6
Issue 02 (2007-06-10)
Figure 6-2 Create a personal communication

MS A MS C Server MPTY CALL A-B-C ACTIVE A wants to create private communication FACILITY FACILITY FACILITY MPTY CALL A-B-C on HOLD A-B CALL ACTIVE MS B MS C
1. 2. 3. 4.
If A wants to set up a new call, the MS A sends a FACILITY message containing the SplitMPTY invoke component to the MS C server. The MS C server sends the FACILITY message to the MS A, indicating that the request of SplitMPTY is accepted. The MS C server activates the A-B call. The MS C server sends the FACILITY message containing the NotifySS invoke component to the MS C and MS B. The CallOnHold-indicator in the invoke component is callOnHold, informing the MS C that the call is on hold.
6.4.3 Adding a Remote Subscriber

The carrier provides the MPTY for subscriber A. The A-B-C is the MPTY call on hold and the A-D is the active single call. The subscriber A, B, C and D are the MSs under the same MS C server. The procedure of adding subscriber D to the MPTY call is as shown Figure 6-3. Figure 6-3 Add a remote subscriber
MS A MS C Server MS B( or C ) MS D
MPTY CALL A-B-C on HOLD A-D CALL ACTIVE A wants to add A-D call to MPTY call FACILITY FACILITY FACILITY FACILITY FACILITY MPTY CALL A-B-C-D ACTIVE
Issue 02 (2007-06-10)
6-7
1. 2. 3.
When subscriber A wants to add a remote subscriber, the MS A sends a FACILITY message containing the BuildMPTY invoke component, to the MS C server. The MS C server sends the FACILITY message to the MS A, indicating the request of BuildMPTY is accepted. The MS C server sends the FACILITY message containing the NotifySS invoke component to the MS-B and MS C separately. The CallOnHold-indicator in the invoke component is callRetrieved, informing the MS-B and MS C that the call is resumed. The MS C server sends the FACILITY message containing the NotifySS invoke component to the MS-B and MS C separately. The invoke component contains the MPTYindicator. The MS C server sends the FACILITY message containing the NotifySS invoke component to the MS-D. The invoke component contains the MPTYindicator.
4.
5.
6.4.4 Disconnecting a Remote Subscriber

Disconnecting a Remote Subscriber Call by the Served Mobile Subscriber
The carrier provides the MPTY service for the subscriber A. The A-B-C-D is the active MPTY call. The procedure for subscriber A to remove the subscriber D from the MPTY calls, is as shown Figure 6-4. Figure 6-4 Disconnect the remote subscriber by main controller
MS A MS C Server A MPTY CALL A-B-C-D ACTIVE A wants to disconnect A-D call DISCONNECT RELEASE RLC RELEASE COMPLETE MPTY CALL A-B-C ACTIVE REL PSTN D
REL: Release
RLC: Release Complete
1.
When subscriber A wants to disconnect the A-D call, the MS A sends a DISCONNECT message to the MS C server. The Transaction identifier in the message is instructed to remove the A-D call. The MS C server A sends a RELEASE message to the MS A to disconnect the A-D call at the wireless side. The MS C server A sends a REL message to the PSTN C to disconnect the A-D call between the PSTN C and the PSTN D.
2. 3.
6-8
Issue 02 (2007-06-10)
4. 5.
The MS C A sends a RELEASE COMPLETE message to the MS C server A to disconnect the A-D call at the wireless side. The PSTN D sends a RLC message to the MS C server A to disconnect the A-D call between the PSTN D and the MS C server A.
Removing Subscriber Disconnect the Call

The carrier provides the MPTY service for the subscriber A. The A-B-C-D is the active MPTY call. The procedures for subscriber D to disconnect the call are as shown Figure 6-5. Figure 6-5 Disconnect the remote subscriber by main controller
MS A MS C Server A MPTY CALL A-B-C-D ACTIVE D wants to disconnect A-D call REL DISCONNECT RELEASE RELEASE COMPLETE MPTY CALL A-B-C ACTIVE RLC PSTN D
REL: Release
RLC: Release Complete
1. 2. 3. 4. 5.
If subscriber D wants to disconnect the call, the PSTN D sends the REL message to the MS C server A, to instruct it to disconnect the A-D call. The MS C server A sends a RLC message to the PSTN D to disconnect the A-D call between the MS C server A and the PSTN D. The MS C server A sends a DISCONNECT message to the MS A. The Transaction identifier in the message instructs to remove the A-D call. The MS A sends the RELEASE message to the MS C server A. The MS C server A sends a RELEASE COMPLETE message to the MS A to disconnect the A-D call at the wireless side.

6.5.1 Data Configuration at MSOFTX3000 Side
For detailed operations of data configuration, see HUAWEI MSOFTX3000 Mobile SoftSwitch Center Configuration Guide.
Issue 02 (2007-06-10)
6-9
Enabling Service
The service availability does not require special configuration data.
Controlling MPTY Service Bill

You can control the bill generation of MPTY service by using the MOD GBILLCTRL command.
Setting Tone Playing of Conference

If it is required, set related data of playing conference tone by using the SET LOCALSRV command.
Related Software Parameter

Name P168 (CM software parameter 1) Bit 10 Definition When the main control party retrieves the MPTY, it controls whether to play tone suggesting the conference is entered. . When the tone is required to be played by the call release initiated at the network side, it controls whether to play tones to prompt the remote subscriber to enter the conference. When the times of control handover or the times of supplementary services operation is over the maximum times set by the system, it controls whether the bills generated is outgoing intermediate bill or the event bill. Value =0:play tones =1:Not play tones Default Value 1
P174 (CM software parameter 7) Bit 8
=0: Support =1: Not support
P129 (CHG parameter 1) Bit 7
=0: Generate intermediate bill =1: Generate event bill
6.5.2 Data Configuration at UMG8900 Side

You can set the conference resources for the TCU board configured with the MVDB subboard by using the SET MPTYRES command.
6-10
Issue 02 (2007-06-10)

There are two operating methods for the MPTY service, Table 6-3 Operation method for MPTY service Method Carrier operation Mobile subscriber operation Interface HLR Client MS Service Provide and cancel the MPTY service. Release o- hold calls, release active calls and resume on-hold calls, release remote subscriber, set up personal communications with remote subscribers, alternate calls, invoke the MPTY and add remote subscriber, initiate a new call and hold the MPTY call, and release all calls. as listed in Table 6-3.
As for the MPTY service, the service is provided when being activated; and the service is cancelled when being deactivated.
6.6.1 Carrier Operation

As for the MPTY service, the service is provided when the service is activated; the service is cancelled when the service is deactivated. For detailed operations, see compatible operation manuals of HLR products used in the network at present.
6.6.2 Mobile Subscriber Operation

Precondition
The carrier provides the MPTY service to the subscribers.
Steps
For detailed operation steps, see Table 6-4. Table 6-4 MPTY service operation (For mobile subscriber) Type Release on-hold calls Release active calls and resume on hold calls Release the remote subscribers resources Step The subscriber dials 0 on the MS and press the "Send" button. The subscriber dials 1 on the MS and press the "Send" button. The subscriber dials 1X on the MS and press the "Send" button. X is the sequence number of remote subscriber. It starts from 1 and increases based on the sequence of setting up or answering the calls for the served mobile subscriber.
Issue 02 (2007-06-10)
6-11
Type Set up personal communications with remote subscriber
Step The subscriber dials 2X on the MS and press the "Send" button. X is the sequence number of remote subscriber. It starts from 1 and increases based on the sequence of setting up or answering the calls for the served mobile subscriber. The subscriber dials 2 on the MS and press the "Send" button. The subscriber dials 3 on the MS and press the "Send" button. The subscriber dials the number of new subscriber on the MS and press "Send" button. Press "Release" button on the MS.
Alternate calls Invoke the MPTY and add the remote subscriber Initiate a new call and keep the MPTY call Release all calls
Some mobile phone can realize the operations list above. For detailed operations, see the mobile phone instructions.

There are two modes to generate the bill of MPTY service for the MSOTX3000, independent charging and segmented charging. The independent charging indicates that the MSOTX3000 generates the following two kinds of bills based on the BuildMPTY and SplitMPTY operations: Event bill containing the MPTY mark and time stamp Original bill of MOC/MTC for complete A-B and A-C calls The iGWB inserts the contents of event bill to the corresponding supplementary service field for original bill of the MOC/MTC. Then, the final MOC/MTC is generated. The segmented bill indicates that the MSOTX3000 generates a group of intermediate bill of the MOC/MTC based on the time interval between the BuildMPTY and the SplitMPTY operations. The charging center combines the bills or processes the other charging. The mark and time stamp of MPTY are added to the latter segment of bill. The MSOTX3000 controls the mode created by bill, and the frequency created by the event bill, or intermediate bill through the CHG parameter 1 (P129) Bit 7 and integrated control table of bill. In usual cases, the independent charging is adopted. The following is an independent charging case for MPTY call. In the following occasions, The subscribers A under the MS C server calls the subscriber B in other offices. During the communications of A-B, subscriber A holds a call and calls the subscriber C in other offices.
6-12
Issue 02 (2007-06-10)
Subscriber C answers the call and sets up the MPTY call. The local office is the MOC bills created by the A-B call. There are two supplementary service operation records in the supplementary service field of the bill. One indicator of supplementary service is CH and the time stamp is the time for the subscriber A sending the HOLD message; the other indicator of supplementary service is the MPTY and the time stamp is the time that the subscriber A sends the FACILITY message containing the BuildMPTY information. The MOC bill is created by the local A-C call. There is one supplementary service operation record in the supplementary service field of the bill. The record indicator of supplementary service operations is the MPTY. The time stamp is the time that subscriber A sends the FACILITY message containing the BuildMPTY.

For the interactions between the MPTY and the other services is listed in Table 6-5. Table 6-5 Interactions between the MPTY and the other services Service MPTY and CLIP Interaction No matter when a served mobile subscriber adds a new remote subscriber to an MPTY call, the remote subscriber subscribing the CLIP and involving the MPTY service cannot receive the number of remote subscriber newly added. The MPTY and the forwarding services do not affect each other. The calling party: When the calling party tries to set up the MPTY call with the called party subscribing the call forwarding service, the forwarding subscriber hears rings and is added to the conference if the forwarding meets the trigger conditions. Forwarding subscriber: When the forwarding subscriber sets up the MPTY call, the forwarding call existed is added to the conference as a connection of the MPTY call. MPTY and CW The MPTY and CW do not affect each other. If a subscriber activates a MPTY call, the subscriber receives a call on hold notice when other subscribers call the subscriber. When the subscriber sets the MPTY call to on hold, the subscriber can answer the call on hold. MPTY and CH Subscribing CH service is the prerequisite of subscribing the MPTY service. If a subscriber activates a MPTY call, the subscriber (the served subscriber or the remote subscriber) is allowed to hold the MPTY call and resume the call. MPTY and BO If the BO service is activated after invoking the MPTY call, the outgoing call of the MPTY is not affected by the BO service. However, the outgoing call made after activation of the BO service is to be barred if the call meets the barring requirements.
MPTY and Forwarding services
Issue 02 (2007-06-10)
6-13
Service MPTY and BI
Interaction If the BI service is activated after invoking the MPTY call, the incoming call of the MPTY is not affected by the BI service. However, the incoming call made after activation of BI service is to be barred if the call meets the barring requirements.
6.9 Reference
The references of the feature are list as follows: 3GPP TS 22.084 V4.1.0 3GPP TS 23.084 V4.1.0 3GPP TS 24.084 V4..0.0 HUAWEI MSOFTX3000 Mobile SoftSwitch Center Configuration Guide

Acronym/Abbreviation 3GPP CH CLIP CLIR CM CN CW MOC MPTY MTC Full Name 3rd Generation Partnership Project Call Holding Calling Line Identification Presentation Calling Line Identification Restriction Call Management Core Network Call Waiting Mobile Originated Call MultiParty Service Mobile Terminated Call
6-14
Issue 02 (2007-06-10)
Contents
Contents
7 Call Barring Service ...................................................................................................................7-1
7.1 Service Description .......................................................................................................................................7-2 7.1.1 Function Code......................................................................................................................................7-2 7.1.2 Definition .............................................................................................................................................7-2 7.1.3 Types ....................................................................................................................................................7-2 7.1.4 Benefits ................................................................................................................................................7-3 7.2 Availability ....................................................................................................................................................7-3 7.2.1 Requirements for NEs..........................................................................................................................7-3 7.2.2 Requirements for License ....................................................................................................................7-3 7.2.3 Applicable Versions..............................................................................................................................7-4 7.3 Working Principle..........................................................................................................................................7-4 7.3.1 Service Data Management ...................................................................................................................7-4 7.3.2 BO........................................................................................................................................................7-4 7.3.3 BI .........................................................................................................................................................7-8 7.4 Service Flow................................................................................................................................................7-10 7.4.1 BO......................................................................................................................................................7-10 7.4.2 BI ....................................................................................................................................................... 7-11 7.5 Data Configuration......................................................................................................................................7-12 7.5.1 Configuring Data at the MSOFTX3000 Side.....................................................................................7-12 7.5.2 Configuring Data at the HLR Side.....................................................................................................7-13 7.6 Service Management ...................................................................................................................................7-13 7.6.1 Operations by Carriers .......................................................................................................................7-13 7.6.2 Operations by Mobile Subscribers .....................................................................................................7-13 7.7 Charging and CDR ......................................................................................................................................7-15 7.8 Service Interaction ......................................................................................................................................7-15 7.8.1 BAOC ................................................................................................................................................7-15 7.8.2 BOIC..................................................................................................................................................7-15 7.8.3 BOIC-exHC .......................................................................................................................................7-17 7.8.4 BAIC..................................................................................................................................................7-18 7.8.5 BIC-ROAM .......................................................................................................................................7-19 7.9 Reference ....................................................................................................................................................7-21 7.9.1 Protocols and Specifications ..............................................................................................................7-21
Issue 02 (2007-06-10)
Contents
HUAWEI MSOFTX3000 Feature Description 7.9.2 Acronyms and Abbreviations .............................................................................................................7-21
ii
Issue 02 (2007-06-10)
Figures
Figures
Figure 7-1 Check flow of the VLR for the BAOC service .................................................................................7-5 Figure 7-2 Check flow of the VLR for the BOIC service...................................................................................7-6 Figure 7-3 Check flow of the VLR for the BOIC-exHC service ........................................................................7-7 Figure 7-4 Check flow of the HLR for the BAIC service ..................................................................................7-8 Figure 7-5 Check flow of the HLR for the BIC-ROAM service ........................................................................7-9 Figure 7-6 BO service flow ..............................................................................................................................7-10 Figure 7-7 BI service flow................................................................................................................................ 7-11
Issue 02 (2007-06-10)
iii
Tables
Tables
Table 7-1 Name and code of the function...........................................................................................................7-2 Table 7-2 NEs required by the call barring services ...........................................................................................7-3 Table 7-3 Applicable versions of Huawei wireless core network products ........................................................7-4 Table 7-4 Operation modes of the call barring supplementary services ...........................................................7-13 Table 7-5 Operations performed by mobile subscribers ...................................................................................7-13 Table 7-6 Interactions between the BAOC service and other services .............................................................7-15 Table 7-7 Interactions between the BOIC service and other services...............................................................7-16 Table 7-8 Interactions between the BOIC-exHC service and other services ....................................................7-17 Table 7-9 Interactions between the BAIC service and other services...............................................................7-18 Table 7-10 Interactions between the BIC-ROAM service and other services ..................................................7-19
iv
Issue 02 (2007-06-10)
7 Call Barring Service
7
About This Chapter
Section 7.1 Service Description 7.2 Availability 7.3 Working Principle 7.4 Service Flow 7.5 Data Configuration 7.6 Service Management 7.7 Charging and CDR 7.8 Service Interaction 7.9 Reference Describes
Call Barring Service
Issue 02 (2007-06-10)
7-1

7.1.1 Function Code
Table 7-1 lists the name and code of the function. Table 7-1 Name and code of the function Name Call barring services Code WMFD-020400
7.1.2 Definition
Call barring supplementary services allow mobile subscribers to perform barring for incoming or outgoing calls with special properties.
7.1.3 Types
Call barring services are classified into two types: barring of outgoing calls (BO) and barring of incoming calls (BI). The BO service includes: Barring of All Outgoing Calls (BAOC is for short.) Barring of All Outgoing International Calls (BOIC is for short.) Barring of Outgoing International Calls except those directed to the Home PLMN Country (BOIC-exHC is for short.) The BI service includes: Barring of All Incoming Calls (BAIC is for short.) Barring of Incoming Calls When Roaming Outside Home PLMN Country (BIC-ROAM is for short.)
BAOC
After the service is activated, a mobile subscriber cannot initiate calls.
BOIC
After the service is activated, a mobile subscriber cannot call any subscriber (including mobile subscriber or fixed network subscriber) outside the country where the caller is.
BOIC-exHC
After the service is activated, a mobile subscriber cannot call any subscribers outside the country (homing to the PLMN) where the caller roaming. After the subscriber is roaming outside the country homing to the PLMN, the subscriber can call only subscribers (mobile subscribers or fixed network subscribers) in homing countries.
7-2
Issue 02 (2007-06-10)
BAIC
After the service is activated, a mobile subscriber cannot receive calls.
BIC-ROAM
After the service is activated, a mobile subscriber cannot receive calls when the subscriber is roaming outside the country homing to the PLMN. Subscribers can select one or several types of call barring service. If the service controller is set to subscribers, subscribers can activate or deactivate call barring services through their handsets. In advance, password must be provided.
7.1.4 Benefits
Beneficiary Carriers Mobile subscribers Description The call barring supplementary services add values of services. After the system provides the call barring service, subscribes can bar some type of incoming/outgoing calls. Subscribes can perform activation/deactivation operation, thus to control incoming/outgoing calls flexibly.
7.2 Availability
Table 7-2 lists the network elements (NEs) required by the call barring services. Table 7-2 NEs required by the call barring services UE/MS NodeB/BTS RNC/BSC MSC server MGW SGSN VLR HLR

The call completion supplementary services are basic services of Huawei wireless core network. No license is needed.
Issue 02 (2007-06-10)
7-3

Table 7-3 lists the applicable versions of Huawei wireless core network products that the call barring services support. Table 7-3 Applicable versions of Huawei wireless core network products Product MSC server MGW MSOFTX3000 UMG8900 Applicable Version V100R002 and later versions V200R002 and later versions

Management on Service Data
The HLR performs the following functions: Completes the management operations of carriers on service data. Modifies the subscription information that it stores. Updates the subscription information in the VLR by inserting subscriber data.
Registration
If the service controller of the call barring services is subscribers, subscribers can modify the password used for service control through registration. The MSC transparently sends the registration operation message to the HLR, and then updates the subscription information in the VLR by inserting subscriber data.
Activation and Deactivation

If the service controller of the call barring services is subscribers, when a subscriber initiates activation or deactivation operation, the MSC transparently sends the operation message to the HLR. The HLR modifies the subscription information that it stores based on the message, and then updates the subscription information in the VLR by inserting subscriber data
If the activated call barring service conflicts with other activated services, the activation may fail. For details, see section 7.8 "Service Interaction."
7.3.2 BO
The following section describes the working principle of the BO service. A subscriber initiates a call. The MSC initiates the operation of fetching subscriber information for outgoing call to the VLR.
7-4
Issue 02 (2007-06-10)
The VLR checks the service based on BO information of the subscriber and call property of the outgoing call. Then the VLR sets the call barring indication based on the check result and sends the indication to the MSC. For service check procedures by the VLR for BAOC, BOIC and BOIC-exHC services, see Figure 7-1, Figure 7-2 and Figure 7-3. The MSC determines whether to perform call barring based on the call barring indication. If the call barring indication is Yes, the MSC releases the call; if the call barring indication is No, the MSC processes the call according to normal flow. Figure 7-1 Check flow of the VLR for the BAOC service
idle
initiate handling of BAOC
emergency call
Yes
activated for basic service
No
set barring indicator ='yes'
set barring indicator ='no'
continue call handling
idle
Issue 02 (2007-06-10)
7-5
Figure 7-2 Check flow of the VLR for the BOIC service
idle
initiate handling of BOIC
Yes emergency call
No international call
No
idle
7-6
Issue 02 (2007-06-10)
Figure 7-3 Check flow of the VLR for the BOIC-exHC service
idle
initiate handling of BOICexHC
Yes emergency call
No international call
destination in HPLMN country
Yes
No
idle
If the MS activates multiple BO services, every service check flow is executed. The MSOFTX3000 can suppress BO service check for special prefix based on the service check configuration in configuration data. Thus, subscribers can still call special numbers when the BO service is activated.
Issue 02 (2007-06-10)
7-7
7.3.3 BI
The following section describes the working principle of the BI service. A subscriber initiates a call. The (G)MSC initiates the operation of fetching route information to the HLR. The HLR checks the service based on BI information of callee and call property of the incoming call. Then the HLR sets the call barring indication based on the check result. For service check procedures by the HLR for BAIC and BIC-ROAM services, see Figure 7-4 and Figure 7-5. The HLR determines whether to perform call barring based on the call barring indication. If the call barring indication is Yes, the HLR indicates to reject the call in the response to the operation of fetching route information; if the call barring indication is No, the HLR processes the call according to normal flow. Figure 7-4 Check flow of the HLR for the BAIC service
idle
initiate handling of BAIC
activated for basic service Yes set barring indicator ='yes'
No
idle
7-8
Issue 02 (2007-06-10)
Figure 7-5 Check flow of the HLR for the BIC-ROAM service
idle
initiate handling of BIC-ROAM
Yes emergency call
international call
No
No
idle
If the MS activates multiple BO services, every service check flow is executed.
Issue 02 (2007-06-10)
7-9
7.4 Service Flow

7.4.1 BO
Figure 7-6 shows the BO service flow. Figure 7-6 BO service flow
MS MSC server MSC server/ PSTN
SETUP RELEASE COMPLETE OR1: Yes Facility (Invoke = NotifySS (SSOR1: No Code, SS-Status)) IAM
OR1: call barred
IAM: Initial Address Message
1. 2.
The MS sends the SETUP message to the MSC server. The VLR of the MSC server checks the service based on BO service information and call property. Then the VLR sets call barring indication based on the check result. For service check procedures, see Figure 7-1, Figure 7-2 and Figure 7-3. The MSC determines whether to perform call barring based on the call barring indication. If the call barring indication is Yes, the MSC sends the RELEASE COMPLETE message or other release message to the MS to release the call. The parameter Facility contains invocation component of NotifySS operation. The SS-Code of the component refers to service code of the BO service. The SS-Status indicates that the BO service is in activated or deactivated status. If the call barring indication is No, the MSC processes the call according to normal flow.
3. 4.
5.
7-10
Issue 02 (2007-06-10)
7.4.2 BI
Figure 7-7 shows the voice BI service flow. Figure 7-7 BI service flow
MS/PSTN (G)MSC server HLRb MSC server b
SETUP or IAM SRI OR1: Yes SRI ack(user error=CallBarred) clearing message OR1: No PRN PRN ack SRI ack(MSRN) IAM
OR1: call barred SRI: Send Routing Information ack: Acknowledge
PRN: Provide Roaming Number IAM: Initial Address Message
1.
If a caller is an MS, the MS sends the SETUP message to the MSC server. If the caller is a fixed network subscriber, the PSTN office sends originated call message (such as the IAM message) to the GMSC server through trunk signaling. The (G)MSC server initiates the SRI operation to the HLR b that callee homes. The HLR b checks the service based on BI service information and call property. Then the HLR b sets call barring indication based on the check result. For service check procedure, see Figure 7-4 and Figure 7-5. If the call barring indication is Yes, the HLR b sends the SRI ack message to the (G)MSC server. The parameter User error in the message is Callbarred. If the caller is an MS, after receiving the SRI ack message, the MSC server b sends the RELEASE COMPLETE or other release message to the MS. Then the MSC server b releases the call according to normal flow that is omitted in the figure. If the caller is a fixed network subscriber, the GMSC server sends release message (such as the REL message) to caller office and releases the call according to normal flow that is omitted in the figure. If the call barring indication is No, the HLR processes the call according to normal flow.
2. 3.
4. 5.
6.
7.
Issue 02 (2007-06-10)
7-11

For the details of data configuration, see the HUAWEI MSOFTX3000 Mobile SoftSwitch Center Configuration Guide.

Checking the Service

The MSOFTX3000 can suppress the BO service for special prefix and special call source through service check configuration. The procedure is as follows: Step 1 Run ADD SRVCHK to define a service check configuration. Of it, the value of BO service item of the parameter SCC is 0; the value of BO service item of the parameter SCM is 1. Step 2 Run ADD CNACLD or MOD CNACLD to set a call prefix. Of it, the value of the parameter ISERVICECHECKNAME is the one of SCN that is set in step 1. ----End The following table lists an example: Description Script BAOC, BOIC, ODB_BAOC and ODB_BOIC subscribers are allowed to dial 110. ADD SRVCHK: CSCNAME="ALL", SCN="NOCHECK", IFSC=YES, SCC=ODB_BAOC-0&BAOC-0&ODB_BOIC-0&BOIC-0, SCM=ODB_BAOC-1&BAOC-1&ODB_BOIC-1&BOIC-1; ADD CNACLD: PFX=K'110, MINL=3, MAXL=3, ISERVICECHECKNAME="NOCHECK";

Name P140 (VLR software parameter) Bit 5 Meaning It indicates enabling forced release function of the supplementary service at once. Value = 0: Not enable forced release function of the supplementary service. = 1: Enable forced release function of the supplementary service at once. That is, if the added supplementary service is BAOC, BOIC or BOIC_EXHC, the forced release flow will be initiated to subscribers in conversation. Default Value 0
7-12
Issue 02 (2007-06-10)


The call barring supplementary services have two operation modes, as listed in Table 7-4. Table 7-4 Operation modes of the call barring supplementary services Operation Mode Operation by carriers Operation Interface HLR9820 SMU Client Service Operations Provide the service. Withdraw the service. Register the service. Activate the service. Deactivate the service. Modify the service control right. Operation by mobile subscribers MS Register the service Activate the service. Deactivate the service.


Prerequisite
The controller of call barring services is subscribers.
Operations
On the MS, mobile subscribers can perform the operations listed in Table 7-5. Table 7-5 Operations performed by mobile subscribers Operation Type Modify call barring service password. Step On the MS, dial "**03*330*oldPW*newPW*newPW#", and then press the Send key. Of it, oldPW refers to old password of the call barring service and newPW refers to new password of the call barring service.
Issue 02 (2007-06-10)
7-13
Operation Type Activate the BAOC service. Deactivate the BAOC service. Activate the BOIC service. Deactivate the BOIC service. Activate the BOIC-ExHC service. Deactivate the BOIC-ExHC service. Activate the BAIC service. Deactivate the BAIC service. Activate the BIC-Roam service. Deactivate the BIC-Roam service. Deactivate all call barring services. Deactivate all BO services. Deactivate all BI services.
Step On the MS, dial "*33*PW#", and then press the Send key. Of it, PW refers to call barring service password. On the MS, dial "#33*PW#", and then press the Send key. Of it, PW refers to call barring service password. On the MS, dial "*331*PW#", and then press the Send key. Of it, PW refers to call barring service password. On the MS, dial "#331*PW#", and then press the Send key. Of it, PW refers to call barring service password. On the MS, dial "*332*PW#", and then press the Send key. Of it, PW refers to call barring service password. On the MS, dial "#332*PW#", and then press the Send key. Of it, PW refers to call barring service password. On the MS, dial "*35*PW#", and then press the Send key. Of it, PW refers to call barring service password. On the MS, dial "#35*PW#", and then press the Send key. Of it, PW refers to call barring service password. On the MS, dial "*351*PW#", and then press the Send key. Of it, PW refers to call barring service password. On the MS, dial "#351*PW#", and then press the Send key. Of it, PW refers to call barring service password. On the MS, dial "#330*PW#", and then press the Send key. Of it, PW refers to call barring service password. On the MS, dial "#333*PW#", and then press the Send key. Of it, PW refers to call barring service password. On the MS, dial "#353*PW#", and then press the Send key. Of it, PW refers to call barring service password.
Subscribers can also perform the operations through the menus of some mobile phones. For details, see the user manuals of the mobile phones. The call barring service password is 0000 by default.
7-14
Issue 02 (2007-06-10)

The call barring services cause call failure. Therefore, no CDR is generated for failed call.

7.8.1 BAOC
Table 7-6 lists the interactions between the BAOC service and other services. Table 7-6 Interactions between the BAOC service and other services Service BAOC and CFU, CFB, CFNRy and CFNRc Interaction The forwarding and BAOC services are incompatible. If a subscriber activates the forwarding service, it is prohibited to activate the BAOC service. If a subscriber activates the BAOC service, it is prohibited to register or activate the forwarding service. BAOC and CW The BAOC and CW services are compatible. When a caller activates the BAOC service, no waiting call that has been initiated is affected. BAOC and CH The BAOC and CH services are compatible. After initiating a call that is in call hold status, a caller activates the BAOC service. The held call still can be invoked. But all new outgoing calls are inhibited. BAOC and MPTY After invoking an MPTY call, a subscriber activates the BAOC service. All outgoing calls in the MPYT call are not affected. All new outgoing calls are inhibited. The BAOC service enjoys higher priority than the CUG service. During an outgoing call, a caller activates the BAOC service without affecting any CUG calls.
BAOC and CUG
7.8.2 BOIC
Table 7-7 lists the interactions between the BOIC service and other services.
Issue 02 (2007-06-10)
7-15
Table 7-7 Interactions between the BOIC service and other services Service BOIC and CFU Interaction If a subscriber activates the BOIC service, the CFU service registered and activated to an international number is rejected. If a subscriber activates the CFU service to an international number, the BOIC service cannot be activated. BOIC and CFB If a subscriber activates the BOIC service, the CFB service registered and activated to an international number is rejected. If a subscriber activates the CFB service to an international number, the BOIC service cannot be activated. If the CFB service is registered to a home country number and both CFB and BOIC services are activated, when a subscriber is roaming to another country, the CFB service is unavailable. If the BOIC service is deactivated later, or the subscriber comes back to the home country, the CFB service auto changes to available. BOIC and CFNRy If a subscriber activates the BOIC service, the CFNRy service registered and activated to an international number is rejected. If a subscriber activates the CFNRy service to an international number, the BOIC service cannot be activated. If the CFNRy service is registered to a home country number and both CFNRy and BOIC services are activated, when a subscriber is roaming to another country, the CFNRy service is unavailable. If the BOIC service is deactivated later, or the subscriber comes back to the home country, the CFNRy service auto changes to available. BOIC and CFNRc If a subscriber activates the BOIC service, the CFNRc service registered and activated to an international number is rejected. If a subscriber activates the CFNRc service to an international number, the BOIC service cannot be activated. If the CFNRc service is registered to a home country number and both CFNRc and BOIC services are activated, when a subscriber is roaming to another country, the CFNRc service is unavailable. If the BOIC service is deactivated later, or the subscriber comes back to the home country, the CFNRc service auto changes to available. BOIC and CW BOIC and MPTY BOIC and CH The BOIC and CW services are compatible. When a caller activates the BOIC service, any waiting international call that has been initiated is affected. After invoking an MPTY call, a subscriber activates the BOIC service. All outgoing calls in the MPYT call are not affected. All new outgoing international calls are inhibited. The BOIC and CH services are compatible. After initiating an international call that is in call hold status, a caller activates the BOIC service. The held call still can be invoked. But all new outgoing international calls are inhibited.
7-16
Issue 02 (2007-06-10)
Service BOIC and CUG
Interaction The BOIC service enjoys higher priority than the CUG service. During an outgoing international call, a caller activates the BOIC service without affecting any CUG calls.
7.8.3 BOIC-exHC
Table 7-8 lists the interactions between the BOIC-exHC service and other services. Table 7-8 Interactions between the BOIC-exHC service and other services Service BOIC-exHC and CFU Interaction If a subscriber activates the BOIC-exHC service, the CFU service registered and activated to numbers except the HPLMN number is rejected. If a subscriber activates the CFU service to numbers except the HPLMN number, the BOIC-exHC cannot be activated. BOIC-exHC and CFB If a subscriber activates the BOIC-exHC service, the CFB service registered and activated to numbers except the HPLMN number is rejected. If a subscriber activates the CFB service to numbers except the HPLMN number, the BOIC-exHC cannot be activated. If the CFB service is forwarded to an HPLMN number and both CFB and BOIC-exHC services are activated, when a subscriber is roaming to another PLMN, the CFB service is unavailable. If the BOIC-exHC service is deactivated later, or the subscriber comes back to the HPLMN, the CFB service auto changes to available. BOIC-exHC and CFNRy If a subscriber activates the BOIC-exHC service, the CFNRy service registered and activated to numbers except the HPLMN number is rejected. If a subscriber activates the CFNRy service to numbers except the HPLMN number, the BOIC-exHC cannot be activated. If the CFNRy service is forwarded to an HPLMN number and both CFNRy and BOIC-exHC services are activated, when a subscriber is roaming to another PLMN, the CFNRy service is unavailable. If the BOIC-exHC service is deactivated later, or the subscriber comes back to the HPLMN, the CFNRy service auto changes to available.
Issue 02 (2007-06-10)
7-17
Service BOIC-exHC and CFNRc
Interaction If a subscriber activates the BOIC-exHC service, the CFNRc service registered and activated to numbers except the HPLMN number is rejected. If a subscriber activates the CFNRc service to numbers except the HPLMN number, the BOIC-exHC cannot be activated. If the CFNRc service is forwarded to an HPLMN number and both CFNRc and BOIC-exHC services are activated, when a subscriber is roaming to another PLMN, the CFNRc service is unavailable. If the BOIC-exHC service is deactivated later, or the subscriber comes back to the HPLMN, the CFNRc service auto changes to available.
BOIC-exHC and CW BOIC-exHC and MPTY BOIC-exHC and CH
The BOIC-exHC and CW services are compatible. When a caller activates the BOIC-exHC service, any waiting international call that has been initiated to outside HPLMN is affected. After invoking an MPTY call, a subscriber activates the BOIC-exHC service. All outgoing calls in the MPYT call are not affected. All new outgoing international calls to outside HPLMN are inhibited. The BOIC-exHC and CH services are compatible. After initiating an international call that is in call hold status to outside HPLMN, a caller activates the BOIC-exHC service. The held call still can be invoked. But all new outgoing international calls to outside HPLMN are inhibited. The BOIC-exHC service enjoys higher priority than the CUG service. During an outgoing international call to outside HPLMN, a caller activates the BOIC-exHC service without affecting any CUG calls.
BOIC-exHC and CUG
7.8.4 BAIC
Table 7-9 lists the interactions between the BAIC service and other services. Table 7-9 Interactions between the BAIC service and other services Service BAIC and CFU, CFB, CFNRy and CFNRc Interaction The forwarding and BAIC services are incompatible. If a subscriber activates the forwarding service, it is prohibited to activate the BAIC service. If a subscriber activates the BAIC service, it is prohibited to activate the forwarding service. BAIC and CW The BAIC service enjoys higher priority than the CW. When the BAIC service is activated, the CW service cannot be activated. The activation of the BAIC service does not affect any waiting call.
7-18
Issue 02 (2007-06-10)
Service BAIC and MPTY
Interaction After invoking an MPTY call, a subscriber activates the BAIC service. All incoming calls in the MPYT call are not affected. All new incoming calls are inhibited. The BAIC and CH services are compatible. If an incoming call has been in call hold status, a callee activates the BAIC service. The held call still can be invoked. But all new incoming calls are inhibited.
BAIC and CH
BAIC and CUG
The BAIC service enjoys higher priority than the CUG service. During receiving incoming call, a callee activates the BAIC service without affecting any CUG calls.
7.8.5 BIC-ROAM
Table 7-10 lists the interactions between the BIC-ROAM service and other services. Table 7-10 Interactions between the BIC-ROAM service and other services Service BIC-ROAM and CFU Interaction The CFU service enjoys higher priority than the BIC-ROAM service. If a subscriber has activated the BIC-ROAM service, when the subscriber activates the CFU service, the activation can be successful. But the BIC-ROAM service changes to static status. If a subscriber has activated the CFU service, when the subscriber registers the BIC-ROAM service, the activation is unsuccessful. BIC-ROAM and CFB If a subscriber has activated the BIC-ROAM service and the BIC-ROAM service is in operational status, when the subscriber activates the CFB service, the activation is rejected. If a subscriber has activated the BIC-ROAM service but the BIC-ROAM service is in static status, the CFB service can be activated after registration. If the BIC-ROAM service changes to operational status later, the CFB auto changes to static status. If a subscriber is roaming outside HPLMN and the subscriber activates the CFB service that is in operational status, it is prohibited to activate the BIC-ROAM service. If a subscriber is roaming outside HPLMN and the subscriber activates the CFB service that is in static status, the BIC-ROAM can be activated.
Issue 02 (2007-06-10)
7-19
Service BIC-ROAM and CFNRy
Interaction If a subscriber has activated the BIC-ROAM service and the BIC-ROAM service is in operational status, when the subscriber activates the CFNRy service, the activation is rejected. If a subscriber has activated the BIC-ROAM service but the BIC-ROAM service is in static status, the CFNRy service can be activated after registration. If the BIC-ROAM service changes to operational status later, the CFNRy auto changes to static status. If a subscriber is roaming outside HPLMN and the subscriber activates the CFNRy service that is in operational status, it is prohibited to activate the BIC-ROAM service. If a subscriber is roaming outside HPLMN and the subscriber activates the CFNRy service that is in static status, the BIC-ROAM can be activated.
BIC-ROAM and CFNRc
If a subscriber has activated the BIC-ROAM service and the BIC-ROAM service is in operational status, when the subscriber activates the CFNRc service, the activation is rejected. If a subscriber has activated the BIC-ROAM service but the BIC-ROAM service is in static status, the CFNRc service can be activated after registration. If the BIC-ROAM service changes to operational status later, the CFNRc auto changes to static status. If a subscriber is roaming outside HPLMN and the subscriber activates the CFNRc service that is in operational status, it is prohibited to activate the BIC-ROAM service. If a subscriber is roaming outside HPLMN and the subscriber activates the CFNRc service that is in static status, the BIC-ROAM can be activated.
BIC-ROAM and CH
The BIC-ROAM and CH services are compatible. When a callee is roaming outside an HPLMN and the callee activates the BIC-ROAM service, if an incoming call has been in call hold status, the held call still can be invoked. But all new incoming calls are inhibited. When a subscriber is roaming outside an HPLMN, if the subscriber activates the BIC-ROAM service after invoking an MPTY call, all incoming calls in the MPYT call are not affected. All new incoming calls are inhibited. The BIC-ROAM service enjoys higher priority than the CUG service. If a callee is roaming outside an HPLMN, during receiving incoming call, the callee activates the BIC-ROAM service without affecting any CUG calls.
BIC-ROAM and MPTY
BIC-ROAM and CUG
7-20
Issue 02 (2007-06-10)
7.9 Reference
This following specifications and manuals are referred to: 3GPP TS 22.088 V4.1.0 3GPP TS 23.088 V4.1.0 3GPP TS 24.088 V4.0.2 3GPP TS 24.008 V4.15.0 3GPP TS 29.002 V4.15.0 HUAWEI MSOFTX3000 Mobile SoftSwitch Center Configuration Guide HUAWEI HLR9820 Home Location Register Operation Manual Subscriber Management

Acronym/Abbreviation BO BI BAOC BOIC BOIC-exHC BAIC BIC-ROAM Full Name Barring of outgoing calls Barring of incoming calls Barring of All Outgoing Calls Barring of All Outgoing International Calls Barring of Outgoing International Calls except those directed to the Home PLMN Country Barring of All Incoming Calls Barring of Incoming Calls When Roaming Outside Home PLMN Country
Issue 02 (2007-06-10)
7-21
Contents
Contents
8 Explicit Call Transfer Service ..................................................................................................8-1
8.1 Service Description .......................................................................................................................................8-2 8.1.1 Function Code......................................................................................................................................8-2 8.1.2 Definition .............................................................................................................................................8-2 8.1.3 Benefits ................................................................................................................................................8-2 8.2 Availability ....................................................................................................................................................8-3 8.2.1 Requirements for NEs..........................................................................................................................8-3 8.2.2 Requirements for License ....................................................................................................................8-3 8.2.3 Applicable Versions..............................................................................................................................8-3 8.3 Working Principle..........................................................................................................................................8-3 8.3.1 Functions of Each NE ..........................................................................................................................8-3 8.3.2 Service Data Management ...................................................................................................................8-3 8.3.3 Invoking the ECT.................................................................................................................................8-4 8.4 Service Flow..................................................................................................................................................8-4 8.4.1 A-B Call Is on Hold and A-C Call Is in the Active State .....................................................................8-4 8.4.2 A-B Call Is in the Active State and A-C Call Is in the Alerting State...................................................8-5 8.5 Data Configuration........................................................................................................................................8-7 8.5.1 Data Configuration on the MSOFTX3000...........................................................................................8-7 8.5.2 Data Configuration on the UMG8900..................................................................................................8-7 8.6 Service Management .....................................................................................................................................8-8 8.6.1 Operation Mode ...................................................................................................................................8-8 8.6.2 Operations by the Carriers ...................................................................................................................8-8 8.6.3 Operations by the Mobile Subscribers .................................................................................................8-8 8.7 Charging and CDR ........................................................................................................................................8-9 8.7.1 Introduction to the Charging Mode......................................................................................................8-9 8.7.2 Independent Charging ..........................................................................................................................8-9 8.7.3 Segmented Charging ..........................................................................................................................8-10 8.8 Service Interaction ......................................................................................................................................8-12 8.9 Reference ....................................................................................................................................................8-13 8.9.1 Protocols and Specifications ..............................................................................................................8-13 8.9.2 Acronyms and Abbreviations .............................................................................................................8-14
Issue 02 (2007-06-10)
Figures
Figures
Figure 8-1 Invoking the ECT when A-B call is on hold and A-C call is in the active state................................8-5 Figure 8-2 Invoking the ECT when C is in the alerting state .............................................................................8-6
ii
Issue 02 (2007-06-10)
Tables
Tables
Table 8-1 Function code of the ECT...................................................................................................................8-2 Table 8-2 Benefits of the ECT ............................................................................................................................8-2 Table 8-3 Requirements for NEs ........................................................................................................................8-3 Table 8-4 Applicable versions ............................................................................................................................8-3 Table 8-5 Parameters of the related software......................................................................................................8-7 Table 8-6 ECT operation mode...........................................................................................................................8-8 Table 8-7 Scenarios of the ECT independent charging.......................................................................................8-9 Table 8-8 Scenarios of the ECT segmented charging ....................................................................................... 8-11 Table 8-9 Interaction between the ECT and other services...............................................................................8-12
Issue 02 (2007-06-10)
iii
8 Explicit Call Transfer Service
8
About This Chapter
Section 8.1 Service Description 8.2 Availability 8.3 Working Principle 8.4 Service Flow 8.5 Data Configuration 8.6 Service Management 8.7 Charging and CDR 8.8 Service Interaction 8.9 Reference
Explicit Call Transfer Service
Issue 02 (2007-06-10)
8-1

8.1.1 Function Code
Table 8-1 gives the function code of the explicit call transfer (ECT). Table 8-1 Function code of the ECT Name Explicit Call Transfer Code WMFD-020800
8.1.2 Definition
When the served mobile subscriber A has two on-going calls respectively with subscribers B and C, subscriber A can use the ECT function to connect B and C, and then A exits the call. The call between A and B (A-B call) or the call between A and C (A-C call) can be an incoming call or an outgoing call. Before the ECT is triggered, the A-B call and A-C call can be in the active state at the same time, or one of them is in the active state and the other is in the alerting state.
Intelligent subscribers do not support the ECT. The served mobile subscriber refers to the mobile subscriber who invokes the ECT.
8.1.3 Benefits
Table 8-2 gives the benefits of the ECT. Table 8-2 Benefits of the ECT Beneficiary Carrier Mobile subscriber Description Value added services are provided and call connection rate is increased. After the ECT function is provided, subscriber A can transfer a call to another subscriber during the conversation. In this case, subscriber A can flexibly determine the callee and the location of the callee.
8-2
Issue 02 (2007-06-10)
8.2 Availability
Table 8-3 gives the required Network Elements (NEs) for the ECT. Table 8-3 Requirements for NEs UE/MS Node B/BTS RNC/BSC MSC Server MGW SGSN GGSN HLR
The symbol "" indicates that NE is required.

The ECT is an optional attribute of Huawei wireless core network. The ECT service can be provided only when the License of the MSOFTX3000 is obtained.

Table 8-4 gives the applicable versions supported by Huawei core network product. Table 8-4 Applicable versions Product MSC server MSOFTX3000 Applicable Versions V100R003 and later versions

8.3.1 Functions of Each NE
The functions of the NEs are as follows: The MSC server and MGW work together to handle the ECT service. The HLR stores and manages the subscriber data and service data. The HLR updates the subscription data in the VLR by inserting the subscriber data.

The HLR provides and withdraws the ECT service and operators modify the subscription data stored in the HLR. The HLR updates the subscription data in the VLR by inserting the subscriber data.
Issue 02 (2007-06-10)
8-3
8.3.3 Invoking the ECT

Both the A-B Call and A-C Call Are in the Active State
The A-B call is in the active state. A holds the call with B and calls C. Then the A-C call is established. The working principle is as follows: 1. 2. 3. 4. 5. 6. The MS A sends the FACILITY message to the MSC to prompt subscriber A to invoke the ECT. After receiving the FACILITY message, the MSC queries the subscription information of subscriber A. If the ECT is to be provided, the MSC then handles the ECT service. The MSC sets up the B-C call. The MSC sends a notification to subscriber B to inform B of call recovery and call transfer. (The B-C call is in the active state.) The MSC sends a notification to subscriber C to inform C of call transfer. (The B-C call is in the active state.) The MSC returns the response message and disconnection request to subscriber A. Then subscriber A exits the call.
The A-B Call Is in the Active State and the A-C Call Is in the Alerting State
The A-B call is in the active state. A holds the call with B and calls C. C is in the alerting state. The working principle is as follows: 1. 2. 3. 4. 5. 6. 7. The MS A sends the FACILITY message to the MSC to prompt subscriber A to invoke the ECT. The MSC receives the FACILITY message and queries the subscription information of subscriber A. If the ECT is to be provided, the MSC then handles the ECT service. The MSC sets up the B-C call. The MSC sends a notification to subscriber B to inform B of call recovery and call transfer. (The B-C call is in the alerting state.) The MSC sends a notification to subscriber C to inform C of call transfer. (The B-C call is in the alerting state.) The MSC returns the response message and disconnection request to subscriber A. Then subscriber A exits the call. After subscriber C answers the call, the MSC sends a notification to subscriber B to inform B that the call is in the active state.
If the mobile phone does not support the ECT service, invoke it through the unstructured supplementary service data (USSD).
8.4 Service Flow

8.4.1 A-B Call Is on Hold and A-C Call Is in the Active State
The carrier provides the ECT service for subscriber A. A holds the call with B and calls C. The A-C call is established. Subscribers A, B and C belong to the same MSC server. Figure 8-1 shows the ECT service flow.
8-4
Issue 02 (2007-06-10)
Figure 8-1 Invoking the ECT when A-B call is on hold and A-C call is in the active state
MS A MSC server MS B MS C
A-B CALL ON HOLD A-C CALL ACTIVE
A wants to invoke ECT FACILITY FACILITY FACILITY FACILITY FACILITY DISCONNECT DISCONNECT B-C CALL ACTIVE
The service flow is as follows: 1. 2. 3. 4. 5. The MS A sends a FACILITY message containing ExplicitCT to the MSC server. The MSC server sends the FACILITY message to MS B. The invoke element is NotifySS. The CallOnHold-indicator informs MS B of call recovery. The MSC server sends the FACILITY to MS B. The invoke element is NotifySS. The ECT-CallState is active. The Rdn indicates the number of subscriber C. The MSC server sends the FACILITY message to MS C. The invoke element is NotifySS. The ECT-CallState is active. The Rdn indicates the number of subscriber B. The MSC server sends the FACILITY message to MS A. If the message contains the result element, the ECT is successfully invoked. If the message contains the error or reject element, the ECT invoking is failed. The MSC server does not disconnect MS A. The MSC server sends the DISCONNECT message of A-B call and A-C call to MS A and completes call release. (The release flow is omitted in Figure 8-1.)
6.
8.4.2 A-B Call Is in the Active State and A-C Call Is in the Alerting State
The carrier provides the ECT service for subscriber A. A holds the call with B and calls C. C is in the alerting state. Subscribers A, B and C belong to the same MSC server. Figure 8-2 shows the ECT service flow.
Issue 02 (2007-06-10)
8-5
Figure 8-2 Invoking the ECT when C is in the alerting state

MSa MSC Server MSb MSc
CALL A-B on HOLD CALL A-C ALERTING
A wants to invoke ECT FACILITY FACILITY FACILITY FACILITY FACILITY DISCONNECT DISCONNECT CALL B-C ALERTING C waits to answer CONNECT FACILITY CALL B-C ACTIVE
The service flow is as follows: 1. 2. 3. 4. 5. If subscriber A wants to invoke the ECT, the MS A sends a FACILITY message containing ExplicitCT to the MSC server. The MSC server sends the FACILITY message to the MS B. The invoke element is NotifySS. The CallOnHold-indicator informs MS B of call recovery. The MSC server sends the FACILITY to MS B. The invoke element is NotifySS. The ECT-CallState is alerting. The MSC server sends the FACILITY message to MS C. The invoke element is NotifySS. The ECT-CallState is active. The Rdn indicates the number of subscriber B. The MSC server sends the FACILITY message to MS A. If the message contains the result element, it indicates that the ECT is successfully invoked. If the message contains the error or reject element, it indicates that the ECT invoking fails. The MS A cannot exit the call. The MSC server sends the DISCONNECT message of A-B call and A-C call to MS A and completes call release. (The later flow is omitted in Figure 8-2.) Subscriber C answers the call. The MS C sends the CONNECT message to the MSC server. The MSC server sends the FACILITY message to MS B. The invoke element is NotifySS. The ECT-CallState is active. The Rdn indicates the number of C.
6. 7. 8.
8-6
Issue 02 (2007-06-10)

8.5.1 Data Configuration on the MSOFTX3000
For detailed data configuration operations, refer to the HUAWEI MSOFTX3000 Mobile SoftSwitch Center Configuration Guide.
Invoking the ECT

If the MS invokes the ECT through the USSD, the data of the USSD must be configured. For details, refer to the service description of the USSD.
Generating the CDR of the ECT

Run MOD GBILLCTRL to generate the Call Detail Record (CDR) of the ECT.

Table 8-5 gives the parameters of the related software. Table 8-5 Parameters of the related software Parameter Name Bit 9 of P18 (ISUP operation reserved parameter 1) Bit 10 of P18 (ISUP operation reserved parameter 1) Bit 5 of P134 (CHG parameter 6) Bit 6 of P134 (CHG parameter 6) Description It determines whether to send the FAC message to the peer office during the ECT. (The ISUP signaling is used between offices.) It determines whether to add the parameter allTransferNumber in the FAC message sent to the peer office. (The signaling between offices is the ISUP signaling.) It determines whether to segment the CDR. It determines the calling numbers filled in the CFW CDR of the forwarding subscriber and in the MTC CDR of the final subscriber after the call is forwarded during the ECT. Value 0: No 1: Yes Default Value 1
0: No 1: Yes
0: Yes 1: No 0: Number of the remote end 1: Number of the originating end
8.5.2 Data Configuration on the UMG8900

None.
Issue 02 (2007-06-10)
8-7

8.6.1 Operation Mode
Table 8-6 gives two ECT operation modes. Table 8-6 ECT operation mode Operation Mode Operations by the carriers Interface HLR client Service Operation Service provisioning Service cancellation Operator Determined Barring (ODB) Operations by the mobile subscribers MS ECT invoking
Suggested change: For the ECT service, the service is provided when it is activated; and the service is cancelled when it is deactivated.
8.6.2 Operations by the Carriers

The carriers are allowed to: Provide the ECT service. Withdraw the ECT service. Perform ODB operations on the ECT service. For details, refer to the related operation manuals of the HLR.
8.6.3 Operations by the Mobile Subscribers

Prerequisite
The carriers have already provided the ECT service for the subscribers.
Operation Steps
To invoke the ECT, perform the following steps: Step 1 Dial 4 on the MS. Step 2 Press the send button. ----End
For certain MS, the ECT can be invoked through the menu. Refer to the instruction of the mobile phone for detailed operations. If the MS does not support this mode, invoke the ECT through the USSD.
8-8
Issue 02 (2007-06-10)

8.7.1 Introduction to the Charging Mode
There are two charging modes: Independent charging: The MSOFTX3000 generates the event CDR that contains the ECT flag and timestamp, and the original MOC/MTC CDR that contains the complete record of the A-B call and A-C call. The iGWB integrates the contents of the event CDR to the supplementary service field of the original MOC/MTC CDR to generate the final MOC/MTC CDR. Segmented charging: The MSOFTX3000 generates a group of MOC/MTC CDRs with the B-C call duration as the interval. The charging center integrates the CDRs. The ECT flag and timestamp are contained in the integrated CDR. The MSOFTX3000 controls the charging mode through parameter Bit 5 (P134) and the CDR control table.
To set the CHG parameter Bit 5 (P134), refer to the software parameter table. To set the CDR control table, refer to the corresponding online help.
8.7.2 Independent Charging

The MSOFTX3000 only generates the CDR of the A-B call and A-C call. The CDR of the call between the remote ends (B-C call) will not be generated by the MSOFT3000. Table 8-7 lists the scenarios of generating the CDR. Table 8-7 Scenarios of the ECT independent charging Scenario CDR of Subscriber A in the A-B Call The Call Hold (CH) and ECT operations are recorded in the supplementary service field. Start time: B answers the call. End time: The B-C call is disconnected. CDR of Subscriber B in the A-B Call There is no record in the supplementary service field. Start time: B answers the call. End time: The B-C call is disconnected. CDR of Subscriber A in the A-C Call The ECT operation is recorded in the supplementary service field. Start time: C answers the call. End time: The B-C call is disconnected. CDR of Subscriber C in the A-C Call There is no record in the supplementary service field. Start time: C answers the call. End time: The B-C call is disconnected.
During the A-B call, A holds the call with B and calls C. After C answers the call, A invokes the ECT. The B-C call is disestablished.
Issue 02 (2007-06-10)
8-9
Scenario
CDR of Subscriber A in the A-B Call The CH and ECT operations are recorded in the supplementary service field. Start time: B answers the call. End time: The B-C call is disconnected. The CH operation is recorded in the supplementary service field. Start time: B answers the call. End time: The B-C call is disconnected.
CDR of Subscriber B in the A-B Call There is no record in the supplementary service field. Start time: B answers the call. End time: The B-C call is disconnected. There is no record in the supplementary service field. Start time: B answers the call. End time: The B-C call is disconnected.
CDR of Subscriber A in the A-C Call The ECT operation is recorded in the supplementary service field. Start time: C answers the call. End time: The B-C call is disconnected. There is no CDR.
CDR of Subscriber C in the A-C Call There is no record in the supplementary service field. Start time: C answers the call. End time: The B-C call is disconnected. There is no CDR.
During the A-B call, A holds the call with B and calls C. After C is in the alerting state, A invokes the ECT. The B-C call is disconnected. During the A-B call, A holds the call with B and calls C. After C is in the alerting state, A invokes the ECT. C does not answer the call.
8.7.3 Segmented Charging

The MSOFTX3000 only generates the CDR of the A-B call and A-C call. The CDR of the call between the remote ends (B-C call) will not be generated by the MSOFTX3000. Table 8-8 lists the scenarios of generating the CDR.
8-10
Issue 02 (2007-06-10)
Table 8-8 Scenarios of the ECT segmented charging Scenario CDR of Subscriber A in the A-B Call The first CDR: The CH operation is recorded in the supplementary service field. Start time: B answers the call. End time: A invokes the ECT. Interval CDR: The ECT operation is recorded in the supplementary service field. Start time: A invokes the ECT. End time: The B-C call is disconnected. During the A-B call, A holds the call with B and calls C. After C is in the alerting state, A invokes the ECT. The B-C call is The first CDR: The CH operation is recorded in the supplementary service field. Start time: B answers the call. End time: A invokes the ECT. There is no record in the supplementary service field. Start time: B answers the call. End time: The B-C call is disconnected. CDR of Subscriber B in the A-B Call There is no record in the supplementary service field. Start time: B answers the call. End time: The B-C call is disconnected. CDR of Subscriber A in the A-C Call The first CDR: There is no record in the supplementary service field. Start time: C answers the call. End time: The B-C call is disconnected. Interval CDR: The ECT operation is recorded in the supplementary service field. Start time: A invokes the ECT. End time: The B-C call is disconnected. The first CDR: There is no record in the supplementary service field. Start time: C answers the call. End time: The B-C call is disconnected. There is no record in the supplementary service field. Start time: C answers the call. End time: The B-C call is disconnected. CDR of Subscriber A in the A-C Call There is no record in the supplementary service field. Start time: C answers the call. End time: The B-C call is disconnected.
During the A-B call, A holds the call with B and calls C. After C answers the call, A invokes the ECT. The B-C call is disconnected.
Issue 02 (2007-06-10)
8-11
Scenario
CDR of Subscriber A in the A-B Call Interval CDR: The ECT operation is recorded in the supplementary service field. Start time: C answers the call. End time: The B-C call is disconnected.
CDR of Subscriber B in the A-B Call
CDR of Subscriber A in the A-C Call Interval CDR: The ECT operation is recorded in the supplementary service field. Start time: C answers the call. End time: The B-C call is disconnected.
CDR of Subscriber A in the A-C Call
disconnected.
During the A-B call, A holds the call with B and calls C. After C is in the alerting state, A invokes the ECT. C does not answer the call.
The CH operation is recorded in the supplementary service field. Start time: B answers the call. End time: The B-C call is disconnected.
There is no record in the supplementary service field. Start time: B answers the call. End time: The B-C call is disconnected.
There is no CDR.
There is no CDR.

Table 8-9 gives the interaction between the ECT and other services. Table 8-9 Interaction between the ECT and other services Service ECT and CLIP Interaction If A is the caller in the A-B call and B (or C) registers with the CLIP, the number of C (or B) must be sent to B (or C). But if C (or B) also registers with the CLIP, the number need not be sent to B (or C). If the A-C call is established before the ECT, the number of C must be sent to B after A invokes the ECT. If the A-C call is established after the ECT, the number of C must be displayed during the connection. If B (or C) is the callee and (or C) registers with the CLIP (OVERRIDE CATEGORY CLIP) service, the number of the peer end is displayed after the ECT is invoked.
8-12
Issue 02 (2007-06-10)
Service ECT and CLIR ECT and COLP
Interaction If B is the caller in the A-B call and registers with the CLIR. The number of B must not be sent to C. If B is the caller in the A-B call and B (or C) registers with the COLP, the number of C (or B) must be sent to B (or C). But if C (or B) also registers with the COLP, the number is not required to be sent to B (or C). If the A-C call is established before the ECT, the number of C must be sent to B after A invokes the ECT. If the A-C call is established after the ECT, the number of C must be displayed during the connection. If B (or C) is the caller and B (or C) registers with the COLP (OVERRIDE CATEGORY COLP) service, the number of the peer end is displayed after the ECT is invoked.
ECT and COLR
If A is the caller in the A-B call and B registers with the COLR service, the number of B must be hidden to C. If A is the caller in the A-C call and C registers with the COLR, the number of C must be hidden to B. If C registers with the CFB, the call is forwarded to D on C busy. If C registers with the CFNRy, the call is forwarded to D when C does not answer the call. The CFNRy timer is not restarted during the call forwarding. The ECT and CFNRc services do not affect each other. If A is in idle state after invoking the ECT, there will be no CW indication. If A has a CW before the ECT, process it as an ordinary terminated call. If C registers with the CW and the A-C call is in the waiting state, B will receive the CW indication after the ECT.
ECT and CFB ECT and CFNRy ECT and CFNRc ECT and CW
ECT and MPTY ECT and AoC ECT and cheating prevention
Both the MPTY originating party and remote party cannot invoke the ECT. The ECT and AoC services conflict with each other. The cheating prevention feature prevents the subscribers from owing fee by continuously invoking the ECT.
8.9 Reference
Refer to the following references: 3GPP TS 22.091 V4.0.0 3GPP TS 23.091 V4.0.0
Issue 02 (2007-06-10)
8-13
3GPP TS 24.091 V4.0.1 HUAWEI MSOFTX3000 Mobile SoftSwitch Center Configuration Guide

Acronym/Abbreviation 3GPP CFB CFNR CFNRc CFNRy CLIP CLIR COLP COLR ECT CW MOC MTC English Name 3rd Generation Partnership Project Call Forwarding on Mobile Subscriber Busy Call Forwarding No Reply Call Forwarding on mobile subscriber Not Reachable Call Forwarding on No Reply Calling Line Identification Presentation Calling Line Identification Restriction Connected Line Identification Presentation Connected Line Identification Restriction Explicit Call Transfer Call Waiting Mobile Originated Call Mobile Terminated Call
8-14
Issue 02 (2007-06-10)
Contents
Contents
9 ODB Service ................................................................................................................................9-1
9.1 Service Description .......................................................................................................................................9-2 9.1.1 Function Code......................................................................................................................................9-2 9.1.2 Definition .............................................................................................................................................9-2 9.1.3 Service Type.........................................................................................................................................9-3 9.1.4 Benefits ................................................................................................................................................9-4 9.2 Availability ....................................................................................................................................................9-4 9.2.1 Requirement for NEs ...........................................................................................................................9-4 9.2.2 Requirement for License......................................................................................................................9-4 9.2.3 Applicable Versions..............................................................................................................................9-5 9.3 Working Principle..........................................................................................................................................9-5 9.4 Service Flow..................................................................................................................................................9-5 9.4.1 Barring of Incoming Calls or MS MT..................................................................................................9-5 9.4.2 Barring of Outgoing Calls or MS MO .................................................................................................9-5 9.4.3 Barring of Roaming .............................................................................................................................9-6 9.4.4 Barring of Supplementary Services .....................................................................................................9-6 9.4.5 Barring of Packet Services...................................................................................................................9-6 9.5 Data Configuration........................................................................................................................................9-6 9.5.1 Data Configuration for MSOFTX3000 ................................................................................................9-6 9.5.2 Data Configuration for UMG8900.......................................................................................................9-7 9.6 Service Management .....................................................................................................................................9-7 9.7 Charging and CDR ........................................................................................................................................9-7 9.8 Service Interaction ........................................................................................................................................9-7 9.9 Reference ......................................................................................................................................................9-8 9.9.1 Protocols and Specifications ................................................................................................................9-8 9.9.2 Acronyms and Abbreviations ...............................................................................................................9-8
Issue 02 (2007-06-10)
Tables
Tables
Table 9-1 Name and function code of the ODB services....................................................................................9-2 Table 9-2 NEs related with the ODB services ....................................................................................................9-4 Table 9-3 Versions that support the ODB services .............................................................................................9-5 Table 9-4 Service interaction between ODB and other services.........................................................................9-7
ii
Issue 02 (2007-06-10)
9 ODB Service
9
About This Chapter
The following table lists the contents of this chapter. Section 9.1 Service Description 9.2 Availability 9.3 Working Principle 9.4 Service Flow 9.5 Data Configuration 9.6 Service Management 9.7 Charging and CDR 9.8 Service Interaction 9.9 Reference Describes
ODB Service
Issue 02 (2007-06-10)
9-1
9 ODB Service

9.1.1 Function Code
Table 9-1 lists the name and function code of the ODB services. Table 9-1 Name and function code of the ODB services Name Operator Determined Barring (ODB) services ODB: Barring of all outgoing calls (BAOC) ODB: Barring of all outgoing international calls (BOIC) ODB: Barring of outgoing international calls except those directed to the home PLMN Country (BOIC-exHC) ODB barring of all incoming calls (BAIC) ODB: Barring of outgoing calls when roaming outside home PLMN country (BOC-ROAM) ODB: Barring of incoming calls when roaming outside home PLMN country (BIC-ROAM) ODB: Barring of outgoing Premium Rate Calls (Information) ODB: Barring of outgoing Premium Rate Calls (Entertainment) ODB barring of supplementary service management ODB: Barring of Roaming outside the home PLMN ODB: Barring of domestic toll calls (HPLMN self-define type1) Self-defined ODB restriction function Code WMFD-030000 WMFD-030100 WMFD-030200 WMFD-030300 WMFD-030400 WMFD-030500 WMFD-030600 WMFD-030700 WMFD-030800 WMFD-030900 WMFD-031000 WMFD-031100 WMFD-031200
9.1.2 Definition
The Operator Determined Barring (ODB) is kind of service through which the PLMN operator determines the access capability of the users to the UMTS or GSM network.
The ODB is similar to the call restriction supplementary service. The differences between these two services are as follows: The service state of the user subscribing to ODB is determined by the operator, and that of the latter type can be determined by both the operator and the user. The ODB service is activated once it is provided to the user, and the latter type must be activated by the user.
9-2
Issue 02 (2007-06-10)
9 ODB Service
9.1.3 Service Type

The ODB service has the following types: Barring of incoming calls or mobile-terminated short message (SM MT) Barring of outgoing calls or mobile-originated short message (SM MO) Barring of roaming Barring of supplementary service Barring of packet service
Barring of Incoming Calls or SM MT (ODB-BIC)

The operator of a PLMN can restrict a user to receive calls of a certain type or SM MT. This service includes: Barring of all incoming calls BIC-ROAM Barring of SM MT
Barring of Outgoing Calls or SM MO (ODB-BOC)

The operator of a PLMN can restrict a user to originate calls of a certain type or SM MO. This service includes: Barring of all outgoing calls Barring of SM MO Barring of outgoing international calls BOIC-exHC BOC-ROAM when roaming outside HPLMN country Barring of outgoing premium rate calls (information) Barring of outgoing premium rate calls (entertainment)
Barring of Roaming (ODB-ROAM)

The operator of a PLMN can restrict a user to roam within a certain area. This service includes: Barring of roaming outside HPLMN Barring of roaming outside HPLMN country
Barring of Supplementary Services (ODB-SS)

Barring of supplementary services includes: Barring of supplementary service management Barring of supplementary service management enables the operator of the PLMN to restrict the user-controlled supplementary services. In this case, the users can not perform the following supplementary service management operations:
Registration
Issue 02 (2007-06-10)
9-3
9 ODB Service

Deregistration Activation Deactivation Querying Invocation
Barring of user registration of call forwarding services Barring of call transfer service
Barring of Packet Over SONET/SDH (ODB-POS)

Barring of POS service includes: Barring of PDP context activation launched by MS Barring of PDP context activation launched by network
9.1.4 Benefits
Beneficiary Carrier Mobile subscriber Description The ODB service helps the operator manage the users regarding all kinds of services based on actual situation. None.
9.2 Availability
9.2.1 Requirement for NEs
The ODB requires the corporation of the MSC server, VLR, HLR, SGSN, and GGSN. Table 9-2 lists the NEs related with the ODB services. Table 9-2 NEs related with the ODB services UE/ MS NodeB /BTS RNC/ BSC MSC Server MGW SGSN GGSN VLR HLR
"" stands for the related NEs.
9.2.2 Requirement for License

The ODB is an optional feature of the Huawei wireless core network. You can obtain this service only after getting the license of MSOFTX3000.
9-4
Issue 02 (2007-06-10)
9 ODB Service

Table 9-3 lists the Huawei core network product versions that support the ODB services. Table 9-3 Versions that support the ODB services Product MSC server MGW MSOFTX3000 UMG8900 Applicable Versions V100R002 an the later versions V200R002 and the later versions

The ODB requires the corporation of the HLR, MSC, VLR, and the SGSN. The MSC processes signaling, analyzes data, and plays announcements. The HLR stores the subscription data, determines whether to trigger the ODB, and sends subscription data of the user to the VLR. The VLR stores temporally the subscription data of the user which is to be queried by the MSC. The SGSN processes all the signaling related with packet services.
9.4 Service Flow

9.4.1 Barring of Incoming Calls or MS MT
Procedure of Barring of Incoming Calls
The HLR checks whether the user subscribes to the ODB barring of incoming calls after receiving a routing request from an MS. If the user subscribes to this service, the HLR sends a refusing message that contains error message to the MSC (or GMSC). The MSC (or GMSC) then sends the error message to the network of the calling party, and the calling party hears the prompt tone defined by the operator.
Procedure of Barring of SM MT
The HLR checks whether the user subscribes to the ODB barring of SM MT after receiving a routing request from an MS. If the user subscribes to this service, the HLR sends a refusing message that contains error message to the MSC (or GMSC). The MSC (or GMSC) then sends the error message to the related short message center.
9.4.2 Barring of Outgoing Calls or MS MO

The MSC checks the user information in the VLR after receiving a service request launched by the user subscribing to barring of outgoing calls. If the outgoing call barring of the user is
Issue 02 (2007-06-10)
9-5
9 ODB Service
activated, the MSC refuses the call request of the user and returns a refusing message which contains the cause value. The MSC needs to analyze the number of the called party to determine whether the following types of calls are barred: International calls Outgoing international calls except the home PLMN country Premium rate calls If a user subscribes to BOC-ROAM and roams to non-HPLMN countries, the MSC/HLR bars all the calls originated by this user and returns a refusing message which contains the cause value.
9.4.3 Barring of Roaming

If a mobile subscriber subscribes to the ODB barring of roaming, and if the subscriber launches registration to the VLR in the roaming restriction area defined by this barring of roaming service, the VLR sends a location update request to the HLR. The HLR checks the identifier of the VLR and determines that the VLR is in the roaming restriction area. Then the HLR responses a location canceling message and refuses the location update.
9.4.4 Barring of Supplementary Services

If a mobile subscriber subscribes to barring of supplementary services, and if the user launches a supplementary service operation, the HLR or MSC/VLR refuses the request and sends an error message to the mobile subscriber.
9.4.5 Barring of Packet Services

The procedure of the PDP context activation launched by a barred MS is as follows: If the SGSN receives a PDP context activation request, and if the MS subscribes to the ODB barring of packet services, the SGSN returns a refusing message which contains error message. The procedure of the PDP context activation launched by a barred network is as follows: If the HLR receives a routing request message to a certain MS, and if the routing request contains the PDP context activation information, the HLR checks the subscription data of the MS. If the MS subscription data contains the data for ODB barring of packet services, the HLR responses a refusing message which contains error message. Then the GGSN sends the error message to the network that launches the PDP context activation.

9.5.1 Data Configuration for MSOFTX3000
The MSOFTX3000 can control the ODB service through call prefix table and service check table: You can add call prefix by using the command ADD CNACLD. You can perform service check through certain call prefix.
9-6
Issue 02 (2007-06-10)
9 ODB Service
You can add service check by using the command ADD SRVCHK. You can perform service check through certain call prefix and determines whether to connect the call based on the check result.
9.5.2 Data Configuration for UMG8900

None.

All the management operations of the ODB services are performed in the HLR. For details, see the related product manuals of the latest version.

None.

Table 9-4 lists the service interaction between ODB and other services. Table 9-4 Service interaction between ODB and other services Service Terminal service and bearer service Supplementary services ODB and call forwarding ODB and CUG Interaction ODB can be applied to all terminal services and bearer services except emergency call. ODB has higher priority over supplementary services. If the ODB conflicts with supplementary services, the supplementary services will be barred. If the ODB barring of call forwarding is activated, the user is not allowed to register call forwarding services. The HLR (incoming calls) or the VLR (outgoing calls) checks the ODB service state and then the CUG service state when it receives a call request. The HLR (incoming calls) or the VLR (outgoing calls) checks the ODB service state and then the call barring service state when it receives a call request.
ODB and call barring
Issue 02 (2007-06-10)
9-7
9 ODB Service
9.9 Reference
This document takes the following protocols and manual as references: 3GPP TS 22.091 V4.0.0 3GPP TS 23.091 V4.0.0 3GPP TS 24.091 V4.0.1 HUAWEI MSOFTX3000 Mobile Softswitch Center Configuration Guide

Acronym/Abbreviation 3GPP HPLMN GGSN PDP ODB SGSN English Full Name 3rd Generation Partnership Project Home PLMN Gateway GPRS Support Node Packet Data Protocol Operator Determined Barring Serving GPRS Support Node
9-8
Issue 02 (2007-06-10)
Contents
Contents
10 Authentication Feature..........................................................................................................10-1
10.1 Service Description ...................................................................................................................................10-2 10.1.1 Function Code..................................................................................................................................10-2 10.1.2 Definition .........................................................................................................................................10-2 10.1.3 Benefits ............................................................................................................................................10-2 10.2 Availability ................................................................................................................................................10-3 10.2.1 Requirements for NEs......................................................................................................................10-3 10.2.2 Requirements for License ................................................................................................................10-3 10.2.3 Applicable Versions..........................................................................................................................10-3 10.3 Working Principle......................................................................................................................................10-3 10.4 Service Flow..............................................................................................................................................10-4 10.4.1 UMTS Authentication ......................................................................................................................10-4 10.4.2 GSM Authentication ........................................................................................................................10-5 10.5 Data Configuration....................................................................................................................................10-7 10.5.1 Data Configuration on MSOFTX3000.............................................................................................10-7 10.5.2 Data Configuration on HLR.............................................................................................................10-7 10.6 Service Management .................................................................................................................................10-7 10.6.1 Subscription of Authentication.........................................................................................................10-7 10.6.2 Query of Authentication...................................................................................................................10-7 10.7 Reference ..................................................................................................................................................10-7 10.7.1 Protocols and Specifications ............................................................................................................10-7 10.7.2 Glossary, Acronyms and Abbreviations ...........................................................................................10-8
Issue 02 (2007-06-10)
Figures
Figures
Figure 10-1 Flow of UMTS authentication ......................................................................................................10-4 Figure 10-2 Flow of GSM authentication.........................................................................................................10-6
ii
Issue 02 (2007-06-10)
Tables
Tables
Table 10-1 Function names and functions codes in the authentication and encryption ....................................10-2 Table 10-2 Benefits for carriers and mobile subscribers...................................................................................10-2 Table 10-3 NEs involved in the authentication and encryption ........................................................................10-3 Table 10-4 Versions of the products that support the authentication and encryption........................................10-3
Issue 02 (2007-06-10)
iii
10 Authentication Feature
10
About This Chapter
Section 10.1 Service Description 10.2 Availability Describes
Authentication Feature
The function code, function definition of this feature, and the benefits that carriers and mobile subscribers can obtain from this feature. The network elements (NEs) that are required for the feature, whether Licenses are required, and the version requirements of the NEs. The functions of the NEs, and networking requirements. The service flow of the network when providing this feature. The data configurations that are required on the MSOFTX3000 and the UMG8900. The service operations that carriers and mobile subscribers are required to implement when the network provides this feature. The protocols and specifications that this feature must comply with, and the acronyms and abbreviations of this chapter.
10.3 Working Principle 10.4 Service Flow 10.5 Data Configuration 10.6 Service Management 10.7 Reference
Issue 02 (2007-06-10)
10-1

10.1.1 Function Code
Table 10-1 lists the mapping between function names and function codes in the speech service. Table 10-1 Function names and functions codes in the authentication and encryption Name GSM Authentication and Encryption UMTS Authentication and Encryption
Note: GSM = Global System for Mobile communications; UMTS = Universal Mobile Telecommunications System
Code WMFD-060301 WMFD-060302
10.1.2 Definition
Authentication is a process used for a network to verify the validity of an UE. In the UMTS, an UE can also verify the validity of a network. Authentication, as part of the security management of a wireless network, guarantees the confidentiality and integrity of the wireless network, so that illegal subscribers cannot use the services that the network provides.
10.1.3 Benefits
Table 10-2 lists the benefits for carriers and mobile subscribers. Table 10-2 Benefits for carriers and mobile subscribers Beneficiary Carriers Description Authentication is an elementary feature of a network. Authentication enables carriers to verify the validity of MSs/UEs, and prevents illegal subscribers from accessing the network and using the services that the network provides. Authentication protects mobile subscribers from illegal attack.
Mobile subscribers
Note: MS = mobile station; UE = user equipment
10-2
Issue 02 (2007-06-10)
10.2 Availability
The authentication and encryption requires the cooperation of the UE/MS, base station subsystem (BSS) , radio access network (RAN) and core network (CN). For details, see Table 10-3. Table 10-3 NEs involved in the authentication and encryption UE/ MS NodeB /BTS RNC/ BSC MSC Server MGW SGSN GGSN VLR HLR
"" means the NE is required.

No License is required to obtain the authentication service, because the service is the elementary feature of the HUAWEI wireless core network.

Table 10-4 lists the versions of the HUAWEI circuited switched (CS) products that support the authentication and encryption. Table 10-4 Versions of the products that support the authentication and encryption Product MSC Server MGW MSOFTX3000 UMG8900 Applicable version V100R002 and later V200R002 and later

In the GSM and UMTS, the MS/UE, visitor location register (VLR) and authentication center (AuC) cooperate with each other to implement authentication. The MS/UE and AuC calculate authentication parameters respectively. The VLR then compares the two results, to verify the validity of the MS/UE. In the UMTS, the MS/UE can also verify the validity of the network.
Issue 02 (2007-06-10)
10-3
10.4 Service Flow

10.4.1 UMTS Authentication
UMTS authentication takes place when a UMTS subscriber accesses the UMTS with a UMTS subscriber identity module (USIM) card. Figure 10-1 shows the flow of UMTS authentication. Figure 10-1 Flow of UMTS authentication
Uu UE RAN 1. Send a service request (call setup/location update/ supplementary serice/SMS) 2. Send a MAP request (CKSN, IMSI/TMSI) 5. Start authentication 5 5 (RAND, AUTN) 3. Send a request for authntication parameters ( IMSI) 4. Return parameters IMSIRANDCK IKAUTNXRES RANAP Iu MSC MAP B VLR MAP D HLR/AuC
6. Refuse authentication (XMAC MAC) 6. Synchronization fails (SQNHE SQNMS) 7. Send an authentication response
AuC re-synchronization
7. Accept the request/ Refuse the request Sends an acceptance response Authentication succeeds legal UE Authentication fails illegal UE
8. Compare SRES and XRES
Explanations of the flow of UMTS authentication are as follows: 1. 2. The UE sends an authentication request to the mobile switching center (MSC). The authentication of services is defined by the data configured on the MSC. The MSC sends a MAP_PROCESS_ACCESS_REQUEST to the VLR, requesting the authentication set from the VLR.
If there are available authentication sets in the VLR, the VLR returns the RAND and AUTN contained in the authentication set to the MSC before starting authentication. The MSC then directly transfers the two parameters to the UE over the RAN, without interacting with the AuC. That is, step 5 takes place immediately after step 2. If no available authentication set is in the VLR, step 3 takes place.
3. 4. 5.
The VLR requests the authentication set from the AuC. The AuC returns one to five groups of quintuples to the VLR based on actual conditions. The VLR starts authentication.
10-4
Issue 02 (2007-06-10)
6.
The UE calculates the authentication parameters XMAC and SQNMS at the UE side, based on the RAND and AUTN returned by the VLR. The UE then compares the XMAC and SQNMS with the MAC and SQNHE in AUTN.

If MAC is not equal to XMAC, the authentication of the UE to the network fails. In this case, the VLR reports the authentication failure message to the AuC. If the difference between SQNMS and SQNHE is not within the specific range, it means the authentication of the UE to the network fails. In this case, the VLR sends a re-synchronization message to the AuC. The re-synchronization flow is similar to the flow of obtaining authentication set from the AuC. The difference is that the MAP_SEND_AUTHENTICATION_INFO message carries the re-synchronization information containing AUTS and RAND. After receiving the re-synchronization message, the AuC calculates MAC based on the RAND in the message, and compares the MAC with the MAC-S in AUTS, to judge whether the re-synchronization is valid. The AuC adjusts its own SQNHE based on the SQNMS in AUTS, and calculates a new group of authentication values for the VLR. The VLR starts authentication again with the new group of authentication values, and returns AUTN and RAND to the UE. After that, steps 3 and 4 are repeated. If the validity verification succeeds, then the authentication succeeds.
7. 8.
The UE calculates XRES based on the AUTN and RAND returned from the VLR, and sends an authentication response carrying XRES to the VLR. The VLR compares the XRES returned by the UE with the XRES calculated by the AuC.
If the two values are different, the VLR sends an authentication rejection response to the UE. The UE receives the response. This means the UE is invalid and the authentication fails. If the two values are the same, the authentication of the network to the UE succeeds. In this case, the network sends a response to the UE, indicating that the service or location update is accepted.
10.4.2 GSM Authentication

GSM authentication takes place under one of the following conditions: A GSM subscriber accesses the GSM with a SIM card. A GSM subscriber accesses the UMTS. A UMTS subscriber accesses the GSM. SIM stands for subscriber identity module. In GSM authentication, the MS does not have to authenticate the network. Figure 10-2 shows the flow of GSM authentication.
Issue 02 (2007-06-10)
10-5
Figure 10-2 Flow of GSM authentication

Um MS BSS 1. Send a service request (call setup/location update/ supplementary serice/SMS) (CKSN, IMSI/TMSI) 3. Send a request for authntication parameters (IMSI) 4. Return parameters (IMSI, KC, S, RAND) BSSAP A MSC 2. Send a MAP request MAP B VLR MAP D HLR/AuC
5. Start authentication 5 5 (CKSN, RAND)
6. Send an authentication response 6 Sends an acceptance response 7. Accept the request/ Refuse the request Authentication succeeds legal UE Authentication fails illegal UE 8. Compare SRES and XRES
Explanations of the flow of GSM authentication are as follows: 1. 2. The MS sends an authentication request to the MSC. The authentication of services is defined by the data configured on the MSC. The MSC sends a MAP_PROCESS_ACCESS_REQUEST to the VLR, requesting the authentication set from the VLR.
If there are available authentication sets in the VLR, the VLR returns the RAND and AUTN contained in the authentication set to the MSC before starting authentication. The MSC then directly transfers the two parameters to the MS, without interacting with the AuC. That is, step 5 takes place immediately after step 2. If no available authentication set is in the VLR, step 3 takes place.
3. 4. 5. 6. 7.
The VLR requests the authentication set from the AuC. The AuC returns one to five groups of triplets to the VLR based on actual conditions. The VLR starts authentication. The MS calculates SRES based on the RAND returned from the VLR, and sends an authentication response carrying SRES to the VLR. The VLR compares the SRES returned by the MS with the SRES calculated by the AuC.
If the two values are different, the VLR sends an authentication rejection response to the MS. The MS receives the response. This means the MS is invalid and the authentication fails. If the two values are the same, the authentication of the network to the MS succeeds. In this case, the network sends a response to the MS, indicating that the service or location update is accepted.
10-6
Issue 02 (2007-06-10)
When a UMTS subscriber roams in the GSM, the AuC may return a quintuple to the VLR. In this case, the VLR must transform the quintuple to a triplet. After that, the VLR returns the ciphering key sequence number (CKSN) together with the RAND in the triple to the MS.

10.5.1 Data Configuration on MSOFTX3000
To configure the data for the authentication feature, perform the following steps: Step 1 Run MOD AUTHCFG to modify authentication configuration. (Optional) Step 2 Run ADD CHKIMEICTRL to add IMEI check control. (Optional) Step 3 Run SET CHKIMEICFG to set IMEI check configuration. (Optional) Step 4 Run ADD VEIRUSER to add a virtual EIR subscriber. (Optional) ----End
10.5.2 Data Configuration on HLR

For the details on configuration steps and parameter description, see the manuals relevant to the HLR.

10.6.1 Subscription of Authentication
The subscription of authentication is on the HLR. For details, see the manuals relevant to the HLR.
10.6.2 Query of Authentication

The query of authentication is on the HLR. For details, see the manuals relevant to the HLR.
10.7 Reference
3GPP TS 33.102: <3rd Generation Partnership Project; Technical Specification Group Services and System Aspects;3G Security; Security Architecture> 3GPP TS 29.002: <3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile Application Part (MAP) specification;>
Issue 02 (2007-06-10)
10-7
10.7.2 Glossary, Acronyms and Abbreviations

Glossary
Glossary Triplet Definition A triplet is a GSM authentication vector composed of three elements: RAND, SRES and Kc. It is a temporary data used for the MSC/VLR or SGSN to negotiate GSM authentication and key agreement (AKA) with a specific subscriber. A quintuple is a UMTS authentication vector composed of five elements: RAND, XRES, CK, IK and AUTN. It is a temporary data used for the MSC/VLR or SGSN to negotiate UMTS AKA with a specific subscriber.
Quintuple
Acronyms and Abbreviations

Acronym/Abbreviation AuC CKSN GSM MAC MS MSC RAND UMTS UE VLR Full Name Authentication Center Ciphering Key Sequence Number Global System for Mobile Communications Message Authentication Code Mobile Station Mobile Switching Center RANDom number Universal Mobile Telecommunication Services User Equipment Visitor Location Register
10-8
Issue 02 (2007-06-10)
Contents
Contents
11 Enhanced MSRN Allocation Feature .................................................................................11-1
11.1 Service Description ................................................................................................................................... 11-2 11.1.1 Function Code .................................................................................................................................. 11-2 11.1.2 Definition ......................................................................................................................................... 11-2 11.1.3 Benefits ............................................................................................................................................ 11-4 11.2 Availability ................................................................................................................................................ 11-4 11.2.1 Requirements for NEs ...................................................................................................................... 11-4 11.2.2 Requirements for License ................................................................................................................ 11-4 11.2.3 Applicable Versions.......................................................................................................................... 11-4 11.3 Working Principle...................................................................................................................................... 11-5 11.3.1 Functions of NEs.............................................................................................................................. 11-5 11.3.2 Processing in the System.................................................................................................................. 11-5 11.4 Service Flow.............................................................................................................................................. 11-7 11.4.1 General Procedure of MSRN Allocation.......................................................................................... 11-7 11.4.2 Procedure for Random Allocation.................................................................................................... 11-8 11.5 Data Configuration .................................................................................................................................... 11-9 11.5.1 Configuring Data at the MSOFTX3000 Side................................................................................... 11-9 11.5.2 Configuraing Data at the UMG8900 Side...................................................................................... 11-10 11.5.3 Configuration Examples................................................................................................................. 11-10 11.6 Service Management ............................................................................................................................... 11-14 11.7 Charging and CDR .................................................................................................................................. 11-14 11.8 Service Interaction................................................................................................................................... 11-14 11.9 Reference................................................................................................................................................. 11-15 11.9.1 Protocols and Specifications .......................................................................................................... 11-15 11.9.2 Acronyms and Abbreviations ......................................................................................................... 11-15
Issue 02 (2007-06-10)
Figures
Figures
Figure 11-1 Simple MSRN allocation procedure ............................................................................................. 11-6 Figure 11-2 General procedure of MSRN allocation........................................................................................ 11-7 Figure 11-3 Procedure for random allocation................................................................................................... 11-8 Figure 11-4 Mapping between the MSRN or HON allocation tables............................................................... 11-9
ii
Issue 02 (2007-06-10)
Tables
Tables
Table 11-1 Name and code of the function ....................................................................................................... 11-2 Table 11-2 Beneficiaries and description of the benefits .................................................................................. 11-4 Table 11-3 NEs required by the enhanced MSRN allocation service ............................................................... 11-4 Table 11-4 Applicable versions of HUAWEI wireless core network products ................................................. 11-5
Issue 02 (2007-06-10)
iii
11 Enhanced MSRN Allocation Feature
11
Enhanced MSRN Allocation Feature
About This Chapter

The following table lists the contents of this chapter. Section 11.1 Service Description 11.2 Availability 11.3 Working Principle 11.4 Service Flow 11.5 Data Configuration 11.6 Service Management 11.7 Charging and CDR 11.8 Service Interaction 11.9 Reference Describes The function code, function definition of this feature, and the benefits that carriers and mobile subscribers can obtain from this feature. The network elements (NEs) that are required for the feature, whether Licenses are required, and the version requirements of the NEs. The functions of the NEs, and networking requirements. The service flow of the network when providing this feature. The data configurations that are required on the MSOFTX3000 and the UMG8900. The service operations that carriers and mobile subscribers are required to implement when the network provides this feature. The charging and the generation of CDRs when the network provides this feature. The relationships and restrictions between this feature and other services or features. The acronyms and abbreviations in this chapter.
Issue 02 (2007-06-10)
11-1

Table 11-1 lists the name and code of the function. Table 11-1 Name and code of the function Name Enhanced MSRN allocation Code WMFD-042400
11.1.2 Definition
Overview
The mobile station roaming number (MSRN) is used by the mobile switching center (MSC) to address callees. When the mobile station (MS) receives a call, the system instructs the visitor location register (VLR) to allocate a temporary MSRN to the MS based on the request of the home location register (HLR). An MSRN has a validity period, and the default value is 90 seconds. You can set the validity period in the VLR configuration table. There are several modes for allocating MSRNs. The parameter MSRN allocation mode specifies the mode adopted by the VLR to allocate roaming numbers for the mobile subscribers roaming to the local office. The default value is Allocate randomly. There are three MSRN allocation modes: Allocation based on the MSC number Allocation based on the LAI number Random allocation The mode of random allocation enables you to allocate roaming numbers based on the attribute of the call or the callee. The VLR can allocate specific roaming number resources through different allocation modes to meet various requirements.
Generally, the mode of random allocation can meet the requirements of networking except for certain special cases: In the multi-area network, you are recommended to set MSRN allocation mode to Allocate according to MSC number. When the location area identification (LAI) number is used for charging, you are recommended to set MSRN allocation mode to Allocate according to LAI number.
Allocation Based on the MSC Number

The VLR ranges the MSRN resources that the local VLR can use based on the MSC number in advance. That is, the VLR allocates MSRN resources for different MSC numbers.
11-2
Issue 02 (2007-06-10)
When the home HLR of a mobile subscriber requests the local MSC or VLR to allocate an MSRN for the mobile subscriber, the local MSC or VLR allocates an idle MSRN randomly from the MSRN pool to which the MSC number of the callee corresponds.
The mapping between the MSRN and the MSC number is configured by using the command ADD MHMSCCFG.
Allocation Based on the LAI Number

The VLR ranges the MSRN resources that the local VLR can use based on the LAI number in advance. That is, the VLR allocates MSRN resources for different LAI numbers. When the home HLR of a mobile subscriber requests the local MSC or VLR to allocate an MSRN for the mobile subscriber, the local MSC or VLR allocates an idle MSRN randomly from the MSRN pool to which the LAI number of the callee corresponds.
The mapping between the MSRN and the LAI number is configured by using the command ADD MHLAICFG.
Random Allocation
The VLR does not range the MSRN resources that the local VLR can use in advance. When the home HLR of a mobile subscriber requests the local MSC or VLR to allocate an MSRN for the mobile subscriber, the local MSC or VLR allocates an idle MSRN randomly from all the MSRN pools that the local MSC or VLR can use. For the mode of random allocation, the VLR adds an extended function to the enhanced MSRN allocation service. The VLR divides roaming numbers into two types based on the attributes of the numbers: Intra-province roaming number The numbers of which MSRN/HON number type is set to MSRN and HON or MSRN are intra-province roaming numbers. Inter-province roaming numbers Inter-province roaming numbers are configured by using the command ADD IMHSUFFIX. Inter-province roaming numbers are classified into four types based on the attribute of the callee. The numbers of which MSRN/HON number type is set to any of the following values are inter-province roaming numbers:

MSRN outer province Is_O_CSI roaming type MSRN outer province No_O_CSI roaming type MSRN outer province Is_O_CSI local type MSRN outer province No O_CSI local type
When a roaming number is requested for an inter-province incoming call, the VLR allocates a roaming number from the corresponding roaming number resource pool based on the attribute of the callee. If the related inter-province roaming numbers are used up, the VLR allocates an intra-province roaming number so that the incoming call can be connected to the office.
Issue 02 (2007-06-10)
11-3
11.1.3 Benefits
Table 11-2 lists the beneficiaries and description of the benefits. Table 11-2 Beneficiaries and description of the benefits Beneficiary Carriers Description Carriers can choose the allocation mode based on their requirements. In this way, the subscriber types are analyzed more effectively, and the customer satisfaction rate is improved. None.
Mobile subscribers
11.2 Availability
Table 11-3 lists the network elements (NEs) required by the enhanced MSRN allocation service. Table 11-3 NEs required by the enhanced MSRN allocation service UE/MS Node B/BTS RNC /BSC MSC server MGW SGSN VLR HLR
Note: UE = user equipment; MS = mobile station; BTS = base transceiver station; RNC = radio network controller; BSC = base station controller; MGW = media gateway; SGSN = serving GPRS support node

The enhanced MSRN allocation service is the basic service of HUAWEI wireless core network. No license is required.

Table 11-4 lists the applicable versions of HUAWEI wireless core network products that the enhanced MSRN allocation service supports.
11-4
Issue 02 (2007-06-10)
Table 11-4 Applicable versions of HUAWEI wireless core network products Product MSC server MSOFTX3000 Applicable Version V100R002 and later versions

11.3.1 Functions of NEs
The MSC server determines the MSRN allocation mode through data configuration. The VLR realizes MSRN allocation based on the configuration of the system.
11.3.2 Processing in the System

Messages are exchanged between the MSC server, VLR, and HLR through the Mobile Application Part (MAP) protocol.
The VLR and HLR exchange and transfer the requests for MSRN allocation. The MSC server performs the following functions: Exchanges information with the VLR and HLR through the C/D interface Checks the status of subscribers Conveys flag bits to the VLR The VLR allocates an MSRN based on the configuration in the MSC server, and records the information required after the call is connected. Figure 11-1 shows the simple MSRN allocation procedure.
Issue 02 (2007-06-10)
11-5
Figure 11-1 Simple MSRN allocation procedure

Caller
(1) (2)
(G)MSC server (5) HLR (4) (10) (6)
(3) (7)
(9)
VLR
(8) VMSC server Callee
1. 2. 3.
The (G)MSC server receives a call request from the caller. The (G)MSC server requests routing information from the HLR of the callee. The HLR checks compatibility and the feasibility of subscription. The HLR obtains an MSRN from the VLR because the HLR records the address of the VLR in the office to which the callee roams. The VLR checks the status of the subscriber, allocates an MSRN based on the current allocation mode, and returns the MSRN to the HLR.

4.
If MSRN allocation mode is set to Allocate according to MSC number, the VLR allocates an MSRN related to the MSC number of the callee. If MSRN allocation mode is set to Allocate according to LAI number, the VLR allocates an MSRN related to the LAI number of the callee. If MSRN allocation mode is set to Allocate randomly, the VLR allocates an MSRN from all MSRN pools. If the extended MSRN allocation function is enabled for the mode of random allocation, the VLR allocates a corresponding MSRN from the MSRN pool based on the attributes of the call and the callee.
5.
The HLR returns the MSRN to the (G)MSC server at the caller side.
11-6
Issue 02 (2007-06-10)
6. 7. 8. 9.
The (G)MSC server sends a request for setting up the call to the VMSC server of the callee based on the MSRN. The VMSC sever queries the VLR for the subscription information of the callee. After receiving the subscription information of the callee, the VMSC server checks the information, and sends a paging request to the callee. The callee sends a response to the MSC of the callee.
10. The MSC of the callee analyzes access data, and sets up the call with the caller side. The UE of the callee rings.
MSRN allocation is processed at the callee side in the module. This section does not give details.
11.4 Service Flow

11.4.1 General Procedure of MSRN Allocation
Figure 11-2 shows the general procedure of MSRN allocation. Figure 11-2 General procedure of MSRN allocation
HLR
MSOFTX3000
VLR
MAP_PROVIDE_ROAMING_NUMBER_IND [GMSC NO] VP_VDB_GetCBData_PRN_VLR_Req MAP_VLR_GetCBData_PRN_RSP [CB_STATUS_PRN] Request MSRN after subscriber status check VP_VDB_MSRNAllocate_Req
The VLR allocates an MSRN based on the MSRN allocation mode, and updates the values of the counters. MAP_VLR_MSRNAllocate_RSP MAP_PROVIDE_ROAMING_NUMBER_RSP [msrn] [msrn]
The VLR and HLR exchange and transfer the requests for MSRN allocation. The MSC server completes the interaction between the C/D interfaces of the VLR and the HLR, checks subscriber status, and conveys flag bits to the VLR. The VLR allocates an MSRN based on the configuration in the MSC server, and records the information required after the call is connected.
Issue 02 (2007-06-10)
11-7
11.4.2 Procedure for Random Allocation

Figure 11-3 shows the procedure for random allocation. Figure 11-3 Procedure for random allocation
HLR MSOFTX3000 VLR
MAP_PROVIDE_ROAMING_NUMBER_IND [GMSC NO] Identify whether the incoming call is an interprovince call based on the GMSC number in the PRN message, and record the Province Flag VP_VDB_GetCBData_PRN_VLR_Req [Province Flag] MAP_VLR_GetCBData_PRN_RSP [CB_STATUS_PRN] VP_VDB_MSRNAllocate_Req [Province] Flag The VLR allocates a roaming number based on the Province Flag and the property of the callee, and updates the values of the counters. MAP_VLR_MSRNAllocate_RSP MAP_PROVIDE_ROAMING_NUMBER_RSP [msrn] [msrn]
Transfer the flag to the VLR after subscriber status check
The MSC server works with the HLR and VLR to realize the enhanced MSRN allocation function through the C/D interfaces. The MSC server analyzes the attribute of an incoming call. When receiving a request for allocating a roaming number from the HLR, the MSC server judges whether the incoming call is an inter-province call based on the gateway MSC (GMSC) number in the request. The MSC server then stores the Province Flag in the MAP table so as to transfer the flag to the VLR when allocating a roaming number. The VLR judges whether to use the inter-province roaming number resources based on the Province Flag in the request for allocating a roaming number, and then allocates a roaming number based on the attribute of the callee. If the inter-province roaming number resources of the callee are used up, the VLR allocates an intra-province roaming number so that the incoming call can be configured with a roaming number. The HLR must carry the GMSC number of the callee; otherwise, the MSC server cannot judge whether the incoming call is an inter-province call. In this case, the MSC server regards the incoming call as an inter-province call by default.
11-8
Issue 02 (2007-06-10)

Mapping Between Tables
Figure 11-4 shows the mapping between the MSRN or handover (HON) allocation tables. Figure 11-4 Mapping between the MSRN or HON allocation tables
ADD/MOD VLRCFG [MSRN Allocation Mode] [HON Allocation Mode]
ADD MHLAICFG [LAI Number] [Preferable Suffix Index]
ADD MHSUFFIX/IMHSUFFIX ADD MHPREFIX [MSRN Prefix Index] [MSRN Prefix] [MSRN Suffix Length] [MSRN Suffix Index] [MSRN Prefix Index] [MSRN Suffix Start] [MSRN Suffix End] [MSRN Number Type]
ADD MHMSCCFG [MSC Number] [Preferable Suffix Index]
As shown in Figure 11-4, the MSRN or HON Prefix table, the MSRN or HON Suffix table, and the Inner MSRN or HON Suffix table are mandatory. The Mapping Between LAI and MSRN or HON table and the Mapping Between MSC and MSRN or HON table are applicable to different allocation modes. The mapping between the tables connected by the broken line is as follows: The MSRN or HON allocation mode is determined based on the parameter MSRN allocation mode or HON allocation mode in the VLR Configuration table. The command ADD MHLAICFG or ADD MHMSCCFG is selected to configure the data.
Both the MHSUFFIX commands and the IMHSUFFIX commands are used to configure the MSRN or HON Suffix table, but they configure different types of roaming numbers. The differences are as follows: The IMHSUFFIX commands can configure inter-province roaming numbers. The MHSUFFIX commands cannot configure the inter-province roaming numbers.
Issue 02 (2007-06-10)
11-9
Configuration Steps
To configure an MSRN or HON, perform the following steps: Step 1 Run ADD VLRCFG to configure the basic functions of the VLR. The default allocation mode is Allocate randomly. Step 2 Run ADD MHPREFIX to configure the prefix of the MSRN. Step 3 Run ADD MHSUFFIX to configure the suffix of the MSRN. Step 4 To allocate an MSRN or HON based on the LAI number or the MSC number, modify the allocation mode by running MOD VLRCFG. Step 5 To enable the extended MSRN allocation function for the mode of random allocation, run MOD MSFP to change the value of BIT of VLR software parameter 1 to 1 from 11. Thus the roaming number resources are re-allocated, and the function of allocation based on the attributes of the call and the callee is enabled. Step 6 Run ADD IMHSUFFIX to add, or MOD IMHSUFFIX to modify the intra- and inter-province roaming numbers.
This step is applicable only when the extended MSRN allocation function for the mode of random allocation is enabled.
Step 7 Run ADD MSRNCTR to configure the GMSC connected to the local office in the case of an intra-province incoming call. This step is optional.
This step is applicable only when the MSRN allocation control function is enabled.
Step 8 For the mode of allocation based on the MSC number, run ADD MHMSCCFG to add the mapping between the MSC number and the MSRN or HON. Step 9 For the mode of allocation based on the LAI number, run ADD MHLAICFG to add the mapping between the LAI number and the MSRN or HON. ----End
11.5.2 Configuraing Data at the UMG8900 Side

None.
11.5.3 Configuration Examples

Scenario 1
The scenario is as follows: The local MSOFTX3000 serves as the MSC server of the peer office. MSRN/HON prefix is set to K'8613901106. MSRN/HON suffix ID is set to 1, Start MSRN/HON suffix to 000, and End MSRN/HON suffix to 499. Inner MSRN/HON suffix ID is set to 2, Start MSRN/HON suffix to 500, and End MSRN/HON suffix to 599.
11-10
Issue 02 (2007-06-10)
Inner MSRN/HON suffix ID is set to 3, Start MSRN/HON suffix to 600, and End MSRN/HON suffix to 699. Inner MSRN/HON suffix ID is set to 4, Start MSRN/HON suffix to 700, and End MSRN/HON suffix to 799. Inner MSRN/HON suffix ID is set to 5, Start MSRN/HON suffix to 800, and End MSRN/HON suffix to 899. The number of the GMSC connected to the MSOFTX3000 is 8613901105.
Scripts
The scripts are as follows: Step 1 Modify VLR configuration. Description Script Set MSRN allocation mode to Allocate randomly. MOD VLRCFG: MSRNAM=RAND;
Step 2 Add a mobile national access code. Description Script Set Mobile national access code to K'139. ADD NACODE: NAC=K'139;
Step 3 Add an MSRN or HON prefix. Description Script Set MSRN/HON prefix to K'8613901106, and MSRN/HON suffix length to 3. ADD MHPREFIX: ID=1, HPFX=K'8613901106, SFXL=3;
Step 4 Add an MSRN or HON suffix. Description Script Set MSRN/HON suffix ID to 1, Start MSRN/HON suffix to 000, and End MSRN/HON suffix to 499. ADD MHSUFFIX: ID=1, PFXIDX=1, SFXS="000", SFXE="499", MSRNT=MSRN;
Step 5 Add an inner MSRN or HON suffix. Description Script Set Inner MSRN/HON suffix ID to 2, Start MSRN/HON suffix to 500, and End MSRN/HON suffix to 599. ADD IMHSUFFIX: ID=2, PFXIDX=1, SFXS="500", SFXE="599", MSRNT=MSRNOPNCL;
Issue 02 (2007-06-10)
11-11
Step 6 Add an inner MSRN or HON suffix. Description Script Set Inner MSRN/HON suffix ID to 3, Start MSRN/HON suffix to 600, and End MSRN/HON suffix to 699. ADD IMHSUFFIX: ID=3, PFXIDX=1, SFXS="600", SFXE="699", MSRNT=MSRNOPCL;
Step 7 Add an inner MSRN or HON suffix. Description Script Set Inner MSRN/HON suffix ID to 4, Start MSRN/HON suffix to 700, and End MSRN/HON suffix to 799. ADD IMHSUFFIX: ID=4, PFXIDX=1, SFXS="700", SFXE="799", MSRNT=MSRNOPNCR;
Step 8 Add an inner MSRN or HON suffix. Description Script Set Inner MSRN/HON suffix ID to 5, Start MSRN/HON suffix to 800, and End MSRN/HON suffix to 899. ADD IMHSUFFIX: ID=5, PFXIDX=1, SFXS="800", SFXE="899", MSRNT=MSRNOPCR;
Step 9 Enable the extended MSRN allocation function of the VLR for the mode of random allocation. Description Script Enable the extended MSRN allocation function of the VLR for the mode of random allocation. MOD MSFP: ID=P200, MODTYPE=P1, BIT=11, BITVAL=1;
Step 10 Add MSRN allocation control. Description Script Add MSRN allocation control. ADD MSRNCTR: ADDRTYPE=GMSC, ADDRESS=K'8613901105;
----End
Scenario 2
The local MSOFTX3000 serves as the MSC server of the peer office. MSRN allocation mode is set to Allocate according to LAI number. There are two number ranges: The MSRN or HON of the cell in the 2G network ranges from 86136000040001 to 86136000040999. MSRN/HON prefix ID is set to 0, MSRN/HON suffix ID to 0, and LAI number to 460000001.
11-12
Issue 02 (2007-06-10)
The MSRN or HON of the cell in the 3G network ranges from 86136000041000 to 86136000041999. MSRN/HON prefix ID is set to 0, MSRN/HON suffix ID to 1, and LAI number to 460000003.
Scripts
The scripts are as follows: Step 1 Modify VLR configuration. Description Script Set MSRN allocation mode to Allocate according to LAI number. MOD VLRCFG: MSRNAM=LAI;
Step 2 Add a mobile national access code. Description Script Set Mobile national access code to K'136. ADD NACODE: NAC=K'136;
Step 3 Add an MSRN or HON prefix. Description Script Set MSRN/HON prefix to K'8613600004, and MSRN/HON suffix length to 4. ADD MHPREFIX: MHPREFIX=K'8613600004, MHSL=4;
Step 4 Add an MSRN or HON suffix. Description Script Set MSRN/HON suffix ID to 0, Start MSRN/HON suffix to 0001, and End MSRN/HON suffix to 0999. ADD MHSUFFIX: PREFIXINDEX=0, SUFFIXSTART="0001", SUFFIXEND="0999", NUMBERTYPE=MSRNHON;
Step 5 Add an MSRN or HON suffix. Description Script Set MSRN/HON suffix ID to 1, Start MSRN/HON suffix to 1000, and End MSRN/HON suffix to 1999. ADD MHSUFFIX: PREFIXINDEX=1, SUFFIXSTART="1000", SUFFIXEND="1999", NUMBERTYPE=MSRNHON;
Issue 02 (2007-06-10)
11-13
Step 6 List MSRN or HON suffixes. Description Script List MSRN or HON suffixes. LST MHSUFFIX;
Step 7 Add mapping between the LAI number and the MSRN or HON. Description You must add a cell first. The MSRN or HON of the cell in the 2G network ranges from 86136000040001 to 86136000040999. To add mapping between the LAI number and the MSRN or HON, set LAI number to 460000001, and MSRN/HON suffix ID to 0. ADD MHLAICFG: LAINUM="460000001", PRESUFFINDEX=0;
Script
Step 8 Add mapping between the LAI and the MSRN or HON. Description You must add a cell first. The MSRN or HON of the cell in the 3G network ranges from 86136000041000 to 861360000419999. To add mapping between the LAI number and the MSRN or HON, set LAI number to 460000003, and MSRN/HON suffix ID to 1. ADD MHLAICFG: LAINUM="460000003", PRESUFFINDEX=1;
Script
----End

None.

The charging module puts the roaming number to be obtained into the call detail record (CDR), and then reports the CDR to the billing center. The billing center sorts different CDRs, judges the types of calls, and charges the calls.

None.
11-14
Issue 02 (2007-06-10)
11.9 Reference
None.

Acronym/Abbreviation HON LAI MSRN Full Name Handover Number Location Area Identification Mobile Station Roaming Number
Issue 02 (2007-06-10)
11-15
Contents
Contents
12 Early and Late Assignment Feature....................................................................................12-1
12.1 Service Description ...................................................................................................................................12-2 12.1.1 Function Code..................................................................................................................................12-2 12.1.2 Definition .........................................................................................................................................12-2 12.1.3 Benefits ............................................................................................................................................12-3 12.2 Availability ................................................................................................................................................12-3 12.2.1 Requirements for NEs......................................................................................................................12-3 12.2.2 Requirements for License ................................................................................................................12-3 12.2.3 Applicable Version ...........................................................................................................................12-3 12.3 Working Principle......................................................................................................................................12-4 12.3.1 MS-Originated Call (Early Assignment)..........................................................................................12-4 12.3.2 MS-Originated Call (Late Assignment) ...........................................................................................12-5 12.3.3 MS-Terminated Call (Early Assignment).........................................................................................12-6 12.4 Service Flow..............................................................................................................................................12-9 12.4.1 Early Resource Assignment for the Caller .......................................................................................12-9 12.4.2 Late Resource Assignment for the Caller....................................................................................... 12-11 12.4.3 Early Resource Assignment for the Callee.....................................................................................12-13 12.4.4 Late Resource Assignment for the Callee ......................................................................................12-15 12.5 Data Configuration..................................................................................................................................12-17 12.5.1 MSOFTX3000 Data Configuration................................................................................................12-17 12.5.2 HLR Data Configuration................................................................................................................12-18 12.5.3 UMG8900 Data Configuration ......................................................................................................12-18 12.5.4 Examples........................................................................................................................................12-18 12.6 Service Management ...............................................................................................................................12-21 12.6.1 Querying the Resource Assignment Mode.....................................................................................12-21 12.6.2 Changing the Resource Assignment Mode ....................................................................................12-22 12.7 Charging and CDR ..................................................................................................................................12-22 12.8 Service Interaction ..................................................................................................................................12-22 12.9 Reference ................................................................................................................................................12-23 12.9.1 Protocols and Specifications ..........................................................................................................12-23 12.9.2 Acronyms and Abbreviations .........................................................................................................12-23
Issue 02 (2007-06-10)
Figures
Figures
Figure 12-1 MS-originated call (early assignment)..........................................................................................12-4 Figure 12-2 MS-originated call (late assignment) ............................................................................................12-5 Figure 12-3 MS-terminated call (early assignment) .........................................................................................12-6 Figure 12-4 MS-terminated call (late assignment) ...........................................................................................12-8 Figure 12-5 Early resource assignment for the caller .....................................................................................12-10 Figure 12-6 Late resource assignment for the caller ......................................................................................12-12 Figure 12-7 Early resource assignment for the callee.....................................................................................12-14 Figure 12-8 Late resource assignment for the callee ......................................................................................12-16
ii
Issue 02 (2007-06-10)
Tables
Tables
Table 12-1 Requirement for NEs ......................................................................................................................12-3 Table 12-2 Applicable versions.........................................................................................................................12-3
Issue 02 (2007-06-10)
iii
12 Early and Late Assignment Feature
12
Section
Early and Late Assignment Feature
About This Chapter

12.1 Service Description 12.2 Availability
12.3 Working Principle 12.4 Service Flow 12.5 Data Configuration 12.6 Service Management 12.7 Charging and CDR 12.8 Service Interaction 12.9 Reference
Issue 02 (2007-06-10)
12-1

Name Early and Late Assignment of Resources for Mobile Subscribers Code WMFD-161100
12.1.2 Definition
Resource assignment refers to the process of wireless resource allocation in call establishment. There are two modes of assignments in call establishment, that is, early assignment and late assignment. The definitions of the two modes of assignments at the caller side are as follows: Name Early assignment Late assignment Definition In the call establishment, after sending the Call Proceeding message to the caller, the MSC server allocates traffic channels for the caller before routing the call to the network where the callee resides. In the call establishment, after sending the Call Proceeding message to the caller, the MSC server allocates traffic channels for the caller after routing the call to the network where the callee resides. Usually, the network resources are allocated after the MS of the callee rings.
The definitions of the two modes of assignments at the callee side are as follows: Name Early assignment Late assignment Definition The MSC server allocates the traffic channels for the subscriber after receiving the Call Confirmed message. Through the Setup message, the MSC server notifies the callee that the traffic channels are allocated in Late assignment mode. Then the callee sends the Call Confirmed message and then immediately the Alerting message to the MSC server. The MSC server determines when to allocate the traffic channels. Usually, the traffic channels are allocated after the callee sends the Connect message.
12-2
Issue 02 (2007-06-10)
12.1.3 Benefits
Beneficiary Operator Description Late assignment can help to save the air interface resources. For example, if a subscriber dials the wrong number and immediately terminates the call, the MSC server needs not to allocate air interface resources for the subscriber. The operator can utilize well the air interface resources based on the actual assignment modes of each location area or service area. Early assignment can help to reduce the wait time of the subscribers and improve the call completion rate.
Subscriber
12.2 Availability
The function is implemented through the cooperation of NodeB, RNC, and CN, as shown in Table 12-1. Table 12-1 Requirement for NEs UE/ MS NodeB /BTS RNC/ BSC MSC Server MGW SGSN GGSN VLR HLR
The symbol represents that the NEs are involved.

Early and late assignment is a basic service. A license is not required.
12.2.3 Applicable Version

The applicable HUAWEI CS product versions are shown in Table 12-2. Table 12-2 Applicable versions Product MSC Server MGW MSOFTX3000 UMG8900 Applicable Version V100R002 and later versions V100R002 and later versions
Issue 02 (2007-06-10)
12-3

The MSOFTX3000 supports both early and late assignments. The two assignment modes are both implemented by configuring the information table of the local location area or service area. In the call establishment, the MSOFTX3000 determines that the assignment mode of the call is early or late assignment by querying the information table of the location area or the service area. The assignment mode for some special services, for example, emergency calls and data services, is early assignment.
12.3.1 MS-Originated Call (Early Assignment)

Figure 12-1 illustrates the MS-originated call flow for early assignment. Figure 12-1 MS-originated call (early assignment)
MS/UE Channel Request Immediate Assignment CM Service Request Authentication Request Authentication Response Cipher Mode Command Cipher Mode Complete Setup Call Proceeding Assignment Command Assignment Complete Alerting Connect Connect Acknowledge Network
The call flow for early assignment is as follows: 1. 2. 3. 4. The MS sends the Channel Request message. The BSC/RNC requests the RR channel to be allocated through the Immediate Assignment message. The MS requests the MM channel to be allocated through the CM Service Request message. The MSC server starts the authentication flow when the MM channel is being established. (optional)
12-4
Issue 02 (2007-06-10)
5. 6. 7.
The MSC server starts the encryption flow when the MM channel is being established. (optional) After the MM channel is allocated, the MS sends the Setup message to the MSC server to request the call to be established. The MSC server determines that the assignment mode is early assignment by querying the information table of the location area and then returns the Call Proceeding message to the MS. The MSC server sends the assignment request and begins the traffic channel allocation. After the MS of the callee rings, the MSC server sends the Alerting message together with the progress indicator cell to the MS of the caller to indicate the MS to tune to the allocated channel.
8. 9.
10. The ring back tone is provided by the MSC server. 11. After the callee answers the call, the conversation between the two parties begins and the MS-originated call is established successfully.
12.3.2 MS-Originated Call (Late Assignment)

Figure 12-2 illustrates the MS-originated call flow for late assignment. Figure 12-2 MS-originated call (late assignment)
MS/UE Channel Request Immediate Assignment CM Service Request Authentication Request Authentication Response Cipher Mode Command Cipher Mode Complete Setup Call Proceeding Alerting Assignment Command Assignment Complete Network
Connect Connect Acknowledge
The MS-originated call flow for late assignment is as follows:
Issue 02 (2007-06-10)
12-5
1. 2. 3. 4. 5. 6. 7.
The MS sends the Channel Request message. The BSC/RNC requests the RR channel to be allocated through the Immediate Assignment message. The MS requests the MM channel to be allocated through the CM Service Request. The network starts the authentication flow when the call is being established. (optional) The MSC server starts the encryption flow when the MM channel is being established. (optional) After the MM channel is allocated, the MS sends the Setup message to MSC server to request the call to be established. The MSC server determines that the assignment mode is late assignment by querying the information table of the location area and then returns the Call Proceeding message to the MS. After the phone of the callee rings, the MSC server sends the Alerting message to the MS of the caller. The MSC server delivers the Assignment request to request the traffic channel to be allocated. After the traffic channel is allocated, the MSC server plays the ring back tone to the MS.
8. 9.
10. After the callee answers the call, the MS tunes to the traffic channel and the MS-originated call is established.
12.3.3 MS-Terminated Call (Early Assignment)

Figure 12-3 illustrates the MS-terminated call flow for early assignment. Figure 12-3 MS-terminated call (early assignment)
MS/UE Paging Channel Request Immediate Assignment Paging Response Authentication Request Authentication Response Cipher Mode Command Cipher Mode Complete Setup Call Confirmed Assignment Command Assignment Complete Alerting Connect Connect Acknowledge Network
12-6
Issue 02 (2007-06-10)
The MS-terminated call flow for early assignment is as follows: 1. 2. 3. 4. 5. 6. 7. 8. The network sends the Paging message to request the call to be established. After detecting that it is the target MS by checking the IMSI/TMSI, the MS sends the Channel Request message to the network side. The BSC/RNC requests the RR channel to be allocated through the Immediate Assignment message. After the RR channel is allocated, the MS sends the Paging Response message to the network side. The MSC server begins to allocate the MM channel. The network starts the authentication flow when the call is being established. (optional) The MSC server starts the encryption flow when the MM channel is being established. (optional) After the MM channel is allocated, the MSC server determines that the assignment mode is early assignment by querying the information table of the location area and then sends the Setup message to request the call to be established. The MS sends the Call Confirmed message to the network.
9.
10. The MSC server begins to allocate the network resources after receiving the Call Confirmed message 11. The MS sends the Alerting message to the network only after the traffic channel is allocated successfully. 12. The mobile-terminated call is established successfully after the callee answers the call.
MS-Terminated Call (Late Assignment)

Figure 12-4 illustrates the MS-terminated call flow for late assignment.
Issue 02 (2007-06-10)
12-7
Figure 12-4 MS-terminated call (late assignment)

MS/UE Network
Paging Channel Request Immediate Assignment Paging Response Authentication Request Authentication Response Cipher Mode Command Cipher Mode Complete Setup Call Confirmed Alerting Connect Assignment Command Assignment Complete
Connect Acknowledge
The MS-terminated call flow for late assignment is as follows: 1. 2. 3. 4. 5. 6. 7. 8. The network sends the Paging message to request the call to be established. After detecting that it is the target MS by checking the IMSI/TMSI, the MS sends the Channel Request message to the network side. The BSC/RNC requests the RR channel to be allocated through the Immediate Assignment message. After the RR channel is allocated, the MS sends the Paging Response message to the network side. The MSC server begins to allocate the MM channel. The network starts the authentication flow when the call is being established. (optional) The MSC server starts the encryption flow when the MM channel is being established. (optional) After the MM channel is allocated, the MSC server determines that the assignment mode is late assignment by querying the information table of the location area and then sends the Setup message to request the call to be established. The MSC server notifies the MS that the assignment mode is late assignment by the Setup message. The callee sends the Call Confirmed message to the MSC server.
9.
12-8
Issue 02 (2007-06-10)
10. The callee sends immediately the Alerting message to the MSC server. 11. The callee sends the Connect message to the MSC server. 12. The MSC server delivers the assignment request after receiving the Connect message. 13. After the network resources are allocated for the callee, the MSC server sends the Connect Acknowledge message to the callee and the call is established successfully.
12.4 Service Flow

This section describes the early and late assignment flow by taking an intra-office call as example. The authentication and encryption processes are optional. You can determine whether to start the processes by configuring system data. Therefore, the two processes are not included in the following flow chart.
12.4.1 Early Resource Assignment for the Caller

Figure 12-5 illustrates the flow of early resource assignment for the caller.
Issue 02 (2007-06-10)
12-9
Figure 12-5 Early resource assignment for the caller

MS/UE BSS/RNC MSC-O/VLR HLR MSC-T/VLR
CM Service Request CM Service Request
CM Service Accept
CM Service Accept
Setup Call Proceeding
Send Routing Information
Provide Roaming Number Provide Roaming Number Acknowledge
Send Routing Info Acknowledge Alllocate Channel Assignment Command Assignment Complete Allocate Complete
Alerting Connect
Connect Acknowledge
The flow of early resource assignment for the caller is as follows: 1. 2. 3. 4. 5. 6. 7. 8. The MS sends the CM Service Request message to the MSC-O through the BSS. The MSC-O sends the CM Service Accept message to the MS through the BSS to indicate that the request is accepted. After receiving the CM Service Accept message, the MS sends the Setup message to the MSC-O through the BSS. The MSC-O sends the Call Proceeding message to the MS. The MSC-O requests routing information of the callee from the HLR. The HLR requests the roaming number of the callee from the MSC/VLR where the callee resides. The VLR provides the roaming number of the callee to the HLR. The HLR provides the routing information of the callee to the MSC-O.
12-10
Issue 02 (2007-06-10)
9.
The MSC-O requests the BSS to allocate the channel and the BSS sends the assignment request to the MS.
10. After the channel is allocated, the MS sends the Assignment Complete message to the BSS and the BSS sends the Allocation Complete message to the MSC-O to indicate that the assignment is complete. 11. The MSC-O sends the Alerting message to the MS to indicate that the MS of the callee is ringing. 12. The MSC-O sends the Connect message to the MS to indicate that the callee has answered the call. 13. The MS sends the Connect Acknowledge message to the MSC-O and the call is established.
12.4.2 Late Resource Assignment for the Caller

Figure 12-6 illustrates the flow of late resource assignment for the caller.
Issue 02 (2007-06-10)
12-11
Figure 12-6 Late resource assignment for the caller

MS/UE BSS/RNC MSC-O/VLR HLR MSC-T/VLR
CM Service Request CM Service Request
CM Service Accept
CM Service Accept
Setup Call Proceeding
Send Routing Information
Provide Roaming Number Provide Roaming Number Acknowledge
Send Routing Info Acknowledge Alerting
Alllocate Channel Assignment Command Assignment Complete Allocate Complete Progress Connect Connect Acknowledge
The flow of late resource assignment for the caller is as follows: 1. 2. 3. 4. 5. 6. 7. 8. The MS sends the CM Service Request message to the MSC-O through the BSS. The MSC-O sends the CM Service Accept message to the MS through the BSS to indicate that the request is accepted. After receiving the CM Service Accept message, the MS sends the Setup message to the MSC-O through the BSS. The MSC-O sends the Call Proceeding message to the MS. The MSC-O requests routing information of the callee from the HLR. The HLR requests the roaming number of the callee from the MSC/VLR where the callee resides. The VLR provides the roaming number of the callee to the HLR. The HLR provides the routing information of the callee to the MSC-O.
12-12
Issue 02 (2007-06-10)
9.
The MSC-O sends the Alerting message to the MS to indicate that the MS of the callee is ringing.
10. The MSC-O requests the BSS to allocate the channel and the BSS sends the assignment request to the MS. 11. After the channel is allocated, the MS sends the Assignment Complete message to the BSS and the BSS sends the Allocation Complete message to the MSC-O to indicate that the assignment is complete. 12. The MSC-O sends the Progress message to the MS to indicate that the assignment is complete. 13. The MSC-O sends the Connect message to the MS to indicate that the callee has answered the call. 14. The MS sends the Connect Acknowledge message to the MSC-O and the call is established.
12.4.3 Early Resource Assignment for the Callee

Figure 12-7 illustrates the flow of early resource assignment for the callee.
Issue 02 (2007-06-10)
12-13
Figure 12-7 Early resource assignment for the callee

MSC/VLR BSS MS
Paging Paging
Channel Request
Immediate Assignment Paging Response Paging Response
Setup Call Confirmed
Allocate Channel Assignment Command Assignment Complete Allocate Complete
Alerting Connect
Connect Acknowledge
The flow of early resource assignment for the callee is as follows: 1. If no wireless connection is set up between the network and the callee, the MSC delivers the Paging message to the BSS and the BSS broadcasts the Paging message through the paging channel. After detecting that it is being paged, the MS sends the Channel Request message to the BSS to request a channel. The BSS returns the Immediate Assignment message to notify the MS to use a dedicated signaling channel. The MS sends the Paging Response message through the channel to the BSS and the BSS sends the Paging Response message to the MSC. The MSC sends the Setup message to the MS.
2.
3. 4.
12-14
Issue 02 (2007-06-10)
5. 6. 7.
The MS returns the Call Confirmed message to the MSC after receiving the Setup message. The MSC requests the BSS to allocate the channel after receiving the Call Confirmed message and the BSS sends the assignment request to the MS. After the assignment is complete, the MS sends the Assignment Complete message to the BSS and the BSS sends the Allocation Complete message to the MSC to indicate that the assignment is complete. The MS sends the Alerting message to the MSC to indicate that the MS of the callee is ringing. After the callee has answered the call, the MS sends the Connect message to the MSC.
8. 9.
10. The MSC sends the Connect Acknowledge message to the MS and the call is established.
12.4.4 Late Resource Assignment for the Callee

Figure 12-8 illustrates the flow of late resource assignment for the callee.
Issue 02 (2007-06-10)
12-15
Figure 12-8 Late resource assignment for the callee

MSC/VLR BSS MS
Paging Paging
Channel Request
Immediate Assignment Paging Response Paging Response
Setup Call Confirmed Alerting Connect
Allocate Channel Assignment Command Assignment Complete Allocate Complete Connect Acknowledge
The flow of late resource assignment for the callee is as follows: 1. If there is no wireless connection between the network and the callee, the MSC delivers the Paging message to the BSS and the BSS broadcasts the Paging message through the paging channel. After detecting that it is being paged, the MS sends the Channel Request message to the BSS to request for a channel. The BSS returns the Immediate Assignment to indicate the MS to use a dedicated signaling channel. The MS sends the Paging Response message through the channel to the BSS and the BSS sends the Paging Response message to the MSC. The MSC sends Setup message to the MS.
2.
3. 4.
12-16
Issue 02 (2007-06-10)
5. 6. 7. 8. 9.
The MS returns the Call Confirmed message to the MSC after receiving the Setup message. The MS sends the Alerting message to the MSC to indicate that the MS of the callee is ringing. After the callee has answered the call, the MS sends the Connect message to the MSC. The MSC requests the BSS to allocate the channel and the BSS sends the Assignment request to the MS. After the assignment is complete, the MS sends the Assignment Complete message to the BSS and the BSS sends the Allocation Complete message to the MSC to indicate that the assignment is complete.
10. The MSC sends the Connect Acknowledge message to the MS and the call is established.

12.5.1 MSOFTX3000 Data Configuration
For 2G network, the assignment mode is configured when the GCI is being added. The steps are as follows: Step 1 Use the LST INOFFMSC command to check if the local MSC and the VLR numbers are configured. If they are not configured, use the SET INOFFMSC command to configure the local MSC and VLR numbers. Step 2 Use LST BSC command to check if the BSC that the cell belongs to and its destination signaling point code are configured. If they are not configured, use the ADD BSC command to add the BSC and its destination signaling point code. Step 3 Use the LST CALLSRC command to check if the call source code corresponding with the cell is configured. If it is not configured, use the ADD CALLSRC command to add the source code for the cell. Step 4 Use the LST OFC command to check if the office direction number is configured for the BSC that the cell belongs to. If it is not configured, use the ADD OFC command to add the office direction number for the BSC that the cell belongs to. Step 5 Use the LST LAIGCI command to check if the LAI that the cell belongs to is configured. If it is not configured, use the ADD LAIGCI command to add the LAI that the cell belongs to. (Configure the parameters based on the information obtained in the preceding query and set the location area type to LAI.) Step 6 Use the ADD LAIGCI command to add a cell and set the assignment type of the cell. (Configure the parameters based on the information obtained in the preceding query and select GCI for the location area type.) ----End
Issue 02 (2007-06-10)
12-17
For 3G network, the assignment mode is configured when the SAI is being added. The steps are as follows: Step 1 Use the LST INOFFMSC command to check if the MSC and the VLR numbers of the local office are configured. If they are not configured, use the SET INOFFMSC command to configure them. Step 2 Use the LST RNC command to check if the RNC that the cell belongs to is configured. If it is not configured, use the ADD RNC command to add the RNC and its destination signaling point code. Step 3 Use the LST CALLSRC command to check if the call source code of the cell is configured. If it is not configured, use the ADD CALLSRC command to add the call source code corresponding with the cell. Step 4 Use the LST OFC command to check if the office direction number of the RNC that the cell belongs to is configured. If it is not configured, use the ADD OFC command to add the office direction number of the RNC that the cell belongs to. Step 5 Use the LST LAISAI command to check if the LAI that the cell belongs to is configured. If it is not configured, use the ADD LAISAI command to add the LAI that the cell belongs to. (Configure the parameters based on the information obtained in the preceding query and set the location area type as LAI.) Step 6 Use the ADD LAISAI command to add a cell and set the assignment type of the cell. (Configure the parameters based on the information obtained in the preceding query and set the location area type as SAI.) ----End
12.5.2 HLR Data Configuration

None.
12.5.3 UMG8900 Data Configuration

None.
12.5.4 Examples
Case 1
In the following environment: Network: 2G Local MSC number: 8613600004 VLR number: 8613600004 Call source name: CS-1
12-18
Issue 02 (2007-06-10)
Add a cell with the following attributes: Assignment mode: late assignment BSC name: BSC-1 Destination signaling point code: C01 Other parameters: default values
Script
The step to add the 2G cell is as follows: Step 1 Add a 2G location area. Description To add a 2G location area with the following attributes: Global cell ID: 460000001 MSC number: 8613600004 VLR number: 8613600004 Location area category: LAI Home BSC DPC: C01 Call source name: CS-1 Script ADD LAIGCI: GCI="460000001", LAIGCINAME="BSC1-LAI", MSCN="8613600004", VLRN="8613600004", LAICAT=LAI, LAIT=HVLR, BSCDPC1="C01", CSNAME="CS-1";
Step 2 Add a 2G cell. Description To add a 2G cell with the following attributes: Global cell ID: 4600000010001 MSC number: 8613600004 VLR number: 8613600004 Location area category: GCI Early assignment flag: LATEASN Home BSC DPC: C01 Call source name: CS-1 Script ADD LAIGCI:GCI="4600000010001",LAIGCINAME="BSC1-GCI", MSCN="8613600004", VLRN="8613600004", LAICAT=GCI, LAIT=HVLR, ISEARASN=LATEASN, BSCDPC1="C01", CSNAME="CS-1"; The ISEARASN parameter is valid only when the value of the LAICAT parameter is GCI.
Description
----End
Issue 02 (2007-06-10)
12-19
Case 2
In the following environment: Network: 3G Local MSC ID: 8613600004 VLR number: 8613600004 Call source name: CS-1 Add a 3G service area with the following attributes: Assignment mode: early assignment RNCID: 1 Other parameters: default values
Script
The step to add the 3G cell is as follows: Step 1 Add the information of the 3G location area. Description To add a 3G location area with the following attributes: Service area number: 460000001 MSC number: 8613600004 VLR number: 8613600004 Location area category: LAI RNC ID: 1 Call source name: CS-1 Script ADD LAISAI: SAI="460000001", LAISAINAME="RNC1-LAI", MSCN="8613600004", VLRN="8613600004", LAICAT=LAI, LAIT=HVLR, RNCID1=1, CSNAME="CS-1";
Step 2 Add the information of the 3G service area.
12-20
Issue 02 (2007-06-10)
Description
To add a 3G service area with the following attributes: Service area number: 4600000010001 MSC number: 8613600004 VLR number: 8613600004 Service area category: SAI Early assignment flag: EARLYASN RNC ID: 1 Call source name: CS-1
Script
ADD LAISAI: SAI="4600000010001", LAISAINAME="RNC1-SAI", MSCN="8613600004", VLRN="8613600004", LAICAT=SAI, LAIT=HVLR, ISEARASN=EARLYASN, RNCID1=1, CSNAME="CS-1"; The ISEARASN parameter is valid only when the value of the LAICAT parameter is SAI.
Description
----End

12.6.1 Querying the Resource Assignment Mode
2G Network
To query the resource assignment mode of a specified cell, perform the following steps: Step 1 Enter the LST LAIGCI command in the command line window of the LMT. Step 2 Enter the ID of the cell to be queried in the Global cell ID field. Step 3 Press F9 or click ----End If you want to query the assignment modes of all the cells, skip step 2. .
3G Network
To query the resource assignment mode of a specified service area, perform the following steps: Step 1 Enter the LST LAISAI command in the command line window of the LMT. Step 2 Enter the number of the service area to be queried in the SAI field. Step 3 Press F9 or click ----End .
Issue 02 (2007-06-10)
12-21
If you want to query the assignment modes of all the service areas, skip step 2.
12.6.2 Changing the Resource Assignment Mode

2G Network
To change the resource assignment mode of a specified cell, perform the following steps: Step 1 Enter the MOD LAIGCI command in the command line window of the LMT. Step 2 Enter the ID of the cell to be modified in the Global cell ID field. Step 3 Enter the MSC ID of the location area to be modified in the MSC number of the LA cell field. Step 4 Set the Location area type to Local VLR. Step 5 Set the Early assignment flag to the required mode. Step 6 Press F9 or click ----End .
3G Network
To change the resource assignment mode of a specified service area, perform the following steps: Step 1 Enter the MOD LAISAI command in the command line window of the LMT. Step 2 Enter the number of the service area to be modified in the 3G service area number field. Step 3 Enter the MSC number of the 3G service area to be modified in the MSC number of 3G service area field. Step 4 Set the 3G service area type to Local VLR. Step 5 Set the Early assignment flag to the required mode. Step 6 Press F9 or click ----End .

None.

The setting of the resource assignment type has no effect on the supplementary services.
12-22
Issue 02 (2007-06-10)
12.9 Reference
None.

Acronyms
None.
Abbreviations
Abbreviation BSC BSS HLR IMSI MM MS MSC RNC RR TMSI VLR Full Name Base Station Controller Base Station Subsystem Home Location Register International Mobile Station Identity Mobility Management Mobile Station Mobile Switching Center Radio Network Controller Radio Resource management Temp Mobile Subscriber Identifier Visitor Location Register
Issue 02 (2007-06-10)
12-23
Contents
Contents
13 IN Service Triggering Feature .............................................................................................13-1
13.1 Service Description ...................................................................................................................................13-2 13.1.1 Function Code..................................................................................................................................13-2 13.1.2 Definition .........................................................................................................................................13-2 13.1.3 Benefits ............................................................................................................................................13-2 13.2 Availability ................................................................................................................................................13-3 13.2.1 Requirement for NEs .......................................................................................................................13-3 13.2.2 Requirement for License..................................................................................................................13-3 13.2.3 Applicable Versions..........................................................................................................................13-3 13.3 Working Principle......................................................................................................................................13-3 13.4 Service Flow............................................................................................................................................13-10 13.5 Data Configuration..................................................................................................................................13-10 13.5.1 Data Configuration for MSOFTX3000 ..........................................................................................13-10 13.5.2 Data Configuration for HLR9820 ..................................................................................................13-10 13.5.3 Data Configuration for UMG8900.................................................................................................13-10 13.5.4 Example ......................................................................................................................................... 13-11 13.6 Service Management ...............................................................................................................................13-14 13.7 Charging and CDR ..................................................................................................................................13-14 13.8 Service Interaction ..................................................................................................................................13-14 13.9 References ...............................................................................................................................................13-15 13.9.1 Specifications.................................................................................................................................13-15 13.9.2 Acronyms and Abbreviations .........................................................................................................13-15
Issue 02 (2007-06-10)
Figures
Figures
Figure 13-1 Triggering IN service (T-CSI).......................................................................................................13-4 Figure 13-2 Routing out the call directly to another office (T -CSI) ................................................................13-5 Figure 13-3 Ignoring IN service (T-CSI)..........................................................................................................13-6 Figure 13-4 Triggering IN service (early forwarding with O-CSI) ..................................................................13-7 Figure 13-5 Routing out the call directly to another office (early forwarding with O-CSI).............................13-8 Figure 13-6 Ignoring IN service (early forwarding with O-CSI) .....................................................................13-9
ii
Issue 02 (2007-06-10)
Tables
Tables
Table 13-1 Name and function code of the IN service triggering.....................................................................13-2 Table 13-2 Processing modes of the IN services ..............................................................................................13-2 Table 13-3 NEs related to the IN service triggering .........................................................................................13-3 Table 13-4 Versions that support the IN service triggering...............................................................................13-3
Issue 02 (2007-06-10)
iii
13 IN Service Triggering Feature
13
About This Chapter
IN Service Triggering Feature
13.3 Working Principle 13.4 Service Flow 13.5 Data Configuration 13.6 Service Management 13.7 Charging and CDR 13.8 Service Interaction 13.9 References
Issue 02 (2007-06-10)
13-1

Table 13-1 lists the name and function code of the IN service triggering. Table 13-1 Name and function code of the IN service triggering. Name CAMEL phase2 CAMEL phase3 Code WMFD-150100 WMFD-150200 Applicable Versions V100R005
13.1.2 Definition
If MSOFTX3000 is adopted in the GMSC/SSP networking, and if the SCP interconnected with the MSOFTX3000 uses private INAP protocol, the MSOFTX3000 fails to trigger the intelligent service (IN service ) when processing IN calls of the IN service subscribers (the subscribers who subscribe to the IN service s in the HLR). To solve this problem, the MSOFTX3000 uses three modes to process the IN service s, as shown in Table 13-2. Table 13-2 Processing modes of the IN services Processing Mode Triggering IN service Routing out the call directly to another office Ignoring IN service Indication The MSOFTX3000 triggers the IN service in the O-CSI or T-CSI mode. The MSOFTX3000 does not trigger IN service and connects the call to the MSC/SSP that can trigger the IN service normally. The connected to MSC/SSP triggers the IN service. The MSOFTX3000 does not trigger IN service and connects the call as an ordinary call.
The carrier can determine the processing mode based on the actual situation.
The IN service triggering feature is supported only by the GMSC and TMSC.
13.1.3 Benefits
Beneficiary Carrier Mobile subscriber Description The carrier can control the IN service s more flexibly, thus the competitiveness of the carriers is highly enhanced. The subscribers can enjoy the IN services.
13-2
Issue 02 (2007-06-10)
13.2 Availability
The IN service triggering feature requires the corporation of the SCP and CN. Table 13-3 lists the NEs related with the IN service triggering. Table 13-3 NEs related to the IN service triggering UE Node B RNC MSC Server MGW SGSN VLR HLR SCP
"" stands for the related NEs.

The IN service triggering is an optional feature of the Huawei wireless core network. You can obtain this service without any license.

Table 13-4 lists the Huawei CS product versions that support the IN service triggering. Table 13-4 Versions that support the IN service triggering Product MSC server MGW MSOFTX3000 UMG8900 Applicable Versions V100R005 and the later versions V100R005 and the later versions

After the MSOFTX3000 obtains IN service data from the HLR, it queries the IN service control data table, and then processes the IN call based on the query results. The MSOFTX3000 has the following processing modes: Triggering IN Service (T-CSI) Routing Out the Call Directly to Another Office (T-CSI) Ignoring IN Service (T-CSI) Triggering IN Service (Early Forwarding With O-CSI) Routing Out the Call Directly to Another Office (Early Forwarding with O-CSI) Ignoring IN Service (Early Forwarding With O-CSI)
Issue 02 (2007-06-10)
13-3
Triggering IN Service (T-CSI)

If the call is an IN call of the MT type, and if the T-CSI subscription information is contained in the subscription data of the called party, the MSOFTX3000 triggers the IN service in the T-CSI mode. The call procedure is as shown in Figure 13-1. Figure 13-1 Triggering IN service (T-CSI)
GMSC (MSOFTX3000) 1.IAM 2.SRI 3.SRI_ACK(TCSI) 4. Query IN service control data table 5.IDP(DP12)
VMSCa
HLR
SCP
VMSCb
6. IN service triggering flow 7.SRI 8.SRI_ACK(MSRN) 9.IAM 10.ACM 11.ACM
12.
Call process
The call procedure is as follows: 1. 2. 3. 4. 5. 6. 7. The GMSC receives the IAM message from the VMSC of the calling party. The GMSC sends the SRI message to the HLR of the called party. The HLR responses the SRI_ACK message to the GMSC. The SRI_ACK contains the T-CSI subscription information of the called party. The GMSC queries the IN service control data table. The query result is "Triggering IN service ". The GMSC sends the IDP (IDP12) message to the SCP to of the called party according to the SCP address in the T-CSI subscription data. The SCP of the called triggers the IN service after receiving the IDP message. The IN service triggering process completes. The GMSC sends for the second time the SRI message to the HLR of the called party. The SRI message contains the suppression T-CSI cell.
13-4
Issue 02 (2007-06-10)
8. 9.
The HLR responses the SRI_ACK to the GMSC. The SRI_ACK contains the MSRN number of the called party. The GMSC sends the IAM message to the VMSC of the called party according to the MSRN number of the called party.
10. The VMSC of the called party responses an ACM message to the GMSC. 11. The GMSC responses the ACM message to the VMSC of the calling party. 12. The call is established.
Routing Out the Call Directly to Another Office (T-CSI)

If the call is an IN call of the MT type, and if the T-CSI subscription information is contained in the subscription data of the called party, the MSOFTX3000 does not trigger the IN service and connects the call to the MSC/SSP which can trigger the IN service normally. The call procedure is as shown in Figure 13-2. Figure 13-2 Routing out the call directly to another office (T -CSI)
VMSCa 1.IAM 2.SRI 3.SRI_ACK(TCSI) 4. Query the IN service control data table 5IAM 6.ACM 7.ACM GMSC HLR MSC/SSP
8. Call process
The call procedure is as follows: 1. 2. 3. 4. 5. 6. 7. The GMSC receives the IAM message from the VMSC of the calling party. The GMSC sends the SRI message to the HLR of the called party. The HLR responses the SRI_ACK message to the GMSC. The SRI_ACK contains the T-CSI subscription information of the called party. The GMSC queries the IN service control data table. The query result is "Routing out the call directly to another office". The GMSC sends an IAM message to the MSC/SSP according to the MSC/SSP routing information in the IN service control data table. The MSC/SSP responses the ACM message to the GMSC. The GMSC responses the ACM message to the VMSC of the calling party.
Issue 02 (2007-06-10)
13-5
8.
The call is established.
Ignoring IN Service (T-CSI)

If the call is an IN call of the MT type, and if the T-CSI subscription information is contained in the subscription data of the called party, the MSOFTX3000 does not trigger the IN service and connects the call as an ordinary call. The call procedure is as shown in Figure 13-3. Figure 13-3 Ignoring IN service (T-CSI)
VMSCa 1.IAM
GMSC
HLR
SCP
VMSCb
2.SRI 3.SRI_ACK(TCSI) 4. Query the IN service control data table 5.SRI 6.SRI_ACK(MSRN) 7.IAM 8.ACM 9.ACM 10. Call process
1. 2. 3. 4. 5. 6. 7. 8. 9.
The GMSC receives the IAM message from the VMSC of the calling party. The GMSC sends the SRI message to the HLR of the called party. The HLR responses the SRI_ACK message to the GMSC. The SRI_ACK contains the T-CSI subscription information of the called party. The GMSC queries the IN service control data table. The query result is "Ignoring IN service ". The GMSC sends for the second time the SRI message to the HLR of the called party. The SRI message contains the suppression T-CSI cell. The HLR responses the SRI_ACK to the GMSC. The SRI_ACK contains the MSRN number of the called party. The GMSC sends the IAM message to the VMSC of the called party according to the MSRN number of the called party. The VMSC of the called party responses an ACM message to the GMSC. The GMSC responses the ACM message to the VMSC of the calling party.
10. The call is established.
13-6
Issue 02 (2007-06-10)
Triggering IN Service (Early Forwarding With O-CSI)

If the call is an IN call of the MF type, and if the called party subscribes to the call forwarding service and the O-CSI service, the MSOFTX3000 triggers the IN service in the O-CSI mode. The call procedure is as shown in Figure 13-4. Figure 13-4 Triggering IN service (early forwarding with O-CSI)
VMSCa 1.IAM
GMSC
HLR
SCP
VMSCb
2.SRI 4. Query the IN servie control data table 3.SRI_ACK (early forwarding with O-CSI)
5. Call forwarding flow 6.IDP(DP2)
7.
IN service triggering flow 8.SRI 9.SRI_ACK(MSRN) 10.IAM 11.ACM
12.ACM
13.
Call process
The call procedure is as follows: 1. 2. 3. The GMSC receives the IAM message from the VMSC of the calling party. The GMSC sends the SRI message to the HLR of the called party. The HLR responses the SRI_ACK message to the GMSC. The SRI_ACK contains the call forwarding subscription information and the O-CSI subscription information of the called party. The GMSC queries the IN service control data table. The query result is "Triggering IN service ". The GMSC launches call forwarding according to the call forwarding subscription information of the called party. The GMSC sends the IDP (DP2) message to the SCP of the called party according to the SCP address in the O-CSI subscription information.
4. 5. 6.
Issue 02 (2007-06-10)
13-7
7. 8. 9.
The SCP triggers the IN service after receiving the IDP message. The IN service triggering process completes. The GMSC sends an SRI message to the HLR of the forwarded-to party. The HLR of the forwarded-to party responses an SRI_ACK to the GMSC. The SRI_ACK contains the MSRN number of the forwarded-to party.
10. The GMSC sends an IAM message to the VMSC of the forwarded-to party according to the MSRN number of the forwarded-to party. 11. The VMSC of the forwarded-to party responses the ACM message to the GMSC. 12. The GMSC responses the ACM message to the VMSC of the calling party. 13. The call is established.
Routing Out the Call Directly to Another Office (Early Forwarding with O-CSI)
If the call is an IN call of the MF type, and if the called party subscribes to the call forwarding service and the O-CSI service, the MSOFTX3000 does not trigger the IN service and connects the call to the MSC/SSP which can trigger the IN service normally. The call procedure is as shown in Figure 13-5. Figure 13-5 Routing out the call directly to another office (early forwarding with O-CSI)
VMSCa 1.IAM
GMSC
HLR
MSC/SSP
2.SRI 3.SRI_ACK (early forwarding with O-CSI) 5.IAM 6.ACM 7.ACM
4.
Query the IN service control data table
8.
Call process
1. 2. 3.
The GMSC receives the IAM message from the VMSC of the calling party. The GMSC sends the SRI message to the HLR of the called party. The HLR responses the SRI_ACK message to the GMSC. The SRI_ACK contains the call forwarding subscription information and the O-CSI subscription information of the called party. The GMSC queries the IN service control data table. The query result is "Routing out the call directly to another office".
4.
13-8
Issue 02 (2007-06-10)
5. 6. 7. 8.
The GMSC sends an IAM message to the MSC/SSP according to the MSC/SSP routing information in the IN service control data table. The MSC/SSP responses the ACM message to the GMSC. The GMSC responses the ACM to the VMSC of the calling party. The call is established.
Ignoring IN Service (Early Forwarding With O-CSI)

If the call is an IN call of the MF type, and if and if the called party subscribes to the call forwarding service and the O-CSI service, the MSOFTX3000 does not trigger the IN service and connects the call as an ordinary call. The call procedure is as shown in Figure 13-6. Figure 13-6 Ignoring IN service (early forwarding with O-CSI)
VMSCa 1.IAM
GMSC
HLR
SCP
VMSCb
2.SRI Query the IN service control data table 3.SRI_ACK (early forwarding with O-CSI)
4.
5.Call forwarding flow 6.SRI 7.SRI_ACK(MSRN) 8.IAM 9.ACM 10.ACM 11.Call process
The call procedure is as follows: 1. 2. 3. The GMSC receives the IAM message from the VMSC of the calling party. The GMSC sends the SRI message to the HLR of the called party. The HLR responses the SRI_ACK message to the GMSC. The SRI_ACK contains the call forwarding subscription information and the O-CSI subscription information of the called party. The GMSC queries the IN service control data table. The query result is "Ignoring IN service ". The GMSC launches call forwarding according to the call forwarding subscription information of the called party.
4. 5.
Issue 02 (2007-06-10)
13-9
6. 7. 8. 9.
The GMSC sends an SRI message to the HLR of the forwarded-to party. The HLR of the forwarded-to party responses an SRI_ACK to the GMSC. The SRI_ACK contains the MSRN number of the forwarded-to party. The GMSC sends an IAM message to the VMSC of the forwarded-to party according to the MSRN number of the forwarded-to party. The VMSC of the forwarded-to party responses the ACM message to the GMSC.
10. The GMSC responses the ACM message to the VMSC of the calling party. 11. The call is established.
13.4 Service Flow

No special service flow.

13.5.1 Data Configuration for MSOFTX3000
If MSOFTX3000 is adopted in the GMSC/SSP networking, and if the SCP interconnected with the MSOFTX3000 uses private INAP protocol, the MSOFTX3000 fails to trigger the IN service when handling the IN service subscribers (the subscribers subscribe to the IN service in the HLR). To solve this problem, the operator needs to configure the IN service control data by using the command ADD INSRVCTRL in the following two cases: The carrier requires that the MSOFTX3000 connect the IN calls to MSC/SSP and that the MSC/SSP triggers the IN service. The carrier requires that the MSOFTX3000 connects the calls as ordinary calls (ignores IN service). When configuring the IN service control data, you can configure different processing modes (triggering IN service, routing out the call directly to another office, and ignoring IN service) according to the IN service triggering type, IN service key, and SCP address. You need pay attention that if the operator configures the IN service control data by using the command ADD INSRVCTRL, the charging of the IN service subscribers is affected. Therefore, the operator must be cautious when configuring this data. The operator can execute the command MOD GBILLCTRL to modify the integrated control data of the call detail record (CDR) to avoid any possible conflict between the carrier and the subscribers concerning the charging.
See online help for the descriptions of the parameters of related commands.
13.5.2 Data Configuration for HLR9820

The HLR9820 can provide this service without any extra data configuration.
13.5.3 Data Configuration for UMG8900

The UMG8900 can provide this service without any extra data configuration.
13-10
Issue 02 (2007-06-10)
13.5.4 Example
Scenario 1
In an IN call, assume that: The subscriber data of the called party contains the T-CSI subscription information. The IN service key is 1. The SCP address is 8613977888 and the SCP uses the INAP private protocol. The MSOFTX3000 can not trigger the IN service when processing this call. In this case, the carrier changes the number of the called party and the call is directly transited to another MSC/SSP which triggers the IN service. No CDR is generated for the IN call of the called party. Assume that: The number of the called party is added with a prefix 123. The routing selection name of Routing out the call directly to another office is 10. The routing selection source name 0 has been defined in the call source table. Routing name 0 already exists.
Scripts for Configuration

Step 1 Configure the routing analysis data. Description Configuring the routing analysis data: Routing selection name: 10 Routing selection source name: 0 Routing name: 0 Signaling priority level: constant Script ADD RTANA: RSN="10", RSSN="0", R=0, ISUP=NOCHG;
Step 2 Configure the number conversion data. Description Configuring the number conversion data: Number conversion name: 10 Number conversion type: insert number to designated location Start conversion location: 0 New number: 123 Script ADD DNC: DCN="10", DCT=TYPE1, DCP=0, ND=K'123;
Issue 02 (2007-06-10)
13-11
Step 3 Configure the IN service control data. Description Configuring the IN service control data: IN service triggering type: mobile subscriber as the called party IN service key: 1 SCP address: 8613977888 Processing mode: routing out the call directly to another office New routing selection name: 10 New service feature: other office of the mobile network Conversion name of the number of the called party: 10 Script Note ADD INSRVCTRL: ITT=MT, SK=1, SA=K'8613977888, PT=SR, RSN="10", NSP=MOO, CLDNCN="10"; If the processing is configured as routing out the call directly to another office, you must configure a new routing selective code and assign the correct service feature.
Step 4 Modify the integrated control data of the CDR. Description Modifying the integrated control data of the CDR: Unselect the CDR for IN call of the called party in the CDR control indication. Script Note MOD GBILLCTRL: BCF=AI_MTC-0; If you execute this command, the MSOFTX3000 does not generate a CDR for the IN call of the called party.
----End
Scenario 2
In an IN call, assume that: The subscriber data contains the call forwarding unconditional (CFU) and O-CSI subscription information. The IN service key is 2. The SCP address is 8613977888 and the SCP uses the INAP private protocol. The MSOFTX3000 can not trigger the IN service when processing this call. In this case, the carrier ignores the IN attributes of the call and connects the call as an ordinary call. No CDR is generated for the IN call of CFU.
13-12
Issue 02 (2007-06-10)
Scripts for Data Configuration

Step 1 Configure the IN service control data. Description Configuring the IN service control data: IN service triggering type: call forwarding of the mobile subscriber IN service key: 2 SCP address: 8613977888 Processing mode: ignoring IN service Script ADD INSRVCTRL: ITT=MF, SK=2, SA=K'8613977888, PT=IGNR;
Step 2 Modify the integrated control data of the CDR. Description Script Note Modifying the integrated control data of the CDR: Unselect the CDR for IN call of CFU in the CDR control indication. MOD GBILLCTRL: BCF=AI_CFW-0; If you execute this command, the MSOFTX3000 does not generate a CDR for IN call of CFU.
----End
Scenario 3
In an IN call, assume that: The subscriber data contains the CFU and O-CSI subscription information. The IN service key is 3. The SCP address is 8613977888. The MSOFTX3000 can trigger the IN service normally in the SCP. The carrier triggers the IN service and generates a CDR for the IN call of CFU.
Scripts for Data Configuration

Step 1 Configure the IN service control data. Description Configuring the IN service control data: IN service triggering type: CFU of the mobile subscriber IN service key: 3 SCP address: 8613977888 Processing mode: triggering the IN service Script ADD INSRVCTRL: ITT=MF, SK=3, SA=K'8613977888, PT=TRG;
Issue 02 (2007-06-10)
13-13
Step 2 Modify the integrated control data of the CDR. Description Script Note Modifying the integrated control data of the CDR: Select CDR for IN call forwarding. MOD GBILLCTRL: BCF=AI_CFW-1; If you execute this command, the MSOFTX3000 is restricted to generate a CDR for the IN call of CFU.
----End

None.

If the operator configures the IN service control data by using the command ADD INSRVCTRL, the charging of the IN service subscribers is affected. Therefore, the operator must be cautious when configuring this data. The operator can execute the command MOD GBILLCTRL to modify the integrated control data of the call detail record (CDR) to avoid any possible conflict between the carrier and the subscribers concerning the charging. You can determine whether to generate a CDR for the IN calls when configuring the parameter CDR control indication in the command MOD GBILLCTRL: If CDR for IN call forwarding is selected, and if the IN service is triggered in the O-CSI mode, CDR for IN call forwarding is generated. If CDR for IN call forwarding is not selected, no CDR for IN call forwarding is generated. If CDR for IN Called Party is selected, and if the IN service is triggered in the T-CSI mode, CDR for IN called party is generated. If CDR for IN Called Party is not selected, no CDR for IN called party is generated.

The IN service triggering feature has the following interactions with other services: This IN service triggering feature does not affect the IN service triggering feature of the NCSI. The option Mobile subscriber as the calling party of the IN service triggering type in the IN service control data is not in current use. It is kept for later upgrade.
13-14
Issue 02 (2007-06-10)
13.9 References
13.9.1 Specifications
None.

Acronym ACM HLR IAM IDP INAP MSC O-CSI SCP SSP T-CSI Full Name Address Complete Message Home Location Register Initial Address Message Initial Detection Point Intelligent Network Application Protocol Mobile Switching Center Originating CAMEL Subscription Information Service Control Point Service Switching Point Terminating CAMEL Subscription Information
Issue 02 (2007-06-10)
13-15
Contents
Contents
14 MNP Feature ...........................................................................................................................14-1
14.1 Feature Description ...................................................................................................................................14-2 14.1.1 Feature Code ....................................................................................................................................14-2 14.1.2 Function Definition..........................................................................................................................14-2 14.1.3 Service Benefits ...............................................................................................................................14-2 14.2 Availability ................................................................................................................................................14-3 14.2.1 Related Network Elements...............................................................................................................14-3 14.2.2 License Support ...............................................................................................................................14-3 14.2.3 Version Support................................................................................................................................14-3 14.3 Principle Description.................................................................................................................................14-3 14.3.1 Functions of NEs..............................................................................................................................14-3 14.3.2 System Interior Processing...............................................................................................................14-3 14.4 Service Flows ............................................................................................................................................14-5 14.4.1 QoR Mode........................................................................................................................................14-5 14.4.2 OR Mode..........................................................................................................................................14-6 14.4.3 AcQ Mode........................................................................................................................................14-7 14.5 Data Configuration....................................................................................................................................14-9 14.5.1 Data Configuration on the MSOFTX3000.......................................................................................14-9 14.5.2 Data Configuration on the UMG8900..............................................................................................14-9 14.5.3 Data Configuration Examples ..........................................................................................................14-9 14.6 Service Management ...............................................................................................................................14-15 14.7 Charging and CDR ..................................................................................................................................14-15 14.8 Service Interaction ..................................................................................................................................14-16 14.9 Reference ................................................................................................................................................14-16 14.9.1 Protocols and Specifications ..........................................................................................................14-16 14.9.2 Acronyms and Abbreviations .........................................................................................................14-16
Issue 02 (2007-06-10)
Figures
Figures
Figure 14-1 Networking of MNP service .........................................................................................................14-4 Figure 14-2 External network subscriber calls a ported out local network subscriber .....................................14-5 Figure 14-3 External network subscriber calls a subscriber ported in the Local Network but does not exist in the local network.....................................................................................................................................................14-6 Figure 14-4 MNP service flow in OR mode.....................................................................................................14-7 Figure 14-5 Local network subscriber calls a ported out local network subscriber based on the IN................14-8 Figure 14-6 Local network subscriber calls a ported out local network subscriber based on signaling ...........14-8
ii
Issue 02 (2007-06-10)
Tables
Tables
Table 14-1 Related NEs of MNP feature ..........................................................................................................14-3 Table 14-2 Product versions that support the MNP feature ..............................................................................14-3
Issue 02 (2007-06-10)
iii
14 MNP Feature
14
About This Chapter
The following table lists the contents of this chapter. Section 14.1 Feature Description Describes 14.2 Availability
MNP Feature
The function code, function definition of this feature, and the benefits that carriers and mobile subscribers can obtain from this feature. The network elements (NEs) that are required for the feature, whether Licenses are required, and the version requirements of the NEs. The functions of the NEs, and networking requirements. The service flow of the network when providing this feature. The data configurations that are required on the MSOFTX3000 and the IMG8900. The service operations that carriers and mobile subscribers are required to implement when the network provides this feature. The charging and the generation of CDRs when the network provides this feature. The relationships and restrictions between this feature and other services or features. The protocols and specifications that this feature must comply with, and the acronyms and abbreviations of this chapter.
14.3 Principle Description 14.4 Service Flows 14.5 Data Configuration 14.6 Service Management
14.7 Charging and 14.8 Service Interaction 14.9 Reference
Issue 02 (2007-06-10)
14-1
14 MNP Feature
14.1 Feature Description

14.1.1 Feature Code
Feature Name MNP Feature Feature Code WMFD-042500
14.1.2 Function Definition

The Mobile Number Portability (MNP) allows Universal Mobile Telecommunications System (UMTS) or GSM mobile subscribers to change the subscription networks within a country, and to preserve the original MSISDNs at the same time. All the services of the subscriber are provided by the new network. They are not affected by the original network. The new network also assigns a new International Mobile Subscriber Identity (IMSI) to the MNP subscriber. In one network, MNP subscribers and non-MNP subscribes enjoy service functions of no difference, but there are differences in service qualities, such as the additional call setup delay. The MNP service provides the following functions: No need to change the MSISDN: Subscribers need not to change their MSISDNs due to the change of carriers or networks. Independent subscription service: The original network has no impact upon the current services of subscribers. If certain services supported by the original network are not supported by the new network, subscribers cannot enjoy the services. Ported many times: There can be numbers ported both in and out in one network. One MSISDN can be ported for multiple times and can be ported back and forth in multiple networks. Independent service: It does not conflict with other mobile services provided by the system.
14.1.3 Service Benefits

Beneficiary Carriers Benefit Description For new carriers, the MNP feature attracts new subscribers and enhances competition capability. For mature carriers, the MNP service brings additional management charges and increases operation revenue. Mobile subscribers Based on the changes of locations, subscribers can choose different networks or more suitable carriers without changing their numbers. Subscribers can subscribe networks of one carrier in different areas and remain the original number. For example, a subscriber registers a number in area A. This number belongs to the number segment of area A. After moving to place B, the subscriber can register the same number in area B.
14-2
Issue 02 (2007-06-10)
14 MNP Feature
14.2 Availability
14.2.1 Related Network Elements
The realization of the MNP feature requires the cooperation of the network elements (NEs) listed in Table 14-1. Table 14-1 Related NEs of MNP feature UE/M S NodeB/ BTS RNC/ BSC MSC Server MGW NPDB SCP VLR HLR
"" indicates the related NEs.
14.2.2 License Support

The MNP feature is an optional feature of Huawei wireless core network. The MNP services are available only when the MSOFTX3000 License is obtained.
14.2.3 Version Support

Table 14-2 lists the product versions that support the MNP feature. Table 14-2 Product versions that support the MNP feature Product MSC Server MGW MSOFTX3000 UMG8900 Version V100R002 and later versions V200R002 and later versions
14.3 Principle Description

The HLR stores the subscription information, home area and home network information of subscribers. The MSC server provides services to subscribers based on their subscription information.
14.3.2 System Interior Processing

Figure 14-1 shows the typical networking of the MNP service.
Issue 02 (2007-06-10)
14-3
14 MNP Feature
Figure 14-1 Networking of MNP service

PLMN Other PLMN
HLR
SMSC Foreign NPDB
SPS
SPS
VMSC
GMSC
Foreign NPDB: NP database of external network PLMN: Public Land Mobile Network GMSC: Gateway Mobile Switch Center VMSC: Visited Mobile Switch Center
SPS: Signaling Service Processing System HLR: Home Location Register SMSC: Short Message Service Center
In the networking, the SPS serves as the MNP-Signaling Relay Function (SRF) and Number Portability Database (NPDB). It is before the HLR in service flows and often configured in pairs. The MNP feature requires that the network addresses in the "Route on GT" mode, and use the SPS as the translation point. The 3G TS 23.066 defines two modes to realize the MNP. One is based on the IN, while the other is based on signaling relay. The MSC queries the MNP Service Processing Table to determine the subsequent processing type: IN based original call query, Release, or No processing. The IN based original call query mode is not usually used. It is used for certain special requirements only. The MSOFTX3000 supports the following MNP modes: Query on Release (QoR) mode Onward Routing (OR) mode All Call Query (AcQ) mode
14-4
Issue 02 (2007-06-10)
14 MNP Feature
14.4 Service Flows

14.4.1 QoR Mode
RN is the route number. Every carrier is assigned with one RN, such as C0101, and C0102. If there is no special note in this article, RNP4 refers to the RN of P4, RNx refers to RN of external network, and NonNP means that no number is ported.
The MNP service in the QoR mode is used when the GMSC calls the following numbers: Numbers ported from local network to external network Numbers ported from external network to local network The GMSC delivers the SRI to the NPDB. Based on the result of querying related table, the NPDB determines whether to deliver the SRI to the HLR or return an SRlack message to the GMSC. When receiving the SRIack, the GMSC queries the MNP Service Processing Table. Based on the result, the GMSC processes as follows: If the returned MSRN is "Foreign RNx + MSISDN" or "NonNP + MSISDN", the GMSC disconnects the call. (If the prefix is RN, the REL message carries a disconnect cause value of 14. If the prefix is NonNP, the REL message carries a disconnect cause value of 1. In the latter case, the system generates an alarm.) Otherwise, the GMSC normally connects the call. The VMSC does failure processing to the REL message returned by the GMSC. If the cause value is 14, the VMSC re-routes the call to the NPDB to obtain the RNx.
External Network Subscriber Calls a Ported Out Local Network Subscriber

Figure 14-2 shows the flow of an external network subscriber calls a ported out local network subscriber. Figure 14-2 External network subscriber calls a ported out local network subscriber
VMSC GMSC STP/NPDB HLR
IAM (MSISDN) SRI (MSISDN) SRIack (RNx+MSISDN) REL (release cause 14)
1.
The GMSC receives an IAM message sent by the VMSC. The message carries a called number with the number segment of the local network. The called number does not carry an RN prefix.
Issue 02 (2007-06-10)
14-5
14 MNP Feature
2. 3. 4.
The GMSC sends an SRI to the NPDB. After querying related table, the NPDB returns an SRIack (RNx + MSISDN) to the GMSC. The GMSC sends a REL message to the VMSC. The VMSC disconnects the call. The call termination cause value is 14, indicating that the called number is ported out.
In the trial bill, the called number is the MSISDN. The call termination cause value is 14, indicating that the called number is ported out.
External Network Subscriber Calls a Subscriber Who Ported In Local Network But Does Not Exist in the Local Network
An external network subscriber calls a local network subscriber. The caller thinks that the callee ported in the local network, but the called does not exist in the local network. Figure 14-3 shows the flow. Figure 14-3 External network subscriber calls a subscriber ported in the Local Network but does not exist in the local network
VMSC GMSC STP/NPDB HLR
IAM (RNP4+MSISDN) SRI (MSISDN) SRIack REL (release cause 1)
1. 2. 3. 4.
The VMSC sends an IAM message to the GMSC. The called number carries the RN prefix of the local network, that is, RNP4. The GMSC sends an SRI to the NPDB. After querying table, the NPDB returns an SRIack (NonNP + MSISDN or RNx + MSISDN) to the GMSC. The GMSC sends an REL message to the VMSC. The VMSC disconnects the call. The call termination cause value of 1, indicating that the called number is not allocated.
In the trial bill, the called number is RNP4 + MSISDN. The call termination cause value is 1, indicating that the called number is not allocated. NonNP + MSISDN returned by the STP means that this MSISDN is a non-NP subscriber.
14.4.2 OR Mode
The MNP service in the OR mode is used when the GMSC calls the number segment that may port from local network to external network. If a called number ports to external network, the
14-6
Issue 02 (2007-06-10)
14 MNP Feature
NPDB returns an SRlack (RN + MSISDN). When receiving the SRlack, the GSMC queries the MNP Service Processing Table and selects a processing type. Figure 14-4 shows the MNP service flow in the OR mode. Figure 14-4 MNP service flow in OR mode
PSTN GMSCa STP/NPDB HLR GMSCb
IAM (MSISDN) SRI (MSISDN) SRIack (RNx+MSISDN) IAM (RNx+MSISDN)
1. 2. 3. 4.
The PSTN sends an IAM message to the GMSCa. The IAM message carries the information of the called number that belongs to the local network number segment. The GMSCa sends an SRI to the NPDB. After querying table, the NPDB returns an SRIack (RNx + MSISDN) to the GMSCa. The GMSCa routes the call to the correct network, such as the GMSCb.
In the GWI, the called number is the MSISDN. In this case, the subscriber is not charged. The called number in the GWO is RNx + MSISDN. (For a GV integrated office, the called number in the GWO is MSISDN. For a GMSC, the called number in the GWO is RNx + MSISDN.)
14.4.3 AcQ Mode

The MNP service in the AcQ mode is used when the called party is a local network subscriber and may port to external network. The MSC routes the call to the NPDB or reports to the NPDB through an IDP message. Based on the result, the MSC sends the IAM out of the office or pages the callee.
Local Network Subscriber Calls a Ported Out Local Network Subscriber Based on IN
Figure 14-5 shows the flow of a local network subscriber calls a ported out local network subscriber based on the IN.
Issue 02 (2007-06-10)
14-7
14 MNP Feature
Figure 14-5 Local network subscriber calls a ported out local network subscriber based on the IN
VMSC STP/NPDB SCP HLR GMSC
IDP (DP2,Cdpa=MSISDN) IDP (DP2,Cdpa=MSISDN) Connect (Cdpa=RNx+MSISDN) IAM (RNx+MSISDN)
1. 2. 3. 4.
The local network subscriber initiates a call, triggers the IN, and reports an IDP message to the NPDB. The NPDB transparently transfers the IDP message to the SCP. The SCP returns the CONNECT (RNx + MSISDN) message to the VMSC. The VMSC routes the call to the correct network.
IN bills are generated. In the MOC, the called number is the MSISDN. The translatedNumber is RNx + MSISDN.
Local Network Subscriber Calls a Ported Out Local Network Subscriber Based on Signaling
Figure 14-6 shows the flow of a local network subscriber calls a ported out local network subscriber based on signaling. Figure 14-6 Local network subscriber calls a ported out local network subscriber based on signaling
VMSC
STP/NPDB
HLR
GMSC
SRI (MSISDN)
SRIack (RNx+MSISDN)
IAM (RNx+MSISDN)
14-8
Issue 02 (2007-06-10)
14 MNP Feature
1. 2. 3.
The subscriber initiates a call. The VMSC sends an SRI to the NPDB. After querying table, the NPDB returns an SRIack (RNx + MSISDN) to the VMSC. The VMSC routes the call to the correct network.
In the MOC, the called number is the MSISDN. The translatedNumber is RNx + MSISDN.

Step 1 Run ADD MNP to add records in the MNP Service Table. Step 2 Run ADD SCCPGT to add GT translation data to the NPDB. Step 3 Run ADD IMSIGT to add the global translation codes of the IMSI. Step 4 Run ADD CNACLD to add called number analysis data. Step 5 Run ADD SCPPARA to add SCP parameters. (This step is required only when the MNP processing type is IN-based MO query.) Step 6 Run ADD CLDPREANA to add called number pre-analysis data. Step 7 Run ADD AIDNUMPRO to add auxiliary number change data. Step 8 Run ADD CFPRO to add failure processing data. Step 9 Run ADD DNC to add number change data. ----End
14.5.2 Data Configuration on the UMG8900

None.
14.5.3 Data Configuration Examples

Case 1
QoR mode: An external network subscriber calls a ported out local network subscriber. The GMSC queries the NPDB. The NPDB returns an SRlack with the RNx prefix and the MSISDN. The calling office routes the call to a third-party network based on the RNx prefix.
Configuration Scripts
The data configuration of the local office is as follows: Step 1 Add the GT translation to the NPDB.
Issue 02 (2007-06-10)
14-9
14 MNP Feature
Description
Add the GT translation to the NPDB to translate corresponding number segments to the NPDB.
Note: The SCCPDSP and SCCP subsystems require independent configuration.
Script
ADD SCCPGT: GTN="10", ADDR=K'48139075203, RESULTT=STP1, SPC="111111";
Step 2 Add the global translation code information of the IMSI. Description Script Add the global translation code information of the IMSI. ADD IMSIGT: MCCMNC=K'460077552000395, CCNDC=K'48139075203, MNNAME="MNP TEST";
Step 3 Configure the Called Number Pre-analysis Table. Description Script Configure the Called Number Pre-analysis Table. Set Processing type to No processing to prevent adding "00" when adjusting the called number. ADD CLDPREANA: CSCNAME=65534, CS=ALL, PFX=K'C0101, MINCLDLEN=6, CDADDR=ALL, CRP=ALL, PT=DONTPROC;
Step 4 Configure the MNP Service Table. Description Configure the MNP Service Table. Set Call source to 0, Call originator to MAP non-forwarding, Called prefix to C0101, Minimum number length to 5, Maximum number length to 20, MNP processing type to External network NP prefix, MNP processing type to Disconnect, Disconnect cause code to 142, and Alarm flag to No. ADD INMNP: CLDPFX=K'C0101, MINDNLEN=5, MAXDNLEN=20, MNPPFT=OTHER, MNPPRT=REL, FCC=CV142, ALMF=NO;
Script
----End The data configuration of the originating office: Step 1 Configure the Called NO Analysis Table. Description Script Configure the Called NO Analysis Table. ADD CNACLD: P=9, PFX=K'C0101, CSA=MLCT, RSN="5", MINL=5, MAXL=32, ICLDTYPE=PS; ADD CNACLD: PFX=K'139075203, MINL=3, MAXL=20, ICLDTYPE=MS;
14-10
Issue 02 (2007-06-10)
14 MNP Feature
Step 2 Add the GT translation to the NPDB. Description Add the GT translation to the NPDB to translate corresponding number segments to the NPDB.
Script
ADD SCCPGT: GTN=10, ADDR=K'48139075203, RESULTT=STP1, SPC="111111";
Step 3 Add the global translation code information of the IMSI. Description Script Add the global translation code information of the IMSI. ADD IMSIGT: MCCMNC=K'460077552000395, CCNDC=K'48139075203, MNNAME="MNP test";
Step 4 Configure the Called Number Pre-analysis Table. Description Script Configure the Called Number Pre-analysis Table. ADD CLDPREANA: CSCNAME=65534, CS=ALL, PFX=K'C0101, MINCLDLEN=6, CDADDR=ALL, CRP=ALL, PT=DONTPROC;
Step 5 Configure the Number Change Table. Description Script Configure the Number Change Table. Set the Number Change Table to add prefix to the called number. ADD DNC: DCN="1", DCT=TYPE1, ND=K'123;
Step 6 Configure the Call Failure Processing Table. Description Script Configure the Call Failure Processing Table. Set Failure cause code to 142 for failure processing. ADD CFPRO: FCC=CV142, FSC=0, RUT=CAT10, PT=CPA, DCN="1";
Step 7 Configure the Auxiliary Number Change Table.
Issue 02 (2007-06-10)
14-11
14 MNP Feature
Description
Configure the Auxiliary Number Change Table.

Note: Configure the Number Change Table to delete the prefix "123".
Script
ADD AIDNUMPRO: CSCNAME="0", NUMTY=TY4, P=9, PFX=K'123, CDX=1;
----End
Case 2
QoR mode: An external network subscriber calls a local network subscriber. The caller thinks that the callee ported in the local network, but the callee does not exist in the local network. The GMSC queries the NPDB. The NPDB returns an SRlack with the NonNP prefix and the MSISDN. The GMSC sends a disconnecting message to the originating office.
Step 1 Add the GT translation to the NPDB. Description Add the GT translation to the NPDB.
Script
Step 3 Configure the Called Number Pre-analysis Table. Description Script Configure the Called Number Pre-analysis Table. Set Processing type to No processing to prevent adding "00" when adjusting the called number. ADD CLDPREANA: CSCNAME="65534", CS=ALL, PFX=K'C0101, MINCLDLEN=6, CDADDR=ALL, CRP=ALL, PT=DONTPROC;
14-12
Issue 02 (2007-06-10)
14 MNP Feature
Step 4 Configure the MNP Service Table. Description Configure the MNP Service Table. Set Call source to 0, Call originator to Wildcard, Called prefix to C0101, Minimum number length to 5, Maximum number length to 20, MNP processing type to Local network NP prefix, MNP processing type to Disconnect, Disconnect cause code to 142, and Alarm flag to No. ADD INMNP: CLDPFX=K'C0101, MINDNLEN=5, MAXDNLEN=20, MNPPFT=LOC, MNPPRT=REL, FCC=CV142, ALMF=YES;
Script
----End
Case 3
OR mode: For calls that the callee is a local subscriber and may port to a number segment of external network, the GMSC sends an SRI to the NPDB. If the called number ports out of the local network, the NPDB returns an SRlack (RNx + MSISDN). When receiving the SRlack, the GMSC queries the MNP Service Processing Table to select a processing type.
Script
Issue 02 (2007-06-10)
14-13
14 MNP Feature
Step 4 Configure the MNP Service Table. Description Configure the MNP Service Table. Set Call source to 0, Call originator to Wildcard, Called prefix to C0101, Minimum number length to 5, Maximum number length to 20, MNP processing type to Local network NP prefix, and MNP processing type to No processing. ADD INMNP: CLDPFX=K'C0101, MINDNLEN=5, MAXDNLEN=20, MNPPFT=LOC, MNPPRT=DONTPROC;
Script
----End
Case 4
AcQ mode: A local network subscriber calls a ported out local network subscriber based on signaling. The originating office queries the NPDB. The NPDB returns an SRlack with the RNx and the MSISDN. The originating office routes to a third-party network based on the RNx.
Script
14-14
Issue 02 (2007-06-10)
14 MNP Feature
Step 4 Configure the Called NO Analysis Table. Description Script Configure the Called NO Analysis Table. ADD CNACLD: P=9, PFX=K'C0101, CSA=MLCT, RSN="5", MINL=5, MAXL=32, ICLDTYPE=PS;
Step 5 Configure the MNP Service Table. Description Configure the MNP Service Table. Set Call source to 0, Call originator to Wildcard, Called prefix to C0101, Minimum number length to 5, Maximum number length to 20, MNP processing type to Local network NP prefix, and MNP processing type to No processing. ADD INMNP: CLDPFX=K'C0101, MINDNLEN=5, MAXDNLEN=20, MNPPFT=LOC, MNPPRT=DONTPROC;
Script
----End

None.

The charging and bill generating principles of the MNP feature are as follows: If IN services are triggered, IN bills are generated. If the roaming number brought back by the NPDB is (RN + MSISDN), the translatedNumber in the bill is RN + MSISDN. Bit 4 and bit 1 of the software parameter P129 control the filling of the called number in the bill: Bit 4: Controls the filling of the numbers in the bills of overseas version and domestic version. = 0: Overseas requirement = 1: Domestic requirement Default value: 1 Bit 1: Controls the format of called numbers in the bill. = 0: Fill the numbers after adjustment. = 1: Fill the numbers the subscribers dial. Default value: 1
Bit 1 is valid only when bit 4 is set to 0. When bit 4 is set to 1, bit 1 is invalid.
It can also be controlled by bit 2 of the software parameter P1300:
Issue 02 (2007-06-10)
14-15
14 MNP Feature
Bit 2: Defines the filling principles of the called numbers in the GWO bill. The GWO bill is generated when subscriber A dials subscriber B and triggers the IN flow CONNECT to subscriber C (in other office): = 0: Fill the number of subscriber C. = 1: Fill the number of subscriber B. Default value: 1 You should configure a piece of data in the Home PLMN Roaming Prefix Table to limit the generation of roaming bills. The MSRN prefix is the RN number.

The MNP feature has service interaction with the ETSI interception. For details, refer to the design specifications of the ETSI interception.
14.9 Reference
The references of the MNP feature are as follows: 3GPP TS 23.066 Design specifications of the ETSI interception

Acronym/Abbreviation 3GPP AcQ CdPA ETSI MNP MOC MSRN MTC NPDB OR QoR RN SCCP Full Name 3rd Generation Partnership Project All Call Query Called Party Address European Telecommunications Standards Institute Mobile Number Portability Mobile Originated Call Mobile Station Roaming Number Mobile Terminated Call Number Portability Database Onward Routing Query on Release Routing Number Signaling Connection Control Part
14-16
Issue 02 (2007-06-10)
14 MNP Feature
Acronym/Abbreviation SCP SPC
Full Name Service Control Point Signaling Point Code
Issue 02 (2007-06-10)
14-17
Contents
Contents
15 IP Fax Feature..........................................................................................................................15-1
15.1 Service Description ...................................................................................................................................15-2 15.2 Working Principle......................................................................................................................................15-2 15.3 Benefits .....................................................................................................................................................15-2 15.3.1 To Carriers........................................................................................................................................15-2 15.3.2 To Mobile Subscribers .....................................................................................................................15-2 15.4 Availability ................................................................................................................................................15-2 15.4.1 Application.......................................................................................................................................15-2 15.4.2 Requirements for Software ..............................................................................................................15-3 15.4.3 Requirements for Hardware .............................................................................................................15-3 15.5 Service Flow..............................................................................................................................................15-3 15.5.1 Classification of Call Model ............................................................................................................15-3 15.5.2 Processing Flow ...............................................................................................................................15-3 15.6 Data Configuration....................................................................................................................................15-7 15.6.1 Configuring Data at the MSOFTX3000 Side...................................................................................15-7 15.6.2 Data Configuration Example............................................................................................................15-9 15.7 Service Management ...............................................................................................................................15-10 15.8 Charging and CDR ..................................................................................................................................15-10 15.9 Service Interaction ..................................................................................................................................15-10
Issue 02 (2007-06-10)
Tables
Tables
Table 15-1 Value options of Support FAX detection ........................................................................................15-8 Table 15-2 Value options of Support 2198 redundancy ....................................................................................15-8 Table 15-3 Value options of 2198 UP Mode.....................................................................................................15-8 Table 15-4 Value options of 2198 redundancy level.........................................................................................15-8 Table 15-5 Value options of 2198 redundancy CODEC type ...........................................................................15-9 Table 15-6 Value options of BICC support red.................................................................................................15-9
ii
Issue 02 (2007-06-10)
15 IP Fax Feature
15
About This Chapter
The following table lists the contents of this chapter. Section 15.1 Service Description 15.2 Working Principle 15.3 Benefits 15.4 Availability 15.5 Service Flow 15.6 Data Configuration 15.7 Service Management 15.8 Charging and CDR 15.9 Service Interaction Describes
IP Fax Feature
The function code and definition of this feature. The principle of the implementation of this feature. The benefits to the carrier and mobile subscribers when this service is used. The application and requirements of this feature. The service flow of the network when providing this feature. The data configuration that is required at the MSOFTX3000 side. The operations that the carrier and subscribers must perform for the implementation of this feature. The charging and the generation of CDRs when the network provides this feature. The relationships and restrictions between this feature and other services or features.
Issue 02 (2007-06-10)
15-1
15 IP Fax Feature

IP fax is the fax service over IP. Data transmission plays an important role in the fax process, because the quality of data transmission determines that of fax. The data stream redundancy is a solution to the data packet loss during transmission. Transmission supporting the data stream redundancy is a type of enhanced service. This service can improve the data transmission quality, and reduce or avoid the service termination caused by bad data transmission quality.

During a call, the MSC server determines whether to send 2198 redundancy parameter of the data service to the MGW based on data configuration. In addition, the MSC server determines whether to notify the MGW to start fax event detection after a call is initiated based on data configuration. The MGW reports fax tone detection event and fax status detection event. The MSC server sends indication of modifying codec property to the MGW based on reported detection events, thus to support data redundancy.
15.3 Benefits
15.3.1 To Carriers
The IP fax feature increases the quality of the fax data transmission and enhances the competitive edge of carriers.
15.3.2 To Mobile Subscribers

Mobile subscribers can enjoy the high-quality fax service.
15.4 Availability
15.4.1 Application
The MSOFTX3000 V100R005 provides the IP fax service. The TS62 service is applicable to visited MSC (VMSC), gateway MSC (GMSC), and tandem MSC (TMSC). The TS61 service is applicable to TMSC only. The limitations of the IP fax service is as follows: The VMSC cannot trigger the TS61 service that contains 2198 redundancy data. The VMSC does not support fax detection. To implement 2198 redundancy transmission for inter-office BICC fax, the TrFO function must be enabled. The modification of 2198 redundancy configuration is not allowed during data service calls.
15-2
Issue 02 (2007-06-10)
15 IP Fax Feature
All the gateways connected with an MSC must support or not support 2198 redundancy at the same time. The distributed interworking function (IWF) is not supported.
15.4.2 Requirements for Software

None.
15.4.3 Requirements for Hardware

None.
15.5 Service Flow

15.5.1 Classification of Call Model
TS61 fax processing on the TMSC TS62 fax processing on the GMSC, VMSC, or TMSC
15.5.2 Processing Flow

TS61 and TS62 Call Processing Flows on the TMSC when the ISUP/TUP/BICC Signaling is Used
ISUP/TUPISUP/TUP When a call is initiated, the TDM point sends the fax detection event to the gateway and meanwhile sends the 2198 data service redundancy modification request. When a fax call is initiated, the gateway reports the fax event, sends the CODEC modification request to the local-end gateway to modify the terminal point, and meanwhile sends the modification request to the peer end. If the local end is the outgoing side, it also needs to send the intermediate bearer request to the gateway. After the fax ends, the gateway reports the fax complete event and the local end sends the open EC operation request to the gateway.
Issue 02 (2007-06-10)
15-3
15 IP Fax Feature
MSOFTX3000
(1) (2) (3)
(4) IP
Incoming side
Outgoing side
1. Report the fax detection event. 3. Return successful 1T modification response.
2. Send the 1T modification request. 4. Notify the peer end to send the CODEC modification request.
ISUP/TUPBICC When a call is initiated, the TDM point sends the fax detection event to the gateway and meanwhile sends the 2198 data service redundancy modification request. When a fax call is initiated, the gateway reports the fax event, sends the CODEC modification request to the local-end gateway to modify the terminal point, and meanwhile sends the modification request to the peer end. The BICC uses the CODEC re-negotiation flow to modify the IP point. After the fax ends, the gateway reports the fax complete event and the local end sends the open EC operation request to the gateway.
MSOFTX3000
(1) (2) (3)
(4) IP
Incoming side
Outgoing side
1. Report the fax detection event. 3. Return successful 1T modification response.
2. Send the 1T modification request. 4. Notify the peer end to send the CODEC modification request.
BICCISUP/TUP When a call is initiated, the TDM point sends the fax detection event to the gateway and meanwhile sends the 2198 data service redundancy modification request.
15-4
Issue 02 (2007-06-10)
15 IP Fax Feature
When a fax call is initiated, the gateway reports the fax event, sends the CODEC modification request to the local-end gateway to modify the terminal point, and meanwhile sends the modification request to the peer end. The BICC uses the CODEC re-negotiation flow to modify the IP point. After the fax ends, the gateway reports the fax complete event and the local end sends the open EC operation request to the gateway.
MSOFTX3000
(6)
(1) (2) (3) (4) (5)
Incoming side
IP
Outgoing side
1. Report the fax detection event. 3. Return successful 1T modification response. 5. Return successful 2T modification response.
2. Send the 1T modification request. 4. Send the 2T modification request. 6. Notify the peer end to send the CODEC modification request.
"Send the 1T modification request" refers to the local-end terminal point modification request. "Send the 2T modification request" refers to the intermediate bearer modification request. For the case of switching the fax to the voice call, observe the original processing flow. This feature does not involve the processing of this part.
BICCBICC The MSOFTX3000 receives the CODEC modification request from another MSC (calling party/called party). The MSOFTX3000 sends the CODEC modification request to the gateway and meanwhile notifies the peer end to send the CODEC modification request. After the successful modification, the peer end sends the CODEC modification request to the other office.
Issue 02 (2007-06-10)
15-5
15 IP Fax Feature
(1)
(6) MSOFTX3000
(2)
(3)
(4)
(5)
Incoming side
IP
Outgoing side
1. Modification request sent by other office 3. Return successful modification response. 5. Return successful modification response.
2. Send the CODED modification request 4. Send the CODED modification request. 6. Modification request sent by other office
Intra-TMSC Cross-Gateway (Over IP) TS61 and TS62 Call Processing Flow
The TMSC determines that the current service is a data service. The TMSC sends the PREPARE BEARER REQ, which carries the redundancy parameter.
MSOFTX3000
(1)
(2)
(3)
(4)
Incoming side
IP
Outgoing side
1. PB with redundancy parameter 3. PB with redundancy parameter
2. PB response 4. PB response
Inter-Office BICC (Over IP) TS61 and TS62 Call Processing Flow
If the local office supports the 2198 redundancy in an outgoing BICC call, the local office negotiates with the peer office. If the message carrying the 2198 redundancy CODEC is received in an incoming BICC call, the local office judges whether it supports the 2198 redundancy capability and records the result. After the negotiation is completed, the MSOFTX3000 sends the CODEC modification request to the gateway.
15-6
Issue 02 (2007-06-10)
15 IP Fax Feature
MSOFTX3000
BICC
MSOFTX3000
(1)
(2)
(3)
(4)
MGW
1. Send the modification request. 3. Send the modification request.
MGW
2. Return the modification request. 4. Return the modification request.
Intra-VMSC Cross-Gateway (Over IP) TS62 Call Processing Flow

The VMSC determines that the current service is a data service. The VMSC sends the PREPARE BEARER REQ, which carries the redundancy parameter.
MSOFTX3000
(1)
(2)
(3)
(4)
Incoming side
IP
Outgoing side
1. PB with redundancy parameter 3. PB with redundancy parameter
2. PB response 4. PB response

Use the parameter Support FAX detection in the Local Office Information table to control whether the local office supports fax detection. Table 15-1 lists the value options of this parameter.
Issue 02 (2007-06-10)
15-7
15 IP Fax Feature
Table 15-1 Value options of Support FAX detection Value Yes No Meaning The local office supports the fax detection. (default value) The local office does not support the fax detection.
Use the parameter Support 2198 redundancy in the Local Office Information table to control whether the local office supports 2198 data redundancy. Table 15-2 lists the value options of this parameter. Table 15-2 Value options of Support 2198 redundancy Value Yes No Meaning The local office supports the 2198 data redundancy. The local office does not support the 2198 data redundancy. (default value)
Use the parameter 2198 UP Mode in the Local Office Information table to configure 2198 data redundancy. Table 15-3 lists the value options of this parameter. Table 15-3 Value options of 2198 UP Mode Value Transparent Mode Support Mode Meaning The transparent mode is adopted for the 2198 UP mode of the local office. (default value) The support mode is adopted for the 2198 UP mode of the local office.
Use the parameter 2198 redundancy level in the Local Office Information table to configure 2198 data redundancy. Table 15-4 lists the value options of this parameter. Table 15-4 Value options of 2198 redundancy level Value 1 2 Meaning The 2198 redundancy level of data service is level 1. (default value) The 2198 redundancy level of data service is level 1.
The 2198 redundancy level of data service is uniformly defined in the whole office.
Use the parameter 2198 redundancy CODEC type in the Local Office Information table to configure 2198 data service redundancy. Table 15-5 lists the value options of this parameter.
15-8
Issue 02 (2007-06-10)
15 IP Fax Feature
Table 15-5 Value options of 2198 redundancy CODEC type Value G.711u G.711a Meaning The codec used for 2198 redundancy of data services is G.711u. The codec used for 2198 redundancy of data services is G.711u. (default value)
Use the parameter 2198 redundancy payload type value in the Local Office Information table to configure 2198 data redundancy. The value range of this parameter is 96127. The default value is 97. Use the parameter BICC support red in the Office Direction table to configure whether to the office direction supports the redundancy parameters. Table 15-6 lists the value options of this parameter. Table 15-6 Value options of BICC support red Value Yes No Meaning The office direction supports the redundancy. (default value) The office direction does not support the redundancy.
Parameters 2198 UP Mode, 2198 redundancy level, 2198 redundancy CODEC type, and 2198 redundancy payload type value are attributes of 2198 redundancy. Thus, when Support 2198 redundancy is set to No, these parameters are not displayed in the parameter list.
P233 (H248 software parameter 2) It controls whether to forcibly change the UP mode to the transparent mode when the redundancy is sent. Bit 14:

= 0: The UP mode is not forcibly changed to the transparent mode when the redundancy is sent. = 1: The UP mode is forcibly changed to the transparent mode when the redundancy is sent.
15.6.2 Data Configuration Example

Scenario Description
The following lists a scenario description. Configure the local office information so that the local office supports the fax detection and 2198 data redundancy. Configure the office direction table so that redundancy is supported. Set bit14 of software parameter 233.
Issue 02 (2007-06-10)
15-9
15 IP Fax Feature
Configuration Script
SET OFI: OFN="VMSC", LOT=LOCMSC, IN=NO, IN2=NO, NN=YES, NN2=YES, SN1=NAT, SN2=NATB, SN3=NAT, SN4=NATB, NPC="2A1101", INS=SP14, IN2S=SP24, NNS=SP24, NN2S=SP14, SPF=YES, SPFAXDT=YES, SPRED=YES, REDLEVEL=L1, REDPT=97, REDCODEC=G711a, UPMODE=TRANS; ADD OFC: ON="VMSC", OOFFICT=NATT, DOL=SAME, SIG=SCTP, IFSUPPORTRED=YES; MOD MSFP: ID=P233, MODTYPE=P1, BIT=14, BITVAL=1;

No special management of the service is required.

None.

None.
15-10
Issue 02 (2007-06-10)
Contents
Contents
16 License Feature .......................................................................................................................16-1
16.1 Service Description ...................................................................................................................................16-2 16.1.1 Function Code..................................................................................................................................16-2 16.1.2 Application Scope ............................................................................................................................16-2 16.2 Working Principle......................................................................................................................................16-2 16.2.1 Working Principle of License...........................................................................................................16-2 16.2.2 Running Status of License ...............................................................................................................16-2 16.2.3 Invalidation of License.....................................................................................................................16-3 16.2.4 Alerting Mechanism of License .......................................................................................................16-3 16.3 Operation and Maintenance of License.....................................................................................................16-4 16.3.1 LOD LICENSE (Loading a License)...............................................................................................16-4 16.3.2 ROL LICENSE (Rolling Back a License) .......................................................................................16-5 16.3.3 LST LICENSE (Listing a License) ..................................................................................................16-6 16.3.4 DSP ESN (Displaying the System ESN)..........................................................................................16-7 16.3.5 STR LICCRC (Starting CRC Check of License).............................................................................16-9 16.3.6 DSP LICENSE (Display Running License File Status) ...................................................................16-9 16.3.7 DMP LICENSE (Dumping License File) ......................................................................................16-10 16.3.8 ULD LICENSE (Uploading License File to FTP Server).............................................................. 16-11 16.3.9 DLD LICENSE (Downloading License File from FTP Server) ....................................................16-12 16.4 License Control Items .............................................................................................................................16-12 16.4.1 Control Items .................................................................................................................................16-12 16.4.2 Resource Control Items..................................................................................................................16-15 16.5 Other Precautions ....................................................................................................................................16-17 16.5.1 License Checks ..............................................................................................................................16-17 16.5.2 License Invalidation and Prevention ..............................................................................................16-17 16.5.3 License Alarms...............................................................................................................................16-19 16.5.4 License Upgrading .........................................................................................................................16-20 16.5.5 Effects of BAM Operations on License .........................................................................................16-20 16.6 Reference ................................................................................................................................................16-21 16.6.1 Protocols and Specifications ..........................................................................................................16-21 16.6.2 Acornyms and Abbreviations .........................................................................................................16-21
Issue 02 (2007-06-10)
Tables
Tables
Table 16-1 Parameters of the command LOD LICENSE .................................................................................16-4 Table 16-2 Parameters of the command LST LICENSE ..................................................................................16-6 Table 16-3 Parameters of the command DSP ESN...........................................................................................16-8 Table 16-4 Parameters of the command DSP LICENSE ..................................................................................16-9 Table 16-5 Parameters of the command DMP LICENSE...............................................................................16-10 Table 16-6 Parameters of the command ULD LICENSE ............................................................................... 16-11 Table 16-7 Alarms from host ..........................................................................................................................16-19 Table 16-8 Alarms from BAM........................................................................................................................16-19
ii
Issue 02 (2007-06-10)
16 License Feature
16
About This Chapter
The following table lists the contents of this chapter. Section 16.1 Service Description 16.2 Working Principle 16.3 Operation and Maintenance of License 16.4 License Control Items 16.5 Other Precautions 16.6 Reference Describes
License Feature
The function code and application scope of the License feature. The working principles, running status, invalidation definition and alarm mechanism of the License feature. The O&M commands and cautions of the License feature. The control items and resource control items of the License feature. Other cautions in using the License feature. The acronyms in this chapter.
Issue 02 (2007-06-10)
16-1
16 License Feature

This feature does not have a function code.
16.1.2 Application Scope

For providers, the License is a contract form of authorizing the usage scope and period of the sold products. For customers, the License is a contract form of being authorized with the usage scope and period of the purchased products. Through the License, customers also obtain the services promised by providers. Physically, the License is presented as License authorization certificates and License files. The License features of the MSOFTX3000 achieve customization of the service functions and quantity of the products. This document aims to help technical staff to use the License features correctly.

16.2.1 Working Principle of License
The License functions of the MSOFTX3000 are realized on the basis of Huawei License unified platform. The application of the License should conform to the related regulations of Huawei. The following are realized by Huawei unified platform: Key generation management License file generation License file management Encryption/decryption signature verification module The following are realized by the MSOFTX3000 products: ESN setting acquisition License file installation update License file verification Capacity restriction of service function
16.2.2 Running Status of License

There are four running status of License: Normal: If the ESN in the License files loaded into the system is consistent with the ESN of the system, the status of the License is Normal. Trial: If the ESN in the License files loaded into the system is inconsistent with the ESN of the system, the status of the License is Trial.
16-2
Issue 02 (2007-06-10)
16 License Feature
Invalidating: If the License files loaded into the system is expired, or no valid License file is loaded into the system, the system triggers a 60-day invalidation alerting period. In this case, each control item of the License files can still be used for 60 days without any service restriction, but alarms indicating that the License is expired are sent every day. After the 60 days, the system enables the default minimum value. Default: After License files are expired for 60 days or the default minimum values are used for 60 days, the system runs under default License and provides only the default permitted License functions.
16.2.3 Invalidation of License

The latest date among the due dates of all License segments is taken as the due date of the License file. Invalidation of License contains the following: Invalidation of the whole License: If the due date of a specific feature is equal to the due date of the whole License file, the feature is handled as "Invalidation of the whole License". It has four running status: Normal, Trial, Invalidating and Default. Partial invalidation of the License: If the due date of a specific feature is not equal to the due date of the whole License file, the feature is handled as "Partial invalidation of the License". Each item of the License file also has four running status: Normal, Trial, Invalidating and Default.
16.2.4 Alerting Mechanism of License

For "Invalidation of the whole License", there are three types of alarms: When the whole License will be invalid in less than 90 days, the system sends a fault alarm every day indicating that the License will be expired. In the next day, the system recovers the fault alarm of the first day, and sends another alarm indicating that the License will be expired. The "Rest days" in the alarm represents how many days are left before the due date. After the whole License file is expired, there comes a 60-day invalidation alerting period. During this period, the original configuration values of the License are remained, but a fault alarm indicating that the License is expired is sent every day. In the next day, the system recovers the fault alarm of the first day, and sends another alarm indicating that the License is expired. After the 60-day invalidation alerting period, the default minimum value is enabled, and a fault alarm indicating that the License is expired is sent every day. In the next day, the system recovers the fault alarm of the first day, and sends another alarm indicating that the License is expired. For "Partial invalidation of the License", there are three types of alarms: When an item of a License file will be invalid in less than 30 days, a fault alarm indicating that the License item will be expired soon is sent every day. In the next day, the system recovers the fault alarm of the first day, and sends another alarm indicating that the License item will be expired. The "Rest days" in the alarm represents how many days are left before the due date. After a License item is expired, there comes a 60-day invalidation alerting period. During the period, the original configuration values of the License are remained, but a fault alarm indicating that the License is expired is sent every day. In the next day, the system recovers the fault alarm of the first day, and sends another alarm indicating that the License item is expired.
Issue 02 (2007-06-10)
16-3
16 License Feature
After the 60-day invalidation alerting period, the system enables the minimum default value of the License item. After the whole License is expired, alarms indicating that the License items are expired are not sent, because the License items are expired if the whole License file is expired.
There are 10 alarm cause values for the event alarm "invalid license", but they are not displayed. When such event alarms occur, check the following: Whether the loaded License is normal. If not, you must load valid License files again. Whether the License of the host and the License of the BAM are consistent. If not, you must load valid License files again.
16.3 Operation and Maintenance of License
After getting License files, you must back up them to avoid unexpected incidents. License files are digitally subscribed; therefore, do not edit them. Or, the License becomes invalid. After the loading, run DSP LICENSE and TR LICCRC immediately to check whether the Licenses of the host and the BAM are consistent. If not, contact Huawei technical staff for consultation.
16.3.1 LOD LICENSE (Loading a License)

You can run LOD LICENSE to load License files and enlarge the subscriber capability and functions of the system.
Parameter Description
Table 16-1 shows the parameters of the command LOD LICENSE. Table 16-1 Parameters of the command LOD LICENSE Parameter Name FN Data Type String Parameter Description License name Explanation It specifies the License to be loaded. Notes: The License must be in the License subdirectory under the installation directory, in the format of Lic*.dat. The input parameter cannot contain any other directory name.
16-4
Issue 02 (2007-06-10)
16 License Feature
Parameter Name LT
Data Type Enumeration
Parameter Description Location
Explanation It specifies the target location to which License is to be loaded. The options are: BAM, and BAM and host. Notes: In general, you are recommended to use the default value of the parameter. This parameter must be set to BAM in certain special cases. That is, for any version between R002C01B022 and R002C01B031 (except B031), if it is required to be updated to any version later than R002C01B031, you must select BAM for loading. It is not required for any version later than R002C01B031.
Notes
Pay attention to the following when using this command. If the specified License does not exist, the License is verified to be incorrect, License decryption fails, or the License is expired, a message indicating failure in running the command is returned, together with related prompts. This does not affect the License in use. If the new License has fewer functions or a lower capacity than the original one, the command can be executed successfully, and each module uses the new License data. But an alarm indicating that the new License has less functions or lower capacity is generated. If the ESN of the specified License is inconsistent with that of the equipment, a prompt for successful loading is prompted, but an alarm indicating inconsistent ESNs is generated. In this case, the system is in trial running (the trial period is specified when applying License files). During this period, the functions of the License can be normally used. After the trail period, the system prompts that the trial period is expired, and the running mode turns to be Invalidating. The configuration values of the License remain, and subscribers are allowed to use the License for 60 days. After the 60 days, the running mode turns to be Default. The products run under the default License and provide only the default permitted License functions. If the system has ever loaded a License with an inconsistent ESN (that is, the system has trialed the License), any License with an inconsistent ESN cannot be loaded again. Therefore, when you find the License is in Trial status, you must apply for a formal License immediately. Or, the License only provides default functions when the Invalidating period is over.
16.3.2 ROL LICENSE (Rolling Back a License)

The host database can store only the License files of the latest 2 loadings. To switch over easily, you can run ROL LICENSE to roll back from the current License file to the License file of the last time. Then the last License is in use. Using this command, you can switch over
Issue 02 (2007-06-10)
16-5
16 License Feature
easily between the last two License files, and then the system obtains the rights to change different functions and customer capacities.
The command ROL LICENSE has no parameter.
Notes
When the system performs the rollback operation, it rolls back to the last normal License configuration. Normal configuration here means the License files that have been successfully loaded in the system. This command is in fact to take the name of the License that has been successfully loaded last time, and then auto run LOD LICENSE to load the License. In general, you are recommended to run LOD LICENSE directly to reload the License.
16.3.3 LST LICENSE (Listing a License)

During maintenance, you can run LST LICENSE to check License files, including the loaded License files, and the unloaded License files under D:\MSOFTX3000\License.
Table 16-2 shows the parameters of the command LST LICENSE. Table 16-2 Parameters of the command LST LICENSE Parameter Name ST Data Type Enumerati on Parameter Description Source Type Explanation It specifies the location where the License to be queried is stored, namely the source type of the License. The parameter options are: Disk: to query the information of the License stored on the BAM disk. The parameter License name is displayed, and you can input the License you want to check. DB (database): to query the information of the License stored in the BAM database. The parameter File type is displayed, and you can select Current license or History license to check.
16-6
Issue 02 (2007-06-10)
16 License Feature
Parameter Name FN
Data Type String
Parameter Description License name
Explanation The parameter is valid only when Source type is set to Disk. It specifies the name of the License to be displayed. Notes: When this parameter is in the default value, all the License files in Lic*.dat format in the License subdirectory under the installation directory are displayed. When the file name is typed in, the content of the License is displayed.
FT
Enumerati on
File type
The parameter is valid only when Source type is set to DB. It specifies the name of the License to be displayed. The parameter options are: Current license: to display the current License file in the database. This option is the default value. History license: to display the history License files in the database.
Notes
Pay attention to the following when using this command: When File name is null, the License files of which the names initiate with the characters "LIC" in the License subdirectory under the installation directory are displayed. Usually the License files from the License center of Huawei are initiated with "OR" or other letters. So, you are recommended to change the License name to "LICENSESerialNo" field content before loading the License. Only a complete file name with extension name can be typed in File name. License files must be located in the License subdirectory under the installation directory, without the directory name. These rules are also applicable to other License operation commands.
16.3.4 DSP ESN (Displaying the System ESN)

During deployment or maintenance, the entity serial number (ESN) information is needed when applying License files. You can run DSP ESN to query the ESN information.
Table 16-3 shows the parameters of the command DSP ESN.
Issue 02 (2007-06-10)
16-7
16 License Feature
Table 16-3 Parameters of the command DSP ESN Name LT Data Type Enumeration Parameter Description Display type Explanation It specifies the type of the ESN to be displayed. The parameter options are: When LT is set to Current config in BAM, the ESN in the BAM server is displayed. When LT is set to Current config in Device, the ESN in the host is displayed. When LT is set to Input raw ESN, the system ESN information generated according to certain algorithm is displayed.
Notes
ESN means entity serial number. It is: The only identifier of a set of equipment The key guarantee of authorizing a License to a specific set of equipment The most important information of License files You, therefore, must ensure the correctness of the ESN. The serial number of the equipment to be authorized is contained in License file. After the License is loaded to the equipment, the system compares the ESN in the License file with that of the equipment. The system authorizes corresponding services to the equipment only when the two ESNs are consistent. The following are the steps to obtain the ESN: Step 1 Install the BAM. Step 2 Configure the MSC number and the DPC number offline. The MSC and DPC number must be identical with the actual data of the current network; otherwise, errors occur in obtaining the ESN. Step 3 Run DSP ESN to obtain the ESN. Set Display type to Current config in BAM. ----End
When there are multiple signaling points, the ESN is irrelevant to the sequence of the signaling points. You can change the sequence of the configuration, but any other change leads to different ESNs. You cannot add or delete signaling points. When the system is running, you cannot modify the MSC number or signaling point number, otherwise the License may become invalid. If you do have to modify them, you must obtain a new ESN number based on the data after the modification, and then apply a new License.
16-8
Issue 02 (2007-06-10)
16 License Feature
16.3.5 STR LICCRC (Starting CRC Check of License)

During maintenance, you can run STR LICCRC to compare the consistency of the License data of the host and the BAM.
The command STR LICCRC has no parameter.
Notes
Pay attention to the following when using this command: When the BAM originates STR LICCRC, the system checks whether the loaded Licenses of the BAM and the foreground host are consistent. The system compares the file names and CRC values only. The foreground host originates an automatic check every two hours. The BAM sends the information of the License loaded in the BAM to the host, irrespective of the check results. In this case, the host performs the following:
Check whether the information of the licenses loaded in the host and in the BAM are consistent. If the sizes and names of the licenses are identical, the licenses are considered consistent. If yes, the host enables the 2-hour basis check timer. If not, the host keeps the license of itself, enables the 10-minute basis check timer, and sends an event alarm indicating that both the licenses of the BAM and the host are valid but inconsistent.
16.3.6 DSP LICENSE (Display Running License File Status)

During maintenance, you can run DSP LICENSE to display the License status of the BAM and the host.
Table 16-4 shows the parameters of the command DSP LICENSE. Table 16-4 Parameters of the command DSP LICENSE Name DT Data Type Enumeration Parameter Description Display type Explanation It specifies whether to display the status of the License files of the BAM or the host. The parameter options are: BAM: The License in the BAM server is displayed. Host: The License in the host is displayed. If no parameter is selected, both the licenses in the host and the BAM are displayed.
Issue 02 (2007-06-10)
16-9
16 License Feature
Notes
DSP LICENSE is different from the command LST LICENSE. LST LICENSE is used to display the static License information while DSP LICENSE is to display the licenses that is loaded to the system and is in use at present.
16.3.7 DMP LICENSE (Dumping License File)

During maintenance, you can run DMP LICENSE to dump License files. The backup files are stored under D:\MSOFTX3000\License and named "License + current time". The License files that can be dumped are: The running License files in the host The current License files in the database The history License files in the database
Table 16-5 shows the parameters of the command DMP LICENSE. Table 16-5 Parameters of the command DMP LICENSE Name ST Data Type Enumeration Parameter Description Source type Explanation It specifies the location where the License to be displaced is stored, namely the source type of the License. The parameter options are: DEV: The License files stored in the host are displaced. DB: The License files stored in the database are displaced. FT String File type The parameter is valid only when Source type is set to Database. It is used to specify the License files in the database to be dumped. The parameter options are: Current file: to dump the current License files in the database which are in use. History file: to dump the history License files in the database which were used. FN String File name The parameter is valid only when Source type is set to Database. It is used to specify the names of the current License files in the database to be dumped. The file names must begin with "Lic", such as Lic_current.dat.
16-10
Issue 02 (2007-06-10)
16 License Feature
Notes
Pay attention to the following when using this command: When you export the contents of the License files being used on the host to a file, the file must be named "LICENSEYYYYMMDDHHMMSS.txt" in which the letters in upper case in the latter part indicate the year, month, date, hour, minute and second of the current system time. This file is stored in the License subdirectory under the BAM installation directory. You are recommended to save the license manually instead of using the DMP method. When exporting the "Current license files" or "History license files" from the database to a file, you can name the file freely.
16.3.8 ULD LICENSE (Uploading License File to FTP Server)

Table 16-6 shows the parameters of the command ULD LICENSE. Table 16-6 Parameters of the command ULD LICENSE Parameter Name IP Data Type IP address String Parameter Description IP address Explanation IP address of the FTP server. Optional. The default value is the IP address of the default file server. Subscriber name used to log in to the FTP server. Optional. The default value is the subscriber name for logging in to the default file server. Subscriber password used to log in to the FTP server. Optional. The default value is the subscriber password for logging in to the default file server. Directory name. The path on the FTP server where the files to be loaded (License files) are stored. Mandatory. Full name of the file to be loaded. Mandatory. Generated serial numbers of License files. Optional. By default, the content of the current License file is uploaded.
USR
Subscriber name
PWD
String
Password
DIR
String
Directory
FN FSN
String String
File name File serial number
Notes
This command uploads License file, obtains License files from the system and store them to a specified FTP server (similar to the command DLD LICENSE, network elements (NEs) also act as the FTP CLIENT).This command has a reverse function comparing to the command DLD LICENSE.
Issue 02 (2007-06-10)
16-11
16 License Feature
16.3.9 DLD LICENSE (Downloading License File from FTP Server)

The command DLD LICENSE loads the specific License files on the FTP server to NEs through the FTP protocol. The NEs act as the FTP clients.
For more details of the parameters of the command DLD LICENSE, refer to 16.3.8 "ULD LICENSE (Uploading License File to FTP Server).
Notes
DLD LICENSE only downloads License files to NEs. The NEs still use the original License configuration data, even if the system is restarted. The new License is not effective, and no decryption and ESN comparison are conducted (These operations are performed while running the command LOD LICENSE).If the ESNs of the NEs are changed, the License files must be updated at the same time.
16.4 License Control Items

16.4.1 Control Items
Control Items CAMEL IN service Switching between the GSM and the WCDMA system Description Decide whether to enable the IN service. Default Value Disabled Scenario VMSC, GMSC, TMSC VMSC
When the HO module processes switching requests originated by the local office or incoming switching requests, query the destination route from the database to determine the type of the switching side (2G or 3G), and then decide whether the switching can be supported based on the License. Decide whether to enable the SMS based on the License when the MSC interacts with the SMC. When the CM and the BICC receive the Codec negotiation result from each other, decide whether to enable the TFO/TrFO function based on the License. If not, the TrFO does not deliver the Modify process to the gateway.
Disabled
SMS
Disabled
VMSC
TFO/TrFO
Disabled
VMSC, GMSC, TMSC
16-12
Issue 02 (2007-06-10)
16 License Feature
Control Items LCS
Description In the MT_LR, MO_LR and NI_LR processes, decide whether to reject the LCS requests based on the License. Decide whether to enable dual homing and handover functions based on the judgment of the License. Decide whether to perform signaling bearer conversion, forwarding and related configuration based on the judgment of the License. Decide whether to perform signaling forwarding and related configuration based on the judgment of the License. Decide whether to enable the encryption function over the Mc interface based on the judgment of the License. Decide whether to enable the PS multimedia service based on the judgment of the License. Decide whether to enable the related configurations and services of VNOs based on the judgment of the License. Decide whether to enable related configurations and services of valid monitoring based on the judgment of the License. Decide whether to enable related configurations and services of intra-office Iu-Flex based on the judgment of the License. Intra-office Iu-Flex means that one RNC can be connected to multiple MGWs under the control of one MSC Server. Decide whether to enable related configurations and services of PRA based on the judgment of the License. Decide whether to enable related configurations and services of eMLPP based on the judgment of the License. Decide whether to enable related configurations and services of MNP (only IN mode is supported at present) based on the judgment of the License.
Default Value Disabled
Scenario VMSC
Dual homing
Disabled
VMSC, GMSC, TMSC VMSC, GMSC, TMSC VMSC, GMSC, TMSC VMSC, GMSC, TMSC VMSC VMSC
SG
Disabled
STP
Disabled
Mc interface encryption CS multimedia service Virtual network operator (VNO) Lawful interception
Disabled
Disabled Disabled
Disabled
VMSC, GMSC
Intra-office Iu-Flex
Disabled
VMSC
PRA access
Disabled
VMSC, GMSC VMSC, GMSC VMSC
eMLPP
Disabled
MNP
Disabled
Issue 02 (2007-06-10)
16-13
16 License Feature
Control Items Short message intelligent routing
Description Decide whether to enable the related configurations and services of short message intelligent routing (short messages are directly forwarded instead of through the SMC) based on the judgment of the License. Decide whether to notify the callee of the calling number through a short message when a call is not connected because of called line busy. Decide whether to enable signaling handling and related configuration over the Gs interface based on the judgment of the License. The EIR function is built in the MSC. Decide whether to enable the EIR based on the License. Decide to enable the ARD function based on the judgment of the License. Decide to enable the explicit call transfer (ECT) function based on the judgment of the License. Decide to enable the SCCP filtering and shielding function based on the judgment of the License. Decide to enable the MAP Policing function based on the judgment of the License. Decide to enable the MGCF function based on the judgment of the License. Decide whether to enable the half-rate hierarchical access function based on the judgment of the License. Decide whether to enable the SNA connection mode sharing function based on the judgment of the License. Decide whether to enable the inter-office Iu-Flex function based on the judgment of the License. Decide whether to enable the Min-A-Flex function based on the judgment of the License.
Scenario VMSC
Notification by SM
Disabled
VMSC, GMSC
Gs interface
Disabled
VMSC
Built-in EIR
Disabled
VMSC
ARD ECT
Disabled Disabled
VMSC VMSC
SCCP filtering and shielding MAP policing MGCF Half-rate hierarchical access SNA connection mode sharing Inter-office Iu-flex Min-A-Flex
Disabled
VMSC
Disabled Disabled Disabled
VMSC VMSC VMSC
Disabled
VMSC
Disabled
VMSC
Disabled
VMSC
16-14
Issue 02 (2007-06-10)
16 License Feature
Control Items ISUP LOOP BAC SOR Flexible control of AC version ussd NTP
Description Decide whether to enable the ISUP LOOP BACK function based on the judgment of the License. Decide whether to enable the SOR function based on the judgment of the License. Decide whether to enable the flexible control of AC version function based on the judgment of the License. Decide whether to enable the ussd function based on the judgment of the License. Decide whether to enable the NTP function based on the judgment of the License. Decide whether to enable subscriber tracing and signaling tracing functions based on the judgment of the License. Decide whether to enable the centralized signaling monitoring function based on the judgment of the License.
Scenario VMSC
Disabled Disabled
VMSC VMSC
Disabled Disabled
VMSC VMSC, GMSC, TMSC VMSC, GMSC, TMSC VMSC, GMSC
Subscriber protocol tracing Centralized signaling monitoring
Disabled
Disabled
16.4.2 Resource Control Items

Resource Control Items Total number of subscribers Description Controlled in the DB. The number of the attached subscribers is limited in the VDB to be less than total number of subscribers. The number of intelligent connections realized by the IN (total IN subscriber number x ERL each IN subscriber). It controls the processing capability. The number of connected 2G subscriber calls (total number of 2G end office subscribers x ERL each subscriber). It controls the processing capability. The number of connected 3G subscriber calls (total number of 3G end office subscribers x ERL each subscriber). It controls the processing capabilities. Default Value 4000 Scenario VMSC
Total number of IN calls
100
VMSC, GMSC
Number of calls originated by 2G end office Number of calls originated by 3G end office
100
VMSC
100
VMSC
Issue 02 (2007-06-10)
16-15
16 License Feature
Resource Control Items Number of trunk calls
Description The CCB controls the number of various types of trunks (total channel number x 2 or Total E1 number x 31), including the ISUP trunk number and BICC trunk number. The number of the subscribers on call hold (total number of subscribers on call hold x ERL each subscriber). The number of the subscribers on call waiting (total number of subscribers on call waiting x ERL each subscriber). The number of the subscribers in a multiparty call (total number of subscribers in a multiparty call x ERL each subscriber). The number of data service subscribers (total number of data service subscribers x ERL each subscriber). The number of monitored subscribers that can be configured (VMSC: total system subscriber number x percentage of monitored subscribers) It controls the number of the valid monitoring centers that can be connected with the MSC. It limits the number of the 2M signaling links can be configured. It limits the number of multiple signaling points that can be configured. It limits the number of the group calls that can be originated simultaneously (VGCS calls) It limits the number of the broadcast calls that can be originated simultaneously (VBS calls)
Default Value 100
Scenario GMSC, TMSC
Supported number of held calls Supported number of waiting calls Number of subscribers in a multiparty call Number of data service subscribers Number of monitored subscribers Number of monitored centers Number of 2M signaling links Number of multiple signaling points Number of group calls Number of broadcast calls
100
VMSC
100
VMSC
10
VMSC
10
VMSC
10
VMSC, GMSC
VMSC, GMSC VMSC, GMSC, TMSC VMSC, GMSC, TMSC Cluster service is ready for the VMSC. Cluster service is ready for the VMSC.
16-16
Issue 02 (2007-06-10)
16 License Feature
16.5 Other Precautions

16.5.1 License Checks
Timing Check
At 01:20 a.m. every day, the BAM and the host check the dates of the currently used License files. The steps are as follows: Step 1 If the license file is in trial state, judge whether the allowed trial period is expired. If not, reduce one day from the rest days and send an alarm indicating that the License will be expired. If yes and the license file is in the 60-day invalidation alerting period, the system remains the original License configuration information and sends an alarm indicating that the License is expired. After 60 days, the License runs with the default configurations and provides the default allowed functions only. Step 2 If the License is in normal state, judge whether the rest days of the License are less than 90 days. If yes, an alarm indicating that the License will be expired is sent, and one day is reduced from the rest days in the check every day. If the usage period is exceeded and the license file is in the 60-day invalidation alerting period, the system remains the original License configuration information and sends an alarm indicating that the License is expired. After 60 days, the License runs with default configurations and provides the default allowed functions only. Step 3 If the License is handled by items, judge whether the rest days of an item are less than 30 days. If yes, an alarm indicating that the License will be expired is sent, and one day is reduced from the rest days in the check every day. If the usage period is exceeded and the license file is in the 60-day invalidation alerting period, the system remains the original License configuration information and sends an alarm indicating that the License is expired. ----End
Check from the Host

The foreground host originates an automatic check every two hours. At this time, the BAM sends the information of the License loaded in the BAM to the host, irrespective of the check results. In this case, the host performs the following: 1. Check whether the license files loaded in the host and in the BAM are consistent. If the sizes and names of the license files are identical, the license files are considered consistent. If they are consistent, the host enables the 2-hour periodic check timer and check every two hours from then on. If they are inconsistent, the host enables the 10-minute periodic check timer and sends an alarm indicating that the License is expired. The cause value of the alarm is that both the licenses of the BAM and the host are valid but inconsistent.
2. 3.
16.5.2 License Invalidation and Prevention

License invalidation contains normal invalidation and abnormal invalidation. Normal invalidation: The trial period of trial License is expired, or the running period of formal License which is specified in License files is expired.
Issue 02 (2007-06-10)
16-17
16 License Feature
Abnormal invalidation: The License files are loaded normally in the system, but the License becomes invalid because of certain maloperations or specific conditions. Once the License becomes invalid, if you have legal License files, you can run LOD LICENSE to reload the License files. The following are certain symptoms of abnormal invalidation, and the methods to prevent them and solve them.
Invalid License on BAM

The symptoms are: When you run DSP LICENSE to check the License on the BAM, the file name is null, and the License control items are in their default minimum values. The tracing function on the operation console of the BAM is out of use. Alarms with ID 2381 and 2382 are generated, indicating that the current License files of the system are in their default values with which the system capacities are straightly limited. The solution to this case: Run LOD LICENSE to load valid License files.
Invalid License on host

The symptoms are: When you run DSP LICENSE to check the License on the host, the file name is null, and the License control items are in their default maximum values. Fault alarm "License is expired" (ID: 2183) and event alarm "License is invalid" (ID: 2246) appear in the alarm window. The solution to this case: Run LOD LICENSE to load valid License files.
License files Are Expired and not Reloaded

License files are expired and not reloaded. The symptoms are: Within the 60 days after the License is expired, you can run DSP LICENSE to check whether the running mode of the License is Invalidating. The file names and control items of the License are remained. Fault alarm "License is expired" (ID: 2183) appears in the alarm window. Within the 60 days after the License is expired, you can run DSP LICENSE to check whether the running mode of the License is Default. The file names are null and the control items are in the minimum values. Fault alarm "License is expired" (ID: 2183) appears in the alarm window. The solution to this case: Run LOD LICENSE to load valid License files.
License Files Are not Reloaded in Emergency Workstation After the Switchover from BAM to Emergency Workstation
The prevention method of this case: Load the License on the emergency workstation offline after the database is recovered and before the emergency workstation is connected to the host. When loading the License offline, you must set the parameter Position to BAM. At this time, the Licenses of the BAM and the host may be inconsistent. To ensure that the License files on
16-18
Issue 02 (2007-06-10)
16 License Feature
the BAM are normal, after the emergency workstation and the host are connected, run LOD LICENSE immediately to load the License to the host online. In this case, you cannot choose the parameter Position.
16.5.3 License Alarms

and Table 16-8 list the alarms related with the License. Table 16-7 Alarms from host Alarm ID 2181 2182 2183 2184 2187 2188 2189 2190 2246 Alarm Name License will be expired License will be expired recovered License is expired License is expired recovered License item will be expired License item will be expired recovered License item is expired License item is expired recovered License is invalid alarm
During maintenance, you should especially pay attention to the alarms 2181, 2183, 2187, 2189, and 2246.
Table 16-8 Alarms from BAM Alarm ID 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 Alarm Name Default license data loaded Default license feature loaded License file is invalid License file ESN does not match with system ESN Capability of license loaded is less than the old one License file trial date reached License file will be invalid License file will be invalid recovered License file expired License file expiry recovered
Issue 02 (2007-06-10)
16-19
16 License Feature
Alarm ID 2391 2392 2393 2394 2395
Alarm Name License file does not exist License file feature will be invalid License file feature will be invalid recovered License file feature expired License file feature expired recovered
16.5.4 License Upgrading

License Updating
When the signaling point configurations are modified or new service contracts are signed, it is necessary to apply new License files. This does not affect the BAM and the services. In this case, you should load the License with the command LOD LICENSE. No other special operation is required.
Version Upgrading
If there are special requirements upon version upgrading, the details are given in the upgrade guide released with the version.
16.5.5 Effects of BAM Operations on License

When the BAM is abnormal, it does not affect the License of the host, because the host can run without the BAM. When restarting the Maintain process on the BAM, the License files that were successfully loaded last time are reloaded on the BAM. In this case, the related information of the License is recorded in the BAM database. If the record does not exist in the database, you can only load the default License instead of the BAM License in the memory. When upgrading the BAM, if all versions of R002 are upgraded to R003, you must run LOD LICENSE to reload the License files after the upgrade. Otherwise, the License files on the BAM are set to the minimum value if they cannot be used. This severely affects the system function. If the SMU boards are not restarted on the host, the original License remains. At this time, if the License on the host is different from that on the BAM, alarms indicating "License is expired" are generated every 10 minutes. If the SMU boards are restarted on the host, License is analyzed in the FLASH. If the Licenses on the host and the BAM are different, alarms "License is invalid" are generated every 10 minutes. When the BAM is reinstalled, the original information about the License is lost. The original License files cannot be auto loaded in the system when the BAM is restarted. You must load the License files manually.
16-20
Issue 02 (2007-06-10)
16 License Feature
16.6 Reference
None.
16.6.2 Acornyms and Abbreviations

Acronym/Abbreviation AC ARD BAM BICC CAMEL CCB CRC ECT EIR eMLPP ESN FTP GMSC GSM IN LCS MGCF MGW MNP MO MSC MT NTP PRA RNC Full Name Application Context Access Restriction Data Back Administration Module Bearer Independent Call Control Protocol Customized Applications for Mobile network Enhanced Logic Call Control Block Cyclic Redundancy Check Explicit Call Transfer Equipment Identity Register enhanced Multi Level Precedence and Preemption Electronic Serial Number File Transfer Protocol Gateway Mobile Switching Center Global System for Mobile communications Intelligent Network Location Service Media Gateway Control Function Media Gateway Support of Mobile Number Portability Mobile Originated Mobile Switching Center Mobile Terminated Network Time Protocol Primary Rate Adaptation Radio Network Controller
Issue 02 (2007-06-10)
16-21
16 License Feature
Acronym/Abbreviation SCCP SG SOR STP TFO TMSC TrFO VDB VMSC WCDMA
Full Name Signaling Connection and Control Part Signaling Gateway Subsystem Out-of-service Request Signaling Transfer Point Tandem Free Operation Tandem Mobile Service Switching Center Transcoder Free Operation VLR Database Visited Mobile Switching Center Wideband Code Division Multiple Access
16-22
Issue 02 (2007-06-10)
Contents
Contents
17 NE User Dynamic Monitoring Feature ..............................................................................17-1
17.1 Function Description .................................................................................................................................17-2 17.1.1 Function Code..................................................................................................................................17-2 17.1.2 Definition .........................................................................................................................................17-2 17.1.3 Standard Compliance .......................................................................................................................17-3 17.1.4 System Specifications ......................................................................................................................17-3 17.1.5 Benefits ............................................................................................................................................17-4 17.1.6 Application Scenario ........................................................................................................................17-4 17.1.7 Application Limitations....................................................................................................................17-4 17.2 Availability ................................................................................................................................................17-4 17.2.1 Requirements for NEs......................................................................................................................17-4 17.2.2 Requirements for License ................................................................................................................17-5 17.2.3 Applicable Versions..........................................................................................................................17-5 17.2.4 Others...............................................................................................................................................17-5 17.3 Working Principle......................................................................................................................................17-5 17.3.1 Functions of NEs..............................................................................................................................17-5 17.3.2 Internal Processing of the System ....................................................................................................17-6 17.3.3 External Interfaces ...........................................................................................................................17-6 17.4 Service Flow..............................................................................................................................................17-6 17.4.1 Monitoring Flow of Online User......................................................................................................17-6 17.4.2 Reporting Flow of User Operation...................................................................................................17-6 17.4.3 Disconnection Flow of User Operation............................................................................................17-7 17.5 Function Maintenance ...............................................................................................................................17-7 17.5.1 Overview..........................................................................................................................................17-7 17.5.2 Maintenance Operations ..................................................................................................................17-7 17.6 Service Management ............................................................................................................................... 17-11 17.7 Charging and CDR .................................................................................................................................. 17-11 17.8 Performance Measurement...................................................................................................................... 17-11 17.9 Service Interaction .................................................................................................................................. 17-11 17.10 References .............................................................................................................................................17-12 17.10.1 Standards and Specifications........................................................................................................17-12 17.10.2 Glossary, Acronyms, and Abbreviations ......................................................................................17-12
Issue 02 (2007-06-10)
Contents
17.11 FAQ .......................................................................................................................................................17-12
ii
Issue 02 (2007-06-10)
Figures
Figures
Figure 17-1 Local Maintenance Monitor tabbed page......................................................................................17-2 Figure 17-2 User Monitor interface..................................................................................................................17-8 Figure 17-3 Subscribed NE List interface ........................................................................................................17-8 Figure 17-4 User Monitor interface................................................................................................................17-10 Figure 17-5 User Session interface 1..............................................................................................................17-10 Figure 17-6 User Session interface 2..............................................................................................................17-10 Figure 17-7 Filtering interface........................................................................................................................ 17-11
Issue 02 (2007-06-10)
iii
Tables
Tables
Table 17-1 Function code of the NE user dynamic monitoring function..........................................................17-2 Table 17-2 Explanations of the Local Maintenance Monitor tabbed page........................................................17-3 Table 17-3 Specifications of the system ...........................................................................................................17-4 Table 17-4 Description of benefits....................................................................................................................17-4 Table 17-5 NEs that are involved in this function ............................................................................................17-5 Table 17-6 Version that supports this function..................................................................................................17-5
iv
Issue 02 (2007-06-10)
17 NE User Dynamic Monitoring Feature
17
NE User Dynamic Monitoring Feature
About This Chapter

The following table lists the contents of this chapter. Section 17.1 Function Description 17.2 Availability Describes The function code and definition of the service and the benefits of the service to carriers and mobile subscribers. The NEs required to implement the service, requirements for the license, and versions of the products applicable to the service. The functions of the NEs used to implement the service and the requirements on the networking. The flow of the service. The data configuration that must be performed at the MSOFTX3000 side and the UMG8900 side as well as the examples of function maintenance. The operations that carrier and mobile subscribers must perform when the service is provided. The procedure for performing charging and generating CDRs when the service is provided. The influence of the service on performance measurement and the implementation of performance measurement. The association between the service and other services as well as the restrictions on each other. The standards and specifications with which the service complies and the glossary, abbreviations, and acronyms used in this chapter. The frequently asked questions related to the service and the solutions.
17.3 Working Principle 17.4 Service Flow 17.5 Function Maintenance
17.6 Service Management 17.7 Charging and CDR 17.8 Performance Measurement 17.9 Service Interaction 17.10 References
17.11 FAQ
Issue 02 (2007-06-10)
17-1
17.1 Function Description

Table 17-1 specifies the function code of the NE user dynamic monitoring function. Table 17-1 Function code of the NE user dynamic monitoring function Name NE user dynamic monitoring function Code -
17.1.2 Definition
Through the network element (NE) user dynamic monitoring function, the network management system (NMS) monitors the operation information and status of online NE users in real time. The monitoring information is displayed on the Local Maintenance Monitor tabbed page on the M2000 client. Figure 17-1 shows the Local Maintenance Monitor tabbed page. For the explanations of the Local Maintenance Monitor tabbed page, see Table 17-2. Figure 17-1 Local Maintenance Monitor tabbed page
17-2
Issue 02 (2007-06-10)
Table 17-2 Explanations of the Local Maintenance Monitor tabbed page Item NE Name User Name User Type Login IP Login Time Service Definition Specifies the name of the login NE. By default, all names of the NEs that log in to the M2000 are specified. Specifies the name of the login user. By default, all names of the NEs that log in to the M2000 are specified. Specifies whether the user is a local user (LOCAL) or an NMS user (EMS). Specifies the IP address of the client that is connected to the NE. Specifies the login time of an NE user. Specifies the type of the service console through which the NE user logs in to the M2000, including O&M system and performance maintenance system. Specifies the login mode of an NE user, including by proxy (Yes) and not by proxy (No). Specifies the current status of an NE user, including online and unknown. A function button, used to display information in this page by selection. A function button, used to obtain the latest information. A function button, used to save all information displayed in the page. A function button, used to choose the operation results reported by the NE user. A function button, used to force a user to exit.
By proxy Status Filter Refresh Save Subscribe Force User to Exit
In this chapter, the NMS refers to the M2000.
17.1.3 Standard Compliance

None.
17.1.4 System Specifications

Table 17-3 lists the specifications of the system.
Issue 02 (2007-06-10)
17-3
Table 17-3 Specifications of the system Item NE user Specification It can be a local or domain user. Local user: It refers to users that are individually managed by each NE, including the default local user. The user of this type can log in to the NE for operation during system initial installation or disconnection from the NMS. Domain user: It refers to a user uniformly managed by the NMS. The user of this type is created, modified, authenticated or authorized by the NMS. After authorization, the user of this type can log in to the NE for operation, through the local maintenance terminal (LMT), and can also log in to the M2000 server for operation, through the M2000 client.
17.1.5 Benefits
Table 17-4 describes the benefits for the beneficiary. Table 17-4 Description of benefits Beneficiary Carrier Description The NMS can obtain the login information and manages NEs through monitoring the status of online users of all NEs. The NMS can monitor the operation of the users of all NEs in real time, and obtain data configuration updates. The network can implement the centralized management of NE users. By clicking Force User to Exit to disconnect a user from an NE, the NMS can prevent the user from performing subsequent operations. Mobile subscriber -
17.1.6 Application Scenario

This function applies to GSM and UMTS R99/R4.
17.1.7 Application Limitations

All the operations involved in this function must be performed on the M2000.
17.2 Availability
To implement this function, the M2000 must work with the MSC server. See Table 17-5.
17-4
Issue 02 (2007-06-10)
Table 17-5 NEs that are involved in this function UE NodeB RNC MSC Server MGW SGSN GGSN M2000
"" indicates the NE that is involved in this function.

No License is required for the availability of this function.

Table 17-6 shows the version of the HUAWEI core network (CN) that supports his function. Table 17-6 Version that supports this function Product MSC server MSOFTX3000 Applicable Version V100R005C10
17.2.4 Others
None.

The NE user dynamic monitoring function is implemented as follows: 1. 2. 3. The M2000 sends the corresponding commands to NEs. The NEs returns the command execution results to the M2000. The M2000, then, displays the result in the Local Maintenance Monitor pane.
Currently, the NE status displayed is reported by the NEs to the M2000 actively. The NMS need not monitor the operations of all NE online users because there are some operations that the NMS does not require. To monitor only the operations that are cared for by the NMS, a subscription and unsubscription mechanism is used between the NEs and NMS. To subscribe to users means to monitor the operations of the users; to unsubscribe to users means to cancel the monitoring of the operations of the users. Through the subscription and unsubscription mechanism, messages between the NEs and NMS are reduced, and the load of the NEs and NMS is lowered. The NE supports the forced disconnection from a user, through the disconnection command sent by the NMS. That is, the user is forced to exit the LMT and disconnect from the NE. After a user is disconnected from the NMS, the NE sends the disconnection message to the
Issue 02 (2007-06-10)
17-5
LMT that the user belongs to, through the operation and maintenance port. At this time, a message is displayed on the LMT, indicating that the user is forcedly disconnected from the NMS.
17.3.2 Internal Processing of the System

Function Implementation
The login and logout of an NE user need to be reported to the NMS. When the NMS first connects to an NE, the NMS obtains the status of the online users of the NE automatically. But the NE must take the initiative to update its data to the NMS later.
Implementation of Monitoring of NE Online User Operation

When the NMS issues a command for monitoring an NE user, the NE reports the operations of the user to the NMS immediately. When the NMS issues a command to cancel the monitoring of an NE user, the NE stops reporting the operations of the user to the NMS. To monitor the operations of all the users of an NE, the NMS sends a command for monitoring all the users of an NE. To cancel the monitoring of the operations of all the users of an NE, the NMS sends a command for canceling the monitoring of all the users of an NE.
Implementation of Forced Disconnection of Online User Operation

When an NE receives a command, indicating disconnection from a user, the NE disconnects from all the LMTs that the user logged in to. When an LMT is disconnected from the NE, a message is displayed, indicating that the user is forcedly disconnected from the NMS. After a user is disconnected from the NMS, the NE sends the disconnection message to the LMT that the user belongs to, through the operation and maintenance port. At this time, a message is displayed on the LMT, indicating that the user is forcedly disconnected from the NMS.
17.3.3 External Interfaces

None.
17.4 Service Flow

17.4.1 Monitoring Flow of Online User
The login and logout of an NE user must be reported to the NMS through synchronization. The NMS can automatically obtain the online user status of NEs for the first time connection. For the following data update, the NEs report the status to the NMS actively. The user of an NE that is monitored can be a local or domain user.
17.4.2 Reporting Flow of User Operation

The NMS issues commands for subscribing to monitoring to an NE. After receiving the commands, the NE reports the operations of the user to the NMS through the synchronization report interface. The NMS issues commands for unsubscribing to monitoring to an NE. After receiving the commands, the NE stops reporting the operations of the user to the NMS.
17-6
Issue 02 (2007-06-10)
17.4.3 Disconnection Flow of User Operation

When the NMS issues commands for forcing user to exit, the NE reports the disconnection message to the LMT to which the user belongs to. When the NE disconnects from the LMT, the LMT cancels the user login, indicating that the user is disconnected from the NMS.
17.5 Function Maintenance

17.5.1 Overview
The NE user dynamic monitoring function is performed through GUI mode on the M2000 client. The function includes: Subscription Canceling the subscription Querying user subscription information Forcing user to exit Filtering
17.5.2 Maintenance Operations

Subscription
To subscribe to the monitoring, perform the following steps: Step 1 Choose System > User Monitor on the M20000 client. The User Monitor interface is displayed, as shown in Figure 17-2.
Issue 02 (2007-06-10)
17-7
Figure 17-2 User Monitor interface
Step 2 Click the Local Maintenance Monitor tab and click Subscribe in the Local Maintenance Monitor tabbed page. The Subscribed NE List interface is displayed, as shown in Figure 17-3. Figure 17-3 Subscribed NE List interface
Step 3 Tick the NE to be subscribed.
17-8
Issue 02 (2007-06-10)
Step 4 Click OK. The subscription is completed. ----End
Canceling Subscription
The procedure for canceling the subscription is as follows: Step 1 Choose System > User Monitor on the M20000 client. The User Monitor interface is displayed, as shown in Figure 17-2. Step 2 Click the Local Maintenance Monitor tab and click Subscribe in the Local Maintenance Monitor tabbed page. The Subscribed NE List interface is displayed, as shown in Figure 17-3. Step 3 Deselect the NE to be un-subscribed. Step 4 Click OK. The canceling subscription operation is completed. ----End
Querying User Subscription Information

The procedure for querying user subscription information is as follows: Step 1 Choose System > User Monitor on the M20000 client. The User Monitor interface is displayed, as shown in Figure 17-2. Step 2 Click the Local Maintenance Monitor tab and click Subscribe in the Local Maintenance Monitor tabbed page. The Subscribed NE List interface is displayed, as shown in Figure 17-3. You can find that all subscribed NEs are ticked. Step 3 Click OK. The querying user subscription information operation is completed. ----End
Forcing User to Exit

The procedure for forcing user to exit is as follows: Step 1 Choose System > User Monitor on the M20000 client. The User Monitor interface is displayed, as shown in Figure 17-4.
Issue 02 (2007-06-10)
17-9
Figure 17-4 User Monitor interface
Step 2 Click the Local Maintenance Monitor tab and select the NE to be disconnected forcedly in the User Session interface, as shown in Figure 17-5. Figure 17-5 User Session interface 1
Step 3 Click Force User to Exit, as shown in Figure 17-6. The forcing user to exit operation is completed. Figure 17-6 User Session interface 2
----End
Filtering
The procedure for filtering is as follows: Step 1 Click Filter in the Local Maintenance Monitor interface to enter the filtering interface, as shown in Figure 17-7.
17-10
Issue 02 (2007-06-10)
Figure 17-7 Filtering interface
Step 2 Set conditions of the NE user to be filtered in the NE, User, Login IP, and Service panes. Step 3 Click OK. The system displays the information that meets the conditions to the Local Maintenance Monitor interface. ----End

None.

None.
17.8 Performance Measurement

None.

None.
Issue 02 (2007-06-10)
17-11
17.10 References
17.10.1 Standards and Specifications
None.
17.10.2 Glossary, Acronyms, and Abbreviations

Glossary
None.

Acronym/Abbreviation LMT Full Name Local Maintenance Terminal
17.11 FAQ
None.
17-12
Issue 02 (2007-06-10)
Contents
Contents
18 SMS Notification for Call Failure Feature ........................................................................18-1
18.1 Service Description ...................................................................................................................................18-2 18.1.1 Function Code..................................................................................................................................18-2 18.1.2 Definition .........................................................................................................................................18-2 18.1.3 Benefits ............................................................................................................................................18-2 18.2 Availability ................................................................................................................................................18-3 18.2.1 Requirements for NEs......................................................................................................................18-3 18.2.2 Requirements for License ................................................................................................................18-3 18.2.3 Applicable Versions..........................................................................................................................18-3 18.3 Working Principle......................................................................................................................................18-3 18.3.1 Functions of Each NE ......................................................................................................................18-3 18.3.2 Internal Processing...........................................................................................................................18-4 18.4 Service Flow..............................................................................................................................................18-6 18.4.1 Prerequisites for Service Triggering.................................................................................................18-6 18.4.2 Service Triggering Point ..................................................................................................................18-7 18.4.3 Processing Flow After Service Triggering .......................................................................................18-8 18.5 Data Configuration..................................................................................................................................18-10 18.5.1 Data Configuration on the MSOFTX3000.....................................................................................18-10 18.5.2 Data Configuration Sample............................................................................................................18-10 18.6 Service Management ............................................................................................................................... 18-11 18.6.1 Operations by Carriers ...................................................................................................................18-12 18.6.2 Operations by Subscribers .............................................................................................................18-13 18.7 Charging and Charging Data Record (CDR)...........................................................................................18-13 18.7.1 CDR of the SMMO........................................................................................................................18-13 18.7.2 CDR of the SMMT ........................................................................................................................18-13 18.7.3 Charging.........................................................................................................................................18-13 18.8 Service Interaction ..................................................................................................................................18-13 18.8.1 Call Service....................................................................................................................................18-13 18.8.2 SM Service.....................................................................................................................................18-13 18.8.3 Call Forwarding Service ................................................................................................................18-13 18.8.4 Voice Mailbox Service ...................................................................................................................18-14 18.9 Reference ................................................................................................................................................18-14
Issue 02 (2007-06-10)
Contents
HUAWEI MSOFTX3000 Feature Description 18.9.1 Protocols and Specifications ..........................................................................................................18-14 18.9.2 Aronyms and Abbreviations...........................................................................................................18-14
ii
Issue 02 (2007-06-10)
Figures
Figures
Figure 18-1 Processing flow of SMS notification for call failure triggered in the GMSC...............................18-5 Figure 18-2 Processing flow of SMS notification for call failure generated in the VMSC..............................18-6 Figure 18-3 Triggering point of SMS notification for call failure in the GMSC..............................................18-7 Figure 18-4 Triggering point of SMS notification for call failure in the VMSC..............................................18-8 Figure 18-5 Processing flow after SMS notification for call failure is triggered..............................................18-9
Issue 02 (2007-06-10)
iii
Tables
Tables
Table 18-1 Benefits of SMS notification for call failure ..................................................................................18-2 Table 18-2 Requirements for NEs ....................................................................................................................18-3 Table 18-3 Applicable versions.........................................................................................................................18-3 Table 18-4 Script for querying the License.....................................................................................................18-10 Table 18-5 Script for setting MAP parameter ................................................................................................. 18-11 Table 18-6 Script for adding the content of SMS notification for call failure ................................................ 18-11 Table 18-7 Script for configuring the processing for SMS notification for call failure .................................. 18-11
iv
Issue 02 (2007-06-10)
18 SMS Notification for Call Failure Feature
18
Section
SMS Notification for Call Failure Feature
About This Chapter

18.2 Availability
18.7 Charging and Charging Data Record (CDR) 18.8 Service Interaction 18.9 Reference
Issue 02 (2007-06-10)
18-1

The SMS notification for call failure does not have a function code.
18.1.2 Definition
SMS notification for call failure informs the callee of missed calls by sending the Short Message (SM). When there is a missed call, the network sends an SM to inform the callee of the date, time and calling number of the missed call. SMS notification for call failure is a network level service. There is no limit on the number of subscribers. If the following exception occurs, the network triggers the service: The callee switches off. The callee is unreachable. The callee is busy. The callee does not answer the call.
18.1.3 Benefits
Table 18-1 lists the benefits of SMS notification for call failure. Table 18-1 Benefits of SMS notification for call failure Beneficiary Carrier Description SMS notification for call failure is a kind of compensation service that provides more compensation measures for subscribers when they cannot answer the call. Notification messages are edited according to the type of call failure. Subscribers can clearly learn the specific causes of missed calls. The service can be provided in two modes: The subscribers do not need to subscribe to the service in the HLR. The service is free of charge, which improves the customer satisfaction. The subscribers subscribe to the HLR. The carriers charge the subscribers with certain amount of fees, which increases the service profit. At present, the former mode is adopted. Mobile Subscriber SMS notification for call failure provides one more choice of compensation service for subscribers. It can reduce the loss resulted from missed calls. Subscribers can clearly learn the specific causes of the missed call, calling number, date and time of the call.
18-2
Issue 02 (2007-06-10)
18.2 Availability
Table 18-2 gives the required network elements (NEs) for SMS notification for call failure service. Table 18-2 Requirements for NEs UE/MS Node B/BTS RNC/BS C MSC Server MG W SMSC VLR HLR
The symbol indicates that the NE is required.

SMS notification for call failure is an optional attribute of Huawei wireless core network. The service can be provided only when the corresponding License is obtained.

Table 18-3 lists the versions of the Huawei CN products that support SMS notification for call failure. Table 18-3 Applicable versions Product MSC server MSOFTX3000 Applicable Version V100R005 and later versions

18.3.1 Functions of Each NE
Three NEs are involved in the SMS notification for call failure service: MSC, HLR and SMSC. The Gateway Mobile Switching Center (GMSC) or Visited Mobile Switching Center (VMSC) provides the following functions: Processing signaling. Analyzing data. Editing and sending notification messages for call failure.
Issue 02 (2007-06-10)
18-3
If the callee is absent in the call (turnoff, roaming not allowed, deleted in the VMSC or unreachable), the HLR sends the information that the subscriber is absent in the SRI ACK message to the GMSC, to complete preparation for triggering the service. The Short Message Service Center (SMSC) receives and sends the call failure SM.
18.3.2 Internal Processing

SMS notification for call failure is triggered at every abnormal point during a call, that is, when the callee cannot answer the call. SMS notification for call failure, call forwarding and voice mailbox compensate for the loss resulted from the call missing. However, the former collides with the latter two services. It can be triggered only when both call forwarding and voice mailbox are not activated. SMS notification for call failure is triggered when the following exception occurs: The GMSC detects in the SRI message that the callee is absent. After the call is routed to the VMSC, the VMSC detects that the callee switches off or is not allowed to roam. After the call is routed to the VMSC, there is no paging response or the response times out. After the call is routed to the VMSC, the VMSC detects that the callee is busy. After the call is routed to the VMSC, the VMSC detects that the network encounters congestion. After the call is routed to the VMSC, the callee does not answer the call. According to triggering places, the processing flow of SMS notification for call failure is classified into two types: GMSC Triggers SMS Notification for Call Failure. VMSC Triggers SMS Notification for Call Failure.
GMSC Triggered SMS Notification for Call Failure

If the GMSC detects that the callee is absent, it triggers SMS notification for call failure. The processing flow is as shown in Figure 18-1.
18-4
Issue 02 (2007-06-10)
Figure 18-1 Processing flow of SMS notification for call failure triggered in the GMSC
MS
(V)MSC SETUP IAM
(G)MSC
HLR
SMSC
MAP_SEND_ROUTING_INF O_REQ MAP_SEND_ROUTING_INF O_CNF
MO_FORWARD_SM_ARG
MO_FORWARD_SM_RES
The processing flow is as follows: 1. 2. 3. 4. 5. 6. The Mobile Station (MS) sends the SETUP request to the VMSC of the MS. The VMSC sends the IAM message to the GMSC. The GMSC sends the MAP SRI REQ message to the HLR of the callee. If the HLR detects that the callee is absent. The HLR then sends the information to the GMSC in the MAP SRI CNF message. The GMSC triggers SMS notification for call failure, edits the content of the message, and sends the MO FORWARD SM ARG message to the SMSC. The SMSC returns MO FORWARD SM RES message to the GMSC.
VMSC Triggered SMS Notification for Call Failure

The VMSC triggers SMS notification for call failure when the following exception occurs: After the call is routed to the VMSC, the VMSC detects that the callee switches off or the roaming is not allowed. After the call is routed to the VMSC, there is no paging response or the response times out. After the call is routed to the VMSC, the VMSC detects that the callee is busy. After the call is routed to the VMSC, the VMSC detects that the network encounters congestion. After the call is routed to the VMSC, the callee does not answer the call. The processing flow is as shown in Figure 18-2.
Issue 02 (2007-06-10)
18-5
Figure 18-2 Processing flow of SMS notification for call failure generated in the VMSC
(G)MSC
(V)MSC
RNC/BSC
MS
IAM PAGING PAGING SETUP SETUP
The processing flow is as follows: 1. 2. 3. 4. 5. 6. 7. 8. The GMSC sends the IAM request to the VMSC of the callee according to the Mobile Station Roaming Number (MSRN). If the VMSC detects that the callee switches off or is not allowed to roam, it triggers SMS notification for call failure. If the VMSC detects that the callee is busy, it triggers SMS notification for call failure. If the conditions in 2 and 3do not happen, the VMSC sends PAGING to the MS. If the MS does not reply to the PAGING or the PAGING response times out, the VMSC triggers the SMS notification for call failure. After receiving the PAGING response, the VMSC sends the SETUP message to the MS and sends channel assignment request to the MGW. If the wireless channel is congested and thus channel assignment fails, the VMSC triggers the SMS notification for call failure. If the MS does not answer the call after alerting, the VMSC triggers the SMS notification for call failure.
In most cases, SMS notification for call failure is triggered in the VMSC. The subsequent flow after triggering is almost the same. For more information, see Figure 19-5.
18.4 Service Flow

SMS notification for call failure is mainly used to compensate for abnormal situations in call service.
18.4.1 Prerequisites for Service Triggering

To trigger this service, the following must be met: The callee does not subscribe to the forwarding service. The callee does not subscribe to the voice mailbox.
18-6
Issue 02 (2007-06-10)
The GMSC and VMSC apply for the License of SMS notification for call failure. The GMSC and VMSC activate the SMS notification for call failure service. The CPU is not overloaded.
18.4.2 Service Triggering Point

Service Triggering Point in the GMSC
The GMSC receives the SRI ACK message from the HLR and detects that the callee is absent. Then the GMSC triggers SMS notification for call failure service. The triggering point is as shown in Figure 18-3. Figure 18-3 Triggering point of SMS notification for call failure in the GMSC
(G)MSC
HLR
MAP_SEND_ROUTING_INFO_REQ
MAP_SEND_ROUTING_INFO_CNF
The callee is absent.
The processing flow is as follows: 1. 2. 3. The GMSC sends the MAP SRI REQ message to the HLR of the callee. The HLR sends the information that the callee is absent to the GMSC in the MAP SRI CNF message. The GMSC triggers the SMS notification for call failure when receiving the information that the callee is absent.
Service Triggering Point in the VMSC

The triggering points of SMS notification for call failure in the VMSC are as shown in Figure 18-4:
Issue 02 (2007-06-10)
18-7
Figure 18-4 Triggering point of SMS notification for call failure in the VMSC
(G)MSC IAM
(V)MSC
RNC/BSC
The callee switches off or roaming not allowed. The network is busy. PAGING There is no response to the PAGING message. PAGING response times out. SETUP Wireless channel is congested. The callee does not reply.
The processing flow is as follows: 1. 2. 3. 4. 5. 6. 7. 8. 9. The GMSC sends IAM message to the VMSC. If the VMSC detects that the callee switches off or is not allowed to roam, skip to Step 9. If the VMSC detects that the callee is busy, skip to Step 9. If conditions in Step 2 and Step 3 do not happen, the VMSC sends the PAGING message to the callee. If there is no PAGING response or the PAGING response times out, skip to Step 9. When receiving the PAGING response, the VMSC sends the SETUP message to the callee and sends channel assignment request to the MGW. If the wireless channel is congested and channel assignment fails, skip to Step 9. If the callee does not answer the call after alerting, skip to Step 9. The VMSC triggers the SMS notification for call failure.
18.4.3 Processing Flow After Service Triggering

The processing flow of the MSC after triggering the SMS notification for call failure is shown in Figure 18-5.
18-8
Issue 02 (2007-06-10)
Figure 18-5 Processing flow after SMS notification for call failure is triggered
MS RNC/BSC (G/V)MSC SMSC HLR
MO_FORWARD_SM Trigger SMS notification for call failure. MO_FORWARD_SM ACK SEND_ROUTING_INFO_F OR_SM SEND_ROUTING_INFO_F OR_SM ACK MT_FORWARD_SM PAGING PAGING PAGING ACK PAGING ACK CP_DATA CP_DATA CP_DATA ACK CP_DATA ACK MT_FORWARD_SM ACK
The processing flow is as follows: 1. 2. 3. 4. 5. 6. 7. 8. After editing the SM for call failure, the GMSC or VMSC sends it to the SMSC. The SMSC receives the SM and sends the response message to the GMSC or VMSC. The SMSC sends SRI FOR SM message to the HLR of the callee to require the routing information of the callee. The HLR sends the routing information of the callee (the number in the VMSC) to the SMSC. The SMSC sends the MT FORWARD SM request to the VMSC according to the routing information returned by the HLR. After receiving the MT FORWARD SM request, the VMSC sends the PAGING request to the MS. The VMSC receives Paging ACK message from the MS, and sends the content of the SM to the MS. After receiving the response message that the MS has received the short message content, the VMSC sends MT FORWARD SM ACK to the SMSC.
Issue 02 (2007-06-10)
18-9

To configure the data of SMS notification for call failure service, perform the following steps: Step 1 Run DSP LICENSE to check whether there is a License that supports SMS notification for call failure. If not, apply for one and run LOD LICENSE to load the file of License that supports this service. Step 2 Run LST MAPPARA to check whether the function of SMS notification for call failure is enabled. If not, run SET MAPPARA to enable it. Step 3 Run ADD SMCONT to edit the content of SM for call failure, including coding scheme, format of call failure date and time. Then run LST SMCONT to query the result. Step 4 Run ADD CFSMSPRO to add the related call failure data for a certain callee, including the supported call failure type, address of the SMS, calling number (the number at the network side) and SM content index. Then run LST CFSMSPRO to query the result. ----End
18.5.2 Data Configuration Sample

Scenario 1
Subscriber A dials B. If B switches off, the GMSC of A triggers the SMS notification for call failure service.
The steps for configuring data in the GMSC of subscriber A are as follows: Step 1 Query the License. Table 18-4 Script for querying the License Description Script Note Query the License to check whether it supports the SMS notification for call failure service. DSP LICENSE:; If the loaded License does not support the SMS notification for call failure service, load the License that supports this function.
18-10
Issue 02 (2007-06-10)
Step 2 Set MAP parameter. Table 18-5 Script for setting MAP parameter Description Script Set MAP parameter to enable the SMS notification for call failure function. SET MAPPARA: SUPCFSMSIND = YES;
Step 3 Add the content of SMS notification for call failure. Table 18-6 Script for adding the content of SMS notification for call failure Description Script Add the content of SMS notification for call failure. ADD SMCONT: SCNAME="A", CSCH=BIT7, CFDATEFMT=YMD, CFTIMEFMT=H24, CONTENT="You have an incoming call from";
Step 4 Configure the processing for SMS notification for call failure. Table 18-7 Script for configuring the processing for SMS notification for call failure Description Script Configure the processing for SMS notification for call failure. ADD CFSMSPRO: CFT=POFF-1&NR-1&BUSY-1&NA-1, TCID=K'8613907550463, SRVCTR=K'8613900007555, OCID=K'1860, SMVT=H12, SCNAME="A"; The processing configuration is intended for subscriber B.
Note
----End

The service management of SMS notification for call failure includes: Providing: The carriers perform operations to enable the service for the subscribers. It is opposite to withdrawing the service. Withdrawing: The carriers perform operations to disable the service for the subscribers. Registering: The carriers perform operations in the GMSC or VMSC to make the service executable. For example, they configure the related data information in SMS notification for call failure of certain type (switch off, unreachable, the callee busy and no answer) for a subscriber. Deregistering: The carriers delete the related information of the subscribers. It is opposite to registering. The service is activated during the registration. There is no need to perform other operations.
Issue 02 (2007-06-10)
18-11

The carriers can provide, withdraw, register and deregister the service through the GMSC and VMSC maintenance console.
Providing
Step 1 Run DSP LICENSE to query whether the License supports the SMS notification for call failure service. If it does, skip to Step 3. Step 2 If the License does not support the service, run LOD LICENSE to load the License of SMS notification for call failure. Step 3 Run LST MAPPARA to query whether the GMSC or VMSC supports the SMS notification for call failure service. Step 4 Run SET MAPPARA to provide the SMS notification for call failure service, that is, set the parameter Support call failed SM indication to TRUE. ----End
Withdrawing
Step 1 Run LST MAPPARA to query whether the GMSC or VMSC supports the SMS notification for call failure service. Step 2 Run SET MAPPARA to withdraw the SMS notification for call failure service, that is, to set the parameter Support call failed SM indication to FALSE. ----End
Registering
Step 1 Run LST SMCONT to query the setting of SM content for call failure. Step 2 Run ADD SMCONT to add the content of SM for call failure, that is, send specific content to the callee when the call fails. Step 3 Run LST CFSMSPRO to query the configuration of SMS notification for call failure. Step 4 Run ADD CFSMSPRO to add related data of the designated subscriber to complete the registration with the service for the subscriber. ----End
Deregistering
Step 1 Run LST CFSMSPRO to query the configuration of SMS notification for call failure. Step 2 Run RMV CFSMSPRO to delete related data of the designated subscriber to cancel the registration with the service for this subscriber. ----End
18-12
Issue 02 (2007-06-10)
18.6.2 Operations by Subscribers

As long as the carrier provides and registers with the SMS notification for call failure for the subscriber in the GMSC or VMSC, the subscriber can enjoy this service without performing any operation.
18.7 Charging and Charging Data Record (CDR)

18.7.1 CDR of the SMMO
SMS notification for call failure is originated at the network side. Therefore, no CDR of Short Message Mobile Originated (SMMO) is provided.
18.7.2 CDR of the SMMT

The Short Message Mobile Terminated (SMMT) flow of SMS notification for call failure is the same as the common SMMT flow. Therefore, the CDR of SMMT is the same as that of ordinary SMMT. For example, if A calls B and the call fails, B will receive the SM for call failure and the ordinary CDR is generated.
18.7.3 Charging
The carriers decide whether to charge for SMS notification for call failure. At present, they do not charge for the service.

This section introduces the interaction of SMS notification for call failure with other services.
18.8.1 Call Service

The SMS notification for call failure is triggered when exception occurs during a call.
18.8.2 SM Service
SMS notification for call failure is realized in the form of SMS. It differs from common SMS in that: common SMS is originated by the MS while the SMS notification for call failure is originated by the network. The SMMT flows are the same.
18.8.3 Call Forwarding Service

SMS notification for call failure conflicts with the forwarding service, and the latter enjoys higher priority. That is, if the call forwarding service is activated, SMS notification for call failure cannot be enabled. The common ground is that the service triggering points are the same.
Issue 02 (2007-06-10)
18-13
18.8.4 Voice Mailbox Service

SMS notification for call failure conflicts with voice mailbox service, and the latter has higher priority. That is, if the voice mailbox is activated, SMS notification for call failure cannot be enabled. The common ground is that the service triggering points are the same.
18.9 Reference
None.
18.9.2 Aronyms and Abbreviations

Acronym/Abbreviation HLR IAM MS SMSC SMMO SMMT VLR Full Name Home Location Register Initial Address Message Mobile Station Short Message Service Centre Short Message Mobile Originated Short Message Mobile Terminated Visitor Location Register
18-14
Issue 02 (2007-06-10)
Contents
Contents
19 Summer Time Feature of Wireless Time Zone ................................................................19-1
19.1 Feature Description ...................................................................................................................................19-2 19.1.1 Function Code..................................................................................................................................19-2 19.1.2 Definition .........................................................................................................................................19-2 19.1.3 Benefits ............................................................................................................................................19-3 19.2 Availability ................................................................................................................................................19-3 19.2.1 Requirement for NEs .......................................................................................................................19-3 19.2.2 Requirement for License..................................................................................................................19-3 19.2.3 Applicable Versions..........................................................................................................................19-3 19.3 Working Principle......................................................................................................................................19-4 19.4 Data Configuration....................................................................................................................................19-5 19.4.1 Data Configuration for the MSOFTX3000 ......................................................................................19-5 19.4.2 Example ...........................................................................................................................................19-6 19.5 Charging and CDR ....................................................................................................................................19-7 19.6 Service Interaction ....................................................................................................................................19-8 19.7 Reference ..................................................................................................................................................19-8 19.7.1 Protocols and Specifications ............................................................................................................19-8 19.7.2 Acronyms and Abbreviations ...........................................................................................................19-8
Issue 02 (2007-06-10)
Figures
Figures
Figure 19-1 Synchronization relationship between the NTP server, BAM server, and the host.......................19-4 Figure 19-2 Time icon of Windows2000 operating system..............................................................................19-5 Figure 19-3 Adjusting clock for daylight saving changes ................................................................................19-6
ii
Issue 02 (2007-06-10)
Tables
Tables
Table 19-1 Name and function code of the summer time feature .....................................................................19-2 Table 19-2 NEs related to the summer time feature of the wireless time zone.................................................19-3 Table 19-3 Versions that support the summer time feature of the wireless time zone ......................................19-3 Table 19-4 Alarms related to summer time.......................................................................................................19-5
Issue 02 (2007-06-10)
iii
19 Summer Time Feature of Wireless Time Zone
19
Section
Summer Time Feature of Wireless Time Zone
About This Chapter

The following table lists the contents of this chapter. Describes The function code, function definition of this feature, and the benefits that carriers and mobile subscribers can obtain from this feature. The network elements (NEs) that are required for the feature, whether Licenses are required, and the version requirements of the NEs. The functions of the NEs, and networking requirements. The data configurations that are required on the MSOFTX3000 and the IMG8900. The charging and the generation of CDRs when the network provides this feature. The relationships and restrictions between this feature and other services or features. The protocols and specifications that this feature must comply with, and the acronyms and abbreviations of this chapter.
19.1 Feature Description 19.2 Availability 19.3 Working Principle 19.4 Data Configuration 19.5 Charging and CDR 19.6 Service Interaction 19.7 Reference
Issue 02 (2007-06-10)
19-1

Table 19-1 lists the name and function code of the summer time feature. Table 19-1 Name and function code of the summer time feature Name Summer time feature of wireless time zone Code None
19.1.2 Definition
Concept of Time Zone
The world time zones are divided based on the prime meridian. The initial time zone covers the west 7.5 to east 7.5 (with a width of 15). From the initial zone eastward and westward, the surface of the earth is divided into 14 and 12 time zones respectively. The GMT+14 time zone overlaps with the GMT-12 time zone. In this way, the surface of the earth is longitudinally divided into 26 time zones, and every neighboring two time zones observe a clock time one hour offset (some neighboring time zone offsets are 30 minutes or 15 minutes). In the same time zone, you can observe sunrise from the east part and the west part respectively within one hour. The time zone boundaries are geographic longitudes in principle. In actual practice, however, they are substituted by the regional boundaries or natural boundaries for easy application. At present, most of the countries use the standard time with the unit zone time. The standard time has hour(s) offset from the GMT. Some countries, however, still use the local time of the capital or some important commercial ports as the standard time. Thus, the offset between the standard time of these countries and that of the GMT is in precision of minute.
Concept of Summer Time

Summer time is a lawfully defined time, which is also called daylight saving time. It is first proposed by the American inventor and politician Benjamin Franklin. He points out that the day breaks earlier in summer, and that we can set out clock backward so that the daylight time can be prolonged. In most of the countries that use the summer time, the summer time is usually one hour (it varies with different countries) later than the standard time. For example, during the summer time, the eastern standard time 10:00 am. becomes the eastern summer time 11:00 am. The application of summer time makes full use of the sunshine and saves fuels and electricity, thus the expenditure on lighting and electricity is reduced. Currently, about 70 countries including Europe and North American countries have implemented the summer time.
19-2
Issue 02 (2007-06-10)
19.1.3 Benefits
Beneficiary Carrier Description In those regions that use the summer time, the carriers can configure the system time of the MSOFTX3000 to accommodate all the services to the summer time. The services provided by the carrier comply with the time habit of the subscribers, thus the subscribers can enjoy the services more conveniently.
Mobile subscriber
19.2 Availability
The summer time feature of the wireless time zone requires the corporation of the MSC server and the HLR. Table 19-2 lists the NEs related to the summer time feature of the wireless time zone. Table 19-2 NEs related to the summer time feature of the wireless time zone UE/MS NodeB/ BTS RNC/BSC MSC Server MGW SGSN VLR HLR
stands for the related NEs.

Summer time feature of the wireless time zone is a basic feature of the Huawei wireless core network. You can obtain this service without any license.

Table 19-3 lists the Huawei UMTS RAN product versions that support the summer time feature of the wireless time zone. Table 19-3 Versions that support the summer time feature of the wireless time zone Product MSC Server MSOFTX3000 Applicable Versions V100R005 and the later versions
Issue 02 (2007-06-10)
19-3

The configuration of the time zone and summer time only requires the modification of the local time. The NTP synchronization, however, uses only the Greenwich Mean Time (GMT) without involving the time zone and summer time. Therefore, the configuration of the time zone and summer time does not affect the NTP service. On the other hand, the NTP server can only rectify the GMT of the BAM server, which exerts no impact on the configuration of the BAM time zone and summer time. The configuration of the time zone and summer time is managed only by the BAM server itself, as shown in Figure 19-1. Figure 19-1 Synchronization relationship between the NTP server, BAM server, and the host
NTP server
GM
ne zo e er tim m s t um ho d s ift e n fy th e a s h cti t y re hos tif ang time ly No c h a l th e dic of 1 rio e Pe tim e 2 th
Host
Time informaton: (BAM Loacal time + time zone+ summer time offset) BAM
When modifying the time zone configuration of the BAM server, the local time of the system in which the BAM resides changes accordingly. In the following example, if: GMT is 00:00:00 Time zone of the BAM is GMT+7 Local time of the BAM is 07:00:00 If you set the time zone of the BAM to GMT+8 by using the command SET TZ, the local time of the BAM changes to 08:00:00 immediately. Then the BAM server sends the modified time zone and local time to the host at once. When it reaches the summer time shift point (the beginning time point or the end time point of the summer time), the local time of the BAM server is set according to the synchronization mode between the BAM server and NTP server: If the BAM is configured with an effective NTP server, the BAM performs automatically time synchronization with the NTP server if it is in normal communication with the NTP server. Then the BAM server adjusts the local time according to the configuration of the summer time. If the BAM is not configured with an effective NTP server, or the BAM is disconnected with all the NTP servers, the BAM does not perform time synchronization with the NTP server. The BAM server adjusts the local time directly according to the configuration of the summer time.
19-4
Issue 02 (2007-06-10)
Once the local time is adjusted, the BAM server synchronizes immediately the local time, time zone, and the summer time with the host. The BAM server also notifies the service processes the summer time. In addition, when it reaches the summer time shift point, the BAM server raises the "Enter daylight saving time" or "Leave daylight saving time" alarm. Table 19-4 lists the detailed alarm information. Table 19-4 Alarms related to summer time Alarm Number 836 837 Alarm Type Event Event Alarm Name Enter daylight saving time Leave daylight saving time Cause The BAM enters the summer time. The BAM leaves the summer time.
If it is in the summer time, the MML message head contains the summer time information. When in summer time, a DST is suffixed to indicate the summer time, for example, 2006-03-21 15:25:58 DST.

19.4.1 Data Configuration for the MSOFTX3000
Preparation
The implementation of the summer time of the MSOFTX3000 is totally independent of the summer time function of the Windows2000. Therefore, when activating the summer time function of the MSOFTX3000, you need to shut down the automatic summer time adjusting of the Windows2000 operating system in which the BAM resides. Otherwise, the consistency between the time of the BAM sever and that of the host and the implementation of the MSOFTX3000 summer time will be affected. To shut down the automatic summer time adjusting of the Windows2000 operating system, do as follows: Step 1 Double-click the time icon at the bottom right of the Windows2000 system interface, as shown in Figure 19-2. Figure 19-2 Time icon of Windows2000 operating system
Step 2 In the Time Zone tab, unselect Automatically adjust clock for daylight saving changes if is selected, and then select the correct time zone from the drop-down list. Click Apply and then OK, as shown in Figure 19-3.
Issue 02 (2007-06-10)
19-5
Figure 19-3 Adjusting clock for daylight saving changes
----End
Procedure
To perform data configuration, do as follows: Step 1 Check the configuration information of the BAM time zone and summer time by using the command LST TZ. Step 2 Configure the time zone and summer time of the BAM server by using the command SET TZ. ----End
19.4.2 Example
Scenario
The BAM server is in GMT-6, and the country in which the BAM server resides uses the summer time. The rule for implementing the summer time is as follows: In the wee hours of the last Sunday of every March, set the clock one hour forward when it shifts from the non-summer time to summer time. In the wee hours of the last Sunday of every October, set the clock one hour backward when it shifts from the summer time to non-summer time.
19-6
Issue 02 (2007-06-10)
Scripts for Configuration

To perform data configuration for time zone and summer time, do as follows: Step 1 Set the time zone and summer time. Description Script Setting the time and summer time. SET TZ: ZONET=GMT-0600, DST=YES, SM=WEEK, SMONTH=MAR, SWSEQ=LAST, SWEEK=SUN, ST=00&00&00, EM=WEEK, EMONTH=OCT, EWSEQ=LAST, EWEEK=SUN, ET=00&00&00, TO=60;
Step 2 Query the time zone and summer time. Description Script Querying the time zone and summer time. LST TZ:;
----End

The MSOFTX3000 supports configuration of time zone and summer time through the MML commands. The time zone and summer time, however, have different influence on the call detail record (CDR), alarms, and logs. After the operator configures the BAM time zone by using the MML command, the host records the time zone information for each gateway or trunk group only in the gateway data table or trunk data table. This time zone affects only the absolute time in the CDR, such as the callee answering time, callee terminating time, call establishing time, wireless channel assigned time, and ringing time. The time adjusting principle for charging and CDR is as follows: If the call is paid by the calling party, the system adjusts the time segment in the CDR based on the time zone of the calling party. If the call is paid by the called party, the system adjusts the time segment in the CDR based on the time zone of the called party. That is, the talk time and charging are not affected by the BAM time change caused by the change of the time zone. If the time zone changes during the call session, the callee answering time, callee terminating time, call establishing time, wireless channel assigned time, and ringing time are affected. After the operator configures the summer time of the BAM server through the MML command, the BAM time is adjusted immediately if it reaches the summer time shift point. The BAM then sends the adjusted time and the summer time offset to the host for synchronization. Therefore, the configuration of the summer time affects the absolute time in the CDR, alarms, and logs. Once the summer time starts, there will be a blank area in the local time of the NE. On the contrary, when the summer time ends, there will be an overlapped area in the local time of the NE. Therefore, relevant processing is required for traffic statistics, CDR, and the charging
Issue 02 (2007-06-10)
19-7
system that uses the local time. Take the traffic statistics for example, when there is an overlapped area in the local time, the traffic of the overlapped time area will be accumulated. In this way, the traffic statistics of the overlapped area is counted. For the traffic statistics and charging of different time zones, if the local time is involved, you need to convert the time of different time zones according to the local time and the summer time.

The settings of the time zone and summer time affect the network management services. If the summer time starts or the time zone changes, the BAM system time shifts accordingly. This shift, however, is only reflected in the local time and it does not affect the GMT, that is, the time controller of the network management system is not affected. The network management system can query the time zone and summer time information of a certain NE by using commands, and then calculates the local time of the NE according to the time zone and summer time of the NE. The network management system delivers tasks to the NE based on the local time of the NE. On the other hand, the network management system can also convert the local time contained in the reported messages by the NE to the local time of the network management system or the GMT according to the time zone and summer time of the NE.
19.7 Reference
None.

Acronym/Abbreviation BAM GMT HLR MML NTP VLR Full Name Back Administration Module Greenwich Mean Time Home Location Register Human-Machine Language Network Time Protocol Visitor Location Register
19-8
Issue 02 (2007-06-10)
Contents
Contents
20 Version Software Management Feature ............................................................................20-1
20.1 Service Description ...................................................................................................................................20-2 20.1.1 Function Code..................................................................................................................................20-2 20.1.2 Definition .........................................................................................................................................20-2 20.1.3 Benefits ............................................................................................................................................20-2 20.2 Availability ................................................................................................................................................20-2 20.2.1 Requirements for NEs......................................................................................................................20-2 20.2.2 License Support ...............................................................................................................................20-3 20.2.3 Applicable Version ...........................................................................................................................20-3 20.3 Working Principle......................................................................................................................................20-3 20.4 Patch Operation Flow................................................................................................................................20-4 20.5 Data Configuration....................................................................................................................................20-6 20.5.1 Data Configuration at the MSOFTX3000........................................................................................20-6 20.5.2 Data Configuration at the UMG8900 Side.......................................................................................20-8 20.6 Service Management .................................................................................................................................20-8 20.6.1 Uploading Patch to The M2000 Server............................................................................................20-9 20.6.2 Operating Patch..............................................................................................................................20-10 20.7 Charging and CDR ..................................................................................................................................20-12 20.8 Service Interaction ..................................................................................................................................20-12 20.9 Reference ................................................................................................................................................20-12
Issue 02 (2007-06-10)
Figures
Figures
Figure 20-1 Patch operation flow .....................................................................................................................20-5
ii
Issue 02 (2007-06-10)
Tables
Tables
Table 20-1 Network elements concerning with version software management features ..................................20-3 Table 20-2 Applicable versions for the version software management features ...............................................20-3 Table 20-3 MML command table for patch management.................................................................................20-7
Issue 02 (2007-06-10)
iii
20 Version Software Management Feature
20
About This Chapter
Section
Version Software Management Feature
The following table lists the contents of this chapter. Describes The function code, function definition of this feature, and the benefits that carriers and mobile subscribers can obtain from this feature. The network elements (NEs) that are required for the feature, whether Licenses are required, and the version requirements of the NEs. The functions of the NEs, and networking requirements. The service flow of the network when providing this feature. The data configurations that are required on the MSOFTX3000 and the IMG8900. The service operations that carriers and mobile subscribers are required to implement when the network provides this feature. The charging and the generation of CDRs when the network provides this feature. The relationships and restrictions between this feature and other services or features. The protocols and specifications that this feature must comply with, and the acronyms and abbreviations of this chapter.
20.2 Availability
20.3 Working Principle 20.4 Patch Operation Flow 20.5 Data Configuration 20.6 Service Management
Issue 02 (2007-06-10)
20-1

Function Name Version software management features Function Code None.
20.1.2 Definition
The software management is a feature in the operation and maintenance field. That is, through the operation and maintenance center or the network management, the following functions can be realized: Manage the version software and data configuration of network elements within the dominated field Realize the lot-size transmission, loading and activation of program and data configuration Therefore, the efficiency and quality of the system maintenance and network element management can be greatly improved.
The version adaptation for software management must be considered. The feature introduces how to load hot patch for the system when the MSOFTX3000 is managed by the M2000 uniformly.
20.1.3 Benefits
Beneficiary Carrier Description Through the maintenance center software and network management software, the carrier can transmit, upload and activate the lot-size files; therefore, the operation efficiency of upgrading, data uploading is improved. Besides, through version identification, the operation quality is also greatly improved. None.
Mobile subscriber
20.2 Availability
The MSC server and the M2000 are required to complete the version software management features, as listed in Table 20-1.
20-2
Issue 02 (2007-06-10)
Table 20-1 Network elements concerning with version software management features UE/ MS Node B/BTS RNC/ BSC MSC Server MGW M2000 SGSN GGSN HLR -
indicates the network elements involved.
20.2.2 License Support

Version software management features are the basic feature of HUAWEI wireless core network, of which services can be obtained without getting License requirement.

The applicable versions of version software management features for HUAWEI core network (CN) products are as listed in Table 20-2. Table 20-2 Applicable versions for the version software management features Product MSC Server MSOFTX3000 Applicable Version V100R005 and subsequent versions

The MSC server cooperates with the M2000 to realize the version software management features. M2000: delivers the commands of transmission, uploading and activation and data information to the managed NEs. MSC Server: accepts and checks the commands and the data sent by the M2000; therefore, the auto upgrading of version software can be realized. The functions of the NEs are as follows: Main Control Board : System control and communication is the main control system to realize the features. It serves as a BAM in the MSOFTX3000, while in the text, it is called the main control board. File Downloading : It indicates that the NEs obtain the data from the file server through FTP. File Uploading : It indicates that the data are transmitted to the file server from the NEs. Patch : There are two patches, hot patch and cold patch. The differences between them are listed as follows:

Hot patch is the on-line effective patch and you do not need to reinstall the board program. Cold patch is the reset board and is valid only after you load the board program.
Issue 02 (2007-06-10)
20-3
The text does not cover the upgrading process of cold patch. Therefore, if there are no special descriptions, the patch is a hot patch.
Hot Patch : Hot patch, a software program entity, adopting software tailor and programming technology, can load and unload files independently on the base of original version by the independent background or independent install files or file copy. The patch is composed of one or more changes. The original program may be affected after patch loading. The hot patch is realized by on-line effective technology. The tool for making patch creates patch files based on the target files complied by the source code. The patch management modules then operate on the patch files to realize the patch management. Cold Patch : Hot patch can not modify some problems; hence, the board software is required to be reloaded. On this occasion, you can use cold patch to repair the system. Board Locating Parameter : In the commands introduced in the text, patch type, module number or active/standby module information are the parameters for locating board.
20.4 Patch Operation Flow

The patch operation flow is shown in Figure 20-1.
20-4
Issue 02 (2007-06-10)
Figure 20-1 Patch operation flow

M2000 DLD PATCH MSOFTX3000 returns the progress report to the M2000 MSOFTX3000 reports sucesss or failure to the M2000 LOD PATCH Load the patch to specified board MSOFTX3000 reports sucess or failure to the M2000 ACT PATCH MSoftX3000 reports success or failure to the M2000 CON PATCH MSOFTX3000 reports sucess or failure to the M2000 Confirm the patch of specifie board Activate the patches of specified boards and make them effctive MSOFTX3000 File server
MSOFTX3000 downloads patch files from file server
DEA PATCH MSOFTX3000 reports sucess or failure to the M2000
Deactivate the patch of specified board
Patch version upgrade does not cause out of service and has a minor impact on the system; therefore, it is an important method of upgrading version during equipment maintenance. The key problem of patch upgrading is the convenient operation for maintenance staffs during upgrading process. You can complete the upgrading after ensuring the correctness of patch version and you also can roll back when finding abnormal conditions. To upgrade patch, perform the following steps: Step 1 Observe the patch status. As the equipment is used in the network for a long time, the status of current patch loaded may be not archived, or the archived information is not correct. Whether the patch version for upgrading can be loaded is closely related to the current patch status; therefore, it is essential to observe the current patch status of system. You can observe the current patch status by using the commands based on the system, subrack, board type and board. You can observe the patch status when patches are in the state of loading, activation and default. Step 2 Load a patch. Patch loading indicates that after the M2000 deliverers the patch loading commands. The MSOFTX3000 loads the patch files downloaded to the BAM system to the boards. After loading, the status of the new patch can be checked by using commands.
Issue 02 (2007-06-10)
20-5
The system loads the corresponding patches for the boards based on the patch types. Patch files must match each version. Each type of board can only have one patch file while one patch file can contain many patch units. Step 3 Validate a patch. To validate the patch is to activate the patch. The patches are managed by the same patch management modules; hence, the patches on the same board can be validated at the same time but the patches on different boards can not. Therefore, the patches on different boards are validated in a certain sequence. The system observes the validated patch on a certain type of board for a period of time. If the running status meets the requirements of system, the patches of other boards are loaded. Therefore, the function validating patches based on the board type is required. Step 4 Cancel a patch.
When you cancel patches, the patches loaded are not validated due to board switchover and reset. Patch cancellation does not differentiate the active/standby boards. Patch cancellation can also be called patch deactivation and patch removal. The patch cancellation is required when the system is abnormal after the patch upgrading is completed. The methods of canceling the patch are listed as follows: Cancellation based on board Cancellation based on board type Step 5 Confirm a patch. Patch confirmation is to set the effective patch to the default patch. After the patch is effective for a period of time, if the system is running normally, update the patch and make the patch loaded to the current default patch. ----End

20.5.1 Data Configuration at the MSOFTX3000
The MML command table of patch management is listed in Table 20-3.
20-6
Issue 02 (2007-06-10)
Table 20-3 MML command table for patch management Number 1 2 3 4 Command Name DLD PATCH ULD PATCH LOD PATCH ACT PATCH Description To download the patch from the file server to the NEs. To upload the patch from the network elements to the file server. To download the patch from the main control board to the board loading patch. To active the patch and ensure that the patch is in active state. The active patch can be run but is still in the trial status. After the patch is on trial for a period of time, if it runs normally after confirmation, confirm the patch to switch to the stable running status from the trial running status. If the patch does not run normally, deactivate the patch to stop trial running. To deactivate the patch and ensure that the patch is in deactivated state You can deactivate the patch only at trial status. 6 CON PATCH RMV PATCH To confirm patch. The patch switches to the running status from the active state. Ensure that the patch is effective after restarting. To remove patch. After the patch is removed, if the patch is required to be run again, reload the patch. You can remove the patch at any status. To list the version and status information of each type of patch for network elements. To display the patch status information of each board for network elements.
DEA PATCH
8 9
LST PATCH DSP PATCH
For the usage of MML commands and the description of parameters, see MML online help of the LMT.
The usages of patch operation commands are listed as follows:
Input
If the patch files are to be loaded, The M2000 delivers DLD PATCH to the MSOFTX3000. The M2000 delivers LOD PATCH to the MSOFTX3000. The M2000 delivers ACT PATCH to the MSOFTX3000. The M2000 delivers CON PATCH to the MSOFTX3000.
Issue 02 (2007-06-10)
20-7
If the activated patch files are to be deactivated, The M2000 delivers DEA PATCH to the MSOFTX3000. If the patch files loaded are to be removed, The M2000 delivers RMV PATCH to the MSOFTX3000.
Output
After the M2000 delivers DLD PATCH to the MSOFTX3000, The MSOFTX3000 downloads the patch files from the file server; The MSOFTX3000 reports the download progress (containing the start packet and end packet) to the M2000. If the download is incorrect, the MSOFTX3000 is required to report the failure mistakes and causes to the M2000. If the downloading is successful, the MSOFTX3000 is required to report the packets indicating the successful downloading to the M2000. After the M2000 delivers LOD PATCH to the MSOFTX3000, The MSOFTX3000 must load the patch to the corresponding boards. The MSOFTX3000 reports the success or failure packets to the M2000. After the M2000 delivers ACT PATCH to the MSOFTX3000, The MSOFTX3000 activates the patch of corresponding board. The MSOFTX3000 reports the success or failure packets to the M2000. After the M2000 delivers CON PATCH to the MSOFTX3000, The MSOFTX3000 confirms the patch of corresponding boards. The MSOFTX3000 reports the success or failure packets to the M2000. After the M2000 delivers DEA PATCH to the MSOFTX3000, The MSOFTX3000 is required to deactivate the patch of boards. The MSOFTX3000 reports the success or failure packets to the M2000. After the M2000 delivers RMV PATCH to the MSOFTX3000, The MSOFTX3000 must remove the board patch. The MSOFTX3000 reports the success or failure packets to the M2000.
20.5.2 Data Configuration at the UMG8900 Side

None.

This section describes all patch operations on the M2000 interface.
The M2000 software management only supports the remote operations for MSOFTX3000 patches.
20-8
Issue 02 (2007-06-10)
20.6.1 Uploading Patch to The M2000 Server

Version Files
The version file folder contains the version files provided by the network elements, such as s3000.wcu and the version description configuration files, such as vercfg.xml. The vercfg.xml file describes the related information, such as version number, file name, file size and file path of version files uploaded currently.
Patch Files
The patch file folder contains the patch files provided by the network element, such as patch.wcu and patch description configuration files, such as patchcfg.xml. The patchcfg.xml file describes the related information, such as version number, patch version number, file name, file size and file path of version files uploaded currently.
Uploading Version Files to the M2000 Server

To upload the version files to the M2000 server, perform the following steps: Step 1 Choose Software > Browser to open the software management interface. Step 2 Choose the Version node under the MSC Server node on the Server tab. Right-click Upload Version Files to Current Folder > From Local. The Upload File(s) to Server dialog box is displayed. Step 3 Choose the version file folder prepared and add it to the right table. Step 4 Click Start and the system displays the uploading progress. If the uploading is success, a version node is added under the node Version. ----End
Uploading Patch Files to the M2000 Server

After uploading the version files to the M2000 server, the patch file is required to be uploaded to the M2000. Step 1 Choose the version number node newly created. Right-click the Upload Version File(s) to Current Folder > From Local. The Upload File(s) to Server is displayed. Step 2 Choose the patch file folder prepared and add to the right table. Step 3 Click Start and the system displays the uploading. After successful uploading, a patch number node is added to the version number node. Step 4 Choose the patch node and you can see the patch file lists in the tables on the right of main software management interface, such as the patch name and patch version. ----End
Issue 02 (2007-06-10)
20-9
20.6.2 Operating Patch

Downloading Patch
To download a patch, perform the following steps: Step 1 Choose the Server tab on the main software management interface. Step 2 Choose MSC Server > Software > Version > Patch. The patch file lists uploaded are auto displayed on the right table.
The Version is the specific version uploaded and the Patch is the specific patch uploaded.
Step 3 Choose the patch to be downloaded to the network element. Right-click Download To NE and the NE Selection dialog box is displayed. Step 4 Choose the network element and click OK. The system auto downloads the files. A new task is added to the task progress table on the lower part of the main software management interface to display the downloading progress and status information. ----End
Loading Patch
To load a patch, perform the following steps: Step 1 Choose the NE page on the main software management interface. Step 2 Choose the nodes MSC Server > NE > Software> Version > Patch. The patch file lists are auto displayed on the right table.
The NE is the specific NE name, Version is the specific version of NE and Patch is the specific patch of NE.
Step 3 Choose the patch. Right-click Load and the Load Patch Parameters Selection dialog box are displayed. Step 4 Enter the corresponding parameter value and click OK. A new task is added to the task progress table on the lower part of the main software management interface to display the loading operation progress and status information. ----End
Activating Patch
To activate a patch, perform the following steps: Step 1 Choose the NE page on the main software management interface. Step 2 Choose the nodes MSC Server > NE > Software > Version > Patch. The patch file lists are auto displayed on the right table.
The NE is the specific network element name, Version is the specific version of NE and Patch is the specific patch of network element.
20-10
Issue 02 (2007-06-10)
Step 3 Choose the patch. Right-click Activate and the Activate Patch Parameters Selection dialog box is displayed. Step 4 Enter the corresponding parameter value and click OK. A new task is added to the task progress table on the lower part of the main software management interface to display the activating operation progress and status information. ----End
Confirming Patch
To confirm a patch, perform the following steps: Step 1 Choose the NE page on the main software management interface. Step 2 Choose the nodes MSC Server > NE > Software > Version > Patch. The patch file lists are auto displayed on the right table.
Step 3 Choose the patch. Right-click Confirm and the Confirm Patch Parameters Selection dialog box is displayed. Step 4 Enter the corresponding parameter value and click OK. A new task is added to the task progress table on the lower part of the main software management interface to display the progress and status information of confirming operations. ----End
Deactivating Patch
To deactivate a patch, perform the following steps: Step 1 Choose the NE page on the main software management interface. Step 2 Choose the nodes MSC Server > NE > Software > Version > Patch. The patch file lists are auto displayed on the right table.
Step 3 Choose the patch. Right-click Deactivate and the Deactivate Patch Parameters Selection dialog box is displayed. Step 4 Enter the corresponding parameter value and click OK. A new task is added to the task progress table on the lower part of the main software management interface to display the progress and status information of the deactivating operation. ----End
Removing patch
To remove a patch, perform the following steps: Step 1 Choose the NE page on the main software management interface.
Issue 02 (2007-06-10)
20-11
Step 2 Choose the nodes MSC Server > NE > Software > Version > Patch. The patch file lists are auto displayed on the right table.
The NE is the specific network element name, Version is the specific version of NE and Patch is the patch of specific network element.
Step 3 Choose the patch. Right-click Unload and the Unload Patch Parameters Selection dialog box is displayed. Step 4 Enter the corresponding parameter value and click OK. A new task is added to the task progress table on the lower part of the main software management interface to display the progress and status information of the unloading operation. ----End

The feature does not affect the charging and CDR.

None.
20.9 Reference
Acronym/Abbreviation BAM FTP HLR GGSN LMT MML SGSN Full Name Back Administration Module File Transfer Protocol Home Location Register Gateway GPRS Support Node Local Maintenance Terminal Human-Machine Language Serving GPRS Support Node
20-12
Issue 02 (2007-06-10)
Contents
Contents
21 Configuration Rollback Feature..........................................................................................21-1
21.1 Service Description ...................................................................................................................................21-2 21.1.1 Function Code..................................................................................................................................21-2 21.1.2 Definition .........................................................................................................................................21-2 21.1.3 Benefits ............................................................................................................................................21-3 21.2 Availability ................................................................................................................................................21-3 21.2.1 Requirements for NEs......................................................................................................................21-3 21.2.2 Requirements for License ................................................................................................................21-3 21.2.3 Applicable Versions..........................................................................................................................21-3 21.3 Working Principle......................................................................................................................................21-3 21.3.1 Basic Principle .................................................................................................................................21-3 21.3.2 State Transition ................................................................................................................................21-4 21.3.3 Validity Check..................................................................................................................................21-6 21.4 Service Flow..............................................................................................................................................21-7 21.5 Data Configuration....................................................................................................................................21-9 21.5.1 Data Configuration on the MSOFTX3000 Side...............................................................................21-9 21.5.2 Configuration Preparations ............................................................................................................ 21-11 21.5.3 Configuration Steps........................................................................................................................21-12 21.5.4 Data Configuration on the UMG8900 Side....................................................................................21-13 21.6 Service Management ...............................................................................................................................21-13 21.6.1 Rollback Commands ......................................................................................................................21-13 21.6.2 Synchronization and Forcible Synchronization Commands ..........................................................21-14 21.6.3 Activation and Forcible Activation Commands .............................................................................21-17 21.6.4 Rollback and Forcible Rollback Commands..................................................................................21-19 21.6.5 Cancellation and Confirmation Commands ...................................................................................21-21 21.6.6 Query Commands ..........................................................................................................................21-23 21.7 Charging and CDR ..................................................................................................................................21-27 21.8 Service Interaction ..................................................................................................................................21-27 21.9 Reference ................................................................................................................................................21-27
Issue 02 (2007-06-10)
Figures
Figures
Figure 21-1 Sketch of the active and the standby areas....................................................................................21-4 Figure 21-2 Illustration of state transition during configuration rollback ........................................................21-5 Figure 21-3 State transition of data in the standby area....................................................................................21-7
ii
Issue 02 (2007-06-10)
Tables
Tables
Table 21-1 Feature name and function code .....................................................................................................21-2 Table 21-2 Benefits of the configuration rollback feature ................................................................................21-3 Table 21-3 Applicable versions that support the configuration rollback feature...............................................21-3 Table 21-4 Tables that support configuration rollback .....................................................................................21-9 Table 21-5 List of configuration rollback commands.....................................................................................21-10 Table 21-6 Synchronization and forcible synchronization commands ...........................................................21-14 Table 21-7 Activation and forcible activation commands...............................................................................21-17 Table 21-8 Rollback and forcible rollback commands ...................................................................................21-19 Table 21-9 Cancellation and confirmation commands ...................................................................................21-21 Table 21-10 Query commands........................................................................................................................21-24
Issue 02 (2007-06-10)
iii
21 Configuration Rollback Feature
21
Section 21.2 Availability
Configuration Rollback Feature
About This Chapter

The following table lists the contents of this chapter. Describes The function code, function definition of this feature, and the benefits that carriers and mobile subscribers can obtain from this feature. The network elements (NEs) that are required for the feature, whether Licenses are required, and the version requirements of the NEs. The functions of the NEs, and networking requirements. The service flow of the network when providing this feature. The data configurations that are required on the MSOFTX3000 and the IMG8900. The service operations that carriers and mobile subscribers are required to implement when the network provides this feature. The charging and the generation of CDRs when the network provides this feature. The relationships and restrictions between this feature and other services or features. The protocols and specifications that this feature must comply with, and the acronyms and abbreviations of this chapter.
Issue 02 (2007-06-10)
21-1

Table 21-1 lists the name and function code of this feature. Table 21-1 Feature name and function code Name Configuration rollback Code WMFD-121500
21.1.2 Definition
To ensure network security, the system is equipped with the timely rollback function that can prevent traffic loss caused by incorrect operations. This is a basic requirement of telecom products. Consider that the configuration rollback feature is not enabled. During data configuration, after you successfully add, delete or modify certain data, the modified data is stored in the database temporarily. The data is then sent to the host and takes effect immediately after the formatting and online setting functions are enabled. If the data is wrongly configured, you have to restore the previous configuration. It wastes time to restore the database backup or run the commands one by one to get back to the previous state. In addition, if you choose to restore the database, you have to set the data table in batch or reset the host, which may interrupt the services and in turn affect the stable operation. To solve these problems, the configuration rollback function is presented. It sets up a standby area for each table that supports configuration rollback. You can first configure data in the standby area. This does not affect the data in the active area or services of the host. After the configuration is complete, you hand over the data in the standby area to the active area to validate the configuration. After a period of trial operation, if the data is found to be incorrect, you hand over the active/standby data to roll back to the previous state. If the data is proved correct, you enable the configuration permanently and end the task.
"Enable" in non-rollback state: The host runs the newly configured data and cannot roll back to the previous configuration. "Enable" in rollback state: The host runs the newly configured data and can roll back to the previous configuration. "Enable permanently" in rollback state: It means the same as "Enable" in non-rollback state. The configuration rollback mechanism is built on the principle that the operator who locks the table is authorized to perform the related operations. As a special internal account is used to log on to the BAM from the M2000 and this account is not related to M2000 users, operations of multiple users on the M2000 cannot be distinguished at the BAM side and thus the BAM cannot obtain specific user information. Therefore, only the local users of the NE can use the configuration rollback feature.
21-2
Issue 02 (2007-06-10)
21.1.3 Benefits
Table 21-2 lists the benefits of the configuration rollback feature. Table 21-2 Benefits of the configuration rollback feature Beneficiary Carriers Subscribers Description It improves the security of configuring sensitive service data and facilitates the maintenance. None.
21.2 Availability
The configuration rollback feature is performed without collaborating with peripheral NEs.

The configuration rollback feature is a basic feature of Huawei Core Network (CN). No License is required to obtain the feature.

Table 21-3 lists the applicable versions that support the configuration rollback feature of Huawei CN. Table 21-3 Applicable versions that support the configuration rollback feature Product MSC Server MSOFTX3000 Applicable Version V100R005 and later versions

21.3.1 Basic Principle
The system sets a standby area for the tables that support configuration rollback, including tables in the database and formatting data files. The active area consists of the current tables and the formatting files. It is in the directory Data. The standby area that contains the standby tables and formatting files is in the directory Data_Backup.
Issue 02 (2007-06-10)
21-3
The standby area directory is in the BAM installation directory MSOFTX3000\ConfigRollBack. All the configuration rollback operations are performed in the standby area. After the configuration is complete, you can hand over the active/standby data to validate the modification. After a period of trial operation, if the data is found to be incorrect, you can hand over the active/standby data to roll back to the previous state. If the data is proved correct, you can enable the configuration permanently and end the task. Figure 21-1 shows the structure of the active and the standby areas. Figure 21-1 Sketch of the active and the standby areas
Active area Data BAM tbl_XXXXX Files of standby tables
tbl_XXXXX_Backup Data_Backup Standby area
21.3.2 State Transition

In actual operation, the state transition of tables during configuration rollback is shown in Figure 21-2.
21-4
Issue 02 (2007-06-10)
Figure 21-2 Illustration of state transition during configuration rollback

Active: V0 Active: V1 Standby: V? Normal operation Standby: V? Normal operation Safe configuration (original (Modified configuration) configuration)
Synchronize Cancel Active: V0 Standby: V0 Activate/ Activate forcibly Modify Active: V0 Standby: V1 Rollback/ Rollback forcibly Compare data before and after modification
Confirm/ timeout Active: V1 Standby: V0 Synchronize forcibly Active: V1 Standby: V1
Trial
Modify
To facilitate the description of state transition, three table states are defined: Normal In "Normal" state, you cannot perform any configuration operation. Modify During configuration rollback, you can run commands to configure data in "Modify" state and only in this state. If a table in "Modify" state is not processed within a period, its state remains unchanged. Trial In "Trial" state, the newly configured data takes effect in the host. If any problem is found in this state, the system rolls back to the "Modify" state to correct the configuration.
The table states are used when the configuration rollback function is enabled. If it is disabled, the configuration flow is as normal, that is, the previous three states do not exist. The restart of the BAM does not affect the table state, original data and backup files of a table in "Modify" or "Trial" state.
Normal State
When the configuration rollback function is enabled, before you run the synchronization command, the tables that support configuration rollback are in "Normal" state. The data in the active area is the original data, represented by V0. The standby area has no data, represented by V?. Consider the Called Number Analysis Table as an example. Suppose there is a record Call prefix = 135 in the active area, then the same record exists in the host and no data exists in the standby area.
Issue 02 (2007-06-10)
21-5
Modify State
Synchronization means to synchronize the data in the standby area with that in the active area. After synchronization, the data in the two areas is the same. The table changes to be in "Modify" state. The record Call prefix = 135 exists in the standby area. You can run commands to configure data in the tables that support configuration rollback feature only in "Modify" state. The commands take effect only in the standby area. The data in the active area does not change and the host is not affected. If you add a record Call prefix = 136 to the table, then there are two records of call prefix in the standby area. The data in the standby area is now represented by V1.There is only one record in the active area and the host, that is, Call prefix = 135. If you cancel the operation in "Modify" state, the data V1 in the standby area is deleted. The data in the active area and the host remains unchanged.
Trial State
After activation or forcible activation, the table changes to be in "Trial" state. The data in the standby area is handed over to the active area and then set to the host immediately. In case of later rollback, the system also hands over the data in the active area to the standby area. Now the data in the active area is V1. Two records (Call prefix = 135 and Call prefix = 136) exist in the active area. The data of the host is the same as that in the active area. The data in the standby area is V0. Only one record (Call prefix = 135) exists in the standby area. In "Trial" state, the data is being tested. You are not allowed to perform any operation. If you find that the configured data has errors, defects or problems that cannot be located, you can roll back the configuration to the original state. After rollback, the data in the active and the standby area exchanges again. The data in the active area is V0. Only the record (Call prefix = 135) exists in the active area and the host. The data in the standby area is V1. Two records (Call prefix = 135 and Call prefix = 136) exist in the standby area. In "Trial" state, if the data in the host is correct, run the confirmation command and enable the configuration in the active area and the host permanently. The table changes to be in "Normal" state. Now the data in the active area is V1. At the same time, the data in the standby area is deleted. In "Trial" state, the host is running as usual. If you want to re-configure the data, you can run the command FSYN XXX to forcibly synchronize the data in the standby area with the data in the active area. Thus, the former data in the standby area is lost completely. The table turns to be in "Modify" state. You can proceed with the configuration and then activate, roll back or confirm the configuration.
21.3.3 Validity Check

During configuration rollback, to ensure the efficiency and accuracy of the data, you must perform validity check on the data configured in the standby area. To facilitate the description of data credibility, four data states are defined: Valid It is a basis for active/standby data handover (activation or rollback) that the data in the standby area is "Valid". The tables are not required to be checked in "Modify" state. Therefore, the data in the standby area must be checked for validity before handover.
21-6
Issue 02 (2007-06-10)
Unknown The tables rely on each other during data configuration. Therefore, the data in the table is updated to be "Unknown" after rollback. The unknown data is the data that has not been verified. Checked The data in "Checked" state means that the data is being checked. Invalid During validity check, if the data fails to meet the check rules, it is set to be "Invalid". Figure 21-3 shows the state transition of the data in the standby area. Figure 21-3 State transition of data in the standby area
Modify Valid Unknown
Check succeeded
Modify
Check storage procedure
Invalid Check failed
Checked
21.4 Service Flow

Besides the functions described in the previous sections, the configuration rollback feature provides protection/restriction functions for the tables, including the following: Single user locking Table state query Comparison of data in active and standby areas In actual usage, the basic operation flow of the configuration rollback feature is as follows: Step 1 Run the command SET FMT to enable the formatting function. Step 2 Run the command SET CFGRLB to enable the configuration rollback function and enter the operation state of configuration rollback.
Before enabling the configuration rollback function, you must enable the formatting function first. The latter cannot be disabled when the former is enabled.
Step 3 Consider that you must modify a table that supports configuration rollback. First, run the command SYN XXX to synchronize the data in the standby area with that in the active area. XXX refers to the object to which the command is executed.
Issue 02 (2007-06-10)
21-7
1. 2.
Synchronize the data in the standby area with that in the active area. This is a basis for later modification. Lock the table. It serves two purposes:

The data of the locked table in the active area cannot be modified. It prevents other operators from modifying the data of the locked table in the standby area at the same time.
You modify data in the standby area and the modification is not set to the host. If another operator wants to modify the table at the same time, he/she must obtain the control right by running the command FSYN XXX. Note that the data modified by you may be lost then.
If you want to run the forcible synchronization command, it is recommended to query the table state to check whether the table is locked by any other operator. If the table has been locked by an operator, you must obtain agreement of that operator first and keep cautious in operation.
Step 4 During data configuration, if you want to cancel the modification, run the command CNL XXX to delete all the modified data in the standby area while the data in the active area remains unchanged. Step 5 After configuration, run the command ACT XXX to validate the modified data and start the trial operation. At present, the data in both the active and the standby areas cannot be modified. The data in the standby area must be checked for validity before activation. If the check fails because the dependent tables affect each other, run the forcible command FACT XXX to omit the validity check on certain tables. Before activation or rollback, the data must be proved valid. The validity check can be performed in either of the following ways: The BAM auto checks the data of the tables that support configuration rollback every five seconds. You can run the command CHK XXX to check the data of a specific table. Step 6 Within 24 hours after activation, if you find errors in the configured data, run the command RLB XXX to hand over the active/standby data again. After handover, modify the incorrect data and then re-activate it. The data in the standby area must be checked for validity before rollback. You can run the forcible command FRLB XXX to avoid the validity check if necessary. Within 24 hours after activation, if you want to re-configure the data, use either of the following methods: Roll back the configuration. Modify the data and then activate it again.
The configuration must be rolled back to the original state by using this method. This may interrupt the services set up by the newly configured data. The data in the standby area, however, resumes the previous configuration after rollback. The operator can modify the data based on the previous configuration.
Run the forcible synchronization command to overwrite the standby area with the data of the active area, that is, use the modified data to overwrite the original data. Then, you can modify the data based on the previous modification and re-activate it.
The configuration can never be rolled back to the original state by using this method.
21-8
Issue 02 (2007-06-10)
Step 7 Confirm the configuration in either of the following two ways: Manual confirmation You can confirm the configuration within 24 hours after activation and run the command CMT XXX to validate the data. The system enters the "Normal" state. Auto confirmation If you do not confirm the configuration within 24 hours, the system auto confirms it and enters the "Normal" state. The data becomes valid permanently. The standby area is now cleaned up. The configuration can never be rolled back again. Step 8 After confirmation, run the command SET CFGRLB to disable the configuration rollback function. At present, you are not allowed to perform any configuration rollback operation. ----End Only the users at the Operator level or higher levels are authorized to perform the configuration rollback operations. A user name often corresponds to a user ID (used inside the BAM). When a user name is deleted and then added again, the user ID of this user changes. The configuration rollback feature only identifies the user ID. Therefore, user names can be used to identify the operators. The same operator can log in to different terminals to perform configuration rollback operations at the same time. During configuration rollback, a set of commands are provided for operators to query the current state, standby table data, differences between the active and the standby tables. These commands are described in the following sections.

21.5.1 Data Configuration on the MSOFTX3000 Side
Tables
The configuration rollback operations are performed on data tables. Table 21-4 lists the tables of the MSOFTX3000 that support configuration rollback. Table 21-4 Tables that support configuration rollback Table ID 105 106 108 119 124 125 126 127 Table Name Called Number Analysis Table Called Number Special Process Table Called Number Pre-analysis Table Calling Number Analysis Table DP Prefix Process Table IN Service Description Table CLI Number Display Process Table CLI Number Display CLD Association Table
Issue 02 (2007-06-10)
21-9
Table ID 129 134 135 136 137 138 139 142 301 302 308 309 368
Table Name Redirecting Analysis Table Incoming Number Pretreatment Table Incoming Calling Number Association Table Incoming Original Called Number Association Table Outgoing Number Pretreatment Table Outgoing Calling Number Association Table Outgoing Original Called Number Association Table HO Number Outgoing Process Table Route Data Table Route Analysis Table Trunk Group Bearer Table Trunk Group Call Bearer Index Table SCCP GT Table
Commands
Table 21-5 lists the MSOFTX3000 commands used for configuration rollback. Table 21-5 List of configuration rollback commands Command SET CFGRLB SYN XXX FSYN XXX Name Set the Status of CFGRLB Synchronize XXX Forcibly Synchronize XXX Cancel the Modification of XXX Acknowledge XXX Activate XXX Forcibly Activate XXX Function To enable or disable the configuration rollback feature To synchronize the standby table with a certain data table To forcibly synchronize the standby table with a certain data table even when the table is locked To cancel the modification of the data in the standby table To confirm the modification of the data in a table To activate the data of a table in the standby area To forcibly activate a standby table when the data in the table is invalid
CNL XXX CMT XXX ACT XXX FACT XXX
21-10
Issue 02 (2007-06-10)
Command RLB XXX FRLB XXX LST XXXBKP CMP XXX
Name Change Back XXX Forcibly Change Back XXX List Backup XXX Compare XXX in Active/Standby Way
Function To roll back the activated table To forcibly roll back the activated table when the data in the table is invalid To list the data in the standby table To compare the differences between the active and the standby areas, such as records existing only in the active area, records existing only in the standby area and records that are different in the active and the standby areas To check the validity of the data in the standby area To list the information of tables that support configuration rollback, including table state, data credibility, operator locking the table, state transition time, table ID and table name To list the configuration rollback status To list the duration after which the system performs automatic confirmation To modify the duration after which the system performs automatic confirmation
CHK XXX LST TBLSTA
Check XXX Table List the Status of Configuration Rollback Table List Dataman Status List Auto Confirm Time Modify Auto Confirm Time
LST DATAMAN LST CMTTM MOD CMTTM
21.5.2 Configuration Preparations

Configuration rollback is a supplementary feature for service data configuration. It is disabled by default. During configuration rollback, you must ensure that the services are not affected. The configuration rollback operations may affect the services in the following ways: The command FSYN XXX deletes the original data in the standby area. Forcible activation or rollback may lead to invalid data in the active area. These commands however, are used only when the handover fails because of the dependent relationship of tables. The data configuration of the configuration rollback feature complies with the normal configuration guide.
Issue 02 (2007-06-10)
21-11
21.5.3 Configuration Steps

In "Modify" or "Trial" state, you can run the command CMP XXX to compare the data between the active and the standby areas. In "Modify" state, the BAM auto checks the validity of the data in the tables that support configuration rollback every five seconds. The auto confirmation duration is 24 hours by default. Therefore, in "Trial" state, the system auto confirms the modification after 24 hours. You can run the command MOD CMTTM to modify the auto confirmation duration.
Consider the Called Number Analysis Table as an example to describe the configuration steps. Step 1 Run the command SET CFGRLB to enable the configuration rollback feature.
SET CFGRLB: STS=ON;
Step 2 Run the command SYN CNACLD to synchronize the call prefix of the active and the standby areas.
SYN CNACLD:;
If you need to synchronize the data forcibly, turn to Step 9.
Step 3 Run the command ADD/MOD/RMV CNACLD to modify the call prefix in the standby area.
ADD CNACLD: P=0, PFX=K'111, MINL=1, MAXL=2;
Step 4 Run the command CHK CNACLD to check the validity of the modified data.
CHK CNACLD:;
Step 5 Run the command ACT CNACLD to activate the modified data in the standby area. The Called Number Analysis Table changes to be in "Trial" state.
ACT CNACLD:;
If you need to roll back the data, turn to Step 8.
Step 6 Run the command CMT CNACLD to confirm the modification in "Trial" state. The newly configured data take effect.
CMT CNACLD:;
Step 7 Run the command SET CFGRLB to disable the configuration rollback feature.
SET CFGRLB: STS=OFF;
If you need to check the table state, turn to Step 14.
Step 8 After Step 5, you can run the command RLB CNACLD to roll back the configuration. The Called Number Analysis Table changes back to be in "Modify" state.
RLB CNACLD:;
If you need to synchronize the data forcibly, turn to Step 9.
21-12
Issue 02 (2007-06-10)
Step 9 After Step 2 and Step 8, you can run the command FSYN CNACLD to forcibly synchronize the data of the active and the standby areas.
FSYN CNACLD:;
Step 10 Run the command FACT CNACLD to forcibly activate the modified data in the standby area.
FACT CNACLD:;
Step 11 Run the command FRLB CNACLD to roll back the configuration forcibly.
FRLB CNACLD:;
Step 12 Run the command CNL CNACLD to cancel the modification in "Modify" state.
CNL CNACLD:;
Step 13 Run the command SET CFGRLB to disable the configuration rollback feature.
SET CFGRLB: STS=OFF;
Step 14 Run the command LST TBLSTA to list the status of tables that support configuration rollback.
LST TBLSTA: ;
Step 15 Run the command LST CNACLDBKP to list the data in the standby area.
LST CNACLDBKP: ;
Step 16 Run the command LST DATAMAN to list the status of the configuration rollback feature.
LST DATAMAN: ;
----End
21.5.4 Data Configuration on the UMG8900 Side

None.

21.6.1 Rollback Commands
This section describes the following commands: SET CFGRLB LST DATAMAN LST TBLSTA LST CMTTM MOD CMTTM
SET CFGRLB
This command is used to enable or disable the configuration rollback function. You can perform the configuration rollback operations only when the command sets it to ON. When the BAM finds after start that the configuration rollback is enabled while the formatting is not, it enables the formatting function forcibly. You can perform the configuration rollback operations only when the two functions are both enabled.
Issue 02 (2007-06-10)
21-13
Therefore, you must first run the command SET FMT to enable the formatting function, and then run the command SET CFGRLB to enable the configuration rollback function.
LST DATAMAN
This command is used to list the status of the configuration rollback, formatting and online setting functions.
LST TBLSTA
This command is used to list the table information, such as table state, data credibility, operator locking the table and state switch time. You can list the information of a certain table or all tables. The operator who is authorized to run this command can list the information of the tables locked by another operator.
LST CMTTM
This command is used to list the auto confirmation duration for configuration rollback.
MOD CMTTM
This command is used to modify the auto confirmation duration for configuration rollback.
21.6.2 Synchronization and Forcible Synchronization Commands

The synchronization and forcible synchronization commands are applied to a specific table. The mapping relationship is listed in Table 21-6. Table 21-6 Synchronization and forcible synchronization commands Command SYN CNACLD /FSYN CNACLD SYN CNACLR /FSYN CNACLR SYN PFXPRO /FSYN PFXPRO SYN CLDPREANA /FSYN CLDPREANA SYN IDPNPRO /FSYN IDPNPRO SYN SRVNUM /FSYN SRVNUM Name Synchronize Call Prefix /Forcibly Synchronize Call Prefix Synchronize Calling Number Analysis /Forcibly Synchronize Calling Number Analysis Synchronize Special Dialed Number Processing /Forcibly Synchronize Special Dialed Number Processing Synchronize Called Number Pre-analysis Information /Forcibly Synchronize Called Number Pre-analysis Information Synchronize IPD Number Processing /Forcibly Synchronize IPD Number Processing Synchronize Intelligent Service Number Information /Forcibly Synchronize Intelligent Service Number Information
21-14
Issue 02 (2007-06-10)
Command SYN CLIPRO /FSYN CLIPRO SYN CLCRPRO /FSYN CLCRPRO
Name Synchronize CLIP Processing /Forcibly Synchronize CLIP Processing Synchronize CLIP Called Number Correlation Processing /Forcibly Synchronize CLIP Called Number Correlation Processing
SYN REDRCTANA /FSYN REDRCTANA SYN INNUMPREPRO /FSYN INNUMPREPRO SYN INCLRIDX /FSYN INCLRIDX
Synchronize Forwarding Number Analysis Information /Forcibly Synchronize Forwarding Number Analysis Information Synchronize Incoming Number Pre-processing /Forcibly Synchronize Incoming Number Pre-processing Synchronize Incoming Calling Number Associated Processing /Forcibly Synchronize Incoming Calling Number Associated Processing
SYN INORICLDIDX /FSYN INORICLDIDX
Synchronize Incoming Original Called Number Associated Processing /Forcibly Synchronize Incoming Original Called Number Associated Processing
SYN OUTNUMPREPRO /FSYN OUTNUMPREPRO SYN OUTCLRIDX /FSYN OUTCLRIDX
Synchronize Outgoing Number Pre-processing /Forcibly Synchronize Outgoing Number Pre-processing Synchronize Outgoing Calling Number Associated Processing /Forcibly Synchronize Outgoing Calling Number Associated Processing
SYN OUTORICLDIDX /FSYN OUTORICLDIDX
Synchronize Outgoing Original Called Number Associated Processing /Forcibly Synchronize Outgoing Original Called Number Associated Processing
SYN HDOVPROC /FSYN HDOVPROC
Synchronize Handover Number Processing Table Information /Forcibly Synchronize Handover Number Processing Table Information
SYN RT /FSYN RT SYN RTANA /FSYN RTANA SYN TGLD /FSYN TGLD
Synchronize Routes /Forcibly Synchronize Routes Synchronize Route Analysis /Forcibly Synchronize Route Analysis Synchronize Trunk Group Bearer /Forcibly Synchronize Trunk Group Bearer
Issue 02 (2007-06-10)
21-15
Command SYN TGLDIDX /FSYN TGLDIDX SYN SCCPGT /FSYN SCCPGT
Name Synchronize Trunk Group Bearer Indexes /Forcibly Synchronize Trunk Group Bearer Indexes Forcibly Synchronize SCCP Global Titles /Forcibly Synchronize SCCP Global Titles
SYN XXX
Before modifying a table that supports configuration rollback, you must synchronize the data of the active and the standby areas. The synchronization can be performed in "Normal" or "Modify" state. Note that the data modified after the first synchronization is lost if you synchronize the data in "Modify" state. After the first synchronization, the table changes to be in "Modify" state. It is locked by the operator who performs the synchronization. Other operators are not allowed to modify the table or perform the configuration rollback operations on the table unless they forcibly synchronize the table to obtain the control right. The data requires to be synchronized includes the formatting data and the tables in the database. Synchronization of formatting data: The formatting files for the standby area are generated and organized on the basis of table. After synchronization, the formatting files Table Name_Backup0.dat and Table Name_Backup1.dat for the standby area are generated in the BAM installation directory \ConfigRollBack\Data_Backup. The initial data of these two files comes from the db_?.dat files of the modules of the table. Table Name_Backup0.dat is the backup file for the active area. It always keeps consistent with the data in the active area. Table Name_Backup1.dat is the formatting file for the standby area. The data in the standby area is formatted to this file in configuration rollback state. Synchronization of database tables: Each table that supports configuration rollback has a standby table named Table Name_Backup1. The data in the active table is exported to the standby table in synchronization. In "Modify" state, the data in the standby table is modified. You cannot modify the data in the active table in "Modify" state. All the configuration commands are executed on the standby table. At the same time, the BAM formats the data in the standby table to the formatting file Table Name_Backup1.dat. The online setting is not enabled now. To improve the configuration efficiency, the storage procedure does not check the consistency of service data in "Modify" state. The state of the data in the standby table is updated from "Valid" to "Unknown". Let the system auto check or run the command CHK XXX to check the data credibility. Activate the data only when it is valid.
FSYN XXX
The forcible synchronization works almost the same as synchronization. The table changes to be in "Modify" state after being forcibly synchronized. It however, can be performed in any state, which is different from synchronization. An operator can obtain the control right of a table by this operation.
21-16
Issue 02 (2007-06-10)
21.6.3 Activation and Forcible Activation Commands

The activation and forcible activation commands are applied to a specific table. The mapping relationship is listed in Table 21-7. Table 21-7 Activation and forcible activation commands Command ACT CNACLD /FACT CNACLD ACT CNACLR /FACT CNACLR ACT PFXPRO /FACT PFXPRO ACT CLDPREANA /FACT CLDPREANA ACT IDPNPRO /FACT IDPNPRO ACT SRVNUM /FACT SRVNUM ACT CLIPRO /FACT CLIPRO ACT CLCRPRO /FACT CLCRPRO ACT REDRCTANA /FACT REDRCTANA ACT INNUMPREPRO /FACT INNUMPREPRO ACT INCLRIDX /FACT INCLRIDX Description Activate Call Prefix /Forcibly Activate Call Prefix Activate Calling Number Analysis /Forcibly Activate Calling Number Analysis Activate Special Dialed Number Processing /Forcibly Activate Special Dialed Number Processing Activate Called Number Pre-analysis Information /Forcibly Activate Called Number Pre-analysis Information Activate IPD Number Processing /Forcibly Activate IPD Number Processing Activate Intelligent Service Number Information /Forcibly Activate Intelligent Service Number Information Activate CLIP Processing /Forcibly Activate CLIP Processing Activate CLIP Called Number Correlation Processing /Forcibly Activate CLIP Called Number Correlation Processing Activate Forwarding Number Analysis Information /Forcibly Activate Forwarding Number Analysis Information Activate Incoming Number Pre-processing /Forcibly Activate Incoming Number Pre-processing Activate Incoming Calling Number Associated Processing /Forcibly Activate Incoming Calling Number Associated Processing ACT INORICLDIDX /FACT INORICLDIDX Activate Incoming Original Called Number Associated Processing /Forcibly Activate Incoming Original Called Number Associated Processing
Issue 02 (2007-06-10)
21-17
Command ACT OUTNUMPREPRO /FACT OUTNUMPREPRO ACT OUTCLRIDX /FACT OUTCLRIDX
Description Activate Outgoing Number Pre-processing /Forcibly Activate Outgoing Number Pre-processing Activate Outgoing Calling Number Associated Processing /Forcibly Activate Outgoing Calling Number Associated Processing
ACT OUTORICLDIDX /FACT OUTORICLDIDX
Activate Outgoing Original Called Number Associated Processing /Forcibly Activate Outgoing Original Called Number Associated Processing
ACT HDOVPROC /FACT HDOVPROC
Activate Handover Number Processing Table Information /Forcibly Activate Handover Number Processing Table Information
ACT RT /FACT RT ACT RTANA /FACT RTANA ACT TGLD /FACT TGLD ACT TGLDIDX /FACT TGLDIDX ACT SCCPGT /FACT SCCPGT
Activate Routes /Forcibly Activate Routes Activate Route Analysis /Forcibly Activate Route Analysis Activate Trunk Group Bearer /Forcibly Activate Trunk Group Bearer Activate Trunk Group Bearer Index /Forcibly Activate Trunk Group Bearer Index Activate SCCP Global Titles /Forcibly Activate SCCP Global Titles
ACT XXX
This command is used to activate the modified data in the standby area. You can perform it only in "Modify" state. After activation, the table changes to be in "Trial" state. Only the operator who locks the table can activate it and the data in the table must be "Valid". If the data is "Unknown", run the command CHK XXX to check it or let the system auto check it. If the data is still "Invalid" after check, you can run the command FACT XXX to activate it forcibly. If there are two tables relying on each other in "Modify" state, the two tables may be both invalid. The key operations for activation are active/standby data handover and data setting. The data handover contains the following: Handover of formatting data: Update the data in Table Name_Backup1.dat to the formatting file, db_?.dat in the active area. Hand over the two files Table Name_Backup0.dat and Table Name_Backup1.dat to ensure that the data in Table Name_Backup0.dat is consistent with the data in the active table.
21-18
Issue 02 (2007-06-10)
Handover of tables in the database, that is, data in the standby table Table Name_Backup1 and that in the active table: After successfully handing over the formatting files and database tables, set the modification to the host to make the hosts data consistent with that of the BAM.
FACT XXX
The forcible activation works almost the same as activation. The table changes to be in "Trial" state after being forcibly activated. The data however, is not checked for validity before forcible activation. Besides, the tables locked by an operator can be activated forcibly by another operator.
21.6.4 Rollback and Forcible Rollback Commands

The rollback and forcible rollback commands are applied to a specific table. The mapping relationship is listed in Table 21-8. Table 21-8 Rollback and forcible rollback commands Command RLB CNACLD /FRLB CNACLD RLB CNACLR /FRLB CNACLR RLB PFXPRO /FRLB PFXPRO RLB CLDPREANA /FRLB CLDPREANA Name Change Back Call Prefix /Forcibly Change Back Call Prefix Change Back Calling Number Analysis /Forcibly Change Back Calling Number Analysis Change Back Special Dialed Number Processing /Forcibly Change Back Special Dialed Number Processing Change Back Called Number Pre-analysis Information /Forcibly Change Back Called Number Pre-analysis Information RLB IDPNPRO /FRLB IDPNPRO RLB SRVNUM /FRLB SRVNUM Change Back IDP Number Processing /Forcibly Change Back IDP Number Processing Change Back Intelligent Service Number Information /Forcibly Change Back Intelligent Service Number Information RLB CLIPRO /FRLB CLIPRO RLB CLCRPRO /FRLB CLCRPRO Change Back CLIP Processing /Forcibly Change Back CLIP Processing Change Back CLIP Called Number Correlation Processing /Forcibly Change Back CLIP Called Number Correlation Processing
Issue 02 (2007-06-10)
21-19
Command RLB REDRCTANA /FRLB REDRCTANA
Name Change Back Forwarding Number Analysis Information /Forcibly Change Back Forwarding Number Analysis Information
RLB INNUMPREPRO /FRLB INNUMPREPRO RLB INCLRIDX /FRLB INCLRIDX
Change Back Incoming Number Pre-processing /Forcibly Change Back Incoming Number Pre-processing Change Back Incoming Calling Number Associated Processing /Forcibly Change Back Incoming Calling Number Associated Processing
RLB INORICLDIDX /FRLB INORICLDIDX
Change Back Incoming Original Called Number Associated Processing /Forcibly Change Back Incoming Original Called Number Associated Processing
RLB OUTNUMPREPRO /FRLB OUTNUMPREPRO RLB OUTCLRIDX /FRLB OUTCLRIDX
Change Back Outgoing Number Pre-processing /Forcibly Change Back Outgoing Number Pre-processing Change Back Outgoing Calling Number Associated Processing /Forcibly Change Back Outgoing Calling Number Associated Processing
RLB OUTORICLDIDX /FRLB OUTORICLDIDX
Change Back Outgoing Original Called Number Associated Processing /Forcibly Change Back Outgoing Original Called Number Associated Processing
RLB HDOVPROC /FRLB HDOVPROC
Change Back Handover Number Processing Table Information /Forcibly Change Back Handover Number Processing Table Information
RLB RT /FRLB RT RLB RTANA /FRLB RTANA RLB TGLD /FRLB TGLD RLB TGLDIDX /FRLB TGLDIDX RLB SCCPGT /FRLB SCCPGT
Change Back Routes /Forcibly Change Back Routes Change Back Route Analysis /Forcibly Change Back Route Analysis Change Back Trunk Group Bearer /Forcibly Change Back Trunk Group Bearer Change Back Trunk Group Bearer Index /Forcibly Change Back Trunk Group Bearer Index Change Back SCCP Global Titles /Forcibly Change Back SCCP Global Titles
21-20
Issue 02 (2007-06-10)
RLB XXX
This command is used to roll back the configuration, and replace the data in the active area with the data in the standby area and validate it. It can be performed only in "Trial" state. After rollback, the table changes back to be in "Modify" state. Only the operator who locks the table can roll it back and the data in the standby table must be "Valid". If the data is "Unknown", you can run the command CHK XXX or let the system auto check it. (The default check period is five seconds.)If the data in the standby area is still "Invalid" after check and you are sure to roll it back, run the command FRLB XXX to roll it back forcibly. If there are two tables relying on each other in "Modify" state, the two tables may both be invalid. Rollback is a converse operation of activation. The key operations of rollback are the same as those of activation, that is, active/standby data handover and data setting. The data handover contains the following: Handover of formatting data: Update the data in Table Name_Backup1.dat to the formatting file, db_?.dat in the active area. Hand over the two files Table Name_Backup0.dat and Table Name_Backup1.dat to make sure that the data in Table Name_Backup0.dat is consistent with the data in the active area. Handover of database tables: Handover the data in the standby table Table Name_Backup1 and that in the active table.
FRLB XXX
The forcible rollback works almost the same as rollback. The table changes to be in "Modify" state after being forcibly rolled back. The data however, is not checked for validity before forcible rollback. Besides, the tables locked by an operator can be rolled back forcibly by another operator.
21.6.5 Cancellation and Confirmation Commands

The cancellation and confirmation commands are applied to a specific table. The mapping relationship is listed in Table 21-9. Table 21-9 Cancellation and confirmation commands Command CNL CNACLD /CMT CNACLD CNL CNACLR /CMT CNACLR CNL PFXPRO /CMT PFXPRO CNL CLDPREANA /CMT CLDPREANA CNL IDPNPRO /CMT IDPNPRO Name Cancel the Modification of a Call Prefix /Acknowledge Call Prefixes Cancel the Modification of Calling Number Analysis /Acknowledge Calling Number Analysis Cancel the Modification of Special Dialed Number Processing /Acknowledge Special Dialed Number Processing Cancel the Modification of Called Number Pre-analysis Information /Acknowledge Called Number Pre-analysis Information Cancel the Modification of IPD Number Processing /Acknowledge IPD Number Processing
Issue 02 (2007-06-10)
21-21
Command CNL SRVNUM /CMT SRVNUM CNL CLIPRO /CMT CLIPRO CNL CLCRPRO /CMT CLCRPRO CNL REDRCTANA /CMT REDRCTANA CNL INNUMPREPRO /CMT INNUMPREPRO CNL INCLRIDX /CMT INCLRIDX CNL INORICLDIDX /CMT INORICLDIDX
Name Cancel the Modification of Intelligent Service Number Information /Acknowledge Intelligent Service Number Information Cancel the Modification of CLIP Processing /Acknowledge CLIP Processing Cancel the Modification of CLIP Called Number Correlation Processing /Acknowledge CLIP Called Number Correlation Processing Cancel the Modification of Forwarding Number Analysis Information /Acknowledge Forwarding Number Analysis Information Cancel the Modification of Incoming Number Pre-processing /Acknowledge Incoming Number Pre-processing
Cancel the Modification of Incoming Calling Number Associated Processing /Acknowledge Incoming Calling Number Associated Processing Cancel the Modification of Incoming Original Called Number Associated Processing /Acknowledge Incoming Original Called Number Associated Processing
CNL OUTNUMPREPRO /CMT OUTNUMPREPRO CNL OUTCLRIDX /CMT OUTCLRIDX CNL OUTORICLDIDX /CMT OUTORICLDIDX CNL HDOVPROC /CMT HDOVPROC CNL RT /CMT RT CNL RTANA /CMT RTANA
Cancel the Modification of Outgoing Number Pre-processing /Acknowledge Outgoing Number Pre-processing
Cancel the Modification of Outgoing Calling Number Associated Processing /Acknowledge Outgoing Calling Number Associated Processing Cancel the Modification of Outgoing Original Called Number Associated Processing /Acknowledge Outgoing Original Called Number Associated Processing Cancel the Modification of Handover Number Processing Table Information /Acknowledge Handover Number Processing Table Information Cancel the Modification of Routes /Acknowledge Routes Cancel the Modification of Route Analysis /Acknowledge Route Analysis
21-22
Issue 02 (2007-06-10)
Command CNL TGLD /CMT TGLD CNL TGLDIDX /CMT TGLDIDX CNL SCCPGT /CMT SCCPGT
Name Cancel the Modification of Trunk Group Bearer /Acknowledge Trunk Group Bearer Cancel the Modification of Trunk Group Bearer Index /Acknowledge Trunk Group Bearer Index Cancel the Modification of SCCP Global Titles /Acknowledge SCCP Global Titles
CNL XXX
This command is used to delete all the modification in the standby area. The table changes back to be in "Normal" state. Only the operator who locks the table can cancel the modification. After cancellation, all the data (including the formatting files and standby table data) in the standby area is deleted. All the data modified in "Modify" state is lost. In "Modify" state, when you want to stop and cancel the data modification, run this command to get back normal running. The command does not affect the data in the active area.
CMT XXX
This command is used to confirm the modification and validate it in the active area permanently. It can be performed only in "Trial" state. After confirmation, the table changes to be in "Normal" state. The execution flow of confirmation is similar to that of cancellation. Only the operator who locks the table can perform it. After confirmation, all the data in the standby area is cleared. The two commands however, function differently. The former validates the modified data while the latter invalidates the data. The BAM provides a 24-hour auto confirmation mechanism. If you do not confirm the configuration within 24 hours in "Trial" state, the system auto confirms it and the table then changes to be in "Normal" state. The only difference between auto confirmation and CMT XXX is that the system does not report the MML status for the former.
21.6.6 Query Commands

The query commands include the commands to: List active table data List standby table data Compare the data of the active/standby tables Check the data validity in the standby table These four categories of commands are supplementary commands for the configuration rollback feature. The operator who is authorized to run these commands can query the tables locked by another operator. The mapping relationship between the commands and the data tables is listed in Table 21-10.
Issue 02 (2007-06-10)
21-23
Table 21-10 Query commands Command LST CNACLDBKP /CMP CNACLD /CHK CNACLD LST CNACLRBKP /CMP CNACLR /CHK CNACLR LST PFXPROBKP /CMP PFXPRO /CHK PFXPRO LST CLDPREANABKP /CMP CLDPREANA /CHK CLDPREANA LST IDPNPROBKP /CMP IDPNPRO /CHK IDPNPRO LST SRVNUMBKP /CMP SRVNUM /CHK SRVNUM LST CLIPROBKP /CMP CLIPRO /CHK CLIPRO LST CLCRPROBKP /CMP CLCRPRO /CHK CLCRPRO LST REDRCTANABKP /CMP REDRCTANA /CHK REDRCTANA LST INNUMPREPROBKP /CMP INNUMPREPRO /CHK INNUMPREPRO Name List Backup-area Call Prefix /Compare Call Prefixes in Active/Standby Way /Check Call Prefix List Backup-area Caller Number Analysis /Compare Calling Number Analysis in Active/Standby Way /Check Caller Number Analysis List Backup-area Call Prefix Processing /Compare Special Dialed Number Processing in Active/Standby Way /Check Call Prefix Processing List Backup-area Called Number Pre-analysis /Compare Called Number Pre-analysis Information in Active/Standby Way /Check Called Number Pre-analysis List Backup-area IDP Number Processing /Compare IDP Number Processing in Active/Standby Way /Check IDP Number Processing List Backup-area IN Service Number /Compare Intelligent Service Number Information In Active/Standby Way /Check IN Service Number List Backup-area CLIP Processing /Compare CLIP Called Number Correlation Processing in Active/Standby Way /Check CLIP Processing List Backup-area CLIP Called Number Correlation Processing /Compare CLIP Called Associated Processing in Active/Standby Way /Check CLIP Called Number Correlation Processing List Backup-area Redirection Number Analysis /Compare Forwarding Number Analysis Information in Active/Standby Way /Check Redirection Number Analysis List Backup-area Incoming Number Pre-processing /Compare Incoming Number Pre-processing in Active/Standby Way /Check Incoming Number Pre-processing
21-24
Issue 02 (2007-06-10)
Command LST INCLRIDXBKP /CMP INCLRIDX /CHK INCLRIDX
Name List Backup-area Incoming Caller Number Associated Processing /Compare Incoming Calling Number Associated Processing in Active/Standby Way /Check Incoming Caller Number Associated Processing List Backup-area Incoming Original Called Number Associated Processing /Compare Incoming Original Called Number Associated Processing in Active/Standby Way /Check Incoming Original Called Number Associated Processing
LST INORICLDIDXBKP /CMP INORICLDIDX /CHK INORICLDIDX
LST OUTNUMPREPROBKP /CMP OUTNUMPREPRO /CHK OUTNUMPREPRO LST OUTCLRIDXBKP /CMP OUTCLRIDX /CHK OUTCLRIDX
List Backup-area Outgoing Number Pre-processing /Compare Outgoing Number Pre-processing in Active/Standby Way /Check Outgoing Number Pre-processing
List Backup-area Outgoing Caller Number Associated Processing /Compare Outgoing Calling Number Associated Processing in Active/Standby Way /Check Outgoing Caller Number Associated Processing List Backup-area Outgoing Original Called Number Associated Processing /Compare Outgoing Original Called Number Associated Processing in Active/Standby Way /Check Outgoing Original Called Number Associated Processing
LST OUTORICLDIDXBKP /CMP OUTORICLDIDX /CHK OUTORICLDIDX
LST HDOVPROCBKP /CMP HDOVPROC /CHK HDOVPROC LST RTBKP /CMP RT /CHK RT LST RTANABKP /CMP RTANA /CHK RTANA LST TGLDBKP /CMP TGLD /CHK TGLD
List Backup-area Handover Number Processing /Compare Handover Number Processing Tables in Active/Standby Way /Check Handover Number Processing List Backup Route /Compare Routes in Active/Standby Way /Check Route Table List Backup Route Analysis /Compare Route Analysis in Active/Standby Way /Check Route Analysis Table List Trunk Group Bearer /Compare Trunk Group Bearer in Active/Standby Way /Check Trunk Group Bearer
Issue 02 (2007-06-10)
21-25
Command LST TGLDIDXBKP /CMP TGLDIDX /CHK TGLDIDX LST SCCPGTBKP /CMP SCCPGT /CHK SCCPGT
Name List Trunk Group Bearer Index Backup /Compare Trunk Group Bearer Indexes in Active/Standby Way /Check Trunk Group Index Backup List Backup SCCP GT /Compare SCCP Global Titles in Active/Standby Way /Check the SCCP GT Table
LST XXXBKP
This command is used to list the standby table data. Only the tables in "Modify" or "Trial" state can be queried. The attributes in the query result are almost the same as those of the active table. The operator who is authorized to run the configuration rollback commands can query the standby tables locked by another operator.
CMP XXX
This command is used to compare the data of the active and the standby areas when the table is in "Modify" or "Trial" state. Three kinds of result can be returned: Records existing only in the active area Records existing only in the standby area Records that are inconsistent in the active and the standby areas The records are checked based on the service index field. If the index of a record exists only in the active table, then the system assumes that the record exists only in the active area. This rule also applies to the data in the standby area. If a record exists in both the active and the standby areas, but certain fields are inconsistent between the two areas, then the system assumes that the record is an inconsistent one. Only the fields related to services in a record are checked for inconsistency. In the result, the service index fields of the inconsistent records are displayed. For detailed record information, you must run the command LST XXX to query the active and the standby tables. The operator who is authorized to run this command can query the standby tables locked by another operator.
CHK XXX
This command is used to check the validity of the data in the standby area. The data can be checked only when the table is in "Modify" or "Trial" state. To improve work efficiency, the configuration commands do not check the relationship between data tables in "Modify" state. The data in the standby area, however, must be valid before activation. Therefore, you must run this command to check the data validity. At the same time, the BAM auto checks the tables with "Unknown" data every five seconds. The purpose of this command is to ensure the correctness of service data after the data is handed over to the active area. Therefore, the validity check is performed between the target standby table and other active tables. When several tables in "Modify" state rely on each other,
21-26
Issue 02 (2007-06-10)
all of them may fail to pass the check. If you confirm that the data is correct, you can run the command FACT XXX/FRLB XXX to hand over the data forcibly. The operator who is authorized to run this command can check the validity of data in the standby tables locked by another operator. The BAM auto checks the data state of the tables that is not "Valid". If the data is proved "Valid", you need not run the command CHK XXX to check the data before activation.

This feature does not affect the charging function and the CDR generation.

None.
21.9 Reference
Acronym/Abbreviation BAM LMT Full Name Back Administration Module Local Maintenance Terminal
Issue 02 (2007-06-10)
21-27
Contents
Contents
22 CAMEL4 Service ....................................................................................................................22-1
22.1 Service Description ...................................................................................................................................22-2 22.1.1 Function Code..................................................................................................................................22-2 22.1.2 Definition .........................................................................................................................................22-2 22.1.3 System Specifications ......................................................................................................................22-4 22.1.4 Benefits ............................................................................................................................................22-4 22.1.5 Application Scenario ........................................................................................................................22-4 22.1.6 Application Limitations....................................................................................................................22-4 22.2 Availability ................................................................................................................................................22-4 22.2.1 Requirements for NEs......................................................................................................................22-4 22.2.2 Requirement for License..................................................................................................................22-5 22.2.3 Applicable Versions..........................................................................................................................22-5 22.2.4 Others...............................................................................................................................................22-5 22.3 Working Principle......................................................................................................................................22-6 22.3.1 Functions of NEs..............................................................................................................................22-6 22.3.2 Internal Processing of the System ....................................................................................................22-6 22.3.3 External Interfaces ...........................................................................................................................22-6 22.4 Service Flow..............................................................................................................................................22-6 22.4.1 Conference Call ...............................................................................................................................22-7 22.4.2 CAMEL4 IN RBT Service...............................................................................................................22-9 22.4.3 CAMEL4 Simultaneous Ringing ...................................................................................................22-10 22.5 Data Configuration..................................................................................................................................22-13 22.5.1 Overview........................................................................................................................................22-13 22.5.2 Data Configuration at the MSOFTX3000 Side..............................................................................22-13 22.5.3 Data Configuration at the UMG8900 Side.....................................................................................22-13 22.5.4 Data Configuration Examples ........................................................................................................22-14 22.6 Service Management ...............................................................................................................................22-17 22.7 Charging and CDR ..................................................................................................................................22-18 22.8 Performance Measurement......................................................................................................................22-18 22.8.1 Specifications.................................................................................................................................22-18 22.8.2 Implementation Principle...............................................................................................................22-19 22.9 Service Interaction ..................................................................................................................................22-19
Issue 02 (2007-06-10)
Contents
HUAWEI MSOFTX3000 Feature Description 22.9.1 Restriction Between the Supplementary Services..........................................................................22-19 22.9.2 Restriction Between Multiple CPH Operations in the CAMEL4 Service......................................22-20
22.10 Reference...............................................................................................................................................22-21 22.10.1 Specifications...............................................................................................................................22-21 22.10.2 Glossary, Acronyms and Abbreviation.........................................................................................22-21 22.11 FAQ .......................................................................................................................................................22-23
ii
Issue 02 (2007-06-10)
Figures
Figures
Figure 22-1 CAP message flow of the CAMEL4 third-party call ....................................................................22-8 Figure 22-2 CAP message flow of the IN RBT..............................................................................................22-10 Figure 22-3 CAP message flow of the simultaneous ringing with C answering the call first ........................ 22-11 Figure 22-4 CAP message flow of the simultaneous ringing with B answering the call first ........................22-12 Figure 22-5 NC failure in the CAMEL4 ........................................................................................................22-23
Issue 02 (2007-06-10)
iii
Tables
Tables
Table 22-1 Function name and function code in the CAMEL4 service............................................................22-2 Table 22-2 Added call functions in the CAMEL4 service ................................................................................22-2 Table 22-3 Benefits for carriers and mobile subscribers...................................................................................22-4 Table 22-4 NEs required to implement the CAMEL4 feature ..........................................................................22-5 Table 22-5 Versions of the Huawei UMTS products that support the CAMEL4 feature..................................22-5 Table 22-6 New CSA Measurement ...............................................................................................................22-18 Table 22-7 Modified WIN event measurement...............................................................................................22-18 Table 22-8 List of supplementary services supported in mode A ...................................................................22-20
iv
Issue 02 (2007-06-10)
22 CAMEL4 Service
22
About This Chapter
The following table lists the contents of this chapter. Section 22.1 Service Description 22.2 Availability Describes
CAMEL4 Service
The function code and definition of the service and the benefits of the service to carriers and mobile subscribers. The NEs required to implement the service, requirements for the license, and versions of the products applicable to the service. The functions of the NEs used to implement the service and the requirements on the networking. The flow of the service. The data configuration that must be performed at the MSOFTX3000 side and the UMG8900 side as well as the examples of data configuration. The operations that carrier and mobile subscribers must perform when the service is provided. The procedure for performing charging and generating CDRs when the service is provided. The influence of the service on performance measurement and the implementation of performance measurement. The association between the service and other services as well as the restrictions on each other. The standards and specifications with which the service complies and the glossary, abbreviations, and acronyms used in this chapter. The frequently asked questions related to the service and the solutions.
22.3 Working Principle 22.4 Service Flow 22.5 Data Configuration
22.6 Service Management 22.7 Charging and CDR 22.8 Performance Measurement 22.9 Service Interaction 22.10 Reference
22.11 FAQ
Issue 02 (2007-06-10)
22-1
22 CAMEL4 Service

Table 22-1 lists the mapping between function name and function code in the CAMEL4 service. Table 22-1 Function name and function code in the CAMEL4 service Name CAMEL4 service Code WMFD-151200
22.1.2 Definition
The CAMEL function is a network feature instead of a supplementary service. As a capability of the network, the CAMEL helps carriers supply the customized enhancement services. With the CAMEL supported in the roaming network, the enhancement services are available even when the user roams out of the HPLMN network. The main functions of the CAMEL are as follows: Implementing the added call functions according to the 3GPP specification The CAMEL function is divided into multiple phases. This guide describes the Phase4 of the CAMEL function, that is, CAMEL4.The CAMEL4 can provide 19 added call functions based on the CAMEL3. Table 22-2 lists added call functions in the CAMEL4 service. Table 22-2 Added call functions in the CAMEL4 service Name Initiate Call Attempt (ICA) Definition The call attempt is initiated at the SCP side. The function is to set up a new call (NC) or a call party (NP) in a call connection. The function is to move a call party from the CS1 to a designated CS, or move a call party to a newly created CS1 when the CS1 does not exist. The CAP operation is used to move a subscriber from a CS to the main scenario CS1. The CAP operation is used to disconnect the designated call party in the current call connection without affecting other call parties.
Split Leg (SL)
Move Leg (ML) Disconnect Leg (DL)
22-2
Issue 02 (2007-06-10)
22 CAMEL4 Service
Name Entity Released
Definition The CSA notifies the SCF to release the logical entity (CS or BCSC) through the CAP operation due to the call abnormality. The other logical entities, however, are not released and thus the SCF cannot end the TC dialog. The CAP operation is used to disconnect the SRF connection established through the CTR or EFT operation (The SCP notifies the MSC Server to perform the disconnection operation). The CallSegmentID parameter is added based on the DFC basis and it is used for the situation with multiple call segments. The MSC server controls the MGW to play tone to a party in the call or a call segment. The flexible Bursts mode can be adopted in the service. For an MO/VT call, the DTMF MidCall can report the keypad value of the MO/VT user to the SCP during the call connection. The charging indicator can be reported to indicate whether the charging is generated in the O-Answer/T-Answer DP event. The parameter is the same as Charge Indicator in the ITU-T Q.763. It can expand the BCSM call module and report the O_Term_Seized/T_Call_Accepted DP event when the called user is rang in the O-BCSM/T-BCSM. The O_Term_Seized and T_Call_Accepted events contain the location information of the users (calling party and called party). The MO call supports DP O_Change_Of_Position and VT call supports DP T_Change_Of_Position. The MSOFX3000 reports the position change information of the calling party and the called party during calling The SSP supports that the criteria matching parameter for Change Of Position DP is distributed. The SCP controls the SSP to determine whether the BOR is available to the call. It indicates whether the warning tone in the BurstList format can be contained in the Apply Charging in the SCP. It is used to notify the SCP that the FTN can be contained when the ERB reports the T_Busy or T_No_Answer DP. It indicates whether the SSP supports the subscribed EDS function. It indicates whether the SSP supports the serving network EDS function.
DFC With Argument
Play Tone
DTMF Mid Call
Charging Indicator
Alerting DP
Location At Alerting
Change Of Position DP
Criteria for Change Of Position DP OR Interactions Warning Tone Enhancements CF Enhancements Subscribed Enhanced Dialed Services Serving Network Enhanced Dialed Services
Issue 02 (2007-06-10)
22-3
22 CAMEL4 Service
Name Service Change DP
Definition It indicates whether the SSP supports that the SCP distributes the O_Service_Change and T_Service_Change DPs configured by RRBE.
Supporting the MT-SMS-CSI subscription IN SMS function Besides the MO-SMS subscription service supported by the CAMEL3, the MT-SMS-CSI function (subscription IN SMS) is supported by the CAMEL4.

None.
22.1.4 Benefits
Table 22-3 lists benefits for carriers and mobile subscribers. Table 22-3 Benefits for carriers and mobile subscribers Beneficiary Carriers Description The CAMEL4 can implement more CAMEL-based service functions, such as IN multi-way conference call, IN RBT service, simultaneous ringing service, and IN callback service. The abundant service flow brings more benefits for carriers. The mobile subscriber can benefit more abundant service flows and use the different service processes in the different conditions. The subscriber also can enjoy more customized services.
Mobile subscribers

The service is applied to all markets of the GSM and the UMTS R99/R4.

The CAMEK4 service has no limitations for customers.
22.2 Availability
The VLR/MSC must interwork with the HLR, SCP to implement the CAMEL4 protocolbased services. Table 22-4 lists the NEs required to implement the CAMEL4 feature.
22-4
Issue 02 (2007-06-10)
22 CAMEL4 Service
Table 22-4 NEs required to implement the CAMEL4 feature UE Node B RNC MGW MSC Server VLR SCP HLR

The CAMEL4 feature is optional for the Huawei MSOFTX3000.The basic call functions of the CAMEL4 is available even without the CAMEL4-specific license. The following are the items involved in the license: Concurrent number of total ICA calls: maximum number of Leg information tables x number of the WCCU or WCSU modules x percentage (actual concurrent number of ICA calls)

Maximum number of Leg information tables: It is set to 4000 be default in the common parameter table. Number of the WCCU or WCSU modules: It must be accumulated based on the required modules actually. Percentage: It is the average percent of the legs (call parties) generated through the NP/NC mode in CAMEL4 services. The value is difficult to be accounted because the flows of every CAMEL4 services must be considered. Generally, it is accounted by 30% to 40%.
CAMEL4 enhancement capability The CAMEL4 enhancement is used as the chief switch to control 19 new functions in the CAMEL4 service. To acquire these functions, apply for this license first.
The MT-SMS-CSI function requires no license at present.

Table 22-5 lists the versions of the Huawei UMTS products that support the CAMEL4 feature. Table 22-5 Versions of the Huawei UMTS products that support the CAMEL4 feature Product MGW SCP HLR MSC server/VLR UMG8900 MSOFTX3000 Applicable Versions V200R006C02 V100R006C01
22.2.4 Others
None.
Issue 02 (2007-06-10)
22-5
22 CAMEL4 Service

The MSC server, MGW and VLR implement the call-related signaling processing, data analysis, tone announcement, and charging. The functions implemented by each NE are as follows: The MSC server implements 19 added functions of the CAMEL4 feature. It supports the CAP messages in the CS domain defined in 29078-640. The MGW interworks with the MSC server to enhance the capability of tone announcement, even in BurstList mode. The VLR interworks with the HLR to implement the location upgrade, roaming number acquisition and subscription data change of users with the CAMEL4 feature subscribed.

On the basis of the CCF/SSF/SRF function supported by the CAMEL2/3, the CSA-specific software function entity is added in the CAMEL4 feature. The CAMEL4 call flow with the CSA software function entity involved is as follows: The MSC initiates the common CAMEL4 IN call, including the MO, MF, MT and VT flows. The SCP initiates the network call, that is, NP or NC call flow. The CAMEL4 call flow without the CSA software function entity involved is as follows: The SSP or AIP invokes the tone announcement flow of the CAMEL4 call through the Assistant Request Instruction (ARI). The call uses the CAMEL4 version, but does not involve the CPH operation. The SMS flow of the CAMEL4 includes the MO-SMS and MT-SMS flows.

The CAMEL4 CAP and MAP adopt the R6 protocol interfaces. The detailed versions are as follows: The CAP interface involving the CAMEL4 service is based on the following interface versions:

3GPP TS 23.078 V6.3.0 (2004-09) 3GPP TS 29.078 6.3.0 (2004-09)
The MAP extension interface involving the CAMEL4 service is based on 3GPP TS 29.002 V6.7.0 (2004-09).
22.4 Service Flow

The service flow implemented in the CAMEL2/3 feature remains. For the CAMEL4-specific flow, only the following typical services are described as carriers do not identify the specific requirements for the CAMEL4 feature:
22-6
Issue 02 (2007-06-10)
22 CAMEL4 Service
Conference call CAMEL4 IN color ring Simultaneous ringing
22.4.1 Conference Call

The following takes the third-party call for an example. Assume that subscriber A calls subscribers B and C for a call conference. To perform the call conference, the following two conditions must be met: Before initiating the call, subscriber A has reserved the conference call for a certain period from the SCP. Based on the reservation conditions, the SCP initiates the call to subscriber C. Subscriber B has subscribes to the service in the SCP. After subscriber A calls subscriber B, the SCP calls subscriber C and makes subscriber C insert into the conversion between subscriber A and subscriber B. When either condition is met, the process for implementing the conference call is as follows: Subscriber A (leg1) calls subscriber B (leg2) and the call connection is established. Based on the subscription conditions, the SCP calls subscriber C (leg3) in NP mode. After subscriber C answers the call, the SCP makes C insert to the conversion between A and B. Thus, the thirdparty call connection is set up.
Issue 02 (2007-06-10)
22-7
22 CAMEL4 Service
Figure 22-1 CAP message flow of the CAMEL4 third-party call
MSC/SSP Initial DP Request Report BCSM Event Apply Charging Continue
SCP
Event Report BCSM(oAnswer) Continue Initiate Call Attempt(leg3) Initiate Call Attempt Ack Request Report BCSM Event(leg3) Apply Charging(For leg3) Continue With Argument(For leg3) Event Report BCSM(oAnswer/leg3) Continue With Argument(leg3) Move Leg(leg3) Move Leg Ack Continue With Argument(CS1)
The CAP message flow of the CAMEL4 third-party is divided into the following parts: A calling B: The process is the same as that of the CAMEL2/3 PPS service. NP calling leg3: See the flow highlighted in blue in Figure 22-1.
The SCP creates the third party in the call through the Initiate Call Attempt (leg3) message. The MSC server returns the Initiate Call Attempt Ack message.
22-8
Issue 02 (2007-06-10)
22 CAMEL4 Service
The SCP sends the Request Report BCSM Event (leg3) and Apply Charging (For leg3) messages to require the MSC server to report basic call status model even and ask for charging. The MSC server returns the Event Report BCSM (oAnswer/leg3) message and reports the response of the third party (leg3).
Porting leg3 to the conversion between A and B through the ML operation: It involves in a serial of complex processes, such as conference establishment inside and bearer refreshment.
The two colors are used in the preceding flow only to ease the description. The entire CAP message flow, however, is implemented in the same Transaction Capabilities Application Part (TCAP) dialog.
22.4.2 CAMEL4 IN RBT Service

Assume that subscriber B has subscribed RBT service in the SCP. When subscriber A (leg1) calls subscriber B (leg2), the CAMEL4 IN RBT function is invoked. The SCP disconnects B (leg2) and re-initiates a call to B in NP mode. In this case, B acts legs in the call. When B receives the ALERTING message, the SCP plays RBT to A. After B answers the call, the RBT stops and thus the call connection between A and B is set up.
For CAMEL4 IN RBT function, the SCP determines the route to the RBT center and the SSP (MSC server) processes only the call connection. You need not configure the RBT control table.
Issue 02 (2007-06-10)
22-9
22 CAMEL4 Service
Figure 22-2 CAP message flow of the IN RBT

SSP Initial DP DisconnectLeg(leg2) Disconnect LegAck InitiateCallAttempt(Number=B,leg3) Initiate Call Attempt Ack RequestReportBCSM Event(leg3,O_Term_Seized_Answer) ContinueWithArgument(leg3) EventRepotBSCM(leg3,O_Term_Seized) ConnectToResource(CS1) PlayAnnouncement(CS1) ContinueWithArgument(leg3) EventReportBCSM(leg3,O_Answer) DisconnectForwardConnectWith Argument(CS1) MoveLeg(leg3) Move Leg Ack ContinueWithArgument(CS1) ContinueWithArgument(leg3) SCP
The CAP message flow of the CAMEL4 IN RBT is divided in to the following parts: The IDP invokes the call and disconnects the leg2 first. The called party (leg3) is connected in the NP call mode. When the Event Report BCSM (O_Term_Seized) is reported to the SCP, the SCP indicates the SSP to play RBT. In the flow, the RBT function is available in the local office by default. If the RBT is not in the local office, the RBT played must be implemented through the AIP or auxiliary SSP in other offices in ETC mode. The called party (leg3) responds the report of the Answer event. The SCP sends the Disconnect Forward Connect With Argument (CS1) message to stop the RBT. At the same time, it sends the Move Leg message to set up the call connection between calling party and called party (leg3).
22.4.3 CAMEL4 Simultaneous Ringing

The simultaneous ringing indicates that being correlated with other subscribers, the subscriber is called and the correlated subscribers are also ringing at the same time. The first to answer
22-10
Issue 02 (2007-06-10)
22 CAMEL4 Service
the call is the actual called party. The following takes two subscribers who are simultaneously ringing for example. Figure 22-3 shows the message flow. Subscriber B has subscribed the simultaneous ringing service with subscriber C and thus subscriber B is correlated with subscriber C. When subscriber A calls B to invoke the IN service, B and C are ringing simultaneously after the SCP starts the simultaneous ringing service. If C answers the call first, the call connection between A and C is established and B is disconnected. If B answers the call first, the call connection between A and B is established and C is disconnected Figure 22-3 CAP message flow of the simultaneous ringing with C answering the call first
SSP Initial DP RequestReportBCSM Event(leg2,O_Term_Seized/O_Answer) InitiateCallAttempt(Number=C,leg3) InitiateCallAttemptResult RequestReportBCSM Event(leg3,O_Term_Seized/O_Answer) ContinueWithArgument(leg3) ContinueWithArgument(leg2)
SCP
EventRepotBSCM(leg2,O_Term_Seized) EventRepotBSCM(leg3,O_Term_Seized) ContinueWithArgument(leg3) ContinueWithArgument(leg2) EventRepotBSCM(leg3,O_Answer) Disconnectleg(leg2) Disconnect leg ACK MoveLeg(leg3) Move Leg Ack ContinueWithArgument(CS1) ContinueWithArgument(leg3)
Issue 02 (2007-06-10)
22-11
22 CAMEL4 Service
Figure 22-4 CAP message flow of the simultaneous ringing with B answering the call first
SSP Initial DP
SCP
InitiateCallAttempt(Number=C,leg3) InitiateCallAttemptResult RequestReportBCSM Event(leg3,O_Term_Seized/O_Answer) ContinueWithArgument(leg3) ContinueWithArgument(leg2)
Disconnect leg ACK ContinueWithArgument(CS1)
The message flow of the simultaneous ringing call is as follows: A calls B to invoke the IN service. The SSP sends the InitialDP message to the SCP. The SCP sends the Request Report BCSM Event (leg2, O_Term_Seized/O_Answer) message to require the SSP (MSC server) to report the ringing and answering event of subscriber B (leg2). After the SCP sends the Initiate Call Attempt(Number =C, leg3) message to set up the third call party subscriber C (leg3), the SSP (MSC server) returns the Initiate Call Attempt Result message. The SCP sends the Request Report BCSM Event (leg3, O_Term_Seized/O_Answer) message. In this case, the SSP (MSC server) reports the ringing and answering event of B (leg2) and C (leg3). If the SSP (MSC server) reports the Event Repot BSCM (leg3, O_Answer) message, it indicates that C answers the call first, as shown in Figure 22-3. The SCP sends the Disconnect leg (leg2) message to release B (leg2).It sends the Move Leg message to port C (leg3) in the conversion, and thus the call connection between C and A is established. If the SSP (MSC server) reports the Event Repot BSCM (leg2, O_Answer) message, it indicates that B answers the call first, as shown in Figure 22-4. The SCP sends the
22-12
Issue 02 (2007-06-10)
22 CAMEL4 Service
Disconnect leg (leg3) message to release B (leg2).The call connection between A and B is established.

22.5.1 Overview
The CAMEL4 service requires less data configuration, but requires more for the mating version. The requirements for applicable version for the CAMEL4 feature are as follows: MSOFTX3000: V100R006C01 UMG: V200R006C02(BUILD3) HLR: none
22.5.2 Data Configuration at the MSOFTX3000 Side

Steps 1 Actions Run DSP LICENSE to check whether the two license files are available for the CAMEL4 feature, including concurrent number of total ICA calls and CAMEL4 enhancement capability. If not, apply for the licenses and run LOD LICENSE to load the licenses file supporting the CAMEL4 service. Run LST MAPACCFG to check whether the CAMEL version is set to CAMEL_PHASE4. If not, run SET MAPACCFG to set CAMEL version to CAMEL_PHASE4. Run ADD SSPCAPA to set the 19 CAMEL4 capabilities of the IN service invoked by the SSP/MSC. The 19 functions require the license. Run MOD MGW and SET CODECCAP to configure the resource capacity of the MGW multi-way conference call in the MSOTFX3000 and the MGW. Run MOD MSFP to set Service key for the NC call. Run MOD MSFP to configure the relation between the CAMEL4 CPH function and the supplementary service. Run MOD MSFP to configure the relation between the different CPH scenarios for the CAMEL4. Run MOD MSFP to configure whether the explicit conference establishment is used when the tone is played to both parties in the CAMEL4 service.
3 4 5 6 7 8

For the UMG8900 involved the CAMEL4, you need to configure the conference call resource capacity in the UMG8900. The number of the channels is configured based on the actual conditions. By default, it is set to 256 conference call channel on each VPU board.
Issue 02 (2007-06-10)
22-13
22 CAMEL4 Service

The following describes the CAMEL4-specific data configuration, without involving the general flow of the CAMEL IN data.
Scenario Description 1
The service key of the OCSI subscribed in the CAMEL4 is 1. The service must support all the newly added functions of the CAMEL4. The SCP in the peer office determines whether IP/SSP capability needs to be reported in the IDP.
The procedure for configuring the MSOFTX3000 is as follows: Step 1 Modify the MAP configuration table and set CAMEL version to CAMEL phase4. Description Script Remark Modify the MAPACCFG table to support the CAMEL4 service. SET MAPACCFG: MAPVER=PHASE3, CAMELVER=PHASE4; The CAMEL4 version needs to be configured with MAP phase3.
Step 2 Configure the SSP capability table. Description Script Configure the SSP capability table. ADD SSPCAPA: SRVKEY=1, SSPCAPA=IPRA-1&VOICEBACK1&SPREC-1&VOICEREC-1&TEXTTOV-1&TRIGMTCBYPRI-1, OSSPCAPA=ReportIpSspCapability-0, CAMEL4FUN=INITIATECALLATTEMPT-1&SPLITLEG1&MOVELEG-1&DISCONNECTLEG-1&ENTITYRELEASED1&DFCWITHARGUMENT-1&PLAYTONE-1&DTMFMIDCALL1&CHARGINGINDICATOR-1&ALERTINGDP1&LOCATIONATALERTING-1&CHANGEOFPOSITIONDP1&ORINTERACTIONS-1&WARNINGTONEENHANCEMENTS1&CFENHANCEMENTS-1&SUBSCRIBEDEDS1&SERVINGNETWORKEDS-1&CRITERIAFORCOPDP1&SERVICECHANGEDP-1; For CAMEL4 capability, if the MSC server need not support all functions, you can configure some functions of the CAMEL4 capability.
Remark
Step 3 Configure the MGW multi-way conference call resource capability.
22-14
Issue 02 (2007-06-10)
22 CAMEL4 Service
Description
To configure the conference call resource capability in the MSOFTX3000 and MGW, the VPU in frame 0 provides 256 channels of conference call resources. At the MSOFTX3000 side: MOD MGW: MGWNAME="DONGGUAN", TRNST=SCTP, CPB=MPTY-1, MPTYRATE=256; At the MGW side: SET CODECCAP: BN=0, CODEC=MPTY-1, MPTYCHN=CHN256;
Script
Remark
The number of conference call resources configured in the MGW must be consistent with that in the MSOFTX3000.
Step 4 Configure the relation between the supplementary service and the CAMEL4 CPH operation. Description Script Remark Modify Call internal parameter 31 to 0. MOD MSFP: ID=P900, MODTYPE=P1, BIT=5, BITVAL=0; For detailed description of the software parameter, refer to Scenario Description 3 in section 1.5 "Data Configuration."
----End
The MSC server supports the NC call initiated by the SCP. The network call uses service key 100 and IP/SSP capability is not required to be reported to the SCP.
The service key of the NC is not specified in the specifications. The service key 100 is defined by Huawei to query the CAMEL capability.
The procedure for configuring the MSOFTX3000 is as follows: Step 1 Modify the MAP configuration table and set CAMEL version to CAMEL phase4. Description Script Remark Modify the MAPACCFG table to support CAMEL4 feature. SET MAPACCFG: MAPVER=PHASE3, CAMELVER=PHASE4; The CAMEL4 version needs to be configured with MAP phase3.
Issue 02 (2007-06-10)
22-15
22 CAMEL4 Service
Step 2 Configure the SSP capability table. Description Script Configure the SSP capability table. ADD SSPCAPA: SRVKEY=100, SSPCAPA=IPRA-1&VOICEBACK1&SPREC-1&VOICEREC-1&TEXTTOV-1&TRIGMTCBYPRI-1, OSSPCAPA=ReportIpSspCapability-0, CAMEL4FUN=INITIATECALLATTEMPT-1&SPLITLEG1&MOVELEG-1&DISCONNECTLEG-1&ENTITYRELEASED1&DFCWITHARGUMENT-1&PLAYTONE-1&DTMFMIDCALL1&CHARGINGINDICATOR-1&ALERTINGDP1&LOCATIONATALERTING-1&CHANGEOFPOSITIONDP1&ORINTERACTIONS-1&WARNINGTONEENHANCEMENTS1&CFENHANCEMENTS-1&SUBSCRIBEDEDS1&SERVINGNETWORKEDS-1&CRITERIAFORCOPDP1&SERVICECHANGEDP-1; For CAMEL4 capability, if the MSC server need not support all functions, you can configure some functions of the CAMEL4 capability.
Remark
Step 3 Modify the service key. Description Script Remark Modify Service key of the NC call to 100. MOD MSFP: ID=P1201, MODTYPE=P0, VALUE="FF64"; P1201 BIT0-7 indicates the service keys used for the NC call. The service key 100 is 0x64 in hexadecimal; thus, the value of the parameter is 64.
----End
Configure the relation between the supplementary service and the CAMEL4 CPH operation.
Description Script Remark Modify Call internal parameter 31 to 0. MOD MSFP: ID=P900, MODTYPE=P1, BIT=5, BITVAL=0; Bit5 of P900 controls the relation between the CPH operation and the supplementary service. 1: It indicates that the CPH operation is not contradictory with supplementary services. It is the default value. 0: It indicates that the CPH operation is contradictory with supplementary services. For details, refer to mode B in section 22.9.1 "Restriction Between the Supplementary Services."
22-16
Issue 02 (2007-06-10)
22 CAMEL4 Service
Configure the restriction between two CPH operations when MO and MT CAMEL4 are invoked by a call.
Description Script Remark Modify P1201 of WIN to mode 2 of the restriction between multiples CPH operations. MOD MSFP: ID=P1201, MODTYPE=P1, BIT=10, BITVAL=1; MOD MSFP: ID=P1201, MODTYPE=P1, BIT=11, BITVAL=0; The P1202 Bit10-11 of WIN controls the restriction between multiple CPH operations: 00: Mode 1 indicates that the CPH operations do not contradictory with each other. It is set to 00 by default. 01: It indicates that mode 2 is used. 10: It indicates that mode 3 is used. 11: It is reserved. Note: For details, refer to 22.9.2 "Restriction Between Multiple CPH Operations in the CAMEL4 Service."

MSC server
For details, refer to 22.5.4 "Data Configuration Examples."
HLR
The CAMEL4 services are centralized in the maintenance of the subscription data. At present, Huawei does not release the HLR version for the CAMEL4 feature. In future, the applicable version of the HLR can be provided based on the related data maintenance guide of the HLR version.
Operations by Carriers
To conduct the CAMEL4 service, carriers can upgrade the entire network to provide all the CAMEL4 service functions, or provide some of the functions.
The CAMEL4 is not widely used in the current network and the service application is not mature. In this case, the service is not provided presently.
Operations by Subscribers
The CAMEL4 service is operated by network and requires no mobile user's operation.
Issue 02 (2007-06-10)
22-17
22 CAMEL4 Service

The charging of the CAMEL4 is complex. For details, refer to the related description documentation of the charging bill.

Traffic Statistics Measurement Unit Involved the CAMEL4
New CSA Measurement is used to measure the number of success and failure for CPH and Entity Release execution. Table 22-6 lists the added custom entities for the CSA measurement. Table 22-6 New CSA Measurement Measurement Unit CSA Measurement Added Custom Entity CSA CPH RECEIVED MOVELEG CSA CPH SEND MOVELEG ACK CSA CPH RECEIVED SPLITLEG CSA CPH SEND SPLITLEG ACK CSA CPH RECEIVED DISCONNECTLEG CSA CPH SEND DISCONNECTLEG ACK CSA CPH SEND ENTITY RELEASE CSA CPH FAILURE NUM
Table 22-7 lists the added custom entities for the modified WIN event measurement. Table 22-7 Modified WIN event measurement Measurement Unit WIN Event Measurement Added Custom Entity MT SMS Delivery Requested MT SMS Failure MT SMS Delivery MO TermSeized MT CallAccepted MO ChangeofPosition MT ChangeofPosition
22-18
Issue 02 (2007-06-10)
22 CAMEL4 Service
Measurement Unit
Added Custom Entity MO ServiceChange MT SserviceChange MO MidCall MT MidCall
22.8.2 Implementation Principle

The principle for implementing the CAMEL4 is the same as that for common traffic statistic. For details, refer to the MSOFTX3000 Performance Specification Reference.

The section describes the mutual impact and restriction between some call scenarios and the CAMEL4, which are not identified in the 3GPP.The scenarios are so complex that you need to consult the R&D personnel for the latest information if the onsite scenario is not described here.
22.9.1 Restriction Between the Supplementary Services

The CAMEL4 supplies the CPH function. After the call is activated and is in connected state, the SCP performs the bearer modification through the CPH operation. Certain supplementary services such as call hold, call waiting, conference call and explicit call transfer (ECT) may also result in bearer modification. In this case, the CPH operation may conflict with the supplementary services. If no measure is taken for the supplementary and CPH operation, the result of the bearer may be unpredictable. The CAMEL4 does not detail the measures to be taken, so you need to conduct the following configurations based on the internal implementation mechanism of the interaction between the CPH operation and supplementary services: Mode A The CPH operation is not contradictory with supplementary services. If the CPH flow and supplementary services exist simultaneously, the result may not meet the requirement for the service application as they do not restrict each other. In this case, adopt mode B to handle the process. Table 22-8 lists the supplementary services supported in mode A. For the services which are not specified, consult the R&D department for the latest information.
Issue 02 (2007-06-10)
22-19
22 CAMEL4 Service
Table 22-8 List of supplementary services supported in mode A Supplementary Services Call hold Whether to Support in Mode A Supported Description
After a subscriber holds a call, but before retrieves the call, the SCP moves the subscriber leg to the CS1 through the CPH operation. The subscriber then restores to the original situation through the RETRIEVE operation. In this case, the result of the RETRIEVE operation may be not consistent with the expectation of the subscriber. It is the same as Call hold. As in the CAMEL2/3, the IN subscriber who initiates the call does not support the ECT service. The subscriber in the conference also cannot initiate the ECT call. (The ECT is enabled only when the number of leg is less than two in the CS1.) The CPH operation and the conference call cannot be supported simultaneously. None.
Call waiting ECT
Supported Supported
Conference call Forwarded call services
Not supported Supported
Mode B The CPH operation is contradictory with supplementary services and the detailed principles are as follows:

During call connection, if the SCP performs the CPH operation first, the supplementary services will be prohibited temporarily in the subsequent process. If supplementary services are performed first, the CPH operation is prohibited when supplementary services do not retrieve the original call scenario completely. After supplementary services are completed, the SCP can continue to perform the CPH operation.
22.9.2 Restriction Between Multiple CPH Operations in the CAMEL4 Service

This scenario is applied when the IN relations of the CAMEL MO and MT/VT are invoked in the MSOFTX3000 at the same time. In this scenario, if two SCPs perform the CPH operation simultaneously, the result is unpredictable. The 3GPP, however, does not detail how to process the contradiction. The MSOFTX3000 supports the following processing modes: No-restriction: The MO and MT/VT do not restrict each other. This mode is used only when the CPH operation cannot be performed to the same call by the MO and MT/VT. The result is difficult to be confirmed, so this mode is not recommended. Determining whether LEG1 and LEG2 retrieve to the CS1: This mode is the same as the HOLD/RETRIEVE mode. You need to determine whether one of the call parties (LEG1 and LEG2) invoked initially is in CS1 (The CPH operation is not performed). If so, the subsequent CPH operation is permitted; otherwise, the CPH operation fails.
22-20
Issue 02 (2007-06-10)
22 CAMEL4 Service
CAMEL4 capability restriction: The mode is implemented through the CAMEL4 capability of the IDP message of the initial call. If the MO invokes the CAMEL4, the CAMEL4 CPH capability of the invoked MT call is cleared. In the MT/VT call, when finding that the SSP has no CAMEL4 capability in the IDP message, the SCP does not perform the CPH operation in the MT call. For details, refer to scenario description 3 in section 22.5.4 "Data Configuration Examples."
22.10 Reference
The reference lists of the feature are as follows: 3GPP TS 23.078 V6.3.0 (2004-09) 3GPP TS 29.078 6.3.0 (2004-09) 3GPP TS 29.002 V6.7.0 (2004-09)
22.10.2 Glossary, Acronyms and Abbreviation

Glossary
Glossary CSA Definition Call segment association involved in the CAMEL4 call. A CSA corresponds to a TCAP dialog. One IN relation of CAMEL4 service contains one CSA, and one CSA contains multiple CSs. Call segment involved in the CAMEL4 call. Ranges from CS1 to CS127. CS1 is the main scenario for the call by default. A logical concept of a call party in the CAMEL4 service, ranging from LEG1 to LEG127.The call initiates by the CAMEL4 IDP must generate LEG1 and LEG2 only. LEG3 and other LEGs are generated in NP/NC mode. Generally, a LEG corresponds to a physical subscriber. In the case of multiple connection and multiple call attempts in a call, however, a LEG may correspond to different physical subscribers. A unique method to create LEG3 and other call parties (NP/NC LEGs) in the CAMEL4.
CS LEG
ICA
Issue 02 (2007-06-10)
22-21
22 CAMEL4 Service
Glossary Bursts/BurstList
Definition A Burst contains the following: ToneDuration: time duration of each Tone, ranging from 0.1 seconds to 2 seconds ToneInterval: interval of each Tone, ranging from 0.1 seconds to 2 seconds NumberOfTonesInBurst: repeated times of the Tone in a Burst, ranging from 1 to 3 BurstInterval: interval between two Bursts, ranging from 0.1 seconds to 120 seconds NumberOfBursts: number of Bursts which is available to broadcast, ranging from 1 to 3

Acronyms/Abbreviations 3G 3GPP TCAP ECT SSP SCP LEG NP NC CS CSA CPH BCSM EDP CAMEL CTR ETC ICA SL Full Name The Third Generation 3rd Generation Partnership Project 2 Transaction Capabilities Application Part Explicit Call Transfer supplementary service Service Switching Point Service Control Point Leg New Party/Network Party New Call/Network Call Call Segment Call Segment Association Call Party Handling Basic Call State Model Event Detection Point Customized Application for Mobile network Enhanced Logic Connect To Resource Establish Temporary Connection Initiate Call Attempt Split Leg
22-22
Issue 02 (2007-06-10)
22 CAMEL4 Service
Acronyms/Abbreviations ML DL
Full Name Move Leg Disconnect Leg
22.11 FAQ
NC failure
Symptom
The SCP initiates an NC, and the SSP uses the service key 100. The message, however, is refused when it reaches the CAP interface. Thus, the NC fails. The message is traced through the TCAP, as shown in Figure 22-5. Figure 22-5 NC failure in the CAMEL4
SSP TC_BEGIN_IND TC_INVOKE_IND(InitiateCallAttempt) TC_U_ABORT_REQ SCP
Analysis
The NC failure may be caused when Service key is not configured in the MSC server. The CAMEL4 requires you to configure the service key for the NC correctly. The correct configuration enables the MSC server to obtain the CAMEL4 capability through querying the table.
Solution
When Service key of the lower 8 bits of P1201 is modified to 100, the failure is removed. MOD MSFP: ID=P1201, MODTYPE=P0, VALUE="FF64";
Issue 02 (2007-06-10)
22-23
Contents
Contents
23 IMSI-Based Announcement.................................................................................................23-1
23.1 Service Description ...................................................................................................................................23-3 23.1.1 Function Code..................................................................................................................................23-3 23.1.2 Definition .........................................................................................................................................23-3 23.1.3 System Specifications ......................................................................................................................23-3 23.1.4 Benefits ............................................................................................................................................23-3 23.1.5 Application Scenario ........................................................................................................................23-4 23.1.6 Application Limitations....................................................................................................................23-4 23.2 Availability ................................................................................................................................................23-4 23.2.1 Requirements for NEs......................................................................................................................23-4 23.2.2 Requirements for License ................................................................................................................23-4 23.2.3 Applicable Versions..........................................................................................................................23-4 23.2.4 Others...............................................................................................................................................23-5 23.3 Working Principle......................................................................................................................................23-5 23.3.1 Functions of the NEs........................................................................................................................23-5 23.3.2 Internal Processing of the System ....................................................................................................23-5 23.3.3 External Interfaces ...........................................................................................................................23-7 23.4 Service Flow..............................................................................................................................................23-7 23.5 Data Configuration....................................................................................................................................23-8 23.5.1 Overview..........................................................................................................................................23-8 23.5.2 Data Configuration at the MSOFTX3000 Side................................................................................23-8 23.5.3 Data Configuration at the UMG8900 Side.......................................................................................23-9 23.5.4 Data Configuration Examples ..........................................................................................................23-9 23.5.5 Querying Tables of the IMSI-Based Announcement Service.........................................................23-10 23.6 Service Management ...............................................................................................................................23-13 23.7 Charging and CDR ..................................................................................................................................23-13 23.8 Performance Measurement......................................................................................................................23-13 23.9 Interactions with Other Services .............................................................................................................23-13 23.10 Reference...............................................................................................................................................23-13 23.10.1 Specifications...............................................................................................................................23-13 23.10.2 Acronyms and Abbreviations .......................................................................................................23-13 23.11 FAQ .......................................................................................................................................................23-13
Issue 02 (2007-06-10)
Contents
HUAWEI MSOFTX3000 Feature Description 23.11.1 Question 1 ....................................................................................................................................23-13 23.11.2 Question 2 ....................................................................................................................................23-14 23.11.3 Question 3 ....................................................................................................................................23-14
ii
Issue 02 (2007-06-10)
Figures
Figures
Figure 23-1 International roaming subscriber originates a call and the callee is power-off (the GMSC server and VMSC server are combined).............................................................................................................................23-6 Figure 23-2 Service flow in the case of an abnormal call ................................................................................23-7 Figure 23-3 Table query flow in the IMSI-based announcement service .......................................................23-12
Issue 02 (2007-06-10)
iii
Tables
Tables
Table 23-1 Name and code of the function.......................................................................................................23-3 Table 23-2 System specifications .....................................................................................................................23-3 Table 23-3 NEs required to implement the IMSI-based announcement service...............................................23-4 Table 23-4 Version of Huawei UMTS MSOFTX3000 that supports the IMSI-based announcement service..23-5 Table 23-5 Steps of data configuration on the MSOFTX3000 .........................................................................23-8 Table 23-6 Related tables in the IMSI-based announcement service..............................................................23-10
iv
Issue 02 (2007-06-10)
23
About This Chapter
IMSI-Based Announcement
The following table lists the contents of this chapter. Describes The function code, function definition of this feature, and the benefits that carriers and mobile subscribers can obtain from this feature. The network elements (NEs) that are required for the feature, whether Licenses are required, and the version requirements of the NEs. The functions of the NEs, and networking requirements. The service flow of the network when providing this feature. The data configurations that are required on the MSOFTX3000 and the UMG8900. The service operations that carriers and mobile subscribers are required to implement when the network provides this feature. The charging and the generation of CDRs when the network provides this feature. The influence of the service on performance measurement and the implementation of performance measurement. The association between the service and other services as well as the restrictions on each other. The protocols and specifications that this feature must comply with, and the acronyms and abbreviations of this chapter.
23.7 Charging and CDR 23.8 Performance Measurement
23.9 Interactions with Other Services 23.10 Reference
Issue 02 (2007-06-10)
23-1
Section 23.11 FAQ
Describes The frequently asked questions related to the service and the solutions.
23-2
Issue 02 (2007-06-10)

Table 23-1 lists the name and code of the function. Table 23-1 Name and code of the function Name IMSI-based announcement Code WMFD-091100
23.1.2 Definition
IMSI-based announcement enables the carrier to set the language type for announcement based on subscriber IMSI. This service realizes announcement based on IMSI number segments of mobile originating subscribers.

Table 23-2 System specifications Item Setting announcement language type based on IMSI number segments of mobile originating subscribers Specification Add the mapping between IMSI and language type. When a mobile subscriber originates a call, the system queries the database based on the subscriber IMSI to obtain the corresponding language type and sets the language type as the preferred for announcement. You can set up to five language types through IMSI mapping.
23.1.4 Benefits
Beneficiary Carrier Description The service enables the system to play announcements in language types that the subscribers are familiar with, providing thoughtful service and improving subscriber satisfaction. With this service, subscribers, especially international roaming subscribers, can hear their familiar languages, thus improving the auditory effect.
Mobile subscriber
Issue 02 (2007-06-10)
23-3

It is applicable to all GSM and UMTS R99/R4 networks. As a basic feature of the MSOFTX3000, IMSI-based announcement is applied in the originating office of announcement. Through this feature, carriers can provide a language type that an international roaming subscriber is familiar with to play announcement based on the subscribers IMSI number segment when the subscriber originates a call. In this way, subscriber satisfaction can be improved.

IMSI-based announcement has the following limitations: It supports announcements by the originating end office only. It is not applicable to asynchronous tone, meeting tone, time reporting tone, praying tone, ring back tone, or call hold tone. For outgoing calls, if the trunk is TUP trunk, IMSI-based announcement is not allowed.
23.2 Availability
Table 23-3 lists the network elements (NEs) required to implement the IMSI-based announcement service. Table 23-3 NEs required to implement the IMSI-based announcement service UE/MS NodeB/ BTS RNC/ BSC MSC Server MGW SGSN GGSN HLR -
"" indicates the NE is involved in this function.

IMSI-based announcement is a basic service of HUAWEI GSM/ UMTS CN. You can use the service without acquiring a license.

Table 23-4 lists the version of Huawei UMTS MSOFTX3000 that supports the IMSI-based announcement service.
23-4
Issue 02 (2007-06-10)
Table 23-4 Version of Huawei UMTS MSOFTX3000 that supports the IMSI-based announcement service Product MSC server MSOFTX3000 Applicable Version V100R005C10
23.2.4 Others
None.

In IMSI-based announcement, the MSC server works with the MGW to implement the service. The MSC server is responsible for: Configuring the announcement according to IMSI segments Obtaining the language based on IMSI segments of mobile originating subscribers The MGW is responsible for: Loading the corresponding announcement file Playing announcement

The IMSI-based announcement service implements announcement to callers according to an intelligent network announcement flow. The IMSI-based announcement service mainly applies to the situation when international roaming subscribers originate calls and the announcements are played at the originating office. The following are the internal processing steps on the MSC server: 1. The MSC server queries the IMSI prefix of the caller in the IMSI Language Configuration table (configured through ADD IMSILANG) to obtain the value of Specific language kind, such as 02, and the value of Reserve old language indication, such as Yes. When the originating office plays the announcement, the MSC server queries the tone ID configuration table (configured through ADD TONECFG) based on the default tone ID such as 0xF0010214, and gets a language type list (shortened as "list 1" hereafter), such as English. Based on the default Tone ID, the MSC server queries the Language Category Index Position table (configured through ADD LKINDPOS), and obtains the language category index position, that is, 0x01. For example, 01 of 0xF0010214 specifies the language category index.
2.
3.
Issue 02 (2007-06-10)
23-5
4.
The MSC server replaces the value of Specific language kind with the bits that specify the language category index, and obtains a new EID such as 0xF0020214.
EID is one of the parameters that the MSOFTX3000 uses to interwork with the MGW. It specifies the code of the signal tone or announcement at the MGW side. An EID is an 8-bit hexadecimal numeral. When it is used to specify signal tones, its bit structure is as follows (from high bit to low bit): service key (2 bits), language index (2 bits), voice code (4 bits). These bits work together to instruct the MGW to correctly handle the voice resources on its MTCU board. For instance, if EID "F0010135" is used to specify the call waiting tone, "F0" is the service key, which represents basic service tone or supplementary service tone. "01" is the language index which means the language is English. "0135" is the voice code, indicating that the tone is a call waiting tone.
5.
Based on the service key and tone bit of the new EID, the MSC server queries the Language Category table (configured through ADD LANKIND), and obtains a language category list (shortened as "list 2" hereafter) such as Chinese. Based on Reserve old language indication in the IMSI Language Configuration table and the information in list 1 and list 2, the MSC server obtains the announcement language list for the MGW. For details, see 23.11 "FAQ." The MSC server queries the Language Kind Change table (configured through ADD LKINDCHG) to obtain the language kind index corresponding to the announcement language list. The MSC server then obtains a tone ID that is sent to the MGW. The MSC server sends the tone ID to the MGW and instructs the MGW to play announcement.
6.
7.
8.
Figure 23-1 shows the flow of the IMSI-based announcement service when an international roaming subscriber originates a call and the callee is in the power-off state. Figure 23-1 International roaming subscriber originates a call and the callee is power-off (the GMSC server and VMSC server are combined)
Caller
(9)
(1) (7)
(2)
(5)
HLR
(3)
(4) (G/V) MSC server
(6) (8)
MGW
The flow of the IMSI-based announcement service is as follows: 1. The (G/V)MSC server receives a call request from the caller, and obtains the values of Reserve old language indication and Specific language kind based on the caller IMSI.
23-6
Issue 02 (2007-06-10)
2. 3. 4. 5. 6. 7. 8. 9.
The (G/V)MSC server requests the routing information from the HLR in which the callee is located. After identifying that the callee is switched off, the HLR returns a corresponding message. The (G/V)MSC server sends a termination establishment request to the MGW. The MGW returns a response message. The (G/V)MSC server plays failure announcement in the corresponding language based on the IMSI Language table. The (G/V)MSC server sends an announcement request to the MGW to instruct the MGW to play announcement in the language derived from the caller IMSI. The MGW responds to the request and plays the announcement. After the announcement is complete, the (G/V)MSC server sends a disconnection message to the caller.

None.
23.4 Service Flow

The IMSI-based announcement service is mainly applied in the situation when an international roaming subscriber originates a call and thus generates various announcements, such as abnormal tone, call forwarding tone and call waiting tone. With the IMSI-based announcement service, the language type for announcement can be adjusted according to the IMSI prefix. The following describes the service flow when an international roaming subscriber originates a call and the callee is switched off, as shown in Figure 23-2. Figure 23-2 Service flow in the case of an abnormal call
MS A /UE A Set-up Info request Info ack(absent subscriber) Add_req(c$,T1) Assignment-Request AssignmentRepsponse Add_reply(C,T1) GMSC server HLR B MGW
Add_req(C,DummyT) Add_reply Mod_req(C,T1,language) Mod_reply
disconnect
The process is as follows:
Issue 02 (2007-06-10)
23-7
1.
MS A initiates a call by sending a Set-up message to the (G/V)MSC server. Based on the caller IMSI, the (G/V)MSC server queries the database and obtains the language type that matches the IMSI. The (G/V)MSC server sends a routing information request to the HLR. The HLR sends an information acknowledgement message, which indicates that the callee is power-off, to the (G/V)MSC server. The (G/V)MSC server sends an Add_req message to the MGW, asking for establishing a calling termination. The MGW responds to the (G/V)MSC server with an Add_reply message. The (G/V)MSC server initiates an Assignment request. The access side responds with an Assignment Complete message. The (G/V)MSC server sends the MGW an Add_req message, asking for establishing a Dummy termination. The MGW responds to the (G/V)MSC server with an Add_reply message.
2. 3. 4. 5. 6. 7. 8. 9.
10. The (G/V)MSC server sends the MGW a play announcement request Mod_req, instructing the MGW to use the language derived from the IMSI of caller. 11. The MGW returns a Mod_reply message to the (G/V)MSC server. 12. The (G/V)MSC server sends a call disconnect message, with the Progress indicator indicating IN_BAND_INFO_OR_APPROPRIATE_PATTERN_IS_NOW_AVAILABLE, to MS A.

23.5.1 Overview
As for this feature, data needs to be configured on the MSOFTX3000 to ensure that the system can map corresponding languages based on IMSI number segments. On the UMG8900, voice files in corresponding languages need to be loaded, but data configuration is not required. .

Table 23-5 lists the steps of data configuration for IMSI-based announcement on the MSOFTX3000. Table 23-5 Steps of data configuration on the MSOFTX3000 Step 1 2 3 Action Run ADD LKINDCHG to configure the mapping between languages in the MSOFTX3000 and the ones on the UMG8900. Run ADD LKINDPOS to configure the start bit of language type (to get the language index). Set Service key to 240. Run ADD LANKIND to configure the mapping between language indexes in the voice EID and internal language types in the MSOFTX3000.
23-8
Issue 02 (2007-06-10)
4 5
Run ADD TONECFG to configure the tone ID of the MGW and such parameters as the cycle times, announcement duration, and default language. Run ADD IMSILANG to configure the mapping between IMSI number segments and language types.

As for this feature, no data need be configured on the UMG8900. Only the voice files of corresponding languages need to be loaded on the UMG8900.

A Chinese subscriber whose IMSI is 460077552000545 roams to Britain and originates a call. The callee is in the power-off state. The carrier wants to play announcements for the subscriber in Chinese and keeps the default configuration of the original MSC Server. Suppose that the basic number analysis data and voice data (including mapping between cause values, tone IDs and configuration of tone IDs and default language English) are configured. On the MSC Server, the announcement that the called subscriber is switched off is configured as follows:
Tone ID = TID58(Mobile callee shutdown tone) MGW tone ID = F0010214 MGW tone content = Sorry! The subscriber you dialed is power off. Use dummy terminal = Yes Number of cycles = 2 Duration(sec) = 0 Language1 = English Language2 = Default language Language3 = Default language Language4 = Default language Language5 = Default language
The configuration steps on the MSOFTX3000 are as follows: Step 1 Configure the Language Kind Change table. Description Script Remark Set Language name to CHINESE, Language kind to 2, and Language change value to 128. ADD LKINDCHG: LN="CHINESE", LK=2, LVALUE=128; Before executing the script, run LST LKINDCHG to query whether the required language is configured. If so, you do not need to configure the language.
Step 2 Set the start bit of a language type.
Issue 02 (2007-06-10)
23-9
Description Script Remark
Set Service key to 240 and use default values for other parameters. ADD LKINDPOS: SRVKEY=240; Before executing the script, run LST LKINDPOS to query whether the required data is configured. If yes, the data need not be added.
Step 3 Configure the Language Category table. Description Script Remark Set Service Key to 240, Language Index to 2 and Language 1 to CHINESE. ADD LANKIND: SRVKEY=240, LKIDX=2, LN1="CHINESE"; None.
Step 4 Configure the IMSI Language Configuration table. Description Script Remark Set IMSI prefix to 4600 and the Specific language kind to 2 and keep the original language. ADD IMSILANG: IMSI=K'4600, RSVLANG=YES, LANGKIND=2; Before using Specific language kind in the command, set it in the Language Category table.
----End
23.5.5 Querying Tables of the IMSI-Based Announcement Service

Related Tables in the IMSI-Based Announcement Service
Table 23-6 lists related tables in the IMSI-based announcement service. Table 23-6 Related tables in the IMSI-based announcement service Table Name Language Kind Index Position Table Language Kind Change Table Function It contains multiple records, which specify from which bit and how many bits in the MSOFTX3000 EID are considered as the language type index. It contains the mappings between the internal languages of the MSOFTX3000 and the values of Language type change of the internal tone IDs. Related Command ADD LKINDPOS
ADD LKINDCHG
23-10
Issue 02 (2007-06-10)
Language Category Table IMSI Language Configuration Table
It contains the mappings between Language type index in EIDs and the internal language types in the MSOFTX3000. It contains the mappings between IMSIs and language types.
ADD LANKIND
ADD IMSILANG
Flow of Querying Tables of the IMSI-Based Announcement Service

The IMSI-based announcement service involves the following tables: IMSI Language Configuration table Language Kind Change table Language Kind Index Position table Language Category table Tone ID Configuration table Figure 23-3 shows how these tables are queried.
Issue 02 (2007-06-10)
23-11
Figure 23-3 Table query flow in the IMSI-based announcement service
Start
IMSI
The MSC server checks whehter Specific language kind in the MSI Language Configuration table is configured to be corresponding to the IMSI prefix. Yes
No
The MGW plays announcement in the default language.
Default tone ID
The MSC server checks whether Service key and Language category start bit in the Language Category Index Position table are configured to be corresponding to the default tone ID. Yes The MSC server queries the Tone ID Configuration table based on the default tone ID to obtain language kind list 1.
No
The MSC server queries the Language Category Index Position table based on the default tone ID, and obtains the bits which specify the language category index.
The MSC server replaces the value of Specific language kind with the bits which specify the language category index, and obtains a new EID.
The MSC server checks whether Service key and Language kind index are configured in the Language Category table. If Reserve old language indication in the IMSI Language Configuration table is set to Yes, the MSC server queries the Tone ID Configuration table. For details, see FAQ. Yes The MSC server queries the Language Category table based on the service key and tone bit of the new EID, and obtains language kind list 2.
No
Based on Reserve old language indication in the IMSI Language Configuration table and the information in list 1 and list 2, the MSC server obtains the announcement language list for the MGW. The MSC server queries the Language Kind Change table to check whether the language in the Language Category table is converted into the language that the MGW can recognize. Yes The MGW plays announcement in the language configured in the IMSI Language table.
No
The MGW does not play announcement.
23-12
Issue 02 (2007-06-10)

None.

None.

The IMSI-based announcement service has no impacts on traffic measurement.
23.9 Interactions with Other Services

None.
23.10 Reference
None.

Acronym/Abbreviation IMSI MCC MNC Full Name International Mobile Subscriber Identity Mobile Country Code Mobile Network Code
23.11 FAQ
23.11.1 Question 1
Description
The IMSI Language Configuration table is successfully configured, but the system does not play announcement as configured.
Issue 02 (2007-06-10)
23-13
Answer
A: After you configure the mapping between IMSI prefix and Specific language kind through ADD IMSILANG, you still need to run ADD LANKIND to configure the corresponding language name.
23.11.2 Question 2
Description
The Language Kind table is configured with eight languages, but the number of actual announcement languages is less than eight.
Answer
A: The final number of announcement language types is determined by the language types configured in the language ID configuration table, which supports up to five announcement languages.
23.11.3 Question 3
Description
What the use of the Reserve old language indication indicator (in the IMSI Language Configuration table) in the IMSI-based announcement service is.
Answer
A: The multi-language table can be configured with eight languages, while the Tone ID configuration table supports up to five language types. When controlling the announcement on MGW, the MSC server reacts according to the setting of the Reserve old language indication indicator. Reserve old language indication is set to Yes

If the multi-language table is configured with five or more language types, the first five languages will be assigned to the MGW. If the multi-language table is configured with less than five language types (for example languages A, B and C), the language types configured in the Tone ID configuration table (for example, languages C, D, E, F, and G) will be added to the former, and then the first five language types (A, B, C, D and E) will be assigned to the MGW. If the number of language types is still less than five, the MSC server directly assigns these available language types to the MGW. If the multi-language table is configured with five or more language types, the first five language types are assigned to the MGW. If the multi-language table is configured with less than five language types (for example languages A, B and C), the MSC server directly assigns these language types (three in this example) to the MGW.
Reserve old language indication is set to No

23-14
Issue 02 (2007-06-10)
Contents
Contents
24 IP over E1 .................................................................................................................................24-1
24.1 Service Description ...................................................................................................................................24-2 24.1.1 Function Code..................................................................................................................................24-2 24.1.2 Definition .........................................................................................................................................24-2 24.1.3 System Specifications ......................................................................................................................24-2 24.1.4 Benefits ............................................................................................................................................24-2 24.1.5 Application Scenario ........................................................................................................................24-3 24.1.6 Application Limitations....................................................................................................................24-3 24.2 Availability ................................................................................................................................................24-4 24.2.1 Requirements for NEs......................................................................................................................24-4 24.2.2 Requirements for License ................................................................................................................24-4 24.2.3 Applicable Versions..........................................................................................................................24-4 24.2.4 Others...............................................................................................................................................24-4 24.3 Working Principle......................................................................................................................................24-4 24.3.1 Functions Provided by NEs..............................................................................................................24-4 24.3.2 Internal Processing Flow of the System...........................................................................................24-5 24.3.3 External Interfaces ...........................................................................................................................24-7 24.4 Service Flow..............................................................................................................................................24-8 24.4.1 Inter-Office Call Flow Based on IP over E1 ....................................................................................24-8 24.4.2 Cross-MGW Call Flow Based on IP over E1.................................................................................24-10 24.5 Data Configuration.................................................................................................................................. 24-11 24.5.1 Overview of Data Configuration.................................................................................................... 24-11 24.5.2 Data Configuration at the MSOFTX3000 Side.............................................................................. 24-11 24.5.3 Data Configuration at the UMG8900 Side.....................................................................................24-13 24.5.4 Data Configuration Example..........................................................................................................24-17 24.6 Service Management ...............................................................................................................................24-19 24.7 Charging and CDR ..................................................................................................................................24-19 24.8 Performance Measurement......................................................................................................................24-20 24.9 Service Interaction ..................................................................................................................................24-20 24.10 Reference...............................................................................................................................................24-20 24.10.1 Specifications...............................................................................................................................24-20 24.10.2 Glossary, Acronyms, and Abbreviations ......................................................................................24-20
Issue 02 (2007-06-10)
Figures
Figures
Figure 24-1 Internal processing of IP over E1 processing in the MSOFTX3000.............................................24-5 Figure 24-2 IP over E1 bearer adopted inter-office MGWs .............................................................................24-6 Figure 24-3 IP over E1 bearer adopted by intra-office MGWs ........................................................................24-7 Figure 24-4 Inter-office call flow of forward fast.............................................................................................24-8 Figure 24-5 Inter-office call flow of forward delay..........................................................................................24-9 Figure 24-6 Inter-office call flow of backward delay.....................................................................................24-10 Figure 24-7 Setup of intra-office medium cluster ..........................................................................................24-10 Figure 24-8 Typical networking of IP over E1 ...............................................................................................24-17
ii
Issue 02 (2007-06-10)
Tables
Tables
Table 24-1 Function code about this service.....................................................................................................24-2 Table 24-2 Benefits of this service to carriers and mobile subscribers.............................................................24-2 Table 24-3 NEs related with IP over E1 ...........................................................................................................24-4 Table 24-4 Product versions that support IP over E1........................................................................................24-4
Issue 02 (2007-06-10)
iii
24 IP over E1
24
About This Chapter
IP over E1
The function code and definition of the service and the benefits of the service to carriers and mobile subscribers. The NEs required to implement the service, requirements for the license, and versions of the products applicable to the service. The functions of the NEs used to implement the service and the requirements on the networking. The flow of the service. The data configuration that must be performed at the MSOFTX3000 side and the UMG8900 side as well as the examples of data configuration. The operations that carrier and mobile subscribers must perform when the service is provided. The procedure for performing charging and generating CDRs when the service is provided. The influence of the service on performance measurement and the implementation of performance measurement. The association between the service and other services as well as the restrictions on each other. The standards and specifications with which the service complies and the glossary, abbreviations, and acronyms used in this chapter.
Issue 02 (2007-06-10)
24-1
24 IP over E1

Table 24-1 lists the function code about this service. Table 24-1 Function code about this service Name IP over E1 Code WMFD-141800
24.1.2 Definition
Some carriers cannot set up and maintain large IP bearer networks. They require using the original Time Division Multiplex (TDM) network after adopting the softswitch. Thus, the IP over E1 plan is designed to meet the requirement of the carriers. IP over E1 is a technology that the user plane bears IP packet data through E1 cables on the existing TDM network. At the same time, the Compressed Real-Time Protocol (CRTP) is used to improve the utilization of voice bandwidth. IP over E1 can save operation cost. The existing TDM network can provide the voice over IP (VOIP) service. In this case, IP over E1 can ensure the high reliability of the TDM network.

The MSOFTX3000 supports IP over E1 between MGWs. The MSOFTX3000 uses the FE interface to connect to a near switch or router without providing any IP over E1 interface. If the Mc and SIGTRAN interface adopt IP over E1, a device must be configured to support the conversion between E1 and FE interfaces. When IP over E1 is adopted for intra-office bearer, only the Bear Independent Call Control (BICC) protocol is supported.
24.1.4 Benefits
Table 24-2 lists the benefits of this service to carriers and mobile subscribers. Table 24-2 Benefits of this service to carriers and mobile subscribers Beneficiary Carriers Description Carriers can save operation cost. The existing TDM network can provide the voice over IP (VOIP) service. In this case, IP over E1 can ensure the high reliability of the TDM network. The CRTP is used to improve the utilization of voice bandwidth. Mobile subscribers None.
24-2
Issue 02 (2007-06-10)
24 IP over E1

IP over E1 is applicable to all GSM and UMTS R99/R4 markets. The MSOFTX3000 supports IP over E1 between MGWs. The MSOFTX3000 uses the FE interface to connect to a near switch or router without providing any IP over E1 interface. If the Mc interface adopts IP over E1, a device must be configured to support the conversion between E1 and FE interfaces. At the Nc interface, IP over E1 supports only the BICC protocol and the forward fast, forward delay and backward delay bearer modes of BICC. MGWs support the Nb interface acting as the IP over E1 interface. The Nb interface supports the following networking modes:

Intra-office single MGW: It connects to the MGW of another office by adopting IP over E1 bearer. Intra-office multiple MGWs: All directly connected MGWs interwork by adopting IP over E1. Intra-office multiple MGWs: Some directly connected MGWs interwork by adopting IP over E1. Others adopt IP bearer. For inter-office calls: The flow control of inter-office MGW bearer can be realized through the BICC CIC and IP QoS bearer quality detection functions configured between offices. For calls cross MGWs (including intra-office calls and inter-office calls): The flow control of MGW bearer can be realized through the VTID and IP QoS bearer quality detection functions configured between MGWs in the office.
The QoS of voice borne by IP over E1 can be ensured through the following methods:
VTID is short for virtual terminal identifier.
The number of BICC CIC and VTID is obtained through the bandwidth of common voice coding (such as AMR and G.729) and the total bandwidth borne between MGWs. AMR is short for Adaptive MultiRate.

Inter-office MGWs adopt IP over E1. The number of inter-office MGW connections is 12, which depends on the maximum number of subroutes. The directly-connected forward office cannot act as the Call Mediation Node (CMN) on the incoming local office. IP over E1 is designed for small or medium carriers. Thus, the CMN is rarely used. Each pair of MGWs in an office support only one bearer mode between them: IP over E1 or IP IP over E1 uses the BICC codec negotiation mechanism. Thus, the MSOFTX3000 must enable the Transcoder Free Operation (TrFO) function. When an E1 cable is faulty, MGWs can automatically adjust the valid bearer bandwidth between two MGWs without reporting the event of faulty E1 to the MSOFTX3000. Thus, MGWs do not adjust the number of VTIDs based on the status of E1. In this case, the transmission is ensured by the maximum bandwidth capacity of MGWs on transmission port.
Issue 02 (2007-06-10)
24-3
24 IP over E1
24.2 Availability
IP over E1 can be provided under the joint work of MSC server and MGW as listed in Table 24-3. Table 24-3 NEs related with IP over E1 UE Node B RNC MSC Server MGW SGSN GGSN HLR -
NE is short for network element. The symbol "" indicates that the NE is required. The symbol "-" indicates that the NE is not required.

IP over E1 is a basic feature of Huawei mobile core network. IP over E1 does not need a license.

Table 24-4 lists the versions of the Huawei mobile core network that support IP over E1. Table 24-4 Product versions that support IP over E1 Product MSC server MGW MSOFTX3000 UMG8900 Applicable Version V100R005C10 V200R006
24.2.4 Others
IP over E1 requires the IP over E1 interface board (MIOE and MTNB) provided by MGWs.

24.3.1 Functions Provided by NEs
The MSC server and MGW work jointly to provide IP over E1. The MSC server determines that the bearer connection of calls to a certain office is IP over E1 on the user plane. Use inter-office calls as an example. An IP domain is configured
24-4
Issue 02 (2007-06-10)
24 IP over E1
corresponding to the BICC office direction. Also, the direction connection relationship between MGWs is configured, indicating that the bearer connection between MGWs is IP over E1 in the office direction. For calls cross MGWs, the MSC server realizes the configuration of direct connection relationship between intra-office MGWs and flow control of bearer between MGWs. The MGW determines that the user plane bearer of a certain call is IP over E1 based on the instruction of the MSC server. The MGW supports IP over E1 to adapt the IP data packet to the TDM. Then the IP data packet is transferred through the MIOE (TDM interface board).
24.3.2 Internal Processing Flow of the System

Overall Processing
Figure 24-1 Internal processing of IP over E1 processing in the MSOFTX3000
(3)
MSC server 1 MSC server 2
(1)
(2)
(4)
MGW 1
IP Over E1
MGW 2
The internal processing flow of the system is as follows: 1. After receiving a call request from the access side, MSC server 1 determines that the bearer mode between outgoing office directions is IP over E1. When requiring MGW 1 to set up voice channel bearer, MSC server 1 instructs the domain where MGW 2 office direction is. MGW 1 selects a bearer address in the domain of MSC server 1 and reports it to MSC server 1. MSC server 1 sends the local office bearer address to the called office. MSC server 2 sends the domain where the incoming office direction is and peer IP address to MGW 2. MGW 2 sets up voice channel bearer.
Run ADD OFC on the MSOFTX3000 to set the domain where an office direction is. MGWs configure IP over E1 bearer resources in the corresponding domains.
2. 3. 4. 5.
Processing of Inter-Office Calls

For inter-office calls, configure the IP domain corresponding to the BICC office direction and direct relationship between intra-office MGWs.
Issue 02 (2007-06-10)
24-5
24 IP over E1
Define local IP domain parameters based on the BICC office direction on the MSC server, as shown in Figure 24-2. Define a BICC office direction for each connection between local MGW and peer MGW. One BICC office corresponds to one IP domain. Configure IP bearer type on the BICC office direction to instruct whether the direct connection is borne between the local office and peer office. Figure 24-2 IP over E1 bearer adopted inter-office MGWs
MGW 1
Office direction 1/domain 1
Office direction 1/domain 1
MGW 2
Off n ic e tio IP Over E1 ec 2/d direc dir in 2 om e a ain tion fic Of /dom 2 2 Off n ice ctio 3/d direc dire n 3 om t ce ai i IP Over E1 ain ion Off /dom 3 3 Office direction Office direction 4/domain 4 4/domain 4
MGW 3
MGW 4
Each inter-office MGW corresponds to a BICC office direction. Thus, the routing policy is that the BICC office direction and subroute are in one to one relationship. All subroutes of the same physical office direction belong to a route. The subroute selection mode of the route is Random or Percent based on actual condition. Through such routing policy, the number of inter-office MGW connections is 12, which depends on the maximum number of subroutes. The number is sufficient for small or medium carriers. Use the call initiated from MSC server 1 to MSC server 2 as an example to explain how the MSC server sets up inter-office bearer: Assume that MSC server 1 selects MGW 1 and office direction. Then MSC server 1 routes calls to MSC server 2. Based on office direction 2, local IP domain (domain 2) and IP bearer type (direct bearer) can be obtained. The two parameters are sent to MGW 1 to set up outgoing bearer. For incoming calls, MSC server 2 obtains MGW 4 in direct connection mode for incoming bearer setup, corresponding IP domain (domain 3) and IP bearer type (direction bearer) based on the incoming office direction (office direction 3). The two parameters are sent to MGW 4 to set up outgoing bearer. When setting up incoming bearer, MSC server 2 must provide the bearer plane address of MGW 1 to MGW 4. (The bearer plane address includes the IP address and port number that are sent by MSC server 1 to MSC server 2 through the IAM message.) IAM is short for initial address message. Multiple BICC office directions are defined between MSC servers. Currently, the multi-signaling plan is not used. Thus, the BICC signaling is borne over the SCTP link only.
Processing of Intra-Office Calls

For intra-office calls, configure the direct connection relationship (domain connection relationship) between intra-office MGWs.
24-6
Issue 02 (2007-06-10)
24 IP over E1
Figure 24-3 IP over E1 bearer adopted by intra-office MGWs

MSC server
MGW 1
Domain 1
Domain 1
MGW 3
IP Over E1
Domain 2 Domain 3
Domain 3
IP Over E1
Domain 2
MGW 2
Domain 4 Domain 4
MGW 4
When configuring the direct connection between intra-office MGWs, configure IP domains corresponding to the direction connection relationship at the same time. As shown in Figure 24-3, the connection relationship between MGW 1 and MGW 3 is domain 1; the connection relationship between MGW 1 and MGW 4 is domain 2; the connection relationship between MGW 2 and MGW 3 is domain 3; the connection relationship between MGW 2 and MGW 4 is domain 4. When the MSC server sets up the bearer between intra-office MGWs (medium bearer), if the IP domain parameter corresponding to a certain segment of medium bearer is not 0, the MSC server instructs IP domain to the related MGW.

Currently, the MSOFTX3000 sets up the outgoing end point for BICC outgoing calls when the outgoing IAM message is sent. Thus, the IAM message must carry the IP over E1 address (IP address and port number) of the local bearer plane. Otherwise, the peer MGW cannot set up the corresponding incoming end point. When the MSOFTX3000 sets up the outgoing end point, it unconditionally requires the MGW to return the local SDP information (bearer plane address). When the IAM message is sent outgoing office, it sends the address of local bearer plane through the customized codec. When setting up the incoming end point, the MSC server instructs the remote SDP information (bearer plane address) to the MGW.
Issue 02 (2007-06-10)
24-7
24 IP over E1
24.4 Service Flow

24.4.1 Inter-Office Call Flow Based on IP over E1
Inter-office MGWs adopt the IP over E1 bearer, backward delay bearer setup modes. supporting forward fast, forward delay and
Forward Fast
Figure 24-4 shows the inter-office call flow of forward fast. Figure 24-4 Inter-office call flow of forward fast
MSC server 1 Add.Req/Rsp (IPD,IPBT=1) Notify.Ind/Ack (IPBCP.Req) MGW 1 MGW 2 MSC server 2
IAM (IPBCP.Req)
Add.Req/Rsp (IPD,IPBT=1,IPBCP.req)
Mod.Req/Rsp (IPBCP.Acc)
APM (IPBCP.Acc)
Notify.Ind/Ack (IPBCP.Acc)
1.
MSC server 1 determines that the bear type between outgoing BICC office direction and peer office is direct connection at outgoing office side. MSC server 1 instructs that IPBT=1 when it prepares bearer. In addition, MSC server 1 sends the IPD (IP domain parameter) configured based on office direction number. Considering the repeat uses of forward delay and backward delay mentioned in the following section, the number of interfaces between MSC server 1 and MGW 1 must be increased. MGW 1 returns the SDP information corresponding to the IPBCP in the Add.Rsp during the forward fast flow. MSC server 1 sends the outgoing IAM message, carrying the private codec corresponding to the SDP information. The codec identifies that the call is an IP over E1 call. MSC server 2 determines that the bear type between incoming BICC office direction and peer office is direct connection at incoming office side. MSC server 2 selects the local MGW directly connected to the peer office based on the incoming office direction number. MSC server 2 instructs that IPBT=1 when it prepares bearer. In addition, MSC server 2 sends the IPD configured based on office direction number, IPBCP Req carrying the peer office bearer information, and SDP information. MGW 2 resolves the IPBCP Req and SDP, and distributes corresponding bearer plane resources.
2.
3.
24-8
Issue 02 (2007-06-10)
24 IP over E1
Forward Delay
Figure 24-5 shows the inter-office call flow of forward delay. Figure 24-5 Inter-office call flow of forward delay
MSC server 1 Add.Req (IPD,IPBT=1) Add.Rsp (LocalSDP) MGW 1 MGW 2 MSC server 2
IAM (SuppCodeclist)
Add.Req
(IPD,IPBT=1,RemoteSDP)
Mod.Req/Rsp Notify.Ind/Ack (IPBCP.Req)
APM (SelCodec,AvaCodeclist)
Add.Rsp (LocalSDP)
APM (IPBCP.Req)
APM (IPBCP.Acc)
Mod.Req/Rsp (IPBCP.Req) Notify.Ind/Ack (IPBCP.Acc)
1.
When MSC server 1 sends the Add.Req message, MGW 1 distributes the bearer plane resource (IP address and port number). Thus, MSC server 1 must send the local bearer information carried in the IAM message to the backward office. MGW 1 requires to return the SDP information (distributed IP address and port number) in the Add.Rsp. MSC server 1 sends the SDP information to the peer office in private codec mode. MSC server 2 determines that the private codec exists in the codec resolution table at the incoming side. MSC server 2 resolves the SDP information and instructs it in the Add.Req to MGW 2. MGW 2 distributes the bearer plane resource based on the SDP information. MSC server 2 does not carry the private codec in the available codec list of the backward APM message.
2.
3.
Backward Delay
Figure 24-6 shows the inter-office call flow of backward delay.
Issue 02 (2007-06-10)
24-9
24 IP over E1
Figure 24-6 Inter-office call flow of backward delay

MSC server 1
Add.Req (IPD,IPBT=1) Add.Rsp (LocalSDP)
MGW 1
MGW 2
MSC server 2
IAM (BCUID=MGW1,SuppCodeclist)
Add.Req (IPD,IPBT=1,RemoteSDP) Add.Rsp Notify.Ind/Ack (IPBCP.Req)
APM (SelCodec,AvaCodeclist,IPBCP.Req) Mod.Req/Rsp (IPBCP.Req) Notify.Ind/Ack (IPBCP.Acc)
APM (IPBCP.Acc)
Mod.Req/Rsp (IPBCP.Acc)
1.
When MSC server 1 sends the Add.Req, MGW 1 distributes the bearer plane resource (IP address and port number). Thus, MSC server 1 must send the local bearer information carried in the IAM message to the backward office. MGW 1 requires to return the SDP information (distributed IP address and port number) in the Add.Rsp. MSC server 1 sends the SDP information to the peer office in private codec mode. MSC server 2 determines that the private codec exists in the codec resolution table at the incoming side. MSC server 2 resolves the SDP information and instructs it in the Add.Req to MGW 2. MGW 2 distributes the bearer plane resource based on the SDP information. MSC server 2 does not carry the private codec in the available codec list of the backward APM message.
2.
3.
24.4.2 Cross-MGW Call Flow Based on IP over E1

After adopting IP over E1, intra-office MGWs support the setup and flow control of intra-office medium cluster.
Setup of Intra-Office Medium Cluster

Figure 24-7 Setup of intra-office medium cluster
IP over E1 T1 T2 T3 T4
MGW1
MGW2
24-10
Issue 02 (2007-06-10)
24 IP over E1
When MSC server 1 sets up a medium cluster, if the bearer type of the medium cluster is IP over E1, MSC server 1 must instruct the SDP information of T3 end point when setting up T2 end point, as shown in Figure 24-7.
Flow Control of Intra-Office Medium Cluster

The flow control of intra-office medium cluster based on IP over E1 adopts the mechanism of existing medium circuit borne by TDM. The VTID is configured between MGW pairs. The maintenance of VTID is the same with that of TID. The VTID does not require being sent to the MGW and performed TID audit with the MGW. The VTID is different from the TID of TDM/IP/ATM port. The number of VTIDs is obtained based on the total bandwidth of medium bearer and common voice coded (such as AMR). Whether a call is a voice or data service, a VTID is distributed on each MGW near by the call. That is, the G.711 codec adopted by data service occupies more bandwidth than the AMR codec adopted by voice service. This is because the ratio of data service is low. When calculating the number of VTIDs, you can reserve some medium bear based on the ratio of data service. The transmission port between MGWs is configured with maximum bandwidth capacity. This can remedy that the MSOFTX3000 cannot exactly control medium bearer flow.

24.5.1 Overview of Data Configuration
For inter-office calls, specify the domain where an office direction is and the connection mode between MGWs on the MSOFTX3000, indicating that the intra-office call bearer adopted by a call is IP over E1. Configure the IP over E1 bearer resource of the MGW on the UMG8900. The domain to which the bearer resource belongs corresponds to the domain configured on the MSOFTX3000. For intra-office calls cross MGWs, configure the inter-office IP domain on the MSOFTX3000, indicating that the intra-office call bearer cross MGWs is IP over E1. Configure the IP over E1 bearer resource of the MGW on the UMG8900. The domain to which the bearer resource belongs corresponds to the domain configured on the MSOFTX3000.

The data configuration of IP over E1 on the MSOFTX3000 is listed as follows: Step 1 Configure IP domain and IP bearer type of the BICC office direction. Command: ADD OFC Function: It is used to configure the BICC office direction, IP domain and IP bearer type of the IP over E1 of the office direction. Parameter description:
Issue 02 (2007-06-10)
24-11
24 IP over E1
Parameter ID IPD
Parameter Name IP domain
Parameter Description This parameter is valid if only Signaling type is not set to Non-BICC. It determines the IP domain corresponding to the connection between inter-office MGWs. Value range: 0999 Default value: 0 The IP bearer type parameter is valid only when IP domain is not set to 0.
IPBT
IP bearer type
This parameter is valid if only Signaling type is not set to Non-BICC. It specifies the type of IP bearer. Value range: Direct bearer and Indirect bearer Default value: Direct bearer
Note: Indirect bearer indicates that the bearer type is not related to physical link.
Example: To configure the BICC_SCTP to IP over E1 office direction, set IP domain to 10 and IP bearer type to Direct bearer:
ADD OFC: ON="BICC_SCTP", OOFFICT=MSC, DOL=SAME, SIG=SCTP,CSCNAME="LOCAL_0", IPD=10, IPBT=DIRECT, AN="0", CONFIRM=Y;
When IP domain is set to 0, it indicates all interconnection by using router. Other values specify concrete IP domains. For MGWs, when IP domain is set to 0, it indicates that all router networking and bearer can be set up on any port. When MGWs do not use all router interconnection (including E1 all interconnection and non interconnection), IP domain must be set to values except 0 to set up bearer on the port corresponding to the MGW specified by IP domain. Thus, for the IP over E1 bearer mode, set Internal MGW connection type to Not all MGW connection and Internal MGW media type to IP by using ADD SRVNODE.
Step 2 Set Internal MGW connection type to Not all MGW connection. Command: MOD SRVNODE Function: It is used to add a dual-homing server node. Parameter description: It already existed. No new parameter description is required. Example: To set Internal MGW connection type to Not all MGW connection, run the following command:
MOD SRVNODE: SN="LOCAL", IMMT=IP, IMCT=NOT-ALLMGW;
Step 3 Configure intra-office IP over E1.
24-12
Issue 02 (2007-06-10)
24 IP over E1
Command: ADD MGWCONN Function: It is used to add the connection between MGWs. Parameter description: It already exists. No new parameter description is required. Example: To configure intra-office MGW connection, set IP domain:
ADD MGWCONN: MGWNM1="MGW0", MGWNM2="MGW1", DN="IP OVER E1", IPDM=10;
Set IP domain when configuring intra-office MGW connection. The value range of IP domain is from 0 to 999. The default value is 0, indicating that all interconnection by using router. Other values specify concrete IP domains. The VTID must be configured for the flow control of medium bearer based on IP over E1.
----End

The bearer resource of IP over E1 on the UMG8900 is listed as follows: Step 1 Add the MIOE. Command: ADD BRD Function: It is used to add a board. Parameter description: It already existed. No new parameter description is required. Example: To add the MIOE, run the following command:
ADD BRD: FN=1, SN=12, BP=FRONT, BT=HRB, HBT=MIOE, BS=ONEBACKUP, BN=2, ADS=ACTIVE;
Step 2 Bind the internal TDM port of the MIOE with the physical TDM port. Command: ADD BIND Function: It is used to bind the internal E1 port of the MIOE with the physical E1 port. Parameter description: Parameter ID TDMBT Parameter Name TDM board type Parameter Description: It is the type of board to which the physical TDM port belongs. Currently, only E1 port is supported. It is enumeration type. Currently, only E32 is supported.
Issue 02 (2007-06-10)
24-13
24 IP over E1
Parameter ID TDMBN
Parameter Name TDM board No. TDM port No.
Parameter Description: It is the board No. where the physical TDM port is. It is numeric type. Value range: 0223 It is the physical TDM port number on a specified interface board. It is numeric type. Value range: 031 After the command is run, the one to one relationship between a certain internal TDM port of the MIOE and a certain physical TDM port of the TDM interface board is set up. It specifies the board No. where the internal TDM port is. It is numeric type. Value range: 013 It is a mandatory sub-parameter. If TDM board type is set to E32, T32, S1L, S2L or PIE, the parameter is displayed. It is enumeration type and its value range is from 0 to 63. It is the port number of the internal TDM in the binding relation.
TDMPORT
IOEBN
IOE board No.
IOEPORT
IOE internal TDM port No.
DESP
Port description
It is an optional sub-parameter. If TDM board type is set to E32, T32, S1L, S2L or PIE, the parameter is displayed. It is character string type. Up to 31 characters can be entered. It describes a pair of TDM ports that have been bound.
Example: To bind the E1 port (physical TDM port) numbered 6 of the E32 numbered 0 with the internal TDM port numbered 0 of the MIOE numbered 2:
ADD BIND: TDMBT=E32, TDMBN=0, TDMPORT=6, IOEBN=2, IOEPORT=0, DESP="Binding TDM Port";
This command is run for the HRB only of which the physical board type is MIOE. The MIOE and bound TDM interface boards must be in the same frame. Each internal TDM port of the MIOE must be bound with one physical TDM port. The timeslot of the specified physical TDM port must be internal timeslot and unused. After the one to one binding relationship is set up by this command, the corresponding physical TDM port cannot be used for other functions. In addition, the physical TDM port cannot be bound with other internal TDM ports of the MIOE.
Step 3 Group the timeslots of internal TDM port of the MIOE configured with binding relationship. Command: ADD CHANNEL Function:
24-14
Issue 02 (2007-06-10)
24 IP over E1
It is used to group the timeslots of internal TDM port of the MIOE to set up an interface supporting IP over E1. The interface type is Serial that can be configured with an IP address. Parameter description: Parameter ID BN Parameter Name IOE board No. Parameter Description: This command is used to group the timeslots of internal TDM port to set up a Serial interface. The parameter specifies the board No. where the internal TDM port is. It is numeric type. Value range: 013 PORT IOE internal TDM port No. Start timeslot It is the internal TDM port No. on a specified MIOE. It is numeric type. Value range: 063 STARTTS The timeslots of the Serial interface set up through the command must be sequent. This parameter specifies the start timeslot. It is numeric type. Value range: 131 ENDTS End timeslot This parameter specifies the end timeslot. It is numeric type. Value range: 131 IFN Interface No. After the command is run, the front four specified timeslots set up a Serial interface. This parameter is the interface No. distributed to the Serial interface. The No. of Serial interfaces on the same MIOE is unique. It is numeric type. Value range: 0255
Example: To group the timeslots numbered 131 of the internal TDM port numbered 0 of the MIOE numbered 2, and set up the Serial interface numbered 0: ADD CHANNEL: BN=2, PORT=0, STARTTS=1, ENDTS=31, IFN=0;
This command is run for the HRB only, of which the physical board type is MIOE. The specified internal TDM port must be bound with a certain physical TDM port of the TDM interface board by the command ADD BIND. The grouped timeslots must be sequent and belong to the same TDM port. The timeslot 0 of the E1 port is used to transmit synchronization information. Thus, it cannot be added to the Serial interface. When multiple timeslot groups are set up on the same TDM port, the timeslots contained in each group cannot be overlap. That is, the same timeslot cannot belong to multiple Serial interfaces.
Step 4 Add the IP address on the Serial interface. Command: ADD IPADDR
Issue 02 (2007-06-10)
24-15
24 IP over E1
Function: It is used to configure the IP address of a specified interface of a specified board. This command supports two new interface types: Serial and VT. Parameter description: Parameter ID IFT IFN Parameter Name Interface type Interface No. Parameter Description: Two new interface types are added: Serial and VT. It is numeric type. Each MIOE can support up to 256 Serial interfaces. Thus, the value range expands from 015 to 0255.
Example: On the Serial interface numbered 0 of the MIOE numbered 2, set IP address to 18.10.0.25 and Subnet mask to 255.255.0.0:
ADD IPADDR: BT=HRB, BN=0, IFT=SRL, IFN=0, IPADDR="192.168.0.1", MASK="255.255.255.0", IFMPLS=NO;
Step 5 Set the property of IP interface. Command: MOD IPIF Function: It is used to modify the configuration of IP interface. This supports two new interface types: Serial and VT. Parameter description: Parameter ID IFT IFN Parameter Name Interface type Interface No. Parameter Description: Two new interface types are added: Serial and VT. It is numeric type. Each MIOE can support up to 256 Serial interfaces. Thus, the value range expands from 015 to 0255. It is an optional sub-parameter only when Interface type is set to Serial. It is used to configure whether the corresponding Serial interface can support MP. If yes, the VT interface to which the Serial interface belongs must be specified through VT Interface No.. It is numeric type. The values are Yes and No. VT VT Interface No. It is a mandatory sub-parameter when Interface type is set to Serial and MP enable is set to Yes. It specifies the VT interface to which the Serial interface belongs. It is numeric type. Value range: 0127
IFMP
MP enable
24-16
Issue 02 (2007-06-10)
24 IP over E1
Parameter ID IFCRTP
Parameter Name CRTP enable
Parameter Description: It is an optional sub-parameter only when Interface type is set to Serial. It is used to configure whether the corresponding Serial interface supports the Compressed Real-Time Protocol (CRTP). It is enumeration type. The values are Yes and No. It is an optional sub-parameter only when Interface type is set to Serial or VT. It identifies whether the corresponding external route is generated after the interface obtains the peer address through PPP negotiation. It is enumeration type. The values are Yes and No.
RPTROUTE
Auto report route
Example: To classify the Serial interface numbered 0 of the MIOE numbered 2 to domain 10:
MOD IPIF: IFT=SRL, BT=HRB, BN=2, IFN=0, MTU=1500, ENABLE=YES, DESP="Serial Interface", AUTH=NONE, TIMEOUT=3, KEEPALIVE=10, DOMAIN=10, BEARBW=1024, IFMP=NO, VT=0, IFCRTP=NO, RPTROUTE=NO, CRCENB=YES, CRCLENGTH=CRC16, SCRAMENB=NO, TIMEFILL=Ox7E, SPACEREG=0, CRCCHKENB=YES, CRCCHKLEN=CRC16, UNSCRAMENB=NO;
----End

Figure 24-8 shows the typical networking of IP over E1. Figure 24-8 Typical networking of IP over E1
MGW 1
IP Over E1
MGW 2
The BICC office direction is configured from MSC server 1 to peer MSC server 2. The interface to peer MGW 2 is the Serial interface with 31 timeslots. The local IP address is 18.10.0.25.
Issue 02 (2007-06-10)
24-17
24 IP over E1
MGW 1 is configured with an MIOE with the board No. 2 and an E32 with the board No. 0. The number of the E1 interface is 6, connecting to MGW 2.
Configuration Script for the MSOFTX3000

Step 1 Configure IP domain and IP connection type of IP over E1 of an office direction. Description Add an office direction: Set the office direction from MSC server 1 to peer MSC server 2 to BICC, Office direction name to BICC_SCTP, Signaling type to BICC over SCTP, IP domain to 10 and IP bearer type to Direct bearer. ADD OFC: ON="BICC_SCTP", OOFFICT=MSC, DOL=SAME, SIG=SCTP, CSCNAME="LOCAL_0", IPD=10, IPBT=DIRECT, AN="0", CONFIRM=Y; For the configurations of TG and BICC CIC, refer to the configuration of common BICC office direction.
Script
Remark
Step 2 Set Internal MGW connection type to Not all MGW connection. Description Script Set Internal MGW connection type to Not all MGW connection. MOD SRVNODE: SN="LOCAL", IMMT=IP, IMCT=NOT-ALLMGW;
Step 3 Configure IP over E1 between MGWs (optional). Description Script Remark Configure media connection between MGWs. ADD MGWCONN: MGWNM1="MGW0", DN="IP OVER E1", IPDM=10; MGWNM2="MGW1",
This command is run only when IP over E1 cross intra-office MGWs is configured.
----End
Configuration Script for the UMG8900

Step 1 Add the MIOE. Description Script Add the MIOE. ADD BRD: FN=1, SN=12, BP=FRONT, BT=HRB, HBT=MIOE, BS=ONEBACKUP, BN=2, ADS=ACTIVE;
24-18
Issue 02 (2007-06-10)
24 IP over E1
Step 2 Bind the internal TDM port of the MIOE with the physical TDM port. Description Script Bind the internal E1 port of the MIOE with the physical E1 port. ADD BIND: TDMBT=E32, TDMBN=0, TDMPORT=6, IOEBN=2, IOEPORT=0, DESP="Binding TDM Port";
Step 3 Divide the timeslots of the IOE internal TDM ports that is configured with binding relation into groups. Description Script Bind timeslots 1 to 31 with IP interface 5 of the IOE with board No. 2, internal port number 2 and interface type serial. ADD CHANNEL: BN=2, PORT=0, STARTTS=1, ENDTS=31, IFN=5;
Step 4 Add the IP address of the Serial interface or VT interface. Description Script Add the IP address of the Serial interface or VT interface. ADD IPADDR: BT=HRB, BN=2, IFT=SRL, IPADDR="18.10.0.25", MASK="255.255.0.0", IFMPLS=NO; IFN=0,
Step 5 Set the property of IP interface. Description Script Set the property of IP interface: Set Interface type to Serial Interface and IP domain to 10. MOD IPIF: IFT=SRL, BT=HRB, BN=2, IFN=0, MTU=1500, ENABLE=YES, DESP="Serial Interface", AUTH=NONE, TIMEOUT=3, KEEPALIVE=10, DOMAIN=10, BEARBW=1024, IFMP=NO, VT=0, IFCRTP=NO, RPTROUTE=NO, CRCENB=YES, CRCLENGTH=CRC16, SCRAMENB=NO, TIMEFILL=Ox7E, SPACEREG=0, CRCCHKENB=YES, CRCCHKLEN=CRC16, UNSCRAMENB=NO;
----End

None.

None.
Issue 02 (2007-06-10)
24-19
24 IP over E1

None.

None.
24.10 Reference
None.

Glossary
Glossary All MGW interconnection Direct connection between MGWs IP domain Description All MGWs can interwork with each other. Direction connection exists between two MGWs.
MGWs in the same IP domain can communicate with each other.

Acronym AMR cRTP IPoE1 BICC IAM IOE IPBCP QoS Full Name Adaptive MultiRate Compressed Real-Time Protocol IP over E1 Bear Independent Call Control Initial Address Message IP over E1 IP Bearer Control Protocol Quality of Service
24-20
Issue 02 (2007-06-10)
24 IP over E1
Acronym CMN TrFO SDP CIC VAD VOIP VTID
Full Name Call Mediation Node Transcoder Free Operation Session Description Protocol Call Identity Code Voice Activity Detect Voice Over IP Virtual Terminal Identifier
Issue 02 (2007-06-10)
24-21
Contents
Contents
25 IP QoS Flow Control .............................................................................................................25-1
25.1 Feature Description ...................................................................................................................................25-2 25.1.1 Function Code..................................................................................................................................25-2 25.1.2 Definition .........................................................................................................................................25-2 25.1.3 System Specifications ......................................................................................................................25-2 25.1.4 Benefits ............................................................................................................................................25-3 25.1.5 Application Scenario ........................................................................................................................25-3 25.1.6 Application Limitations....................................................................................................................25-3 25.2 Availability ................................................................................................................................................25-3 25.2.1 Requirements for NEs......................................................................................................................25-3 25.2.2 Requirements for License ................................................................................................................25-4 25.2.3 Applicable Versions..........................................................................................................................25-4 25.2.4 Others...............................................................................................................................................25-4 25.3 Working Principle......................................................................................................................................25-4 25.3.1 Functions of NEs..............................................................................................................................25-4 25.3.2 Internal Processing of the System ....................................................................................................25-5 25.3.3 External Interfaces ...........................................................................................................................25-8 25.4 Service Flow..............................................................................................................................................25-8 25.4.1 IP QoS Flow Control in Inter-Office Office Direction Mode for Outgoing Calls............................25-9 25.4.2 IP QoS Flow Control in Inter-Office Gateway Pair Mode for Outgoing Calls ................................25-9 25.4.3 IP QoS Flow Control in Gateway Pair Mode for Intra-Office Calls ..............................................25-10 25.5 Data Configuration.................................................................................................................................. 25-11 25.5.1 Overview........................................................................................................................................ 25-11 25.5.2 Data Configuration at the MSOFTX3000 Side..............................................................................25-12 25.5.3 Data Configuration at the UMG8900 Side.....................................................................................25-15 25.5.4 Data Configuration Examples ........................................................................................................25-16 25.5.5 Operations by Carriers ...................................................................................................................25-18 25.5.6 Operations by Mobile Subscribers .................................................................................................25-18 25.6 Charging and CDR ..................................................................................................................................25-18 25.7 Performance Measurement......................................................................................................................25-18 25.7.1 Index Description...........................................................................................................................25-19 25.7.2 Implementation Principle...............................................................................................................25-19
Issue 02 (2007-06-10)
Contents
25.8 Service Interaction ..................................................................................................................................25-19 25.9 References ...............................................................................................................................................25-19 25.9.1 Standards and Specifications..........................................................................................................25-19 25.9.2 Acronyms and Abbreviations .........................................................................................................25-19 25.10 FAQ .......................................................................................................................................................25-20
ii
Issue 02 (2007-06-10)
Figures
Figures
Figure 25-1 Networking of the IP QoS flow control granularity......................................................................25-6 Figure 25-2 IP QoS processing flow in inter-office office direction mode.......................................................25-9 Figure 25-3 IP QoS processing flow in inter-office gateway pair mode for inter-office calls ........................25-10 Figure 25-4 IP QoS processing flow in gateway pair mode for intra-office calls........................................... 25-11
Issue 02 (2007-06-10)
iii
Tables
Tables
Table 25-1 NEs that are involved in this IP QoS flow control..........................................................................25-3 Table 25-2 Earliest version that implements the IP QoS flow control..............................................................25-4 Table 25-3 Software parameter setting for QoS flow control function...........................................................25-12
iv
Issue 02 (2007-06-10)
25 IP QoS Flow Control
25
About This Chapter
Section 25.1 Feature Description 25.2 Availability
IP QoS Flow Control
The following table lists the contents of this chapter. Describes The function code and definition of the service and the benefits of the service to carriers and mobile subscribers. The NEs required to implement the service, requirements for the license, and versions of the products applicable to the service. The functions of the NEs used to implement the service and the requirements on the networking. The flow of the service. The data configuration that must be performed at the MSOFTX3000 side and the UMG8900 side as well as the examples of data configuration. The procedure for performing charging and generating CDRs when the service is provided. The influence of the service on performance measurement and the implementation of performance measurement. The association between the service and other services as well as the restrictions on each other. The standards and specifications with which the service complies and the glossary, abbreviations, and acronyms used in this chapter. The frequently asked questions related to the service and the solutions.
25.6 Charging and CDR 25.7 Performance Measurement
25.8 Service Interaction 25.9 References
25.10 FAQ
Issue 02 (2007-06-10)
25-1

Name IP QoS flow control Code WMFD-163900
25.1.2 Definition
Logically, the MSOFTX3000 is classified into two network entities: mobile softswitch center (MSC) server and media gateway (MGW) . One MSC server controls one or more MGWs through H.248 or Media Gateway Control Protocol (MGCP). The functions of the network entities are as follows: MSC server: It is responsible for control functions in the circuit-switched (CS) domain, such as mobility management, security management, handoff processing, signaling processing, and subscriber service data management (VLR function). MGW: It bears the circuits in the CS network and media streams in the IP network, and is responsible for voice, data and video connection between the CS network and IP network, or in the same network. When the MSOFTX3000 interworks with another MSC server through the Bearer Independent Call Control (BICC) protocol, the MSOFTX3000 supports the IP QoS flow control if the MSOFTX3000 and MSC server bear media streams in IP mode. This ensures that the voice quality of an established call borne by the IP is not affected by the quality degradation of the IP bearer network. The IP QoS flow control can be used when the MSOFTX3000 works as end office, gateway office or tandem office. For an established call between two MGWs (intra-office or inter-office call), the IP QoS detection is implemented on the endpoints of the call. If an alarm is generated with the IP QoS damage, the MSOFTX3000 restricts subsequent calls through the flow control mechanism such as quality degradation or call restriction, so that the voice quality of the established call is not affected.

Item IP QoS and distributed trunk selection function Specification The IP QoS flow control is implemented on a WCDB. Through this distributed trunk selection function, the number of WCDBs that perform the trunk selection function increases. When the traffic is normal, the trunk selection function is implemented in load-sharing mode and thus each WCDB can independently perform the trunk selection. In this case, the IP QoS flow control is implemented only on one WCDB for one call.
25-2
Issue 02 (2007-06-10)
Item IP QoS flow control in inter-office gateway pair mode Others
Specification The case that BCUID is not contained in the signaling between network elements (NEs) is not considered. If BCUID is not contained in the signaling, the MSC server cannot obtain gateway pair information or call route information. Thus, the MSC server cannot send the detection event and cannot implement the IP QoS flow control. When the quality of the bearer network becomes poorer, subsequent calls are restricted, but established calls are not released.
25.1.4 Benefits
Beneficiary Carrier Description In a mobile network, the IP QoS flow control ensures the quality of the IP bearer network. In case of heavy traffic, the traffic can be efficiently distributed or subsequent calls are restricted so that the quality of established calls is maintained. The IP QoS flow control improves the quality of established calls.
Mobile subscriber

The IP QoS flow control applies to GSM and UMTS R99/R4.

This flow control does not apply to a non-IP bearer network.
25.2 Availability
To implement the IP QoS flow control, the MSOFTX3000 must work with the MGW. 25-1 lists the NEs that are involved in this IP QoS flow control. Table 25-1 NEs that are involved in this IP QoS flow control UE NodeB RNC MSC Server MGW SGSN GGSN HLR Table
"" indicates the network element (NE) is involved in this function.
Issue 02 (2007-06-10)
25-3

The IP QoS flow control feature is an optional feature of the MSOFTX3000. No license is currently required for the availability of this feature. This feature is controlled by P353 software parameter. By default, this feature is disabled. For the configuration of P353, see section 1.5.2 Data Configuration at the MSOFTX3000 Side.

Table 25-2 lists the versions of the Huawei UMTS CN that implements the IP QoS flow control. Table 25-2 Earliest version that implements the IP QoS flow control Product MSC Server MSOFTX3000 Applicable Version V100R005C01
25.2.4 Others
None.

In the IP QoS flow control, the functions of the MSC server and MGW are as follows: MGW: It reports the quality alarm for a call. The alarm value indicates the call quality. The bigger the alarm value is, the poorer the quality of the call. MSC server: It implements call sampling, and the flow control of subsequent calls. The sampling message sent by the MSC server to the gateway is to detect the voice quality of calls of a certain direction on the gateway. If the voice quality is poor, subsequent calls are restricted, that is, the number of calls allowed per minute is restricted to a certain range. Through the sampling message, the QoS feedbacks of the bearer endpoints are given. Therefore, this method is also called feedback-mode flow control. The implementation of the IP QoS flow control is as follows: 1. The MSC server sends the call sampling message to the MGW before connecting to the calls of a certain direction on an MGW. After the connection, the MGW reports the alarm values of the voice quality of the calls to the MSC server. The MSC server determines whether to implement the flow control for subsequent calls, based on the alarm value of the voice quality of the calls (three calls supported currently). When subsequent calls are connected, the flow control is implemented if the MSC server detects that the voice quality of the calls of a certain direction on the MGW becomes poorer That is, the number of calls allowed per minute is restricted to a certain range. If the range is exceeded within a minute, the extra calls of this direction are released on the MGW. At the same time, a call restriction alarm is generated by the MSC server. For the
2.
3.
25-4
Issue 02 (2007-06-10)
call restriction alarm between inter-office office direction gateways, the alarm ID is 1887; for the call restriction alarm between intra-office gateways, the alarm ID is 1890. 4. When the voice quality of the calls of a certain direction becomes good, a recovery period is enabled to avoid the call traffic jitter during the recovery and a recovery alarm is generated. For a recovery alarm between inter-office office direction gateways, the alarm ID is 1888; for a recovery alarm between intra-office gateways, the alarm ID is 1891. Within the recovery period, if the voice quality becomes better, the number of calls allowed per minute increases by geometric progression or arithmetical progression (set in SET QOSPARA), but the flow control is not released until the maximum threshold value (set in SET QOSPARA) is reached after the recovery period.
Currently, the policies of the IP QoS flow control are as follows: The IP QoS flow control is disabled. Only sampling function of the IP QoS flow control is enabled to detect the quality of the bearer network. The sampling function of the IP QoS flow control, and the IP QoS flow control are enabled. If it is found that the quality of the bearer network becomes poor through call sampling, the number of calls is restricted. This restriction is not cancelled until the quality of the bearer network is restored.

The IP QoS flow control can be implemented on two kinds of network segments: Network segment between two intra-office gateways Network segment between one outgoing gateway in a local office and one gateway in the peer office Based on the granularity of the IP QoS flow control, the IP QoS flow control between one outgoing gateway in an office and one gateway of the peer office falls into two modes: Inter-office office direction mode Inter-office gateway pair mode Therefore, in the current network, an outgoing gateway in an office can connect to more than one gateway in the peer office, and can also connect to more than one peer office. Figure 25-1 Networking of the IP QoS flow control granularity
MSOFTX3000-4 MSOFTX3000-1 MSOFTX3000-2 MSOFTX3000-3
MGW1
MGW2
MGW3
MGW4
MGW5
MGW6
MGW7
MGW8
Signaling Bearer
Issue 02 (2007-06-10)
25-5
Inter-office office direction mode In this mode, the QoS flow control granularity is reflected between the gateway in a local office, and the gateway in a peer office. As shown in Figure 25-1, MGW 3 of MSOFTX3000-1 is an outgoing gateway, which can connect to MSOFTX3000-2, MSOFTX3000-3 or MSOFTX3000-4. Calls from MGW 3 of MSOFTX3000-1 to any gateway of MSOFTX3000-2 are processed uniformly. And the IP QoS flow control is implemented on all these calls to MSOFTX3000-2. Inter-office gateway pair mode In this mode, the QoS flow control granularity is reflected between a gateway in a local office, and one or more gateways of a peer office, or more than one gateway of multiple peer offices. The gateways connected to the gateway in a local office are regarded as a whole, also called a virtual office direction. Therefore, the inter-gateway pair mode is also called inter-gateway virtual office direction mode. In this mode, the IP QoS flow control is implemented on all calls from outgoing MGW3 to a virtual office direction.
When the MSC server detects that the voice quality of calls of a certain direction on the MGW becomes poor, subsequent calls are restricted. In different flow control modes, the processing of subsequent alls is different. In inter-office office direction mode, subsequent calls are diverted to other MGWs with good bearer quality. If there are no other MGWs with good bearer quality, outgoing selection and subsequent calls fail. In inter-office gateway pair mode, subsequent calls are released.
These two inter-office modes are exclusive of each other. P353 software parameter is used to control which mode is used. For details, see the Software Parameter Description. Intra-office IP QoS flow control is independent of inter-office IP QoS flow control.
Internal Implementation of the System

When a call bearer channel adopts the IP bearer mode, IP voice packets are always delayed, lost, or jittered. Based on the bearer quality of the current call, it can be inferred that calls over the same channel also have the same bearer quality. By sampling the bearer quality of the current call, the system can obtain the bearer quality information of a specific inter-office office direction gateway pair or the bearer quality information of intra-office MGWs. Based on the information, the system restricts calls of a specific office direction gateway pair or calls of intra-office MGWs. For outgoing calls, IP QoS sampling and flow control are performed on the outgoing gateway and the office direction. The detailed processing flow is as follows: 1. If there is a call and the MSC determines that it is an outgoing call, the MSC instructs the WCDB board to select a route. After the WCDB board returns the route selection result, the system issues a sampling instruction if the system determines that the local office adopts the IP bearer mode or the outgoing trunk adopts SIP trunk or BICC trunk and the sample number is less than three (up to three samples are allowed to be obtained from each MGW direction). The sampling instruction is transparently transmitted by each module and finally sent to the gateway. Based on the quality of the current bearer network, the gateway reports the QoS value periodically. The value is sent to the CRO first. The CRO processes the value and then reports the processed value to the WCDB board periodically. Based on the QoS value reported, the WCDB board determines the quality of the current network. The method is: Set a QoS value, which indicates that the network bearer quality is normal, on the MSC through SET QOSPARA. If the QoS value reported by an MGW is equal to or larger than the value, it is considered that the
25-6
Issue 02 (2007-06-10)
gateway bearer quality is bad. If the QoS value reported by an MGW is less than the value, it is considered that the gateway bearer quality is normal. 2. If the bearer quality of a gateway changes from good to bad, the WCDB board restricts the number of calls that pass this gateway in the next minute based on the number of calls in the previous minute or the average number of calls per minute from 4:00 a.m. till now. (Set the two options through the software parameter P354 QoS Control Parameter. For detailed description, refer to the Software Parameter Description. The default configuration, that is, the number of calls in the previous minute, is used as an example in this section.) The number of calls that pass the gateway in the next minute cannot exceed the number of calls in the previous minute. At this time, the number of calls in the previous minute obtained is defined as the number of calls per minute. If the gateway continues to report QoS values that are equal to or larger than the value configured on the MSC, the number of calls that pass the gateway is reduced based on the configured percentage and the number of calls per minute. If the QoS value reported is equal to the value configured on the MSC, the number of calls is reduced based on First descend percentage. If the QoS value reported is larger than the value configured on the MSC, the number of calls is reduced based on Second descend percentage. The two parameters can be configured through SET QOSPARA. If the gateway continues to report QoS values equal to or larger than the value configured on the MSC, the number of calls allowed to pass the gateway is reduced until it reaches the minimum number of calls allowed. Configure the minimum number of calls through SET QOSPARA. When the bearer quality of the gateway keeps worsening, the number of calls per minute is reduced based on the configured percentage. The number of calls in the next minute cannot exceed the number of calls being reduced. The established calls, however, are not disconnected forcedly. If the bearer quality of a gateway changes from bad to good (the MSC server does not consider that the bearer quality becomes good. The MSC server only starts a recovery process, during which the flow control is still enabled. After complete recovery, the MSC server considers that the bearer quality becomes good and disables flow control), the MSC server enables Resume long timer T1 (configured through SET QOSPARA). If a serious alarm (the QoS value reported to the MSC server the QoS value configured on the MSC server) occurs before T1 times out, the system enters the call restriction state again, and the call-restriction-threshold-increment Delta1 is set to 0; if T1 times out, set the times of continuous ascending call restriction threshold to N through SET QOSPARA, and start Resume short timer T2 (configured through SET QOSPARA) for N times. If a serious alarm occurs before T2 times out, the system enters the call restriction state again and Delta1 is set to 0; if T2 times out, set the initial value of Delta1 based on Resume delta type (When Resume delta type is set to Geometric Progression, the initial value of Delta1 is 1; when Resume delta type is set to Arithmetical Progression, the initial value of Delta1 is set to 0), then add Delta1 based on Resume delta type (By default, Geometric Progression is adopted, and Resume value is set to 2 through SET QOSPARA. You can also adopt Arithmetical Progression, and set Resume value to 1, 2 or other values), reduce N, and if N is not reduced to 0, T2 is restarted, the gateway keeps being recovered. If N is 0, add Delta1 to the number of calls per minute. If the number of calls per minute at present is larger than Maximal threshold (configured through SET QOSPARA), it indicates that the number of calls reaches the maximum value, and it is considered that the gateway is completely recovered and flow control is stopped. Otherwise, restart T1 to repeat the previous process to recover the gateway. If no sample is reported within a certain period (configured through SET QOSPARA), it is considered that the MGW loses information of the quality sampling call. The MSOFTX3000 issues a new sampling instruction.
3.
4.
5.
Issue 02 (2007-06-10)
25-7
If an intra-office call crosses two gateways, IP QoS sampling and flow control are performed between the two gateways. The detailed process is the same as previous description.
During the flows of the two modes, note the following: The processing flow in inter-office gateway pair mode and that in inter-office office direction mode are the same. Note that: In inter-office gateway pair mode, whether the MSC decides to issue sampling instructions and perform flow control is not processed during WCDB trunk line hunting. The BICC sends a QoS query message to the WCDB board to determine whether the call is under flow control, is going on by carrying samples, or is going on without carrying samples. Due to the distributed WCDB trunk line hunting function, the strategy adopted in inter-office gateway pair mode is that the BICC sends QoS query messages to each WCDB board in sequence so that the call samples can be evenly distributed. You can neglect the case caused by this strategy, that is, trunk line hunting for a call is performed on the first WCDB board while the QoS samples of this call are processed on the second WCDB board. Due to the distributed WCDB trunk line hunting function, the strategy adopted in inter-office office direction mode is that the WCDB board that performs trunk line hunting also issues samples and performs flow control. In case of large-volume calls, the possibility to perform trunk line hunting is the same for every WCDB board, and the flow control strategy of IP QoS is evenly configured for each WCDB board.

None.
25.4 Service Flow

The basic call flow bears the IP QoS service flow.
25.4.1 IP QoS Flow Control in Inter-Office Office Direction Mode for Outgoing Calls
Figure 25-2 IP QoS processing flow in inter-office office direction mode
Signaling Bearer MSX1 MSX2
MGW1
MGW2
MGW3
MGW4
25-8
Issue 02 (2007-06-10)
For outgoing calls, the processing flow for IP QoS flow control in inter-office office direction mode is as follows: 1. An outgoing route is selected for a call on MSX1. MGW2 is selected as the outgoing gateway. The office direction is MSX2. If a route is selected successfully, MSX1 samples calls from MGW2 to MSX2. MSX1 issues a sampling instruction to MGW2. After receiving the sampling instruction, MGW2 reports the bearer quality of the call to MSX1 periodically in the form of QoS alarm value until the call is completed. The worse the bearer quality is, the larger the QoS alarm value is. MSX1 receives the QoS alarm value from MGW2 periodically. MSX1 analyzes the value to determine whether to perform flow control to future calls from MGW2 to MSX2. For the analysis principles, see 25.3.2 "Internal Processing of the System." If MSX1 determines to perform flow control to calls from MGW2 to MSX2, MSX1 restricts the number of calls per minute so that the calls do not exceed the number of calls in the previous minute. If subsequent calls from MGW2 to MSX2 meet the flow control requirements, these calls cannot be transmitted from MGW2. The system chooses another MGW for call connection. If there are no available MGWs, the calls are disconnected.
2.
3.
4.
25.4.2 IP QoS Flow Control in Inter-Office Gateway Pair Mode for Outgoing Calls
When the inter-office flow control mode is set to Gateway pair mode, the MSOFTX3000 determines whether to send the QoS detection after the BUCUID of the peer MGW is learnt in the subsequent APM message, because the BUCUID of the peer MGW is unknown when the MGW selects the outgoing gateway. Accordingly, the MSOFTX3000 must detect whether the MGW meets the conditions of the IP QoS flow control. Figure 25-3 shows the QoS processing flow in inter-office gateway pair mode for inter-office calls. Figure 25-3 IP QoS processing flow in inter-office gateway pair mode for inter-office calls
Signaling Bearer MSX1 MSX2
MGW2 IP Network
MGW3
MGW1
MGW4
Issue 02 (2007-06-10)
25-9
The IP QoS flow control in inter-office gateway pair mode for an outgoing call is described as follows: 1. MSX1 routes a call to MSX2 through MGW2, which functions as an outgoing gateway. MSX2 returns an APM, which contains the BCUID of the peer MGW. Suppose the BCUID of MGW3 is returned. MSX1, based on the BCUID of MGW3, determines whether the path from MGW2 to MGW3 meets the flow control conditions.

2.
If the path meets the conditions, the call is disconnected. If the path does not meet the conditions, MSX1 checks whether the number of sampling objects of the current path reaches three. If not, MSX1 instructs MGW2 for sampling.
3.
MGW2 periodically reports the bearer quality, which is expressed in QoS alarm value, to MSX1, before the call ends. The poorer the bearer quality, the larger the QoS alarm value is. MSX1 analyzes the alarm value and determines whether to carry out flow control for future calls from MGW2 to MGW3. For the analysis principles, see 25.3.2 "Internal Processing of the System." In gateway pair mode, the call from the MGW to the peer MGW is released directly. MSX1 does not select other MGWs to connect the call. This is because the MSOFTX3000 determines whether to carry out the flow control after the BCUID of MGW3 is obtained.
4.
5.
25.4.3 IP QoS Flow Control in Gateway Pair Mode for Intra-Office Calls
Figure 25-4 shows the QoS processing flow in gateway pair mode for intra-office calls. Figure 25-4 IP QoS processing flow in gateway pair mode for intra-office calls
Signaling Beaer MGW2
MSX
MGW1
MGW3
The IP QoS flow control in gateway pair mode for inter-office calls is described as follows:
25-10
Issue 02 (2007-06-10)
1.
For a call from MGW1 to MGW3, the MSX selects the path from MGW1 to MGW3 first. The MSX instructs MGW1 for sampling. (In intra-office gateway pair, the MSOFTX3000 only need to instruct one MGW for sampling to obtain the QoS alarm value.) MGW1 periodically reports the bearer quality, which is expressed in QoS alarm value, to the MSX, before the call ends. The poorer the bearer quality, the larger the QoS alarm value is. The MSX analyzes the alarm value and determines whether to carry out flow control for future calls from MGW1 to MGW3. For the analysis principles, see 25.3.2 "Internal Processing of the System." If the bearer quality of the path from MGW1 to MGW3 gets poorer, the MSX enables the flow control to limit the number of calls per minute through this path. Thus, the number of calls does not exceed that of the last minute. The calls that exceeds the number, are routed through another path, such as MGW1>MGW2>MGW3. If the path from MGW1 to MGW2 or the path from MGW2 to MGW3 meets the flow control conditions, calls cannot be put through, either.
2.
3.
4.

25.5.1 Overview
The service must be provided by the UMG8900 of the version V002R005 or later. Thus, the service must be configured with both the MSOFTX3000 and the UMG8900 data. The configuration principles are as follows: Enable the IP QoS function on the MSOFTX3000, and select the flow control mode. Set parameters related to QoS through SET QOSPARA. Set the bearer quality mapping the QoS alarm value at the UMG8900 side.

If both the local office and the peer office adopt the IP bearer, or the gateways of the local office adopts the IP bearer, the data configuration of QoS flow control is based on the IP bearer. To configure the data at the MSOFTX3000 side, perform the following steps: Step 1 Set data of the IP QoS function. Run MOD MSFP to modify the software parameter P353. You can determine whether to enable the IP QoS function and set the inter-office flow control mode. The meaning of each bit of P353 is described as follows: Bit 0 indicates the inter-office flow control mode

= 0: inter-office office direction mode = 1: inter-office gateway pair mode = 0: No. = 1: Yes. = 0: No.
Bit 1 indicates whether to enable the sampling function.

Bit 2 indicates whether to enable the flow control function.
Issue 02 (2007-06-10)
25-11
= 1: Yes.
Bit 2 has higher priority than bit 1, that is, if the flow control function is enabled, the sampling function is enabled irrespective of the value of bit 1. By default, the value of P353 is 0, indicating that the IP QoS flow control function is disabled. Table 25-3 lists the setting of software parameter P353. Table 25-3 Software parameter setting for QoS flow control function Bit 2 0 0 Bit 1 0 1 Meaning QoS is disabled. QoS is enabled. The sampling function is enabled. The MSOFTX3000 does not carry out the flow control when the quality of the bearer network gets poorer. QoS is enabled. The sampling function is enabled. The MSOFTX3000 carries out the flow control when the quality of the bearer network gets poorer.
Step 2 Configure the parameters for inter-office and intra-office QoS. Command SET QOSPARA LST QOSPARA Function Set QoS parameters. List QoS parameters.
The following describes the parameters related to SET QOSPARA. Call barring type It specifies the call barring type. The options are described as follows: Inter MSC: Inter-office calls are barred. Intra MSC: Intra-office calls are barred. This parameter must be specified. Sample object count It specifies the number of objects sampled by the MSOFTX3000 to detect the quality of the IP bearer network in the current call barring mode. This parameter is for future expansion and is reserved now. Sample protect time It specifies the sample protect time in the current call barring mode, in unit of minute. After the MSC server issues the sampling instruction, the sampling information is determined to be lost if no message is reported within the value of Sample protect time. In this case, the MSC server issues a new sampling instruction. Call barring alarm level
25-12
Issue 02 (2007-06-10)
It specifies the threshold for call barring in the current call barring mode. In the current call barring mode, if the IP bearer quality alarm, that is, the QoS alarm value reported by the UMG8900, reaches the value of Call barring alarm level configured, the MSOFTX3000 carries out the call barring. Otherwise, the MSOFTX3000 does not carry out the call barring. First descend percentage It specifies the first descend percentage in the current call barring mode. When the QoS alarm value reported by the MGW reaches the value of Call barring alarm level, the MSC server bars calls according to the value of First descend percentage. Note that the value of First descend percentage must be larger than that of Second descend percentage. Second descend percentage It specifies the second descend percentage in the current call barring mode. When the QoS alarm value reported by the MGW is greater than the value of Call barring alarm level, the MSC server bars calls according to the value of Second descend percentage. Minimal threshold It specifies the minimum threshold value in the current call barring mode, that is, the minimum number of calls that can be connected every minute in the path in which the flow control is carried out. Resume long timer It specifies the duration of the resume long timer in the current call barring mode, in unit of second. Note that the value of Resume long timer must be equal to or greater than the value of resume short timer. Resume short timer It specifies the duration of the resume short timer in the current call barring mode, in unit of second. Resume hold times It specifies the resume hold times in the current call barring, that is, it specifies the number of times for the MSOFTX3000 to enable the short timer during the resuming. Resume delta type It specifies the resume delta type in the current call barring mode. The options are described as follows: Geometric progression: The MSOFTX3000 resumes calls according to the geometric proportion principle. Arithmetical progression: The MSOFTX3000 resumes calls according to the arithmetical progression principle. Resume value It specifies the resume delta value in the current call barring mode. This parameter is the radix for call barring resume. This parameter with Resume hold times determines the number of calls that can be resumed. The calculation relationship is as follows: When Resume delta type is set to Geometric progression, the number of calls that can be resumed is the nth power of Resume value, where n is the value of Resume hold
Issue 02 (2007-06-10)
25-13
times. For example, if Resume value is set to 2 and Resume hold times is set to 3, the number of calls that can be resumed is 8. When Resume delta type is set to Arithmetical progression, the number of calls that can be resumed is Resume value multiplied by n, where n is the value of Resume hold times. For example, if Resume value is set to 2 and Resume hold times is set to 3, the number of calls that can be resumed is 6. Maximal threshold It specifies the maximum threshold value in the call barring mode. During the call resume, if the number of calls per minute reaches or exceeds the value of Maximal threshold, the MSOFTX3000 stops the call barring in this path. Note that the value of Maximal threshold must be equal to or greater than that of Minimal threshold. Step 3 Configure the parameters for virtual office direction. When the QoS flow control office direction mode is set to inter-office mode, you must set the virtual office direction parameters through the following commands. Command ADD BCUIDOFC MOD BCUIDOFC RMV BCUIDOFC LST BCUIDOFC Function Add BCUID_Virtual Office Direction Mapping Modify BCUID_Virtual Office Direction Mapping Remove BCUID_Virtual Office Direction Mapping List BCUID_Virtual Office Direction Mapping
The following parameters are described by considering the command ADD BCUIDOFC for example. BCUID It specifies the ID of a bearer control unit. When the MSOFTX3000 is interconnected with the MSC server through the BICC protocol, the BCUID is used to uniquely identify an MGW in the BICC protocol message. The BCUID cannot be set freely. It is allocated by the network operator in the entire network. That is to say, each MGW has its unique BCUID in a network. Peer MGW description It specifies an MGW for identification. Its value is the character string with the value range of 32 characters. It is null by default. Virtual office direction name It specifies a virtual office direction for identification. It maps the virtual office direction name one to one. Its value is the character string with the value range of 32 characters. It is set to DFTVON by default. Note the following when configuring the virtual office direction through ADD/MOD BCUIDOFC: If only one virtual office direction mapping the MGW is configured, ensure that the VON is different from that mapping another MGW.
25-14
Issue 02 (2007-06-10)
If one virtual office direction mapping multiple MGWs is configured, separately set the VONs mapping the MGWs to the same value through ADD/MOD BCUIDOFC. For data configuration of the auxiliary functions, see related descriptions of P354 and P355 in the software parameter description document. ----End

This document introduces the UMG8900 data configuration only related to the MSOFTX3000. For details of UMG8900 data configuration, see its related documentation. The UMG8900 obtains the QoS value between the IP pairs based on the combination of package discarding rate, delay, and jitter. When the UMG8900 identifies that the voice quality becomes poor, it sends alarms to the MSC server (the UMG8900 also adopts timing alarming mechanism to ensure the reliability). The alarm message contains the QoS alarm level (level 0 is the lowest one and 5 is the highest). The package discarding rate of the MGW and the QoS value can be configured on the MGW (see MGW related document for details). The default value of each level is listed in the following table. QoS Value Level 0 Level 1 Level 2 Level 3 Level 4 Level 5 Package Discarding Rate 0% 0%3% 3%8% 8%15% 15%30% 30% (> 0% and < 3%) ( 3% and < 8%) ( 8% and < 15%) ( 15% and < 30%)
The package discarding rate of each level is adjustable. For example, the package discarding rate of level 2 can be set to 5%10%. The level can be calculated according to the quality of the bearer network. The package discarding rate, delay, and jitter are the factors that reflect the QoS level. If packages are discarded, the QoS level is calculated based on the package discarding rate. For example, if the current package discarding rate is 3%, the corresponding QoS level is 1; if the rate is 10%, the QoS level is 3. If the package is not discarded, the loop delay and jitter are the factors that reflect the QoS level. If one of them exceeds the threshold (the value preset on the MGW), the QoS level can be considered as 1. For other situations, the QoS level can be considered as 0.

When both the sampling function and flow control function of the IP QoS flow control feature are enabled, the inter-office flow control mode must be "inter-office office direction mode".
Issue 02 (2007-06-10)
25-15
Step 1 Set QoS function switch. Description Script Remarks Modify the software parameter P353 to 4, that is, set BIT0 to 0, BIT1 to 0, and BIT2 to 1. MOD MSFP: ID=P353, MODTYPE=P0, VALUE="4"; When BIT2 is set to 1, BIT1 can be set to 0 or 1. You can modify the data by value or by bit.
Step 2 Set QoS function parameter. Description Set Call barring type to Inter MSC, Sample object count to 3, Sample protect time to 5, Call barring alarm level to 2, First descend percentage to 95%, Second descend percentage to 90%, Minimal threshold to 2, Resume long timer to 150, Resume short timer to 75, Resume hold times to 2, Resume delta type to Geometric Progression, Resume value to 2, and Maximal threshold to 200. SET QOSPARA: CBT=INTMSC, SOC=3, SPT=5, CBAL=2, FDP=95, SDP=90, MNT=2, RLT=150, RST=75, RHT=2, RDT=GP, RV=2, MXT=200; If the data in this step is not configured, the system adopts the default data. Both the inter- and intra-office QoS parameters are configured through this command.
Script
Remarks
----End
When the sampling function is enabled but the flow control function is disabled, the inter-office flow control mode must be "Inter-office gateway pair mode".
Step 1 Set QoS function switch. Description Script Modify the software parameter P353 to 3, that is, set BIT0 to 1, BIT1 to 1, and BIT2 to 0. MOD MSFP: ID=P353, MODTYPE=P0, VALUE="3";
25-16
Issue 02 (2007-06-10)
Step 2 Set QoS function parameter. Description Set Call barring type to Intra MSC, Sample object count to 3, Sample protect time to 5, Call barring alarm level to 2, First descend percentage to 95%, Second descend percentage to 90%, Minimal threshold to 2, Resume long timer to 150, Resume short timer to 75, Resume hold times to 2, Resume delta type to Geometric Progression, Resume value to 2, and Maximal threshold to 200. SET QOSPARA: CBT=INTMSC, SOC=3, SPT=5, CBAL=2, FDP=95, SDP=90, MNT=2, RLT=150, RST=75, RHT=2, RDT=GP, RV=2, MXT=200; If the data in this step is not configured, the system adopts the default data. Both the inter- and intra-office QoS parameters are configured through this command.
Script
Remarks
Step 3 Set virtual office direction parameters. Description Script Set the two MGWs with the BCUID of 0 and 1 to be in the same virtual office direction, and set the office name to Virtual_Office. ADD BCUIDOFC: BCUID=0, MGWDESCRN="Mgw1 of ShenZhen", VON="Virtual_Office"; ADD BCUIDOFC: BCUID=1, MGWDESCRN="Mgw2 of ShenZhen", VON="Virtual_Office";
----End

See data configuration examples for details about configuring the QoS related data.

The IP QoS feature does not concern the interaction with mobile subscribers, and it is transparent to subscribers.

None.

None.
Issue 02 (2007-06-10)
25-17
25.7.1 Index Description

None.

None.

The IP QoS feature is independent from other features. It is only used to detect and control the IP network QoS and does not concern the interaction with other functions.
25.9 References
None.

Acronyms
Acronyms NA Meaning NA
Abbreviations
Abbreviations APM BICC CCB CDB CM CRO IAM MSC PB QoS Full Name Application Transport Mechanism Bearer Independent Call Control Protocol Call Control Block Center Database Call Manager Common Resource Operation Initial Address Message Mobile Switching Center Prepare Bearer Quality of Service
25-18
Issue 02 (2007-06-10)
Abbreviations TK
Full Name Trunk
25.10 FAQ
FAQ1
The quality of calls on a certain MGW office direction becomes poorer but the subsequent calls are still being connected. Step 1 Check whether the IP QoS flow control function of the MSC server is enabled and BIT2 of P353 is set to 1. If the flow control function is disabled, enable it. Step 2 If the flow control function is enabled. Run LST QOSPARA to check whether the Minimal threshold is set to a bigger value. If yes, modify the value to a smaller one (In call barring status, the number of calls connected per minutes is over this value). Step 3 If the problem remains, check the MGW configuration (see MGW user manual for details) to confirm the relation between the MGW QoS alarm value and the network QoS detected by the MGW. This problem occurs when the lower QoS alarm value maps the higher package discarding rate. Step 4 If the problem remains, save related information and contact Huawei technical support engineers for help. ----End
FAQ2
The quality of calls on a certain MGW office direction is good but some of the subsequent calls cannot be connected. Step 1 Check whether the IP QoS flow control function of the MSC server is enabled (follow the preceding steps). If the function is disabled, check whether the problem occurs due to other causes. Step 2 If the problem remains, check the MGW configuration (see MGW user manual for details) to confirm the relation between the MGW QoS alarm value and the network QoS detected by the MGW. This problem occurs when the lower QoS alarm value maps the higher package discarding rate. Step 3 If the problem remains, save related information and contact Huawei technical support engineers for help. ----End
Issue 02 (2007-06-10)
25-19
Contents
Contents
26 O-CSI SMS ..............................................................................................................................26-1
26.1 Service Description ...................................................................................................................................26-2 26.1.1 Function Code..................................................................................................................................26-2 26.1.2 Definition .........................................................................................................................................26-2 26.1.3 Standard Compliance .......................................................................................................................26-2 26.1.4 System Specifications ......................................................................................................................26-2 26.1.5 Benefits ............................................................................................................................................26-2 26.1.6 Application Scenario ........................................................................................................................26-2 26.1.7 Application Limitations....................................................................................................................26-3 26.2 Availability ................................................................................................................................................26-3 26.2.1 Requirements for NEs......................................................................................................................26-3 26.2.2 Requirements for License ................................................................................................................26-3 26.2.3 Applicable Versions..........................................................................................................................26-3 26.2.4 Others...............................................................................................................................................26-4 26.3 Working Principle......................................................................................................................................26-4 26.3.1 Functions of the NEs........................................................................................................................26-4 26.3.2 Intenal System Processing ...............................................................................................................26-4 26.3.3 External Interfaces ...........................................................................................................................26-7 26.4 Service Flow..............................................................................................................................................26-8 26.5 Data Configuration..................................................................................................................................26-10 26.5.1 Overview........................................................................................................................................26-10 26.5.2 Data Configuration at the MSOFTX3000 Side..............................................................................26-10 26.5.3 Data Configuration at the HLR Side ..............................................................................................26-13 26.5.4 Data Configuration Example..........................................................................................................26-13 26.5.5 Table Query Procedure of the O-CSI SMS ....................................................................................26-14 26.6 Service Management ...............................................................................................................................26-16 26.6.1 Operations by Carriers ...................................................................................................................26-17 26.6.2 Operations by Subscribers .............................................................................................................26-18 26.7 Charging and CDR ..................................................................................................................................26-18 26.7.1 Charging Principle .........................................................................................................................26-18 26.7.2 CDR ...............................................................................................................................................26-18 26.8 Performance Measurement......................................................................................................................26-18
Issue 02 (2007-06-10)
Contents
26.9 Service Interaction ..................................................................................................................................26-18 26.10 Reference...............................................................................................................................................26-18 26.10.1 Specifications...............................................................................................................................26-18 26.10.2 Glossary, Acronyms, and Abbreviations ......................................................................................26-19 26.11 FAQ .......................................................................................................................................................26-19
ii
Issue 02 (2007-06-10)
Figures
Figures
Figure 26-1 Internal processing of system when the sending of short message is allowed by the SCP ...........26-5 Figure 26-2 Internal processing of system when the sending of short message is prohibited by the SCP .......26-6 Figure 26-3 Service flow when the sending of short message is allowed by the SCP .....................................26-8 Figure 26-4 Service flow when the sending of short message is prohibited by the SCP................................26-10 Figure 26-5 Procedure for querying the table to obtain the O-CSI SMS processing information ..................26-15 Figure 26-6 Procedure for querying the table to obtain the location number in the INITIAL-DP message...26-16
Issue 02 (2007-06-10)
iii
Tables
Tables
Table 26-1 Function code .................................................................................................................................26-2 Table 26-2 Benefits of the O-CSI SMS service ................................................................................................26-2 Table 26-3 NEs required to implement the O-CSI SMS...................................................................................26-3 Table 26-4 Versions of Huawei core network products that support the O-CSI SMS ......................................26-3 Table 26-5 Parameters in the Initial-DP message .............................................................................................26-7 Table 26-6 Logical relationship to determine whether to allow the triggering of the O-CSI............................26-9 Table 26-7 Parameter description of ADD SMOCSI...................................................................................... 26-11 Table 26-8 Parameter description of ADD LAIGCI (2G)...............................................................................26-12 Table 26-9 Parameter description of ADD LAISAI (3G) ...............................................................................26-13 Table 26-10 Tables related to the O-CSI SMS................................................................................................26-15 Table 26-11 interactions between the O-CSI SMS and other services............................................................26-18
iv
Issue 02 (2007-06-10)
26 O-CSI SMS
26
About This Chapter
O-CSI SMS
26.11 FAQ
Issue 02 (2007-06-10)
26-1
26 O-CSI SMS

Table 26-1 lists the function code of the Originating CAMEL Subscription Information (OCSI) short message service (SMS). Table 26-1 Function code Name O-CSI Short Message Function Code WMFD-151400
26.1.2 Definition
O-CSI SMS means that subscribers subscribing to O-CSI (hereinafter O-CSI refers to O-CSI DP2) without subscribing to SMS-CSI can also trigger the MOS SMS flow.

None.

None.
26.1.5 Benefits
Table 26-2 lists the benefits of the software management service. Table 26-2 Benefits of the O-CSI SMS service Beneficiary Carrier Description SMS-CSI is applicable to CAMEL Phase3 and above versions, whereas O-CSI is applicable to all CAMEL versions. This function provides wider CAMEL application to carriers in terms of MO-SMS, enabling carriers to use CAMEL Phase2 and below versions and CAP interface to provide CAMEL application over mobile originated short messages. Subscribers In case that the carrier only supports CAMEL Phase2 and later versions, subscribers can also enjoy O-CSI SMS.

The O-CSI SMS is applicable to the GSM network and universal mobile telecommunications system (UMTS) R99/R4 network.
26-2
Issue 02 (2007-06-10)
26 O-CSI SMS

None.
26.2 Availability
Table 26-3 lists the network elements (NEs) required to implement the O-CSI SMS, including MS/UE, BTS/Node B, BSC/RNC, MSC Server, SMC, HLR, and SCP. Table 26-3 NEs required to implement the O-CSI SMS MS/UE BTS/Node B BSC/RNC MSC Server MGW SMC HLR SCP
The symbol represents that the NE is required to implement the service. The availability description in other sections of this document deals with the MSC server only.

The O-CSI SMS is an optional service of the HUAWEI GSM/UMTS wireless core network. You can use the service without a license.

Table 26-4 lists the versions of Huawei core network products that support the O-CSI SMS. Table 26-4 Versions of Huawei core network products that support the O-CSI SMS Product MSC server MSOFTX3000 Applicable Version V100R002C01B078 V100R003C07 V100R003C10 V100R005C02 V100R005C05 V100R005C10
26.2.4 Others
None.
Issue 02 (2007-06-10)
26-3
26 O-CSI SMS

The functions of the NEs are as follows: The MS, BTS, and BSC provide signaling access and content submit of the MO SMs. The MSC server receives and saves the O-CSI subscription data during location update. The MSC server also processes the signaling, triggers the CAMEL service, and generates CDRs during the MO SM flow. The SMC receives and sends short messages. The HLR enables subscribers to subscribe to the O-CSI and inserts the data into the VLR during location update. The SCP processes and controls the IN part of the O-CSI SMS.
26.3.2 Intenal System Processing

When a subscriber who subscribes to the O-CSI but not the SMS-CSI originates a short message, the MSC server triggers the O-CSI SMS flow. Depending on the instructions from the SCP, the internal processing of the MSC server is classified into the following types: Sending of short message allowed by the SCP Sending of short message prohibited by the SCP
Sending of Short Message Allowed by the SCP

After O-CSI is triggered, if the SCP allows the subscriber to send the short message, the MSC Server continues to process the short message, as shown in Figure 26-1.
26-4
Issue 02 (2007-06-10)
26 O-CSI SMS
Figure 26-1 Internal processing of system when the sending of short message is allowed by the SCP
RCF MS 1. SMO-MSC CP_DATA CP_ACK gsmSSF SCP VLR SMC
2.
SEND INFO FOR MO-SMS COMPLETE SMO CALL (TC_CONT)
DP-SO-COLLECTED-INFO 3. 4. CONTINUE SEND INFO 5. FOR MO-SMS INITIAL-DP CONTINUE
COMPLETE SMO CALL (TC-END) 6. Forward Short Message Forward Short Message ack
CP_DATA(RP_ACK) CP_ACK
When the sending of short message is allowed by the SCP, the service flow is as follows: 1. 2. The MSC server receives the CP_DATA short message from the subscriber. By sending the SEND INFO FOR MO-SMS message to the VLR, the MSC server checks the ODB BAOC of the subscriber to see whether the barring of all outgoing services of the subscriber is enabled. The MSC server triggers the O-CSI SMS and sends the INITIAL-DP message to the SCP. The SCP sends the CONTINUE message to the MSC Server, indicating to continue with the flow. The MSC server sends the SEND INFO FOR MO-SMS message to complete the ODB BOIC check and to see whether the barring of all outgoing international services is enabled. The MSC server forwards the short message to the SMC.
3. 4. 5.
6.
Issue 02 (2007-06-10)
26-5
26 O-CSI SMS
The MSC server acts as both the RCF and the VLR in the preceding figure. When the MSC server checks the ODB BAOC and BOIC of the subscriber and finds that the services are barred, the MSC server terminates the O-CSI SMS flow.
Sending of Short Message Prohibited by the SCP

After the O-CSI is triggered, the SCP prohibits the subscriber from sending the short message. The MSC server terminates the O-CSI SMS flow, as shown in Figure 26-2. Figure 26-2 Internal processing of system when the sending of short message is prohibited by the SCP
RCF MS 1. CP_DATA CP_ACK SMO-MSC gsmSSF SCP VLR SMC
2.
SEND INFO FOR MO-SMS
COMPLETE SMO CALL DP-SO-COLLECTED-INFO 3. 4. int-RELEASE 5. CP_DATA(RP_error) CP_ACK INITIAL-DP RELEASE CALL
When the sending of short message is prohibited by the SCP, the service flow is as follows: 1. 2. The MSC server receives the CP_DATA short message from the subscriber. By sending the SEND INFO FOR MO-SMS message to the VLR, the MSC server checks the ODB BAOC of the subscriber to see whether the barring of all outgoing services of the subscriber is enabled. The MSC server triggers the O-CSI SMS and sends the INITIAL-DP message to the SCP. The SCP sends the RELEASE CALL message to the MSC server to terminate the flow. The MSC server terminates the O-CSI SMS flow by sending the CP_DATA (RP_error) message to the MS.
3. 4. 5.
26-6
Issue 02 (2007-06-10)
26 O-CSI SMS

This service is implemented through the CAP interface between the MSC server and SCP. The interface complies with CAMEL 03.78 and uses DP2 as the report point. Table 26-5 shows the content of the report sent by the CAP interface. Table 26-5 Parameters in the Initial-DP message Parameter ServiceKey CalledPartyNumber CallingPartyNumber CallingPartysCategory LocationNumber OriginalCalledPartyID Extensions HighLayerCompatibility AdditionalCallingPartyNumber BearerCapability EventTypeBCSM RedirectingPartyID RedirectionInformation IMSI SubscriberState LocationInformation --locationNumber --CellIdOrLAI --GeographicalInformation --AgeOf location --VLRNumber Ext-basicServiceCode CallReferenceNumber MscAddress CalledPartyBCDNumber M/O M NA M M M NA NA NA NA NA M NA NA M NA M NA M O M M M M M M
Issue 02 (2007-06-10)
26-7
26 O-CSI SMS
M/O: M means Mandatory; O means Optional; NA means Not Applicable. The parameters with "--" are sub-layer parameters.
26.4 Service Flow

The O-CSI SMS enables the subscribers who subscribe to the O-CSI in the HLR but not the SMS-CSI to trigger the MO SMS flow. Depending on whether the SCP allows the sending of short messages, the service flows of the O-CSI SMS are classified into the following types:
Sending of Short Message Allowed by the SCP

Figure 26-3 shows the service flow when the sending of short message is allowed by the SCP. Figure 26-3 Service flow when the sending of short message is allowed by the SCP
BSC MSC Server Access process 1.CP_DATA 2.Intial-DP 3.CONTINUE 4.FORWARD_SHORT_MESSAGE_REQ FORWARD_SHORT_MESSAGE_CNF 5.CP_ACK SCP SMC
When the sending of short message is allowed by the SCP, the service flow is as follows: 1. 2. After the subscriber access is completed, the content of the short message is sent to the MSC server through the CP_DATA message. After receiving the short message content, the MSC server obtains the subscriber data (including CAMEL data) from the VLR and checks whether the subscriber subscribes to the SMS-CSI. If the subscriber subscribes to the SMS-CSI, the MSC server triggers the SMS-CSI flow. If the subscriber subscribes to the O-CSI but not the SMS-CSI, and the local office supports the O-CSI SMS by using the software parameters, the MSC server triggers the O-CSI and sends the Initial-DP message to the SCP. After receiving the Initial-DP message, the SCP determines to allow the sending of short messages, and sends the CONTINUE message to the MSC server. After receiving the CONTINUE message, the MSC server sends the content of the short message to the SMC through the FORWARD_SHORT_MESSAGE_REQ message. After receiving the FORWARD_SHORT_MESSAGE_CNF message from the SMC, the MSC server sends the CP_ACK message to the subscriber, indicating that the short message is sent successfully.
3. 4. 5.
After receiving the content of the short message from the BSC and before sending the InitialDP message to the SCP, the MSC server checks whether to allow the triggering of the O-CSI based on the logic relationship listed in Table 26-6. The software parameter that controls
26-8
Issue 02 (2007-06-10)
26 O-CSI SMS
whether the local office supports the O-CSI SMS must be enabled for the MSC server to complete the check. Table 26-6 Logical relationship to determine whether to allow the triggering of the O-CSI CSI Subscribed on the HLR SMS-CSI O-CSI Configuration of the SMOCSI Table The IMSI prefix is configured in the table. The IMSI prefix is not configured in the table. SMS-CSI and O-CSI The IMSI prefix is configured in the table. The IMSI prefix is not configured in the table. None The IMSI prefix is configured in the table. The IMSI prefix is not configured in the table. Trigger the normal MO SMS flow. Service Flow Triggered Trigger the standard CAMEL MO SMS flow. Trigger the O-CSI SMS flow. Do not trigger the CAMEL MO SMS flow. Trigger the normal MO SMS low. Trigger standard CAMEL MO SMS flow.
The logical relationship is described as follows: When the SMS-CSI is subscribed on the HLR, the subscriber can use the standard CAMEL MO SMS flow and the MSC server processes the short message according to the flow. When the O-CSI is subscribed on the HLR, the subscriber can use the O-CSI SMS flow and the MSC server processes the short message according to the flow and the subscriber information in the SMOCSI table. If the subscriber information is not configured in the SMOCSI table, the MSC server terminates the CAMEL MO SMS flow and starts the normal MO SMS flow. When both the SMS-CSI and O-CSI are subscribed on the HLR, no confliction occurs because the priority of the SMS-CSI is higher than the priority of the O-CSI. The MSC server processes the short message according to the standard CAMEL MO SMS flow. When no CSI data of the subscriber is subscribed on the HLR, the MSC server processes the short message according to the normal MO SMS flow.
Sending of Short Message Prohibited by the SCP

Figure 26-4 shows the service flow when the sending of short message is prohibited by the SCP.
Issue 02 (2007-06-10)
26-9
26 O-CSI SMS
Figure 26-4 Service flow when the sending of short message is prohibited by the SCP
BSC MSC Server Access process 1.CP_DATA 2.Intial-DP 3.RELEASE_CALL SCP
4.CP_ACK(RP_ERROR)
When the sending of short message is prohibited by the SCP, the service flow is as follows: 1. 2. After the subscriber access is completed, the content of the short message is sent to the MSC server through the CP_DATA message. After receiving the short message content, the MSC server checks whether the subscriber subscribes to the SMS-CSI. If the subscriber subscribes to the SMS-CSI, the MSC server triggers the SMS-CSI flow. If the subscriber subscribes to the O-CSI but not the SMSCSI, and the local office supports the O-CSI SMS by using the software parameters, the MSC server triggers the O-CSI and sends the Initial-DP message to the SCP. After receiving the Initial-DP message, the SCP determines to prohibit the sending of short messages, and sends the RELEASE CALL message to the MSC server. After receiving the RELEASE CALL message, the MSC server terminates the MO SMS flow, and sends the CP_ACK message to the subscriber, indicating that the short message fails to be sent.
3. 4.

26.5.1 Overview
To enable the O-CSI SMS, you must configure data both at the MSOFTX3000 side and at the HLR side.

Configuring Function Switch
The function switch configuration is described as follows: Overview A software parameter is used as the function switch to control whether the MSOFTX3000 supports the O-CSI SMS. Configuration steps The command MOD MSFP is used to configure whether the MSOFTX3000 supports the O-CSI SMS. Detailed configuration
26-10
Issue 02 (2007-06-10)
26 O-CSI SMS
Run MOD MSFP to set whether MSOFTX3000 supports the O-CSI SMS. Configure the parameter as follows: Bit 6 of P650 (MAP part2 software parameter 1) The bit is used as a function switch to control whether the MSOFTX3000 supports the O-CSI SMS. The value options are:

0: No. 1: Yes. The default value is 0.
Configuring the Data of the SMOCSI Table

The data configuration of the SMOCSI table is described as follows: Overview After the MSOFTX3000 is configured to support the O-CSI SMS, it is required to configure the O-CSI SMS processing information. Configuration steps The command ADD/MOD/LST/RMV SMOCSI is used to configure the O-CSI SMS processing information. Detailed configuration Run ADD SMOCSI to add the O-CSI SMS processing information. The parameters are described in Table 26-7. Table 26-7 Parameter description of ADD SMOCSI Parameter ID IMSIPREFIX SERVICEKEY Parameter Name IMSI Prefix Service Key Parameter Description The IMSI prefix of the subscriber, maximum 15 numbers. . The service key entered in the INITIAL-DP message of the O-CSI SMS. The value of the parameter ranges from 0 to 2147483647. The CAMEL version entered in the INITIAL-DP message. The value options are: BYOSCI (Indicating to use the CAMEL version in the subscribed O-CSI) CAP1(CAMEL_PHASE1) CAP2(CAMEL_PHASE2) CAP3(CAMEL_PHASE3) CAP4(CAMEL_PHASE4)
CAMELVERSION
CAMEL Version
Issue 02 (2007-06-10)
26-11
26 O-CSI SMS
Parameter ID CALLEDBCDNUMPA RTY
Parameter Name Called Party BCD Number Type
Parameter Description The type of called number entered in the INITIAL-DP message. The value options are: CALLEDPARTY (the called number of the short message) SMCADDR (the SMC number)
In the O-CSI SMS flow, the CAMEL version (which is the value of CAMEL Version in the preceding table) in the INITIAL-DP message must not be higher than the CAMEL version configured in the local MSC server. The CAMEL versions supported by the local office can be queried by LST MAPACCFG. In the O-CSI SMS flow, IDP location number must be configured. IDP location number is configured by ADD LAISAI (3G) or ADD LAIGCI (2G). In a 2G network, use ADD LAIGCI to configure the IDP location number (LOCATIONNUM). In a 3G network, use ADD LAISAI to configure the IDP location number (LOCATIONNUM). Note the difference between IDP location number and Location number name (LOCNONAME). Location number name is used for enhanced roaming restriction and connection mode sharing. If the IDP location number (LOCATIONNUM) is not configured in ADD LAISAI (3G) or ADD LAIGCI (2G), Location Number in the INITIAL-DP2 message is set to the MSC number of the local office.
Table 26-8 Parameter description of ADD LAIGCI (2G) Parameter ID GCI Parameter Name Global cell ID Parameter Description When the MNC is a 2-digit number, enter the 9-digit LAI number to configure the LAI or the 13-digit GCI number to configure the GCI, depending on the value of Location area category. When the MNC is a 3-digit number, enter the 10-digit LAI number to configure the LAI or the 14-digit GCI number to configure the GCI, depending on the value of Location area category. MSCN VLRN BSCDP1 LOCATIONNUM MSC number of the LA cell VLR number of the LA cell Home BSC DPC 1 IDP location number The MSC number is already defined in ADD INOFFMSC. The VLR number is already defined in ADD INOFFMSC. Indicates the signaling point code of the first home BSC of the location area. Indicates the location number in the INITIAL-DP message
26-12
Issue 02 (2007-06-10)
26 O-CSI SMS
Table 26-9 Parameter description of ADD LAISAI (3G) Parameter ID SAI Parameter Name 3G service area number Parameter Description When the MNC is a 2-digit number, enter the 9-digit LAI number to configure the LAI or the 13-digit SAI number to configure the SAI, depending on the value of Location area category. When the MNC is a 3-digit number, enter the 10-digit LAI number to configure the LAI or the 14-digit SAI number to configure the SAI, depending on the value of Location area category. MSCN VLRN RNCID1 LOCATIONNUM MSC number of 3G service area VLR number of 3G service area RNCID1 IDP location number The MSC number is already defined in ADD INOFFMSC. The VLR number is already defined in ADD INOFFMSC. Indicates the network ID of the first home RNC of the location area. Indicates the location number in the INITIAL-DP message
26.5.3 Data Configuration at the HLR Side

The O-CSI SMS data must also be configured on the HLR.

Subscribers can use the O-CSI SMS. The HLR, MSC, SCP, and MSC/VLR are required to implement the service. The number of the subscriber is 86139075511.
The configuration steps are as follows Step 1 Use the function switch to enable the O-CSI SMS. Description Script Remark Configure the function switch to enable the O-CSI SMS. MOD MSFP: ID=P650, MODTYPE=P1, BIT=6, BITVAL=1; Set bit 6 of P650 to 1 to enable the function.
Issue 02 (2007-06-10)
26-13
26 O-CSI SMS
Step 2 Configure the O-CSI SMS processing information. Description Script Remark Configure the O-CSI SMS processing information. ADD SMOCSI: IMSIPREFIX=K'46007, SERVICEKEY=95, CAMELVERSION=CAP1, CALLEDBCDNUMTYPE=CALLEDPARTY; Set IMSI Prefix to 46007, Service Key to 95, CAMEL Version to 1, and Called Party BCD Number Type to Called Party Number.
Step 3 Configure the IDP location number of the location area. Description Script Configure the location number of the location area. The location number is required in the Initial-DP message. ADD LAISAI: SAI="460510001", MSCN="86139075511", VLRN="86139075511", LAICAT=LAI, LAIT=HVLR, RNCID1=0, CSNAME="A", LOCATIONNUM="1111111111111111"; ADD LAIGCI: GCI="460510002", MSCN="86139075511", VLRN="86139075511", LAICAT=LAI, LAIT=HVLR, BSCDPC1="C1", CSNAME="A", LOCATIONNUM="2222222222222222"; Remark The location number for the 3G location area is configured by ADD LAISAI, and the location number of the 2G location area is configured by ADD LAIGCI.
Step 4 Configure the location number of the cell. Description Script Configure the location number of the cell. The location number is required in the Initial-DP message. ADD LAISAI: SAI="4605100010001", MSCN="86139075511", VLRN="86139075511", LAICAT=SAI, LAIT=HVLR, RNCID1=0, CSNAME="B", LOCATIONNUM="1111111111111111"; ADD LAIGCI: GCI="4605100020001", MSCN="86139075511", VLRN="86139075511", LAICAT=GCI, LAIT=HVLR, BSCDPC1="C1", CSNAME="B", LOCATIONNUM="2222222222222222"; Remark The location number for the 3G cell is configured by ADD LAISAI, and the location number of the 2G cell is configured by ADD LAIGCI.
----End
26.5.5 Table Query Procedure of the O-CSI SMS

Tables Related to the Service
Table 26-10 lists the tables related to the O-CSI SMS service.
26-14
Issue 02 (2007-06-10)
26 O-CSI SMS
Table 26-10 Tables related to the O-CSI SMS Table Name SM Over OCSI Process table 3G/2G LAI or SAI/GCI Information table Function Contains multiple records about the IMSI prefix and corresponding CAMEL short message processing information, such as the CAMEL service key, CAMEL version, and called number type. Contains multiple records about the location area or cell (GCI for 2G and SAI for 3G). The parameter related to the O-CSI SMS is the Initial-DP location number corresponding to the location area or cell. MML Command ADD SMOCSI
ADD LAISAI ADD LAIGCI
Procedure for Querying Tables

To obtain the O-CSI SMS processing information configured in the local office, carry out the procedure shown in Figure 26-5 to query the SM Over OCSI Process table based on the IMSI prefix and service key. Figure 26-5 Procedure for querying the table to obtain the O-CSI SMS processing information
Enter an IMSI prefix and CAMEL service key.
No
Check if the O-CSI SMS processing information corresponding to the CAMEL service key and the IMSI prefix is configured in the SM Over OCSI Process table.
Yes
Check if the CAMEL version obtained is higher than CAMEL version 4. Yes Do not trigger the O-CSI SMS. Start the normal MO SMS flow.
No
Continue to trigger the O-CSI SMS.
Issue 02 (2007-06-10)
26-15
26 O-CSI SMS
To obtain the INITIAL-DP location number of the location area or cell to trigger the O-CSI and generate the INITIAL-DP message, carry out the procedure shown in Figure 26-6 to query the LAI Information table based on the location area or cell. Figure 26-6 Procedure for querying the table to obtain the location number in the INITIAL-DP message
Input location area or location area cell
No No
Check "Location area cell table" to see whether the IDP location number corresponding to the location area or location area cell has been configured? Yes
Check whether the obtained IDP location number is invalid?
No
Fill in the IDP message with the IDP location number as the location number
Yes Fill in the IDP message with the local MSC Number of the local office as the location number

For the O-CSI SMS, the management operations and their definitions are defined as follows: Provision: An operation executed by the carrier, which makes the service available to subscribers. A reverse operation to Cancellation. Cancellation: An operation executed by the carrier that makes the service unavailable to subscribers. A reverse operation to Provision. Register: An operation run by the carrier that makes the service usable. It includes sending the O-CSI subscription information to the HLR and configuring O-CSI SMS processing information in the MSOFTX3000. Erase: An operation run by the carrier that makes the service unusable. A reverse operation to Register.
26-16
Issue 02 (2007-06-10)
26 O-CSI SMS

By enabling and disabling the software parameters, the carrier can provide or cancel the OCSI SMS on the MSOFTX3000. By entering the O-CSI on the HLR and configure the O-CSI SMS processing information on the MSOFTX3000, the carrier can control the registration of the O-CSI SMS. By removing the O-CSI on the HLR SMU Client and the O-CSI SMS processing information on the MSOFTX3000, the carrier can deregister the O-CSI SMS.
Provision
The steps of the operation are as follows: Step 1 On the MSOFTX3000 LMT, run LST MSFP to list the value of bit 6 of software parameter 650 that controls whether to enable the O-CSI SMS. Step 2 On the MSOFTX3000 LMT, run MOD MSFP. Set bit 6 of software parameter 650 to 1 to enable the O-CSI SMS. ----End
Cancellation
The steps of the operation are as follows: Step 1 On the MSOFTX3000 LMT, run LST MSFP to list the value of bit 6 of software parameter 650 that controls whether to enable the O-CSI SMS. Step 2 On the MSOFTX3000 LMT, run MOD MSFP. Set bit 6 of software parameter 650 to 0 to disable the O-CSI SMS. ----End
Register
The steps of the operation are as follows: Step 1 On the HLR SMU Client, run MOD OCSI to subscribe to the O-CSI for the subscriber. Set PROV to True. Step 2 On the MSOFTX3000 LMT, run ADD SMOCSI to configure the O-CSI SMS processing information. ----End
Erase
The steps of the operation are as follows: Step 1 On the HLR SMU Client, run MOD OCSI to remove the subscribed O-CSI. Set PROV to False. Step 2 On the MSOFTX3000 LMT, run RMV SMOCSI to remove the O-CSI SMS processing information. ----End
Issue 02 (2007-06-10)
26-17
26 O-CSI SMS

None.

26.7.1 Charging Principle
The charging principle for O-CSI short messages is the same as that for MO-SMS-CSI short messages.
26.7.2 CDR
The CDRs of O-CSI short messages are the same as those of MO-SMS-CSI short messages.

None.

Table 26-11 lists the interactions between the O-CSI SMS and other services. Table 26-11 interactions between the O-CSI SMS and other services Service O-CSI SMS and MO SMS O-CSI SMS and MO-SMS-CSI O-CSI SMS and MT-SMS-CSI Interaction The O-CSI SMS is embedded in the MO SMS. If the conditions are met, the O-CSI SMS is triggered during the MO SMS flow. If a subscriber subscribes to the MO-SMS-CSI and both the MAP version and the CAMEL version supported by the local office are higher than 3, the MO-SMS-CSI is valid, but the O-CSI SMS is not. No interaction between them. The O-CSI SMS is used only in the MO SMS.
26.10 Reference
The references of the O-CSI SMS are as follows: 3GPP TS 03.78, "Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase 2;Stage 2"
26-18
Issue 02 (2007-06-10)
26 O-CSI SMS
3GPP TS 23.078, "Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase 3; Stage 2" 3GPP TS 09.78, "Customized Applications for Mobile network Enhanced Logic (CAMEL); CAMEL Application Part (CAP) specification" 3GPP TS 29.078, "Customized Applications for Mobile network Enhanced Logic (CAMEL) Phase 3;CAMEL Application Part (CAP) specification"

Glossary
None.

Abbreviation O-CSI SMS-CSI MO-SMS-CSI 3G 3GPP Full name Originating CAMEL Subscription Information Short Message ServiceCAMEL Subscription Information Mobile Originated- Short Message Service--CAMEL Subscription Information The Third Generation 3rd Generation Partnership Project
26.11 FAQ
Symptom
A subscriber subscribes to the O-CSI, but the O-CSI SMS is not triggered in the MO SMS flow.
Troubleshooting
To troubleshoot the problem, perform the following steps: Step 1 Check whether the O-CSI SMS is enabled on the local office. If it is disabled, run MOD MSFP to enable it. Step 2 Check whether the O-CSI SMS processing information is configured on the local office. If it is not configured, run ADD SMOCSI to configure the data. Step 3 Check whether the service key in the O-CSI SMS processing information is the same as the service key subscribed by the subscriber. If not, run MOD SMOCSI to modify the service key. Step 4 Check whether the values of CAMEL Version and Called Party BCD Number Type in the O-CSI SMS processing information configured on the local office are valid. If the values are
Issue 02 (2007-06-10)
26-19
26 O-CSI SMS
invalid, run MOD SMOCSI to modify the values. The value of CAMEL Version must be set based on the configuration of the CAP interface of the local office. ----End
26-20
Issue 02 (2007-06-10)
Contents
Contents
27 UP Header Redundancy Data Service................................................................................27-1
27.1 Service Description ...................................................................................................................................27-2 27.1.1 Function Code..................................................................................................................................27-2 27.1.2 Definition .........................................................................................................................................27-2 27.1.3 Benefits ............................................................................................................................................27-2 27.1.4 Application Scenario ........................................................................................................................27-2 27.1.5 Application Limitations....................................................................................................................27-2 27.2 Availability ................................................................................................................................................27-3 27.2.1 Requirements for NEs......................................................................................................................27-3 27.2.2 Requirements for License ................................................................................................................27-3 27.2.3 Applicable Versions..........................................................................................................................27-3 27.2.4 Others...............................................................................................................................................27-3 27.3 Working Principle......................................................................................................................................27-3 27.3.1 Functions of the NEs........................................................................................................................27-3 27.3.2 Internal Processing of the System ....................................................................................................27-4 27.3.3 External Interfaces ...........................................................................................................................27-8 27.4 Service Flow..............................................................................................................................................27-9 27.5 Data Configuration..................................................................................................................................27-15 27.5.1 Data Configuration at the MSOFTX3000 Side..............................................................................27-15 27.5.2 Data Configuration at the UMG8900 Side.....................................................................................27-17 27.5.3 Data Configuration at the HLR Side ..............................................................................................27-17 27.5.4 Data Configuration Example..........................................................................................................27-17 27.6 Performance Measurement......................................................................................................................27-19 27.7 Service Interaction ..................................................................................................................................27-19 27.8 Reference ................................................................................................................................................27-20 27.8.1 Specifications.................................................................................................................................27-20 27.8.2 Glossary, Acronyms, and Abbreviations ........................................................................................27-20 27.9 FAQ .........................................................................................................................................................27-20
Issue 02 (2007-06-10)
Figures
Figures
Figure 27-1 Call flow when a narrowband trunk connects to a BICC trunk ....................................................27-4 Figure 27-2 Call flow when a narrowband trunk connects to a narrowband trunk (crossing multiple IP gateways) ...........................................................................................................................................................................27-5 Figure 27-3 Call flow when the access side connects to a BICC trunk (TS61)................................................27-6 Figure 27-4 Call flow when the access side connects to a narrowband trunk (crossing multiple IP gateways)27-7 Figure 27-5 Call flow when the access side connects to a BICC trunk (TS62)................................................27-8 Figure 27-6 Service flow when a narrowband trunk connects to a BICC trunk (voice service switching to fax service) ............................................................................................................................................................27-10 Figure 27-7 Service flow when a narrowband trunk connects to a narrowband trunk (crossing multiple IP gateways) (TS61) ............................................................................................................................................ 27-11 Figure 27-8 Service flow when the access side connects to a BICC trunk (using IP bearer between offices) (TS61) .............................................................................................................................................................27-13 Figure 27-9 Service flow when the access side connects to a BICC trunk (TS62) ........................................27-14
ii
Issue 02 (2007-06-10)
Tables
Tables
Table 27-1 Name and code of the function.......................................................................................................27-2 Table 27-2 NEs required to implement the UP header redundancy service......................................................27-3 Table 27-3 Versions of the Huawei GSM/UMTS products that support the UP header redundancy service....27-3
Issue 02 (2007-06-10)
iii
27
UP Header Redundancy Data Service
About This Chapter

The following table lists the contents of this chapter. Section 27.1 Service Description 27.2 Availability Describes The function code and definition of the service and the benefits of the service to carriers and mobile subscribers. The NEs required to implement the service, requirements for the license, and versions of the products applicable to the service. The functions of the NEs used to implement the service and the requirements on the networking. The flow of the service. The data configuration that must be performed at the MSOFTX3000 side and the UMG8900 side as well as the examples of data configuration. The operations that carrier and mobile subscribers must perform when the service is provided. The association between the service and other services as well as the restrictions on each other. The standards and specifications with which the service complies and the glossary, abbreviations, and acronyms used in this chapter. The frequently asked questions related to the service and the solutions.
27.6 Performance Measurement 27.7 Service Interaction 27.8 Reference
27.9 FAQ
Issue 02 (2007-06-10)
27-1

Table 27-1 lists the name and code of the function. Table 27-1 Name and code of the function Name UP header redundancy service Code WMFD-141900
27.1.2 Definition
The user plane (UP) header redundancy service is designed to solve the undesirable effects in some data services (such as poor quality or even failure in faxing) caused by unreliable data transmission over IP bearer networks. Based on RFC 2198, the service uses the free bytes in voice packets (such as G.711A/U) to transmit redundancy packets. This reduces the chances of successive packet losses and improves the reliability in data transmission.
27.1.3 Benefits
Beneficiary Carriers Subscribers Description More reliable data services like fax and video call can be implemented on IP bearer networks. A subscriber can gain better experience in fax and video call, and the services are more reliable.

This service is applicable to all markets of GSM and UMTS R99/R4. For IP bearer networks, this service improves the reliability of data services (primarily faxes at present) in the traditional circuit switched (CS) domain and provides better user experience.

The application limitations include the following: This service can be used only between the Huawei MSC servers of the same R level version. This service does not support interworking with the devices of other manufacturers. Currently, only when the trunk signaling is ISUP, TUP, or BICC can this service be used.
27-2
Issue 02 (2007-06-10)
27.2 Availability
Table 27-2lists the network elements (NEs) required to implement the UP header redundancy service. Table 27-2 NEs required to implement the UP header redundancy service UE Node B RNC MSC Server MGW SGSN GGSN HLR -
The symbol represents that the NE is required to implement the service.

No License is required. However, the UP header redundancy data service depends on the TrFo service. The TrFo service requires the support of the License.

Table 27-3 lists the versions of the Huawei GSM/UMTS products that support the UP header redundancy service. Version match is not required between the MSC server and MGW where this service is supported. Table 27-3 Versions of the Huawei GSM/UMTS products that support the UP header redundancy service Product MSC server MGW MSOFTX3000 UMG8900 Applicable versions V100R005C10; V100R005C02 and later versions V200R006
27.2.4 Others
None.

The MSC server is responsible for signaling handling, charging, and performance measurement, while the MGW is responsible for transmitting the redundancy information.
Issue 02 (2007-06-10)
27-3

The internal processing of the system varies with different networking types, which mainly includes the following: Narrowband trunk connecting to BICC trunk. Narrowband trunk connecting to narrowband trunk (crossing multiple IP gateways) Access side connecting to BICC trunk (TS61) Access side connecting to narrowband trunk (crossing multiple IP gateways) Access side connecting to BICC trunk (TS62)
The narrowband trunk mentioned in this document refers to an ISUP trunk and a TUP trunk.
Narrowband Trunk Connecting to BICC Trunk

Figure 27-1 shows the call flow when a narrowband trunk connects to a BICC trunk. Figure 27-1 Call flow when a narrowband trunk connects to a BICC trunk
MSC Server A 4 MSC Sever B
2 1
PSTN A
MGW A
MGW B PSTN B
In the above figure, the signaling between PSTN A and MSC server A, PSTN B and MSC server B is narrowband signaling, while that between MSC server A and MSC server B is BICC signaling.
The process is as follows: 1. 2. 3. 4. 5. 6. 7. After a normal voice call between PSTN subscriber A and subscriber B is set up and answered, PSTN subscriber A initiates a fax. MGW A detects the fax signal and reports this to MSC server A. MSC server A delivers a request to MGW A, requiring MGW A to change the service mode from a voice service mode to a data service mode. MSC server A sends an APM message to MSC server B, asking to change the supported codec. MSC server B delivers a CODEC change request to MGW B. The bearer between MGW A and MGW B is changed. The fax signal is sent to PSTN B.
27-4
Issue 02 (2007-06-10)
Narrowband Trunk Connecting to Narrowband Trunk (Crossing Multiple IP Gateways)

Figure 27-2 shows the call flow when a narrowband trunk connects to a narrowband trunk, crossing multiple IP gateways. Figure 27-2 Call flow when a narrowband trunk connects to a narrowband trunk (crossing multiple IP gateways)
MSC Server
3 2
4 5
MGW A
MGW B
PSTN A
PSTN B
In the above figure, the signaling between PSTN A and the MSC server, and that between PSTN B and the MSC server is narrowband signaling.
The process is as follows: 1. 2. 3. 4. 5. After a normal voice call between subscriber A and subscriber B is set up and answered, PSTN subscriber A initiates a fax request. MGW A detects the fax signal and reports it to the MSC server. The MSC server instructs MGW A and MGW B to change the service mode from a voice service mode to a data service mode. The bearer between MGW A and MGW B is changed. The fax signal is sent to PSTN B.
Access Side Connecting to BICC Trunk (TS61)

Figure 27-3 shows the call flow when the access side connects to a BICC trunk.
Issue 02 (2007-06-10)
27-5
Figure 27-3 Call flow when the access side connects to a BICC trunk (TS61)
MSC Server A 3 MSC Server B
6 2 1 5 4 7 MGW A 8 MGW B
UE A
UE B
In the preceding figure, the signaling between MSC server A and the MSC server B is BICC signaling.
The process is as follows: 1. 2. After a normal voice call between user equipment (UE) A and UE B is set up and answered, UE A initiates a fax request and reports the request to MSC server A. After confirming that UE A supports the fax service and 2198 redundancy, MSC server A instructs MGW A to change the service mode from a voice service mode to a data service mode. MSC server A sends an APM message to MSC server B. MSC server B notifies UE B about the fax service. After confirming that UE B supports the fax service, MSC server B instructs MGW B to change the service mode from a voice service mode to a data service mode. MSC server B sends a message to MSC server A, indicating that the change is successful. The bearer between MGW A and MGW B is changed. The fax is transmitted between the UEs.
3. 4. 5. 6. 7. 8.
Access Side Connecting to Narrowband Trunk (Crossing Multiple IP Gateways)

Figure 27-4 shows the call flow when the access side connects to a narrowband trunk, crossing multiple IP gateways.
27-6
Issue 02 (2007-06-10)
Figure 27-4 Call flow when the access side connects to a narrowband trunk (crossing multiple IP gateways)
VMSC Server GMSC Server
2 1 3 IP MGW A 4
TDM MGW B MGW C
UE A
FAX USER
In the preceding figure, the signaling between the VMSC server and the GMSC Server is narrowband signaling.
The process is as follows: 1. After a normal voice call between a handset subscriber and a fixed-line phone subscriber is established and answered, the handset subscriber initiates a fax request and sends the request to the VMSC server. After confirming that UE A supports the fax service and 2198 redundancy, the VMSC server changes IP terminations of MGW A and MGW B in the office. The bearer between MGW A and MGW B is changed. As the bearers between MGW B and other networks are based on TDM, they need not to be changed. The fax is transmitted between the UEs.
2. 3. 4.

shows the call flow when the access side connects to a BICC trunk (TS62).
Issue 02 (2007-06-10)
27-7
Figure 27-5 Call flow when the access side connects to a BICC trunk (TS62)
MSC Sever A 3 6 8 MSC Sever B
2 1 7
5 4
MGW A
MGW B
9 UE A UE B
The process is as follows: 1. 2. UE A initiates a data service request. After confirming that UE A supports the data service and the local office supports 2198 redundancy, and after confirming that the call is a BICC outgoing call (based on the number), MSC server A sends MGW A an Add_Request that carries 2198 redundancy parameters. MSC server A sends an outgoing message IAM. The Codec List of the message carries codec information, indicating that the local office supports 2198 redundancy. MSC server B sends a paging message to locate UE B. After confirming that the local office supports 2198 redundancy, MSC server B sends an Add_Request message to MGW B, carrying 2198 redundancy parameters. MSC server B sends an IAM message to MSC server A, indicating that MSC server B supports 2198 redundancy. The bearer is established between MGW A and MGW B. MSC Server B returns ACM and ANM messages to MSC server A, indicating that the call is connected and answered. The fax is transmitted between UE A and UE B.
3. 4. 5. 6. 7. 8. 9.

None.
27-8
Issue 02 (2007-06-10)
27.4 Service Flow

Fax handover means to change the IP bearer. This happens after a voice call is established between two sides and one of them initiates a fax request to the other. Fax handover involves the following cases: Narrowband trunk connecting to BICC trunk (voice service switching to fax service) Narrowband trunk connecting to narrowband trunk (crossing multiple IP gateways) (TS61) Access side connecting to BICC trunk (using IP bearer between offices) (TS61) In addition, there is another case in fax service where a call is made as data call during call establishment, and therefore no service handover is required. This is known as "Access side connecting to BICC trunk (TS62)".
Narrowband Trunk Connecting to BICC Trunk (Voice Service Switching to Fax Service)
Figure 27-6 shows the service flow when a narrowband trunk connects to a BICC trunk (voice service switching to fax service).
Issue 02 (2007-06-10)
27-9
Figure 27-6 Service flow when a narrowband trunk connects to a BICC trunk (voice service switching to fax service)
MSC Server A MSC Server B MGW A
MGW B
1: Notify:Fax Tone Dectect 2: Notify Rep 3: Modify Req 4: Modify Rep 5: BICC:APM(Modify Codec Req) 6: Modify Req(Reserve Char) 7: Modify Rep(Reserve Char Rsp) 8:Modify Req(Confirm Char) 9: Modify Rep(Confirm Char Rsp) 10: Modify Bearer 11: Modify Rep 12: Notify(Bearer Modified) 13: Notify Rep 14: BICC:APM(Succes Modify Codec)
The process is as follows: 1. 2. 3. 4. 5. 6. After a call is answered, MGW B reports a fax event. MSC server B returns a Notify Rep message to MGW B. MSC server B sends a modification request to MGW B, instructing MGW B to change the voice call to a data call. The request carries 2198 redundancy parameters. MGW B returns a Modify Rep message to MSC server B. MSC server B sends an APM message to MSC server A. The message contains the indicator Modify Codec Req, which indicates that the bearer needs to be changed. After receiving the APM message, MSC server A delivers a Reserve Char message to MGW A, instructing MGW A to change the service mode to data service.
27-10
Issue 02 (2007-06-10)
7. 8. 9.
MGW A changes the service mode and returns a Reserve Char Rsp message. After receiving the Reserve Char Rsp message, MSC server A delivers a Confirm Char message to MGW A. MGW A returns a Confirm Char Rsp message.
10. MGW A sends a Modify Bearer message to MGW B, instructing MGW B to re-initialize the bearer. 11. MGW B returns a Modify Rep message. 12. MGW A reports to MSC server A that the service mode has been changed to data service successfully. 13. MSC server A returns a Notify Rep message. 14. MSC server A sends an APM message to MSC server B, indicating that the modification is successful.
Narrowband Trunk Connecting to Narrowband Trunk (Crossing Multiple IP Gateways) (TS61)

Figure 27-7 shows the service flow when a narrowband trunk connects to a narrowband trunk, crossing multiple IP gateways (TS61). Figure 27-7 Service flow when a narrowband trunk connects to a narrowband trunk (crossing multiple IP gateways) (TS61)
PSTN A MGW A MSC Server MGW B PSTN B
1: ISUP:IAM 2: Add Request( TDM Termination) 4: Add Request (IP Termination) 5: ISUP:IAM 6: ISUP:ACM 7: ISUP:ACM 8: ISUP:ANM 9: ISUP:ANM 10: Notify(Fax Tone Detect) 11: Notify Reply 13: Modify Char Req(IP Termination) 15: Modify Char Rsp 12: Modify Char Req(IP Termination) 14: Modify Char Rsp 3: Add Request( TDM Termination, IP Termination)
Issue 02 (2007-06-10)
27-11
The process is as follows: 1. 2. The MSC server receives an ISUP IAM message from the PSTN A. The MSC server analyzes the call model and sends an Add_Request message to MGW A, instructing MGW A to add incoming side TDM termination and enable fax detection on the termination. The MSC server sends an Add_Request message to MGW B, instructing MGW B to add the TDM termination and IP termination at the outgoing side and perform fax detection on the TDM termination. The MSC server sends an Add_Request message to MGW A, instructing MGW A to add IP termination. MSC Server sends an IAM message to PSTN B. PSTN B returns an ACM message. The MSC server forwards the message to PSTN A. PSTN B sends an ANM message to the MSC Server. The MSC server forwards the message to PSTN A.
3.
4. 5. 6. 7. 8. 9.
10. MGW A detects the fax tone on the termination and reports the event to the MSC server. 11. The MSC server returns a Notify Reply message to MGW A. 12. The MSC server delivers a Modify Req message, which carries 2198 redundancy parameters, to MGW B. 13. Meanwhile, the MSC server also delivers a Modify Req message to MGW A, the message carrying 2198 redundancy parameters. 14. MGW B changes its bearer and returns a Modify Char Rsp message to the MSC server. 15. MGW A changes its bearer and returns a Modify Char Rsp message to the MSC server.
Access Side Connecting to BICC Trunk (Using IP Bearer Between Offices) (TS61)
Figure 27-8 shows the service flow when the access side connects to a BICC trunk and IP bearer is used between offices (TS61).
27-12
Issue 02 (2007-06-10)
Figure 27-8 Service flow when the access side connects to a BICC trunk (using IP bearer between offices) (TS61)
UE A MGW A MSC Server A MSC Server B MGW B UE B
1:modify 2:Modify Char Req 3:Modify Char Rsp 4:APM(Codec Modify Req) 5:Reserve Char Req 6:Reserve Char Rsp 7:Modify 8:Modify Complete 9:Confirm Char Req 10:Confirm Char Rsp 11:APM(Success Codec Modify) 12:Modify Complete 13:Fax Proceeding
The process is as follows: 1. 2. After a normal voice call between UE A and UE B is set up and answered, UE A initiates a fax modification request. The local office is configured to support the fax service. Both the local office and the peer office support 2198 redundancy. MSC server A requests to change the service mode of the local office termination to a data service mode. The request message carries the 2198 redundancy information. MGW A returns a Modify Char Rsp message. MSC server A sends an APM message to MSC server B, instructing MSC server B to change the service mode to a data service mode to support faxes. MSC server B sends a Reserve Char Req message to the IP termination of MGW B, requesting to modify the service mode. The message carries the 2198 redundancy information. MGW B returns a Reserve Char Rsp message. MSC server B sends a Modify message to UE B, instructing UE B to change the service mode to the fax service. UE B returns a Modify Complete message.
3. 4. 5.
6. 7. 8.
Issue 02 (2007-06-10)
27-13
9.
MSC server B sends a Confirm Char message to MGW B.
10. MGW B returns a Confirm Char Rsp message. 11. MSC Server B sends an APM message to MSC server A, indicating that the codec modification is completed. 12. MSC Server A sends a Modify Complete message to UE A, indicating that the modification is completed. 13. The fax is transmitted between UE A and UE B.

Figure 27-9 shows the service flow when the access side connects to a BICC trunk (TS62). Figure 27-9 Service flow when the access side connects to a BICC trunk (TS62)
UE A MGW A MSC Server A MSC Server B MGW B UE B
1: Setup 2: Add Request 3: Add Reply 4: IAM (With 2198 Codec) 5: Paging 6: Paging Response 7: Add Request 8: Add Reply
9: APM(With 2198 Codec) 10: Bearer Estiblish 11:alerting/ACM 12:Connect/ANM 13:Fax Proceeding
The flow is as follows: 1. 2. UE A sends a data service request to MSC server A. After confirming that the trunk signaling to MSC server B is BICC and the local office supports 2198 redundancy, MSC server A sends an Add_Request message to MGW A. The message carries 2198 redundancy parameters. MGW A responds with a message, which indicates that the termination is added successfully.
3.
27-14
Issue 02 (2007-06-10)
4.
MSC server A sends an IAM message to MSC server B. The message specifies that the service type is data service. The Codec List of the message contains 2198 redundancy parameters, which indicate that the local end supports 2198 redundancy. MSC server B sends a paging message to locate UE B. UE B responds with a message. MSC server B sends an Add_Request message to MGW B. The message carries 2198 redundancy parameters. MGW B returns an Add Reply message to MSC server B. MSC server B sends an IAM message to MSC server A. The Codec List of the message carries 2198 redundancy parameters, which indicate that MSC server B also uses 2198 redundancy mode to transmit data.
5. 6. 7. 8. 9.
10. The bearer between MGW A and MGW B is established. 11. UE B returns an ACM message to UE A, indicating that the call is connected. 12. UE B answers the call. 13. The fax is transmitted between UE A and UE B.

Related Commands
The configuration involves the following commands: ADD OFC, MOD OFC, SET OFI, ADD CODECCFG, LST CODECCFG, and MOD CODECCFG. The meanings of the parameters for the ADD and SET commands are explained below. For information about other commands, refer to the online help. ADD OFC BICC support TrFO This parameter is valid only when the Signaling type is one of the following: BICC over MTP3/M3UA_272, BICC over MTP3B, BICC over SCTP and BICC over M3UA_4096. It is one of the parameters used when the MSOFTX3000 interworks with the peer office. It specifies whether the office in the current office direction supports Transcoder Free Operation (TrFO). TrFO is a codec negotiation mechanism provided by the network. TrFO implements voice codec negotiation by means of out-of-band signaling transcoder control. This improves voice quality and saves bandwidth without using any codec. TrFO differs from TFO in that: if negotiation is successful, no codec is used at all in TrFO; while in TFO, though codec is not used, the codec unit continues to work to monitor TFO information in the voice channel. As such, no resources are saved during coding and decoding. BICC support red This parameter is valid only when the Signaling type is one of the following: BICC over MTP3/M3UA_272, BICC over MTP3B, BICC over SCTP and BICC over M3UA_4096.
Issue 02 (2007-06-10)
27-15
It is one of the parameters used when the MSOFTX3000 interworks with the peer office. It specifies whether the office in the current office direction supports data redundancy. Data redundancy is designed to solve the packet loss problem in data transmission. The data redundancy improves the quality of data transmission and reduces or avoids service failure due to poor data transmission quality. SET OFI Support FAX detection This parameter specifies whether the local MSOFTX3000 supports fax detection. The MOSFTX3000 notifies the MGW to check the fax event. The MGW then reports the checking events such as fax tone and fax status to the MOSFTX3000, which then handles the event according to the report. Note that if the Special attributes for the gateway is set to No fax, the call may fail. Support 2198 redundancy This parameter specifies whether the local MSOFTX3000 supports 2198 redundancy. This function is supported by default. If you choose Support, configure the 2198 redundancy parameters. In implementing this function, the MSOFTX3000 delivers the 2198 redundancy parameters to the MGW during a call. 2198 data redundancy is designed to solve the packet loss problem in data transmission. The 2198 data redundancy improves the quality of data transmission and reduces or avoids service failure due to poor data transmission quality. 2198 redundancy level As one of the parameters for 2198 data redundancy, this parameter is valid only when Support 2198 redundancy is set to Support. The parameter is used to specify the 2198 redundancy level, which is 1 by default. 2198 redundancy payload type value As one of the parameters for 2198 data redundancy, this parameter is valid only when Support 2198 redundancy is set to Support. The parameter is used to specify the 2198 redundancy payload type value, which ranges from 96 to 127 and defaults to 97. 2198 redundancy codec type This parameter is valid only when Support 2198 redundancy is set to Support. It is used to specify the codec type for 2198 redundancy, either G.711u or G.711a. The default is G.711a. ADD CODECCFG Codec ID This parameter defines a codec ID in the configuration database of the MSOFTX3000. The ID ranges from 0 to 254. PAYLOAD TYPE It is a parameter of the H248 signaling used when the MSOFTX3000 interacts with the MGW. The default value is 96. You can refer to RFC 1890 for the mapping between a Codec and its payload type. Note that the value must not be the same as the value of 2198 redundancy payload type value in the Basic Local Info table. PACKET TIME
27-16
Issue 02 (2007-06-10)
It is a parameter of the H248 signaling used when the MSOFTX3000 interacts with the MGW. CLOCK RATE It is a parameter of the H248 signaling used when the MSOFTX3000 interacts with the MGW.
Notes
Note the following during your configuration: You must enable 2198 redundancy support and fax detection in the local office information table. You must not set Special attributes in the MGW configuration table to No fax. You must enable 2198 redundancy support and TrFO negotiation support in the BICC office direction table. The payload type of 2198 redundancy in the local office information table must not be the same as that in the codec configuration table.

Note the following during your configuration: The UMG must be configured to support the TC resources of NGN codecs. The UMG must be configured to support the 2198 redundancy and the related parameters. For configuration guidance, refer to the relevant documents or the online help for UMG8900.

You must configure the subscribers to support one or more of the following services: BS20, BS30, TS61 and TS62. For configuration guidance, refer to the relevant documents or the online help for the HLR product.

Scenario 1
Both the local office and peer office support 2198 redundancy and fax detection. Both BICC office directions between the two offices support 2198 redundancy. The HLR has been configured to support BS20, BS30, TS61 and TS62 services.
Follow these steps to configure the MSOFTX3000, assuming that the related tables have not been configured. Step 1 Configure the Basic Local Info table.
Issue 02 (2007-06-10)
27-17
Description
Configure the information tables for the local office. Enable fax detection and redundancy support. Set the payload type to 97, the redundancy level to 2, the redundancy codec to G.711A. SET OFI: SPFAXDT=YES, SPRED=YES, REDLEVEL=L2, REDPT=97, REDCODEC=G711a; None.
Script Remark
Step 2 Configure the Codec Config table. Description Configure the codec configuration table, and add virtual redundancy codec parameters. The codec ID is set to 82, the payload type to 96, the packetization time to 5 and the clock rate to 8000. ADD CODECCFG: CODECID=82, PAYLOADTYPE=96, PKTIME=5, CLOCKRATE=8000; The payload type must not be the same as the value of 2198 redundancy payload type value in the Basic Local Info table.
Script Remark
Step 3 Configure the Office Direction table. Description Script Remark Modify the BICC office direction by setting BICC support TrFO to Yes and BICC support red to Yes. MOD OFC: ON="xxx", SUPTTRFO=YES, IFSUPPORTRED=YES; None.
Step 4 Configure the software parameter table. Description Script Remark Set bit 4 of software parameter 28 to 0, so that 3.1K audio is regarded as data call. MOD MSFP: ID=P28, MODTYPE=P1, BIT=4, BITVAL=0; Modify the software parameters so that audio services with the bearer service type of 3.1K are considered as data services.
----End Follow these steps to configure the UMG8900: Step 1 Set the codec capability.
27-18
Issue 02 (2007-06-10)
Configure the codec capability on the gateway to support NGN codec capabilities. SET CODECCAP: BN=XXX, CODEC=NGN-1; None.
Step 2 Set the TC parameters. Description Script Remark Configure the related parameters for 2198 redundancy. SET TCPARA: R2198RN = 1, R2198RNT = 99, DYNPLT = 96, G711RDT = ENABLE; In the MSOFTX3000 Codec configuration table, the Codec payload type for 2198 redundancy must be the same as the dynamic payload type in TC parameters on the MGW.
----End

This section describes measurement entities. CODEC MODIFY TIMES In the case of BICC signaling, it is the number of times that the MSC receives a request from the peer office for changing the mode to 2198 redundancy mode. CODEC MODIFY SUCCESSTIMES In the case of BICC signaling, it is the number of times that the IP bearer is successfully changed to 2198 redundancy mode. 2198 Red Times It specifies times that the intra-office IP bearer service (the TS61 Service, voice service switched over to fax service) uses the 2198 redundancy. 2198 Red Success Times It specifies times that the intra-office IP bearer service (the TS61 Service, voice service switched over to fax service) changes the codec into 2198 redundancy successfully.

None.
Issue 02 (2007-06-10)
27-19
27.8 Reference
3GPP TS 23.153, "Out of band transcoder control, V4.a.0". IETF RFC 2198, "RTP Payload for Redundant Audio Data"

Glossary
Glossary 2198 redundancy Meaning A mechanism developed based on RFC 2198, which uses voice packets to transmit data services and increases reliability by providing redundancy transmission.

Acronym/Abbreviation 3G 3GPP IETF UP Full Name The Third Generation 3rd Generation Partnership Project Internet engineering task force User Plane
27.9 FAQ
None.
27-20
Issue 02 (2007-06-10)
Contents
Contents
28 VDB Dynamic Data Backup ................................................................................................28-1
28.1 Feature Description ...................................................................................................................................28-2 28.1.1 Function Code..................................................................................................................................28-2 28.1.2 Function Definition..........................................................................................................................28-2 28.1.3 System Specification........................................................................................................................28-3 28.1.4 Service Benefits ...............................................................................................................................28-3 28.1.5 Application Scenario ........................................................................................................................28-3 28.1.6 Use Restriction.................................................................................................................................28-3 28.2 Availability ................................................................................................................................................28-4 28.2.1 Requirements for NEs......................................................................................................................28-4 28.2.2 Requirements for License ................................................................................................................28-4 28.2.3 Applicable Versions..........................................................................................................................28-4 28.3 Working Principle......................................................................................................................................28-4 28.3.1 Functions Provided by NEs..............................................................................................................28-4 28.3.2 Internal System Processing ..............................................................................................................28-5 28.3.3 External Interfaces ...........................................................................................................................28-8 28.4 Service Flow..............................................................................................................................................28-8 28.4.1 Subscriber Data Backup FLow ........................................................................................................28-8 28.4.2 Processing of Aging upon Dual-Homing Switchover ....................................................................28-14 28.4.3 MT Flow Optimization upon Dual-Homing Switchover ...............................................................28-14 28.5 Data Configuration..................................................................................................................................28-14 28.5.1 Overview........................................................................................................................................28-14 28.5.2 Data Configuration at the MSOFTX3000 Side..............................................................................28-15 28.5.3 Data Configuration at the UMG8900 Side.....................................................................................28-16 28.5.4 Example .........................................................................................................................................28-16 28.6 Service Management ...............................................................................................................................28-21 28.7 Charging and CDR ..................................................................................................................................28-22 28.8 Interaction with Other Services...............................................................................................................28-22 28.9 Reference ................................................................................................................................................28-22 28.9.1 Specifications.................................................................................................................................28-22 28.9.2 Glossary, Acronyms, and Abbreviations ........................................................................................28-23
Issue 02 (2007-06-10)
Figures
Figures
Figure 28-1 Dual-homing 1 + 1 mutual-aid networking model........................................................................28-5 Figure 28-2 Dual-homing N+1 backup networking model ..............................................................................28-6 Figure 28-3 Block diagram of dual-homing backup.........................................................................................28-6 Figure 28-4 Registering a backup task for location update ..............................................................................28-9 Figure 28-5 "Dirty" backup flow....................................................................................................................28-10 Figure 28-6 Complete backup flow ................................................................................................................28-10 Figure 28-7 Flow of location information backup.......................................................................................... 28-11 Figure 28-8 Flow of status information backup .............................................................................................28-12 Figure 28-9 Flow of authentication data backup ............................................................................................28-12 Figure 28-10 Flow of synchronous deleting backup data...............................................................................28-13
ii
Issue 02 (2007-06-10)
Tables
Tables
Table 28-1 Function code .................................................................................................................................28-2 Table 28-2 Concepts related to VDB dynamic data backup .............................................................................28-2 Table 28-3 NEs required for the VDB dynamic data backup ...........................................................................28-4 Table 28-4 Versions applicable to VDB dynamic data backup .........................................................................28-4
Issue 02 (2007-06-10)
iii
28
About This Chapter
Section 28.1 Feature Description 28.2 Availability
VDB Dynamic Data Backup
The following table lists the contents of this chapter. Describes The function code and definition of the service and the benefits of the service to carriers and mobile subscribers. The NEs required to implement the service, requirements for the license, and versions of the products applicable to the service. The functions of the NEs used to implement the service and the requirements on the networking. The flow of the service. The data configuration that must be performed at the MSOFTX3000 side and the UMG8900 side as well as the examples of data configuration. The operations that carrier and mobile subscribers must perform when the service is provided. The procedure for performing charging and generating CDRs when the service is provided. The association between the service and other services as well as the restrictions on each other. The standards and specifications with which the service complies and the glossary, abbreviations, and acronyms used in this chapter.
28.6 Service Management 28.7 Charging and CDR 28.8 Interaction with Other Services 28.9 Reference
Issue 02 (2007-06-10)
28-1

Table 28-1 lists the function code. Table 28-1 Function code Function Name Dual-homing VDB dynamic data backup Function Code WMFD-160500 WMFD-164400
28.1.2 Function Definition

The VDB dynamic backup indicates that the VLR of the active MSC server backs up subscriber data in the VDB to the VDB of the standby MSC server through M3UA links in real time in the dual-homing networking environment. After the active MSC server fails and the standby MSC server takes over the service of the active MSC server, the backed up subscriber data can be used directly. In this case, the impact of automatic recovery of subscriber data on the A/IU/C/D interface can be avoided effectively. Table 28-2 lists concepts related to this feature. Table 28-2 Concepts related to VDB dynamic data backup Concept Dual-homing Description In the networking architecture (control is separated from bearer) of R4, an MGW belongs to two MSC servers. Normally, the MGW is only registered in one MSC server. When the MSC server fails, the MGW can be registered in another MSC server and continues to provide services for subscribers managed by the MGW. The MSC server is applied in the networking architecture of R4, and the MSOFTX3000 serves as the MSC server in the application. A virtual server is also called a virtual node. It is put forward to realize the N + 1 backup mode of the MSC server (virtual Server in short). As for this mode, one server (the standby MSC server) in N + 1 mode is divided into N + 1 MSC servers logically and the MSC servers are marked through indexes. Server0 indicates the node fixedly, and other virtual Servers are disaster recovery systems of other N servers respectively. When the system is normal, the active MSC server, in contrast to disaster recovery MSC servers, processes services on the network. Also called disaster recovery MSC server, a standby MSC server is used to provide data and service backup for the active MSC server.
MSC server Virtual Server
Active MSC server Standby MSC server
28-2
Issue 02 (2007-06-10)
Concept VLR VDB
Description The visitor location register (VLR), a dynamic database. VLR database.
28.1.3 System Specification

Item Backup capacity Specification To ensure the backup capacity of a standby MSC server, the data of backup subscribers is stored by means of compression in the standby server. Each standby MSC server can store the data of 2,000,000 backup subscribers, and the whole office supports 20,000,000 backup subscribers. The VDB supports up to 200,000 subscribers. Therefore, each VDB decompresses only 200,000 subscribers and deletes excessive subscribers and subscribers of other offices. Each MSC server supports backup of 20,000,000 subscribers and takes over the service of backup subscribers in an office only.
28.1.4 Service Benefits

Beneficiary Operator Description This function helps to avoid the impact on the A/IU/C/D interface of the system after dual-homing switchover so that the dual-homing switchover can be more secure and effective. It provides more reliable assurance for remote dual-homing disaster recovery. None.
Mobile subscriber

It is applicable to all markets of the GSM and UMTS R99/R4.
28.1.6 Use Restriction

The VDB dynamic data backup function must be used with the dual-homing function in the dual-homing networking environment. It supports 1+1 mutual-aid networking, 1+1 backup networking, N+1 backup networking, and N+1 mutual-aid networking. The VDB dynamic data backup function supports switchback of subscriber data from the standby server to the original active server during dual-homing changeback. However, changeback of data in the VDB must be performed manually. For N+1 backup networking or N+1 mutual-aid networking, the standby MSC server can back up all subscriber data in the active MSC server simultaneously. When dual-homing switchover occurs, however, only the subscriber data in one active server is reserved and the
Issue 02 (2007-06-10)
28-3
subscriber data in other active MSC servers is deleted, that is, the standby server can take over the subscriber data of one active server only.
28.2 Availability
VDB Dynamic Data Backup can be and is only performed in the mutual-aid MSC/VLR. The requirements for NEs are listed in Table 28-3. Table 28-3 NEs required for the VDB dynamic data backup UE Node B RNC MSC server MGW SGSN GGSN HLR -
"" means the network element is involved.

The dual-homing feature is optional. It is enabled by License. VDB dynamic data backup is based on the dual-homing feature and serves this feature. Therefore, the dual-homing feature must be supported by the License file.

The VDMSOFTX3000 versions applicable to VDB dynamic data backup are shown in Table 28-4. Table 28-4 Versions applicable to VDB dynamic data backup Product MSC server MSOFTX3000 Applicable Version V100R005C10

28.3.1 Functions Provided by NEs
VDB dynamic backup is a backup process between mutual-aid MSCs/VLRs under dualhoming networking environment. The backup channel is the backup M3UA link between the mutual-aid MSCs/VLRs.
28-4
Issue 02 (2007-06-10)
28.3.2 Internal System Processing

The role that MSC/VLR plays varies for different dual-homing networking. VDB dynamic backup distinguishes different dual-homing roles. By the four dual-homing networking schemes, that is, 1 + 1 mutual-aid, 1 + 1 backup, N + 1 mutual-aid, and N + 1 backup, MSC servers can be classified into three roles: active MSC server, standby MSC server, and mutualaid MSC server. VDB dynamic data backup supports the above four networking schemes. Since 1 + 1 mutualaid is a special instance of N + 1 mutual-aid and 1 + 1 backup is a special instance of N + 1 backup, for the sake of simplicity, the following section analyzes two commonly used networking schemes: 1 + 1 mutual-aid model and N+1 backup model. 1+1 mutual-aid networking means dual-homing networking at MSC server layer using two MSOFTX3000s as mutual-aid, that is, each of the two MSOFTX3000s is an active MSC server and is at the same time a standby MSC server for the other MSOFTX3000. The typical networking diagram is shown in Figure 28-1. For the networking, you must configure one or two dual-homing backup link(s) between two servers in order to provide mutual data backup between two mutual-aid MSC servers. Figure 28-1 Dual-homing 1 + 1 mutual-aid networking model
MSC Server1 Heartbeat link Backup link Master Channel Slave Channel Slave Channel MSC Server2
MGW1
MGW2
MGW3
MGW4
MGW5
MGW6
N+1 backup networking means dual-homing networking at the MSC server layer using N+1 MSOFTX3000s, N of which are active and the other one is standby for these N MSOFTX3000s. The typical networking diagram is shown in Figure 28-2. In this networking scheme, each active MSC server VLR must back up user data to the standby MSC server and the standby MSC server must back up user data back to the said active MSC server after it takes over the service. For this purpose, each MSC server and the standby MSC server shall have one or two dual-homing backup link(s).
Issue 02 (2007-06-10)
28-5
Figure 28-2 Dual-homing N+1 backup networking model

MSC Server1 Hertbeaklink Backup link Node 1 MSC Server2 Heartbeaklink Backup link Node 2 MSC Server3
MGW1
MGW2
MGW3
MGW4
MGW5
MGW6
Dual-homing Active MSC Server

The active MSC server refers to the one that in normal situations takes up services in dualhoming networking. MSC server1 in Figure 28-1 and MSC server1 and MSC server3 in Figure 28-2 are called active MSC server. Because the active MSC server only processes services and does not receive backup data from other servers, all resources in VDB are used by the subscribers who are served by the active MSC server. Assume that each module of an active MSC server supports 200 thousand subscribers, and then the whole office supports 1.8 million subscribers. When subscription information of the active MSC server changes or supplementary service status changes, the active MSC server first uses high-priority backup task to inform the standby MSC server of the information change (by using Dirty flag), and then in the later backup process uses normal backup task to back up the subscriber information or supplementary services to the standby MSC server. By using high-priority backup task, the standby MSC server can sense the subscriber data change in the active MSC server, thus ensuring reliability of the backup data. The subscription information backup is shown in Figure 28-3. Figure 28-3 Block diagram of dual-homing backup
1 2 3 4
The subscription flow is as follows: 1. 2. 3. The active MSC server sends the Dirty flag to the standby MSC server. The standby MSC server acknowledges receipt. Upon receiving the acknowledgement, the active MSC server packs the subscription information, compresses it, and sends it to the backup server.
28-6
Issue 02 (2007-06-10)
4.
The backup server saves the subscriber data and acknowledges backup success.
Change of non-subscription data, such as location information, handset on/off status, and authentication data are backed up through normal backup task, where data change is directly sent to the backup server. VDB dynamic backup is built on M3UA links, which ensures backup reliability. Each backup message is confirmed by acknowledgement. If active server fails to receive backup success message from standby server, it repeats the backup task every 100s. If it still fails after five repeats, it sends backup failure alarm.
Dual-homing Standby MSC Server

The standby MSC server refers to the one that plays backup role in the 1+1 active/standby networking or N+1 active/standby networking. MSC server2 in both Figure 28-1 and Figure 28-2 is the standby MSC server. When the standby MSC server does not take over services of other offices, the local office does not process any service and all of its resources are idle. Therefore these resources can be used to save backup subscriber information. To ensure backup capacity of the backup server, the standby MSC server saves compressed subscriber data. Each module can save backup data for 2 million subscribers and the office supports 20 million subscribers. After the standby server takes over the service, subscriber data cannot be compressed. The subscriber data of the corresponding active MSC server must be decompressed. Because a VDB module supports maximum 200 thousand subscribers, each module can only decompress 100 thousand subscribers and deletes other subscribers and subscribers of other active servers. That is, each MSC server supports backup of 20 thousand subscribers but can only take over subscribers of one active server.
Dual-Homing Mutual-Aid MSC Server

Apart from processing its own services, a mutual-aid MSC server also works as a standby server for other MSC servers and is ready to take over their services at any time. In VDB dynamic data backup, mutual-aid MSC servers save not only their own subscriber data, but also the subscriber data that have been backed up from other MSC servers. When the other MSC server is down, the normal server must activate its service data configured locally. Therefore this scheme requires that the two mutual-aid MSC servers shall process subscribers no more than 1.8 million. In mutual-aid MSC servers, VDB backup data supports two storage formats: Real-time initialized or non-real-time initialized. In real-time initialized format, the MSC server decompresses and saves the backup data from the mutual-aid MSC server. In this mode, the backup data occupy resources, even the server does not take over the services of the mutual-aid MSC server. The resources occupied by backup subscribers do not affect normal services, because the capacity of mutual-aid MSC servers is the sum of the capacity of two servers. In non-real-time initialized format, the mutual-aid MSC server saves backup subscriber data in compressed format. When the server takes over the services of the mutual-aid MSC server, the backup subscriber data is decompressed and is stored in ordinary subscriber data space. This is the same as the processing in the standby MSC server. Subscriber data in non-real-time initialized format do not occupy any resource when the local office does not take over the services of the MSC server.
Issue 02 (2007-06-10)
28-7
VDB dynamic data backup supports 1+1 mutual-aid and N+1 mutual-aid networking. This is the same as dual-homing mutual-aid networking.
Real-time initialization is configured through SET DHBKPCFG. The backup method in real-time initialization is not applicable to N+1 mutual-aid. In the standby MSC, Real time initialize backup data in the Dual Home Backup Configuration table is invalid. The standby MSC saves backup subscriber data in compressed format.

None.
28.4 Service Flow

28.4.1 Subscriber Data Backup FLow
Each time subscriber information, supplementary service status, location information, and handset on/off status change or subscriber authentication set is updated, a backup operation is initiated. To avoid impact on normal traffic, VDB backup is non-real-time. When subscriber data changes, only a backup task is registered and then the server smoothly processes the backup task of each subscriber. Depending on the feature of subscriber data, the backup tasks are marked "Dirty" backup task, complete backup task, location information backup task, status information backup task, subscriber authentication set backup task, and synchronized deletion task. Figure 28-4 registers a backup task for location update flow. Figure 28-4 Registering a backup task for location update
UE--RNS A_LU_REQUEST MAP_UPDATE_LOCATION_REQ PVLR MAP_CANCEL_LOCATION
Register backup task, delete backup user data.
MSC/VLR
HLR
MAP_CANCEL_LOCATION ack MAP_INSERT_SUBSCRIBER_DATA

Register backup task, back up user's all data
MAP_INSERT_SUBSCRIBER_DATA ack A_LU_CONFIRM MAP_UPDATE_LOCATION ack
28-8
Issue 02 (2007-06-10)
1.
When HLR goes to front VLR to cancel location registration, if front MSC/VLR supports VDB dynamic backup, then the front VLR registers synchronized deletion task, deleting the backup data in its standby MSC server. When HLR inserts subscription data, VLR will register two backup tasks: "Dirty" backup task and complete backup task. "Dirty" backup is similar to real-time backup; therefore, when subscriber data changes, the standby MSC server can sense and record the change of subscriber data at once.
2.
"Dirty" Backup Flow

When subscriber location is inserted into subscription information or when subscription data changes, VLR first registers the Dirty flag and informs the standby MSC server (or mutual-aid MSC server) of the subscriber data change in real time. Figure 28-5 "Dirty" backup flow
DHBKP_DIRTY_REQ
DHBKP_DIRTY_RSP
The "dirty" backup flow is described as follows: 1. 2. The active MSC server sends a DHBKP_DIRTY_REQ message to the standby MSC server according to the registered task. Upon receiving the DHBKP_DIRTY_REQ, standby MSC server sets subscriber data to HLR_Unconfirmed and returns a DHBKP_DIRTY_RSP message, indicating backup success. Upon receiving the DHBKP_DIRTY_RSP, the active MSC server completes the "dirty" backup and continues to other backup tasks of the subscriber.
3.
Complete Backup Flow

When subscriber location update is inserted into subscription information, subscription information changes, or subscriber supplementary service status changes, VLR registers complete backup flow. Only when the Dirty flag backup flows are processed, will a complete backup flow be processed. Because complete backup message contains all backup information of that subscriber, it requires no other backup flows, unless other backup information changes.
Issue 02 (2007-06-10)
28-9
Figure 28-6 Complete backup flow

DHBKP_ALL_DATA_REQ
DHBKP_ALL_DATA_RSP
The complete backup flow is described as follows: 1. The active MSC server packs and compresses subscriber data according to pre-set data dictionary and sends the data packet to the standby MSC server through the DHBKP_ALL_DATA_REQ message. Upon receiving the backup message packet, the standby MSC server decompresses the data packet according to the data dictionary and saves the data, setting subscriber data to HLR_Confirmed and sending response, indicating backup success. (In the scenario of non-real-time initialization, subscriber data is not decompressed immediately but waits until services are taken over.) Upon receiving the response message, the active MSC server finishes complete backup and continues to process other backup tasks of the subscriber.
Data dictionary is configured through ADD/MOD/RMV/LST USRDD and SET USRDDVER. These two commands are implicit commands. Generally modifying data dictionary gives rise to fatal disaster and is not allowed. If you want to customize the backup through data dictionary, contact Huawei engineers.
2.
3.
Flow of Location Information Backup

When subscriber location information changes, the location information backup task registers. Information changes include location updates between different intra-office location areas/cells and union location update between different intra-office location areas/cells.
28-10
Issue 02 (2007-06-10)
Figure 28-7 Flow of location information backup

DHBKP_LOC_INFO_REQ
DHBKP_LOC_INFO_RSP
The flow of location information backup is described as follows: 1. The active MSC server sends subscriber location information (including location area cell number and MSC number) to the standby MSC server through a DHBKP_LOC_INFO_REQ message. Upon receiving the DHBKP_LOC_INFO_REQ, the standby MSC server saves the subscriber location information and returns a DHBKP_LOC_INFO_RSP message, indicating backup success. Upon receiving the DHBKP_LOC_INFO_RSP, the active MSC server completes location information backup and continues to process other backup tasks of the subscriber.
2.
3.
Flow of Status Information Backup

At present the status information only includes handset on/off status. Upon IMSI attach/ detach, and IMSI implicit detach, status information backup task is also registered Figure 28-8 Flow of status information backup
DHBKP_STATUS_INFO_REQ
DHBKP_STATUS_INFO_RSP
The flow of status information backup is described as follows:
Issue 02 (2007-06-10)
28-11
1.
The active MSC server sends subscriber status information (including only IMSI attach/detach status at present) to the standby MSC server through a DHBKP_STATUS_INFO_REQ message. Upon receiving the DHBKP_STATUS_INFO_REQ, the standby MSC server updates the subscriber status information and returns a DHBKP_STATUS_INFO_RSP message, indicating backup success. Upon receiving the DHBKP_STATUS_INFO_RSP, the active MSC server completes the status information backup and continues to process other backup tasks of the subscriber.
2.
3.
Flow of Authentication Data Backup

When subscriber authentication set is updated, if the configuration supports authentication set backup, the VDB registers an authentication data backup task. Whether authentication set backup is supported is configured in the Dual Home Backup Configuration table. Figure 28-9 Flow of authentication data backup
DHBKP_AUTH_SET_REQ
DHBKP_AUTH_SET_RSP
The flow of authentication data backup is described as follows: 1. 2. 3. The active MSC server sends subscriber authentication data to the standby MSC server through a DHBKP_AUTH_SET_REQ message. Upon receiving the backup message, the standby MSC server updates the subscribers authentication data and sends response message, indicating backup success. Upon receiving the response message, the active MSC server completes authentication data backup and continues to process other backup tasks of the subscriber.
Flow of Synchronous Deleting Backup Data

When the subscriber data of the active MSC server is deleted, the corresponding backup data must be deleted synchronously. The scenarios when the active MSC server deletes subscriber data include the following: CANCEL LOCATION flow. Using DEL MS, DEL HLRMS, and DEL GRPMS commands to delete VDB subscribers. Subscriber is deleted for not taking part in any activities for a long time.
28-12
Issue 02 (2007-06-10)
Subscriber data deletion due to VDB distribution parameter change will not delete the backup subscriber data. Figure 28-10 Flow of synchronous deleting backup data
DHBKP_DELETE_SUB_REQ
DHBKP_DELETE_SUB_RSP
The flow of synchronous deleting backup data is described as follows: 1. 2. The active MSC server sends a DHBKP_DELETE_SUB_REQ message to the standby MSC server. Upon receiving the synchronous deletion message, the standby MSC server deletes all backup information of subscribers and sends a DHBKP_DELETE_SUB_RSP message, indicating deletion success. Upon receiving the DHBKP_DELETE_SUB_RSP, the active MSC server stops processing of the synchronous deletion task.
3.
28.4.2 Processing of Aging upon Dual-Homing Switchover

Taking into account the fact that during the backup process there is no true real-time backup (such as SCTP link disconnect and active MSC servers sudden failure, where some of the data cannot be backed up timely to the standby MSC server), consistency between subscriber data in the standby MSC server and those in the HLR cannot be fully guaranteed. After dualhoming switchover occurs, you can set subscriber data un-reliability in batches to gradually obtain all subscriber data from HLR, so that the subscriber data between standby MSC server and HLR are consistent. This process is called aging processing. The configuration of backup subscriber aging consists of Backup user aging time(min) and Max aging percent. These two parameters are configured in Dual Home Backup Configuration table. Backup user aging time(min) refers to the time lapse between dualhoming switchover and beginning of aging processing; Max aging percent means that after un-reliable subscribers in VDB reach this percent, aging processing of the backup subscribers is suspended, until lower than this percentage.
28.4.3 MT Flow Optimization upon Dual-Homing Switchover

When a subscriber switches off the phone before dual-homing switchover and switches on the phone during the switchover, if the ON flag is not backed up to the standby MSC server and if the terminal do not repeat location update, the subscriber cannot be called for certain time (the subscriber cannot originate a call in one periodic location update period). Therefore we propose to optimize the MT flow as follows: After dual-homing switchover occurs, the standby MSC server or mutual-aid MSC server takes over the services. In all MT
Issue 02 (2007-06-10)
28-13
flows, if the called party is a backup subscriber and switches off the phone, paging is delivered. If paging fails, it is not regarded as unavailable but is processed as OFF status. For example, announcement is played as in power-off status; PRN pre-paging replies "HLR subscriber is turned off"; for short messages the system prompts that the handset of the subscriber is powered off. Next time when the subscriber is called, no more paging is made. Bit 0 of software parameter 1151 controls MT flow optimization. When bit 0 of the software parameter is set to "1", only one global paging is delivered to the backup subscriber. When bit 0 of the software parameter is set to "0", subscriber paging is processed according to the original paging control table. By default, bit 0 of the software parameter is set to "0".

28.5.1 Overview
Since this function is based on dual-homing and enhances the dual-homing function, the dual-homing function must be configured before this function is enabled. The configuration procedure is as follows: Step 1 Configure the dual-homing function. Step 2 Configure the Dual-homing Backup Function Configuration table and enable the VDB dynamic backup function. Step 3 Configure a dual-homing node to make it support backup of subscribers. Step 4 Configure backup M3UA routes for two standby offices. ----End

The configuration of VDB dynamic data backup includes the following: Configuration of the Dual-homing Backup Function Configuration table Configuration of the Dual-homing Server Node table Dual-homing backup routes The configuration procedure is as follows: Step 1 Configure the Dual-homing Backup Function Configuration table. Enable or disable the VDB dynamic data backup function. In the case that the local office supports dual-homing backup, configure the dual-homing backup function of the local office through other options, including whether to support the backup authentication set and whether to initialize the backup data in real time. The related configuration commands are as follows: Key Configuration Command SET DHBKPCFG LST DHBKPCFG Description It is used to configure the dual-homing backup function and set backup related parameters. It is used to query the configuration data of dual-homing backup.
28-14
Issue 02 (2007-06-10)
Step 2 Configure a dual-homing node and make it support backup of subscribers. Configure the backup function for a dual-homing node. All dual-homing nodes must support the backup of subscribers of the local server node through configuration. The related configuration commands are as follows: Key Configuration Command ADD SRVNODE MOD SRVNODE LST SRVNODE Description It is used to add a dual-homing node. Select Support for Backup Users of Local Server node. It is used to modify a dual-homing node. Select Support for Backup Users of Local Server node. It is used to list dual-homing nodes.
Step 3 Configure data related to an M3UA route. Configure an M3UA route and add the backup-related M3UA local entity, M3UA destination entity, M3UA link set, M3UA destination entity supplementary service, M3UA link, and M3UA route. The VDB backup function requires that M3UA links between mutual-aid MSC servers must be direct-connection links. Key Configuration Command ADD M3LE ADD M3DE ADD M3DS Description It is used to add an M3UA local entity. It is used to add an M3UA destination entity. It is used to add an M3UA destination entity supplementary service. When Network mode of ADD M3DE is set to Shared SPC, this command must be executed. It is used to add an M3UA link set. It is used to add an M3UA link. It is used to add an M3UA route.
ADD M3LKS ADD M3LNK ADD M3RT
Step 4 Configure associated dual-homing backup routes. Associate a dual-homing node with M3UA routes. One dual-homing node can be associated with two M3UA routes. To achieve higher backup performance, it is recommended to associate one dual-homing node with two M3UA routes. Key Configuration Command ADD BKPRT RMV BKPRT Description It is used to add the configuration of backup routes to the specified server. It is used to delete the configuration of backup routes to the specified server.
Issue 02 (2007-06-10)
28-15
Key Configuration Command LST BKPRT
Description It is used to list the configuration of backup routes to the specified server.
----End.

None.
28.5.4 Example
The 1 + 1 mutual-aid networking scheme is used for a dual-homing office. The two mutualaid MSC servers are MSCA and MSCB, and are configured with a dual-homing function. The signaling point codes for the domestic active network of MSCA and MSCB are 3A1106 and 3A1108 respectively. The Dual-homing Server Node table is configured.
MSCA Script Configuration

Step 1 Configure the Dual Home Backup Configuration table. Description Script Remark Set dual-homing backup configuration. Set Support dual home backup to Yes. SET DHBKPCFG: SPDHBK=YES; By default, dual-homing backup is not supported. To enable this function, the command must be executed.
Step 2 Configure the backup function for a dual-homing node in the local office. Description Script Remark Modify a dual-homing Server node. Configure the dual-homing node of the local office to support backup of subscribers. MOD SRVNODE: SN="LOCAL", DHBKPUSER=SUPPORT; By default, the system does not support backup of subscribers of the local server node.
Step 3 Configure the backup function for a mutual-aid dual-homing node.
28-16
Issue 02 (2007-06-10)
Description Script Remarks
Modify a dual-homing server node. Configure the mutual-aid dual-homing node MSCB to support backup of subscribers. MOD SRVNODE: SN="MSCB", DHBKPUSER=SUPPORT; By default, the system does not support backup of subscribers of the local server node.
Step 4 Add an M3UA local entity. Description Script Add an M3UA local entity. Set Signaling point code of local entity to 3A1106, and Local entity type to Application server. ADD M3LE: LENM="LOCAL_BAK", OPC="3A1106", LET=AS;
Step 5 Add an M3UA destination entity. Description Add an M3UA destination entity. Set Signaling point code of destination entity to 3A1108, Destination entity type to Application server, and Network mode to Shared SPC. ADD M3DE: DENM="MSCB_BAK", LENM="LOCAL_BAK", DPC="3A1108", DET=AS, NM=INCLUSIVE; Destination entity type must be set to Application server. Adjacent flag must be set to True, and Network mode must be set to Shared SPC.
Script Remarks
Step 6 Add an M3UA destination entity supplementary service. Description Add an M3UA destination entity supplementary service. Set Destination entity name to MSCB_BAK, OPC to 3A1106, and Service indicator to VDB. ADD M3DS: DSNM="VDB", DENM="MSCB_BAK", OPC="3A1106", SI=VDB; This command must be executed because Network mode of ADD M3DE is set to Shared SPC.
Script Remarks
Step 7 Add an M3UA link set between the local office and the mutual-aid office MSCB. Description Script Remarks Add an M3UA link set. Set Work mode to IPSP. ADD M3LKS: WM=IPSP; LSNM="MSCB_BAK", ADNM="MSCB_BAK",
You can configure two backup link sets to MSCB.
Step 8 Add an M3UA link between the local office and the mutual-aid office MSCB.
Issue 02 (2007-06-10)
28-17
Description Script
Add an M3UA link. Set WBSG module number to 135 and Client/Server mode to Server side. ADD M3LNK: MN=135, LNKNM="MSCB_BAK", LOCIP1="192.168.0.252", LOCPORT=7000, PEERIP1="192.168.0.253", PEERPORT=7000, CS=S, LSNM="MSCB_BAK", QoS=TOS; One or more links can be configured for an M3UA link set.
Remark
Step 9 Add an M3UA route between the local office and the mutual-aid office MSCB. Description Script Remark Add an M3UA route. ADD M3RT: RTNM="MSCB_BAK", LSNM="MSCB_BAK"; Two M3UA routes to MSCB can be configured. DENM="MSCB_BAK",
Step 10 Configure a dual-homing backup route. Description Script Remark Add the backup route configuration to the mutual-aid office MSCB. ADD BKPRT: SN="MSCB", RTNAME="MSCB_BAK"; It is recommended to add two backup routes for the destination server node to be configured.
---End.
MSCB Script Configuration

Step 1 Configure the Dual Home Backup Configuration table. Description Script Remarks Set dual-homing backup configuration. Set Support dual home backup to Yes. SET DHBKPCFG: SPDHBK=YES; By default, the system does not support dual-homing backup. To enable this function, this command must be executed.
Step 2 Configure the backup function for a dual-homing node in the local office. Description Script Modify a dual-homing server node: Make the dual-homing node in the local office support backup of subscribers through setting. MOD SRVNODE: SN="LOCAL", DHBKPUSER=SUPPORT;
28-18
Issue 02 (2007-06-10)
Remark
By default, the system does not support backup of subscribers of the local server node.
Step 3 Configure the backup function for a mutual-aid dual-homing node. Description Modify a dual-homing server node: Make the mutual-aid dual-homing node MSCB in the local office support backup of subscribers through setting. MOD SRVNODE: SN="MSCA", DHBKPUSER=SUPPORT; By default, the system does not support backup of subscribers of the local server node.
Script Remark
Step 4 Add an M3UA local entity. Description Script Add an M3UA local entity. Set Signaling point code of local entity to 3A1108 and Local entity type to Application server. ADD M3LE: LENM="LOCAL_BAK", OPC="3A1108", LET=AS;
Step 5 Add an M3UA destination entity. Description Add an M3UA destination entity. Set Signaling point code of destination entity to 3A1106, Destination entity type to Application server, and Network mode to Shared SPC. ADD M3DE: DENM="MSCA_BAK", LENM="LOCAL_BAK", DPC="3A1106", DET=AS, NM=INCLUSIVE; Destination entity type must be set to Application server. Adjacent flag must be set to True, and Network mode must be set to Shared SPC.
Script Remark
Step 6 Add an M3UA destination entity supplementary service. Description Add an M3UA destination entity supplementary service. Set Destination entity name to MSCB_BAK, OPC to 3A1108, and Service indicator to VDB. ADD M3DS: DSNM="VDB", DENM="MSCB_BAK", OPC="3A1108", SI=VDB; This command must be executed because Network mode of ADD M3DE is set to Shared SPC.
Script Remarks
Step 7 Add an M3UA link set between the local office and the mutual-aid office MSCA.
Issue 02 (2007-06-10)
28-19
Description Script Remarks
Add an M3UA link set: Set the work mode to IPSP. ADD M3LKS: WM=IPSP; LSNM="MSCA_BAK", ADNM="MSCA_BAK",
Two M3UA link sets to MSCA can be configured.
Step 8 Add an M3UA link between the local office and the mutual-aid office MSCA. Description Script Add an M3UA link. Set WBSG module number to 135 and Client/Server mode to Client side. ADD M3LNK: MN=135, LNKNM="MSCA_BAK", LOCIP1="192.168.0.253", LOCPORT=7000, PEERIP1="192.168.0.252", PEERPORT=7000, CS=C, LSNM="MSCA_BAK", QoS=TOS; One or more links can be configured for a backup link set.
Remark
Step 9 Add an M3UA route between the local office and the mutual-aid office MSCA. Description Script Remark Add an M3UA route. ADD M3RT: RTNM="MSCA_BAK", LSNM="MSCA_BAK"; Two M3UA routes to MSCA can be configured. DENM="MSCA_BAK",
Step 10 Configure a dual-homing backup route. Description Script Remark Add the backup route configuration to the mutual-aid office MSCA. ADD BKPRT: SN="MSCA", RTNAME="MSCA_BAK"; It is recommended to add two backup routes for the destination server node to be configured.
---End.

The maintenance for the VDB subscriber data backup function covers the following:
Querying Dual-Homing Backup Statistical Information

Maintenance command: DSP DHBKSTAT This command can be used to query the backup statistical information of the dual-homing node of the active MSC server and the standby MSC server.
28-20
Issue 02 (2007-06-10)
For the active MSC server, the operation result shows the progress of current backup, including the following: Number of all subscribers Number of backup subscribers Number of subscribers acknowledged by the HLR Progress percentage Subscriber data compression failures Number of complete backup subscribers For the standby MSC server, the operation result shows the number of backup subscribers who are served by the active VMSC, and the number of subscribers acknowledged by the HLR.
Forcedly Backing Up Subscribers on the Specified Server

Maintenance command: RST DHBKSTAT Enter the specified server in Server name. The specified Server can serve as a dual-homing node of an active MSC server or a standby MSC server.
Displaying Backup Status of Subscriber

Maintenance command: DSP DHBKUSR Enter a number of a subscriber based on requirements. You can view the backup status of the subscriber. If the subscriber is a backup subscriber and the backup data is not initialized in real time, the subscriber number must be set to an IMSI. Otherwise, the operation fails. If another number is selected, the system displays the error information "The subscriber does not exist" even if the subscriber exists. In the standby MSC, Real time initialize backup data is invalid. Subscriber data can be queried only through an IMSI.
Manually Setting Backup Status of Subscriber

Maintenance command: RST DHBKUSR Enter a number of a subscriber according to requirements, and you can reset the backup status of a subscriber. Back up the data of the subscriber again. This command can be executed in the active MSC server and the standby MSC server. The command can be executed in the standby MSC server after subscriber data is backed up to the VDB of the standby MSC server. If the subscriber is a backup subscriber and the backup data is not initialized in real time, the subscriber number must be set to an IMSI. Otherwise, the operation fails. If another number is selected, the system displays the error information "The subscriber does not exist" even if the subscriber exists. In the standby MSC, Real time initialize backup data is invalid. Subscriber data can be queried only through an IMSI.

None.
Issue 02 (2007-06-10)
28-21
28.8 Interaction with Other Services

None.
28.9 Reference
None.

Glossary
Glossary Duel-homing Meaning In the networking architecture (control is separated from bearer) of R4, an MGW belongs to two MSC servers. Normally, the MGW is only registered in one MSC server. When the MSC server fails, the MGW can be registered in another MSC server and continues to provide services for subscribers managed by the MGW.

Abbreviations MSC VLR VDB Full name Mobile Switching Center Visitor Location Register VLR Database
28-22
Issue 02 (2007-06-10)
Contents
Contents
29 Multi-Area Network Role-Based and Domain-Based Management Feature.............29-1
29.1 Service Description ...................................................................................................................................29-3 29.1.1 Function Code..................................................................................................................................29-3 29.1.2 Definition .........................................................................................................................................29-3 29.1.3 Standard Compliance .......................................................................................................................29-6 29.1.4 System Specifications ......................................................................................................................29-6 29.1.5 Benefits ............................................................................................................................................29-6 29.1.6 Application Scenario ........................................................................................................................29-7 29.1.7 Application Limitations....................................................................................................................29-7 29.2 Availability ................................................................................................................................................29-7 29.2.1 Requirements for NEs......................................................................................................................29-7 29.2.2 Requirements for License ................................................................................................................29-8 29.2.3 Applicable Versions..........................................................................................................................29-8 29.2.4 Others...............................................................................................................................................29-8 29.3 Working Principle......................................................................................................................................29-8 29.3.1 Functions of NEs..............................................................................................................................29-8 29.3.2 System Internal Processing ..............................................................................................................29-8 29.3.3 External Interfaces ...........................................................................................................................29-9 29.4 Service Flow..............................................................................................................................................29-9 29.5 Data Configuration..................................................................................................................................29-10 29.5.1 Overview........................................................................................................................................29-10 29.5.2 Data Configuration on the M2000 .................................................................................................29-10 29.5.3 Data Configuration on the MSOFTX3000.....................................................................................29-16 29.5.4 Data Configuration Example..........................................................................................................29-16 29.6 Service Management ...............................................................................................................................29-19 29.7 Charging and CDR ..................................................................................................................................29-19 29.8 Performance Measurement......................................................................................................................29-20 29.9 Service Interaction ..................................................................................................................................29-20 29.10 Reference...............................................................................................................................................29-20 29.10.1 Specifications...............................................................................................................................29-20 29.10.2 Acronyms and Abbreviations .......................................................................................................29-20 29.11 FAQ .......................................................................................................................................................29-20
Issue 02 (2007-06-10)
Figures
Figures
Figure 29-1 Relationship between domains and resources...............................................................................29-6 Figure 29-2 Flowchart of the role-based and domain-based management service...........................................29-9 Figure 29-3 Create Domain ............................................................................................................................ 29-11 Figure 29-4 Bind User....................................................................................................................................29-12 Figure 29-5 Bind NE ......................................................................................................................................29-13 Figure 29-6 Rename Domain .........................................................................................................................29-14 Figure 29-7 Delete Domain ............................................................................................................................29-16
ii
Issue 02 (2007-06-10)
Tables
Tables
Table 29-1 Function code .................................................................................................................................29-3 Table 29-2 Classification of resources..............................................................................................................29-3 Table 29-3 Benefits...........................................................................................................................................29-7 Table 29-4 NEs required for role-based and domain-based management feature ............................................29-7 Table 29-5 Versions applicable to role-based and domain-based management feature ....................................29-8
Issue 02 (2007-06-10)
iii
29 Multi-Area Network Role-Based and Domain-Based Management Feature
29
Multi-Area Network Role-Based and Domain-Based Management Feature
About This Chapter

The following table lists the contents of this chapter. Section 29.1 Service Description 29.2 Availability Describes The function code and definition of the service and the benefits of the service to carriers and mobile subscribers. The NEs required to implement the service, requirements for the license, and versions of the products applicable to the service. The functions of the NEs used to implement the service and the requirements on the networking. The flow of the service. The data configuration that must be performed at the MSOFTX3000 side and the UMG8900 side as well as the examples of data configuration. The operations that carrier and mobile subscribers must perform when the service is provided. The procedure for performing charging and generating CDRs when the service is provided. The influence of the service on performance measurement and the implementation of performance measurement. The association between the service and other services as well as the restrictions on each other. The standards and specifications with which the service complies and the glossary, abbreviations, and acronyms used in this chapter.
Issue 02 (2007-06-10)
29-1
Section 29.11 FAQ
29-2
Issue 02 (2007-06-10)

The function code is listed in Table 29-1. Table 29-1 Function code Name Multi-area network role-based and domain-based management feature Code WMFD-122400
29.1.2 Definition
The role-based and domain-based management feature assigns different operation authority to different operators through domains, hence controlling the operator's operations on the system resources (for example, running ADD/MOD/RMV/LST). The concepts related to the role-based and domain-based management feature are resources, domains, operators, and relationship between domain and resource.
The role-based and domain-based feature is implemented to meet the requirement of multi-area network management. Therefore, the feature is called multi-area network role-based and domain-based management.
Resources
Resources are physical entities or logical entities used by the system, such as office directions, MSC, signaling points, office direction number, route numbers, number segments, trunk circuits, and MGW. Resources are classified into private domain resources, non-domain resources, and public domain resources, as listed in Table 29-2. Table 29-2 Classification of resources Private Domain Resources Call source code Media gateway configuration Media gateway maintenance H248 link configuration H248 link maintenance Inter-gateway TDM circuit connection Inter-gateway TDM circuit Non-Domain Resources TST NMA All commands of BAM (including but not limited to alarm management, performance measurement, and configuration rollback). Subscriber maintenance License management Public Domain Resources Resources except for private domain resources and nondomain resource are public domain resources.
Issue 02 (2007-06-10)
29-3
Private Domain Resources maintenance Inter-gateway path information Inter-gateway media connection M2UA M3UA IUA DSS1 signaling MTP signaling ATM signaling SCCP signaling BICC protocol Office direction Route and sub-route Route analysis Office direction CALLGAP Trunk group (except trunk group bearer configuration), trunk circuit BSC management, RNC management Roaming management Handover management Paging control Location area management Number analysis management (except TST NMA, protocol cause value conversion, and CIC configuration) Subscriber service attribute index Subscriber integrated service information Subscriber network information ISDN user configuration IMSI GT
Non-Domain Resources Board loading Maximum tuple number Timer management Patch management
Public Domain Resources
Domain
A domain is a set of resources. Domains are classified into public domains and private domains. An instance of a resource can belong to the public domain or a private domain, or
29-4
Issue 02 (2007-06-10)
neither the public domain nor a private domain. The instance cannot belong to multiple domains. A domain is classified into the following: Public domain The public domain exists by default, and its corresponding domain index is 0 and domain name is "PUBLIC". The public domain cannot be added, deleted, or modified. Resources without requirement for authority-base domain-based management belong to the public domain by default. Private domain A private domain is added by administrators on the M2000. The private domain is numbered from 1. ADD/RMV/MOD/LST commands are available to operators.
Operators
The operators of the MSOFTX3000 are classified into the following: Administrator Operator User Guest Custom The domain users of the M2000 are classified into the following: Administrator Operator Guest You can add a local operator on the MSOFTX3000 LMT by running ADD OP, and can also add a domain operator on the M2000 client. On the M2000 client, you can assign domains to which each operator belongs. An operator can belong to the public domain or a private domain. An operator belongs to only one domain and a domain can have multiple operators. The domain is an attribute of the operators. You can modify the domain attributes of the operators. Operators without a specified domain belong to the public domain by default. An operator's operation authority on a domain is classified into full control and read-only. Full control includes modify and read rights. Modify means to modify static attributes and dynamic attributes. Modifying static attributes means to add, delete, and modify static data. Modifying dynamic attributes refers to maintenance operations that change host status, such as activating, deactivating, and blocking. Read-only right includes query (LST and DSP operations) and reference.
You can add a domain before adding an operator, or add an operator before adding a domain. When no domain is specified for a new operator, that operator belongs to the public domain by default.
Relationship Between Domains, Resources and Operators

The relationship between resources and domains are described as follows: An operator who has proper authority can set domain attributes for a resource.
Issue 02 (2007-06-10)
29-5
If an operator has no authority to specify the domain attributes of a resource, the resource added by the operator automatically belongs to the domain of the operator. In principle, public domain operators have full control authority on global resources including public domain resources and private domain resources. Their operations on the resources only depend on the command execution authority of the operators (existing command group authority of the operators). Private domain operators have read-only authority on public domain resources and other private domain resources, and have full control authority on resources in the domain to which the operators belong. A super administrator belongs to the public domain by default. You are not allowed to assign a super administrator to a private domain. The relationship between domains and resources is shown in Figure 29-1. Figure 29-1 Relationship between domains and resources
Public domain Private domain 3
Resources Private domain 1
Private domain 2
Private domain n

None.

None.
29.1.5 Benefits
The benefits are listed in Table 29-3.
29-6
Issue 02 (2007-06-10)
Table 29-3 Benefits Beneficiary Carrier Description Role-based and domain-based management provides integrated maintenance management for carriers. It is applicable to provincial level maintenance center or higher maintenance center for their uniform scheduling and uniform configuration of the resources. Role-based and domain-based management provides control of operator authority, control of resources, enhances system reliability and security from the M2000. When a new operator account is added on the M2000, the domain of that account can be specified. The operations available to that login operator are strictly controlled within the specified domain. The operator cannot modify or delete resources in other domains. The operator can only reference or query. Operators in public domain can perform adding, deleting, modifying, and querying operations. This means that when allocating authority and domain from the M2000 to operators, you must be careful when assigning public domain attribute. Subscriber None.

The service is applicable to GSM and UMTSR99/R4 networks. This service is used in mobile communication networks, where all network elements (NEs) are managed by network management system in role-based and domain-based mode.

None.
29.2 Availability
Role-based and domain-based management feature requires MSC server and M2000. The NEs required for this feature is listed in Table 29-4. Table 29-4 NEs required for role-based and domain-based management feature MS/ UE BTS/ NodeB BSC/ RNC M2000 MSC Server MGW SGSN GGSN HLR -
Issue 02 (2007-06-10)
29-7
"" indicates the NE is involved in this function.

Role-based and domain-based management feature is a basic feature of Huawei GSM/UMTS core network. This feature does not require a license.

The versions of Huawei UMTS CS products applicable to role-based and domain-based management feature are listed in Table 29-5. Table 29-5 Versions applicable to role-based and domain-based management feature Product MSC server MSOFTX3000 Applicable Version V100R005C10
29.2.4 Others
None.

The M2000 and MSOFTX3000 provide the following functions: M2000 administrators perform role-based and domain-based management and assign operators to domains on the M2000 client. The administrators can add, delete, modify, and query domains through the menu of the M2000 client. The administrators can assign an operator to a domain. The administrators can also modify the domain to which the operator belongs. On the MSOFTX3000, you cannot add, delete, or modify domains or specify an operator's domain information. However, a domain operator can query the domain information by running LST DOMAIN. On the MSOFTX3000, a domain operator cannot query the operator information by running LST OP. That is, when the operator runs LST OP, the MSOFTX3000 prompts operation failure. On the MSOFTX3000, local operators can query operator information by running LST OP. However, the query result is local operator information.
29.3.2 System Internal Processing

Multi-area network role-based and domain-based management is implemented in the network management system (NMS). Its basic idea is that the NMS assigns specified domain authority to the operators of each MSOFTX3000. This facilitates resource management, such as office directions, MSC, and signaling points. In this way, the operators can operate only resources within their own domain.
29-8
Issue 02 (2007-06-10)
Resources are used in the principle of "Creator owns". The ownership and operation authority of a resource are marked by domain. The resources created by an operator belong to the domain of that operator. All operations on resources must pass the match check between the domain authority of the operator and the domain of the resource. If the operator has no authority to access the domain, the operation cannot proceed.

None.
29.4 Service Flow

Role-based and domain-based management service flow is shown in Figure 29-2. Figure 29-2 Flowchart of the role-based and domain-based management service
M2000/LMT
BAM
Add/MOD/LST/RMV domains Domain information updated in the database Command execution result
Set operator's domain attribute ADD OP/MOD OP Operator and domain information updated in database
Command execution result
Resource operation command Authentication according to match between operator domain and resource domain authority Command execution result
The message interaction for role-based and domain-based management is as follows:
Issue 02 (2007-06-10)
29-9
1.
On the M2000 client, a user runs a domain operation command such as ADD/RMV/MOD/LST. The domain information is saved in the BAM database, not in the host. The command execution result is returned. On the M2000 client, the user adds an operator, and specifies user groups, NE users, rights, NEs, rules, and domains for the operator. The command execution result is returned. The user logs in to the MSOFTX3000 LMT as the domain operator. On the MSOFTX3000, the user can run a configuration command or a maintenance command. The MSOFTX3000 checks whether the domain user that runs a MOD or RMV command has authority to perform operations on the domain. For public domain resources, the BAM checks whether the operator that runs a MOD or RMV command belongs to a private domain. If yes, the MSOFTX3000 does not run the command. For private domain resources, the MSOFTX3000 checks whether the operator belongs to the public domain. If yes, the MSOFTX3000 runs the command. If the operator belongs to a private domain, the MSOFTX3000 checks whether the domain to which the operator belongs is the same as the domain to which the resources belong. If the domain is the same, the MSOFTX3000 runs the command; otherwise, the MSOFTX3000 does not run the command.
The system does not perform domain authority matching check for commands such as ADD.
2. 3. 4. 5.
6.
The database returns the execution result.

29.5.1 Overview
To implement this service, configure resources on the MSOFTX3000 and perform domain management on the M2000 Client.
29.5.2 Data Configuration on the M2000

Adding Users
Log in to the M2000 Client as an administrator, and then perform the following steps: Step 1 Choose System > Security Management on the M2000 Client. Step 2 In the Security Management navigation tree, right-click User, and then choose Add. Step 3 An Add User dialog box is displayed. In the Detail tab, enter user information such as name and password. In the User Groups tab, select the user group to which the user belongs. In the NE Users tab, select NE User. In the Rights tab, select Physical Root. In the NE tab, choose an NE type from the NE Type drop-down list box and select Command Group. In the Rules tab, select command groups. Step 4 Click OK. ----End
29-10
Issue 02 (2007-06-10)
Adding Local Network Domains

One MSC server can manage more than one local network. User management is based on the local network. The operations on local networks do not affect each other. The users in the local network can set and view information of only the local network. After you add a local network domain, and specify users or NEs to the domain, users can perform operations on resources in the domain. To add a local network domain, perform the following steps: Step 1 Choose Configuration > Domain Management. Step 2 In the navigation tree on the left side, right-click the Domain node, and then choose Create. A Create Domain dialog box is displayed as shown in Figure 29-3. Step 3 In the Please Input Domain Name: text box, enter the local network domain name.
The domain name can contain 130 characters. The system does not support any special character except an underline. You can select NEs and users under NE List and User List to bind them to the local network domain. In this manner, users can perform operations on data of the NEs.
Step 4 Click OK or Apply. The added domain is displayed in the Domain navigation tree on the left side and under Domain List on the right side. Figure 29-3 Create Domain
----End
Issue 02 (2007-06-10)
29-11
Managing Users in the Local Network Domain

Users in the local network domain can perform operations on resources in the domain. Through managing users in the local network domain, you can bind users to a domain. Then the users can perform operations on resources in the domain. To manage the users in the local network domain, perform the following steps: Step 1 Choose Configuration > Domain Management. Step 2 Select a domain under the Domain node in the navigation tree on the left side, or select a user under User List. Right-click the domain or the user and choose Bind User, or click Bind User. A Bind User dialog box is displayed as shown in Figure 29-4. Step 3 Under User List, select or clear users that are to be bound to the domain. Step 4 Click OK. Figure 29-4 Bind User
----End
Managing NEs in the Local Network Domain

Managing NEs in the local network domain means to assign data of the NEs to a domain so that the users in the local network domain can perform operations on resources in the domain. Therefore, through managing NEs in the local network domain, the users in the local network domain can perform operations on data of the NEs.
29-12
Issue 02 (2007-06-10)
Before managing NEs in the local network domain, ensure that the NEs added to or removed from a domain are connected to the M2000. To manage NEs in the local network domain, perform the following steps: Step 1 Choose Configuration > Domain Management. Step 2 Select a domain under the Domain node in the navigation tree on the left side or under NE List. Right-click the domain and choose Bind NE, or click Bind NE. A Bind NE dialog box is displayed as shown in Figure 29-5.
If the NEs are not connected to the M2000, the NEs cannot be bound to the domain.
Step 3 Under NE List, select or clear NEs that are to be bound to the domain. Step 4 Click OK. Figure 29-5 Bind NE
----End
Modifying Local Network Domain Names

Modifying local network domain names means to modify operation authority of users in the local network domain. After you perform synchronization operations, the users can perform operations on resources in the domain. To modify a local network domain name, perform the following steps: Step 1 Choose Configuration > Domain Management.
Issue 02 (2007-06-10)
29-13
Step 2 Modify the domain name with one of the following methods: Method 1 1. 2. 3. 4. 1. 2. 3. 4. In the Domain navigation tree on the left side, select a domain. Right-click the domain and choose Rename. A Rename Domain dialog box is displayed as shown in Figure 29-6. In the Please Input Domain Name: text box, enter a new name. Click OK. Method 2 Under Domain List on the right side, select a domain. Right-click the domain and choose Rename, or click Rename. A Rename Domain dialog box is displayed as shown in Figure 29-6. In the Please Input Domain Name: text box, enter a new name. Click OK.
If the NEs in the domain are not connected to the M2000, after you modify the local network domain name, the data of the M2000 is not the same as that of the NEs. After the NEs are connected to the M2000, select the NE whose Synchronized State is Different under NE List. Right-click the NE and choose Synchronize. Then the domain name on the M2000 is the same as that on the NE.
Figure 29-6 Rename Domain
----End
29-14
Issue 02 (2007-06-10)
Synchronizing Domain Information of the Local MSOFTX3000

When the domain name on the M2000 is not the same as that on the MSOFTX3000, the domain users of the MSOFTX3000 do not have operation authority. In this case, to ensure that the domain users have operation authority, synchronize domain information of the local MSOFTX3000. To synchronize domain information of the local MSOFTX3000, perform the following steps: Step 1 Choose Configuration > Domain Management. Step 2 In the navigation tree on the left side, select the Domain node. Under NE List on the right side, select the MSOFTX3000 whose Synchronized State is Different. Step 3 Right-click the MSOFTX3000 and choose Synchronize, or click Synchronize. ----End If the MSOFTX3000 is connected to the M2000, Synchronized State of the MSOFTX3000 changes to Accordant; otherwise, Synchronized State of the MSOFTX3000 is still Different.
Deleting Local Network Domains

If you do not need a local network domain, delete the domain. If a domain is deleted, users in the domain become global users, and the resources that are bound to the NEs in the local network domain become public resources. To delete a local network domain, perform the following steps: Step 1 Choose Configuration > Domain Management. Step 2 Delete the domain with one of the following methods: Method 1 1. 2. In the navigation tree on the left side, select a domain under the Domain node. Right-click the domain and choose Delete as shown in Figure 29-7. The domain is deleted automatically. Method 2 1. 2. Under Domain List on the right side, select a domain. Right-click the domain and choose Delete as shown in Figure 29-7. You can also click Delete. The domain is deleted automatically.
Issue 02 (2007-06-10)
29-15
Figure 29-7 Delete Domain
----End
If the NEs in the domain are not connected to the M2000, the domain cannot be deleted.
Deleting Users
Log in to the M2000 as an administrator. To delete a user, perform the following steps: Step 1 On the M2000 Client, choose System > Security Management. Step 2 Select a user under the User node in the navigation tree on the left side or in the detail list on the right side. Right-click the user and choose Delete. ----End

When adding resources, the domain attributes of the resource must be configured to specify the relationship between a resource and a domain.

This section considers an operator USER01 in the private domain DOMAIN01 as an example.
29-16
Issue 02 (2007-06-10)
Step 1 On the M2000, add an operator named USER01 and a domain named DOMAIN01, and bind the operator to the domain. For details, see section 29.5.2 "Data Configuration on the M2000." Description Script Remark On the M2000, add an operator named USER01 and a domain named DOMAIN01, and bind the operator to the domain. For details, see section 29.5.2 "Data Configuration on the M2000." The operation is successful.
Step 2 Log in to the MSOFTX3000 LMT as USER01. Step 3 On the MSOFTX3000 LMT, run ADD CNACLD and set Domain to PUBLIC. Description Script Remark On the MSOFTX3000 LMT, run ADD CNACLD and set Domain to PUBLIC. ADD CNACLD: PFX=K'13907283, CSTP=NEW, MINL=5, MAXL=32, DMNAME="PUBLIC"; The operation fails. The reason is that the operator USER01 of the private domain DOMAIN01 cannot add a call prefix with a PUBLIC domain attribute.
Step 4 On the MSOFTX3000 LMT, run ADD CNACLD and set Domain to DOMAIN02. Description Script Remark On the MSOFTX3000 LMT, run ADD CNACLD and set Domain to DOMAIN02. ADD CNACLD: PFX=K'13907283, CSTP=NEW, MINL=5, MAXL=32, DMNAME="DOMAIN02"; The operation fails. The reason is that the operator of the private domain DOMAIN01 cannot add a call prefix with a DOMAIN02 domain attribute.
Step 5 On the MSOFTX3000 LMT, run ADD CNACLD and set Domain to DOMAIN01. Description Script Remark On the MSOFTX3000 LMT, run ADD CNACLD and set Domain to DOMAIN01. ADD CNACLD: PFX=K'13907283, CSTP=NEW, MINL=5, MAXL=32, DMNAME="DOMAIN01"; The operation is successful.
Step 6 On the MSOFTX3000 LMT, run ADD CNACLD and set Domain to DOMAIN03 (not exists).
Issue 02 (2007-06-10)
29-17
On the MSOFTX3000 LMT, run ADD CNACLD and set Domain to DOMAIN03. ADD CNACLD: PFX=K'13907283, CSTP=NEW, MINL=5, MAXL=32, DMNAME="DOMAIN03"; The operation fails. The reason is that the operator of the private domain DOMAIN01 cannot add a call prefix of the domain that does not exist.
Step 7 On the MSOFTX3000 LMT, run ADD CNACLD and do not set Domain. Description Script Remark On the MSOFTX3000 LMT, run ADD CNACLD and do not set Domain. ADD CNACLD: PFX=K'13907285, CSTP=NEW, MINL=5, MAXL=32; The operation is successful. If Domain is not set, the MSOFTX3000 regards the domain to which the operator belongs as the domain attribute of the call prefix.
Step 8 On the MSOFTX3000 LMT, run MOD CNACLD and set Domain to PUBLIC. Description Script Remark On the MSOFTX3000 LMT, run MOD CNACLD and set Domain to PUBLIC. MOD CNACLD: P=0, PFX=K'12345678, DMNAME="PUBLIC"; The operation fails. The reason is that the operator of the private domain cannot modify public domain resources.
Step 9 On the MSOFTX3000 LMT, run MOD CNACLD and set Domain to DOMAIN02. Description Script Remark On the MSOFTX3000 LMT, run MOD CNACLD and set Domain to DOMAIN02. MOD CNACLD: P=0, PFX=K'13907287, DMNAME="DOMAIN02"; The operation fails. The reason is that the operator USER01 of the private domain DOMAIN01 cannot modify the domain attribute of the specified resource to another private domain DOMAIN02.
Step 10 On the MSOFTX3000 LMT, run MOD CNACLD and set Domain to DOMAIN01. Description Script Remark On the MSOFTX3000 LMT, run MOD CNACLD and set Domain to DOMAIN01. MOD CNACLD: P=0, PFX=K'13907287, DMNAME="DOMAIN01"; The operation is successful.
29-18
Issue 02 (2007-06-10)
Step 11 On the MSOFTX3000 LMT, log in as USER02 who belongs to DOMAIN02. Step 12 On the MSOFTX3000 LMT, run RMV CNACLD. Description Script Remark On the MSOFTX3000 LMT, run RMV CNACLD and set Call prefix to 13907285. The call prefix 13907285 belongs to DOMAIN01. RMV CNACLD: PFX=K'13907285; The operation fails. The reason is that the operator USER02 of the domain DOMAIN02 cannot remove the call prefix of the private domain DOMAIN01.
Step 13 On the MSOFTX3000 LMT, run RMV CNACLD. Description Script Remark On the MSOFTX3000 LMT, run RMV CNACLD and set Call prefix to 12345678. The call prefix 12345678 belongs to the PUBLIC domain. RMV CNACLD: PFX=K'12345678; The operation fails. The reason is that the operator USER02 of the domain DOMAIN02 cannot remove the call prefix of the PUBLIC domain.
Step 14 On the MSOFTX3000 LMT, run RMV CNACLD. Description Script Remark On the MSOFTX3000 LMT, run RMV CNACLD and set Call prefix to 13908625. The call prefix 13908625 belongs to the DOMAIN02 domain. RMV CNACLD: PFX=K'13908625; The operation is successful. The reason is that the operator USER02 of the domain DOMAIN02 can remove the call prefix of the domain DOMAIN02.
----End

None.

None.
Issue 02 (2007-06-10)
29-19

None.

None.
29.10 Reference
None.

Acronym/Abbreviation BICC ISDN IUA M2UA M3UA MSISDN TDM UMTS Full Name Bearer Independent Call Control Protocol Integrated Services Digital Network ISDN Q.921-User Adaptation Layer MTP2 User Adapter MTP3 User Adapter Mobile Station International ISDN Number Time Division Multiplex Universal Mobile Telecommunication System
29.11 FAQ
None.
29-20
Issue 02 (2007-06-10)
Contents
Contents
30 Alarm for Malicious Short Messages .................................................................................30-1
30.1 Service Description ...................................................................................................................................30-2 30.1.1 Function Code..................................................................................................................................30-2 30.1.2 Definition .........................................................................................................................................30-2 30.1.3 Standard Compliance .......................................................................................................................30-2 30.1.4 System Specifications ......................................................................................................................30-2 30.1.5 Benefits ............................................................................................................................................30-2 30.1.6 Application Scenario ........................................................................................................................30-2 30.1.7 Application Limitations....................................................................................................................30-3 30.2 Availability ................................................................................................................................................30-3 30.2.1 Requirements for NEs......................................................................................................................30-3 30.2.2 Requirements for License ................................................................................................................30-3 30.2.3 Applicable Versions..........................................................................................................................30-3 30.2.4 Others...............................................................................................................................................30-4 30.3 Working Principle......................................................................................................................................30-4 30.3.1 Functions of the NEs........................................................................................................................30-4 30.3.2 Internal Processing of the System ....................................................................................................30-4 30.3.3 External Interfaces ...........................................................................................................................30-5 30.4 Service Flow..............................................................................................................................................30-5 30.5 Data Configuration....................................................................................................................................30-7 30.5.1 Overview..........................................................................................................................................30-7 30.5.2 Data Configuration at the MSOFTX3000 Side................................................................................30-7 30.5.3 Data Configuration at the UMG8900 Side.......................................................................................30-8 30.5.4 Data Configuration Examples ..........................................................................................................30-8 30.5.5 Data Table Relevant to the Alarm for Malicious Short Messages....................................................30-9 30.6 Service Management .................................................................................................................................30-9 30.7 Service Interaction ....................................................................................................................................30-9
Issue 02 (2007-06-10)
Figures
Figures
Figure 30-1 Processing of the NEs for the alarm for malicious short messages service ..................................30-5 Figure 30-2 Process of the alarm for malicious short messages.......................................................................30-6
ii
Issue 02 (2007-06-10)
Tables
Tables
Table 30-1 Function code of the alarm for malicious short messages function ................................................30-2 Table 30-2 Benefits of the alarm for malicious short messages function .........................................................30-2 Table 30-3 NEs required to implement the alarm for malicious short messages ..............................................30-3 Table 30-4 Versions of the Huawei CS products that support the alarm for malicious short messages ...........30-3 Table 30-5 Commands involved in the alarm for malicious short messages ....................................................30-7
Issue 02 (2007-06-10)
iii
30 Alarm for Malicious Short Messages
30
Alarm for Malicious Short Messages
About This Chapter

The following table lists the contents of this chapter. Section 30.1 Service Description 30.2 Availability Describes The function code and definition of the service and the benefits of the service to carriers and mobile subscribers. The NEs required to implement the service, requirements for the license, and versions of the products applicable to the service. The functions of the NEs used to implement the service and the requirements on the networking. The flow of the service. The data configuration that must be performed at the MSOFTX3000 side and the UMG8900 side as well as the examples of data configuration. The operations that carrier and mobile subscribers must perform when the service is provided. The association between the service and other services as well as the restrictions on each other.
30.6 Service Management 30.7 Service Interaction
Issue 02 (2007-06-10)
30-1

Table 30-1 lists the function code of the alarm for malicious short messages function. Table 30-1 Function code of the alarm for malicious short messages function Function name Alarm for malicious short messages Function code WMFD-121600
30.1.2 Definition
A malicious short message subscriber refers to the one who sends more short messages than the preset threshold in a certain period. The function, alarm for malicious short messages, enables the system to discriminate malicious short message subscribers by means of alarm according to requirements of carriers. Based on malicious short message alarms, carriers take corresponding measures on the malicious short message subscribers.

None.

None.
30.1.5 Benefits
Table 30-2 lists the benefits of the alarm for malicious short messages function. Table 30-2 Benefits of the alarm for malicious short messages function Beneficiary Carriers Description Reduce interference of malicious short messages on the network so as to provide better quality of service (QoS) to subscribers and reduce complaints against harassing short messages. Mitigate harassment of malicious short messages on mobile subscribers.
Mobile subscriber

This feature is applicable to all the markets of the GSM and UMTS.
30-2
Issue 02 (2007-06-10)
It is a basic feature of the MSOFTX3000. Carriers can use it based on actual conditions. For example, if some subscribers use tools to send a lot of advertising or harassing short messages to mobile subscribers in the network, the customer satisfaction will be affected. In this case, carriers can use this feature to find out those subscribers based on alarms, and take measures to reduce or put an end to such actions to improve customer satisfaction.

The MSOFTX3000V100R005C10 and later versions support this feature. There is no specific restriction. Alarms can be generated for any subscriber sending malicious short messages (without distinguishing pre-paid subscribers from post-paid subscribers).
30.2 Availability
Table 30-3 lists the network elements (NEs) required to implement the alarm for malicious short messages. Table 30-3 NEs required to implement the alarm for malicious short messages MS/ UE BTS/ NodeB BSC/ RNC MSC Server MGW SGSN VLR SMC HLR
"" indicates that the NE is required for the function.

The alarm for malicious short messages is a basic feature of HUAWEI GSM/ UMTS CN. It is available for the subscribers without obtaining the License.

Table 30-4 lists the versions of the Huawei CS products that support the alarm for malicious short messages. Table 30-4 Versions of the Huawei CS products that support the alarm for malicious short messages Product MSC server MGW MSOFTX3000 UMG8900 Applicable Version V100R005C10 and later versions V200R002 and later versions
Issue 02 (2007-06-10)
30-3
30.2.4 Others
None.

This section describes the functions implemented by the NEs. MSC The Mobile SoftSwitch Center (MSC) transfers the short message, which is sent from the mobile station (MS) through the Radio Access Network (RAN) subsystem, to the corresponding short message center (SMC). If the MSC is configured with the alarm for malicious short messages function, it distinguishes the malicious short messages through alarms when the number of short messages sent by the subscriber exceeds the preset threshold. When the MSC receives a short message delivered by the SMC, it queries the related route information and subscriber information and delivers the information to the subscriber through the RAN subsystem. VLR The visitor location register (VLR) performs the authentication management function before the SMC sends a short message to the subscriber. It also provides the route information for the MSC when the SMC delivers a short message. HLR The home location register (HLR) provides the SMC with the information of the MSC where the subscriber visits upon receiving the request from the SMC before a short message delivery. It also provides the authentication vector set for the MSC when the VLR does not store the authentication vector set if the authentication is required. SMC The SMC stores and transfers the short messages.

The alarm for malicious short messages function is implemented in the short message sending process. Figure 30-1 shows the processing of the NEs for the alarm for malicious short messages function.
30-4
Issue 02 (2007-06-10)
Figure 30-1 Processing of the NEs for the alarm for malicious short messages service
The process is as follows: 1. 2. 3. Subscriber A sends a short message to the RAN. The RAN sends the short message to the MSC/VLR through the A/Iu interface. The MSC/VLR checks whether to enable the alarm for malicious short messages function. If the function is disabled, the original short message sending process proceeds. If the function is enabled, the process proceeds with 4. 4. The MSC/VLR checks whether the subscriber subscribe the malicious short messages function. (For details, refer to 30.4 "Service Flow.") If the subscriber sends malicious short messages, the MSC/VLR generates the alarm and reports it to the alarm console. The short message sending process proceeds.

None.
30.4 Service Flow

The alarm for malicious short messages function is implemented in the short message sending process. Figure 30-2 shows the process of the alarm for malicious short messages.
Issue 02 (2007-06-10)
30-5
Figure 30-2 Process of the alarm for malicious short messages

Subscriber A sends a short message
The MSC sends a request to the VLR for subscriber data The MSC receives the response of the subscriber data request from the VLR No
The MSC decides whether to enable the alarm for malicious short messages
The short message sending process proceeds
Yes
No Time of sending the current short message - Time of sending the first short message > Time cost on statistics of malicious short messages Yes The VLR restarts to count the sent short messages Yes No
No Number of the sent short messages > Alarm threshold for malicious short messages
Whether the MSC sends an alarm for malicious short messages Yes
The MSC sends an alarm for malicious short messages The original short message sending process proceeds
The VLR counts the number of short messages; the MSC does not send an alarm for malicious short messages
The process is as follows: 1. 2. 3. 4. Subscriber A sends a short message request to the MSC through the RAN. The MSC sends a request to the VLR for subscriber data after it receives the short message request. The VLR sends a response of subscriber data request to the MSC. The MSC decides whether to enable the alarm for malicious short messages function. If the function is disabled, the original short message sending process proceeds. If the function is enabled, the process proceeds with 5. 5. The VLR checks whether the time cost on accumulative measurement of short messages originated by the subscriber exceeds the value of the parameter Original short message statistic timer(sec). If yes, the VLR restarts to count the short messages originated by the subscriber. If no, the process proceeds with 6. 6. The VLR checks whether the number of the sent short messages exceeds the alarm threshold of the malicious messages.
30-6
Issue 02 (2007-06-10)
If yes, the process proceeds with 7. If no, the process proceeds with 8. 7. The VLR checks whether an alarm for malicious messages is sent for the subscriber. If yes, the process proceeds with 8. If no, the MSC sends an alarm for malicious messages of the subscriber. 8. The VLR proceeds counting the number of short messages. The MSC does not send an alarm for malicious messages. The original short message sending process proceeds.

30.5.1 Overview
Data must be configured only on the MSOFTX3000 for the alarm for malicious short message function.

On the MSOFTX3000, only the VLR Configuration Data table must be modified. Table 305 lists the related commands. Table 30-5 Commands involved in the alarm for malicious short messages No. 1 2 Action Run the command ADD VLRCFG to add the configuration of VLR (if there is no data for the configuration of VLR). Run the command MOD VLRCFG to modify the configuration of VLR. Turn on or turn off the switch of the alarm for malicious short messages and set statistical duration for originating short messages and the alarm threshold for malicious short messages. Run the command LST VLRCFG to query the setting of the current alarm for malicious short messages.
Configure the following parameters for the VLR Configuration Data table: Hostility short message alarm switch It is the switch of the alarm for malicious short messages. This parameter is used to set whether the office supports the alarm for malicious short messages. When the switch is off, the office does not support this function. When the switch is on, the VLR scans all subscribers in the office and resets alarm data for each subscriber. The data of malicious short message alarm includes the time when the first short message is originated, number of accumulated originating short messages and the alarm flag for malicious short messages. When resetting data of malicious short message alarm, the system sets the time when the first short message is originated to "0", number of originating short messages to "0" and the alarm flag for malicious short messages to "no alarm". Original short message statistic timer(sec)
Issue 02 (2007-06-10)
30-7
It specifies the statistical duration of originated short messages. This parameter is used to set the length of the time required by the system for collecting statistics of originating short messages. The start time is the time when the first short message is originated, and the end time is the time when the current short message is sent. After receiving the statistics sent from the MSOFTX3000, the VLR makes the following judgment: If the difference between the end time and the start time is less than the value of this parameter, the VLR checks whether the number of accumulated short messages exceeds the alarm threshold of malicious short message. If not, the VLR does not send an alarm and continues to count short messages. If yes, the VLR checks whether the alarm for malicious short messages is sent for the subscriber. If not, the VLR sends an alarm. Otherwise, the VLR continues to count short messages instead of sending the alarm. If the difference between the end time and the start time is greater than the value of this parameter, the system restarts to count the short messages. Hostility short message alarm threshold It specifies the alarm threshold of malicious short messages. This parameter is used to set the number of short messages that the subscriber is allowed to originate within the statistical duration of originated short messages. If the number of accumulated short messages sent by a subscriber exceeds the preset alarm threshold and the system does not send an alarm for malicious short messages, the system sends an alarm for malicious short messages.

For this feature, no data need be configured on the UMG8900.

Enable this function in the local office and set the parameter Original short message statistic timer(sec) to 3600 and Hostility short message alarm threshold to 1000. If a subscriber sends more than 1000 short messages within 3600 seconds and the system does not send any alarm for malicious short message for the subscriber, the alarm for malicious short message appears on the alarm system.
Step 1 Add the configuration of VLR. Description Script Remarks Add the configuration of VLR. Set the maximum number of subscribers to 50000 and the mobile country code (MCC) to 460. ADD VLRCFG: MAXUSR=50000, MCC=K'460; The maximum number of subscribers and the MCC are mandatory for configuration of VLR. If there is no special requirement, use default values for other parameters. This step is optional. If the system has executed this step (check through the command LST VLRCFG), execute step 2 directly.
Step 2 Modify the configuration of VLR and enable the local office to support this feature by setting.
30-8
Issue 02 (2007-06-10)
Description
Set the configuration data of VLR. Turn on the switch of the alarm for malicious short messages and set the statistical duration of malicious short messages to 3600 seconds and the alarm threshold for malicious short messages to 1000. MOD VLRCFG: SMALM=OPEN, SMTIMER=3600, SMCOUNT=1000; The specific value is based on requirements of the carrier.
Script Remarks
Step 3 Query the configuration of VLR and view the setting of the malicious short message alarm. Description Script Remarks View the setting of the alarm for malicious short messages. LST VLRCFG:; After the configuration of VLR is modified, query the configuration through the command LST VLRCFG.
----End
30.5.5 Data Table Relevant to the Alarm for Malicious Short Messages
The data table relevant to the alarm for malicious short messages only includes the VLR Configuration Data table.

As for this feature, carriers only need to configure data on the MSOFTX3000 after obtaining relevant license. Service management is not involved.

None.
Issue 02 (2007-06-10)
30-9
Contents
Contents
31 Call Simulation.......................................................................................................................31-1
31.1 Service Description ...................................................................................................................................31-2 31.1.1 Function Code..................................................................................................................................31-2 31.1.2 Definition .........................................................................................................................................31-2 31.1.3 System Specifications ......................................................................................................................31-3 31.1.4 Benefits ............................................................................................................................................31-4 31.1.5 Application Scenario ........................................................................................................................31-4 31.1.6 Application Limitations....................................................................................................................31-4 31.2 Availability ................................................................................................................................................31-5 31.2.1 Requirements for NEs......................................................................................................................31-5 31.2.2 Requirements for License ................................................................................................................31-5 31.2.3 Applicable Versions..........................................................................................................................31-5 31.3 Working Principle......................................................................................................................................31-5 31.3.1 Functions of the NEs........................................................................................................................31-5 31.3.2 Internal Processing of the System ....................................................................................................31-8 31.4 Service Flow..............................................................................................................................................31-8 31.4.1 Selection of LAI/GCI and Circuits ..................................................................................................31-8 31.4.2 Handling at the Trunk Side ..............................................................................................................31-9 31.5 Data Configuration..................................................................................................................................31-10 31.5.1 Configuration Description..............................................................................................................31-10 31.5.2 Data Configuration at the MSOFTX3000 Side..............................................................................31-10 31.5.3 Data Configuration at the UMG8900 Side.....................................................................................31-10 31.5.4 Data Configuration Example..........................................................................................................31-10 31.6 Service Management ............................................................................................................................... 31-11 31.6.1 Creating a Call Simulation Task..................................................................................................... 31-11 31.6.2 Message Trace and Logs During the Call Simulation....................................................................31-14 31.6.3 Description of the Shortcut Menu of the Message Output Pane ....................................................31-15 31.6.4 File Saving .....................................................................................................................................31-16 31.6.5 Operations by Carriers ...................................................................................................................31-16 31.7 Charging and CDR ..................................................................................................................................31-17 31.8 Performance Measurement......................................................................................................................31-17 31.9 Service Interaction ..................................................................................................................................31-17
Issue 02 (2007-06-10)
Contents
31.10 Reference...............................................................................................................................................31-17 31.10.1 Specifications...............................................................................................................................31-17 31.10.2 Glossary, Acronyms, and Abbreviations ......................................................................................31-17 31.11 FAQ .......................................................................................................................................................31-18
ii
Issue 02 (2007-06-10)
Figures
Figures
Figure 31-1 Example of the BAM log..............................................................................................................31-7 Figure 31-2 Detailed query result...................................................................................................................31-12 Figure 31-3 Specifying the querying conditions ............................................................................................31-12 Figure 31-4 Displayed query result ................................................................................................................31-13 Figure 31-5 Call simulation node ...................................................................................................................31-13 Figure 31-6 Specifying call simulation related parameters. ...........................................................................31-14 Figure 31-7 Message output format ...............................................................................................................31-14 Figure 31-8 Shortcut menu in the output pane ...............................................................................................31-16
Issue 02 (2007-06-10)
iii
Tables
Tables
Table 31-1 Definitions of the functions ............................................................................................................31-2 Table 31-2 System specifications of the call simulation...................................................................................31-3 Table 31-3 NEs related to call simulation.........................................................................................................31-5 Table 31-4 Versions that support the call simulation ........................................................................................31-5 Table 31-5 Script for registering virtual subscriber ........................................................................................31-10 Table 31-6 Script for changing the virtual subscriber data ............................................................................. 31-11 Table 31-7 Script for querying the virtual subscriber information.................................................................. 31-11 Table 31-8 Meanings of the message contents ...............................................................................................31-15 Table 31-9 Description of the shortcut menu of the message output pane .....................................................31-15
iv
Issue 02 (2007-06-10)
31 Call Simulation
31
About This Chapter
Call Simulation
31.3 Working Principle 31.4 Service 31.5 Data Configuration
31.11 FAQ
Issue 02 (2007-06-10)
31-1
31 Call Simulation

Function Name Call simulation Function Code WMFD-122100
31.1.2 Definition
Call simulation refers to the process in which the operator delivers a command to the back administration module (BAM) through the GUI interface to start the call simulation. After the BAM responds to the MML command, the table querying process of a specified subscriber call or trunk call is reported to the local maintenance terminal (LMT) in the form of message (the tables queried and the query results are included in the message). In this way, the data flow of the data tables can be monitored to facilitate data analysis for the data check after the upgrade or for later maintenance. The MSOFTX3000 supports the call simulation, thus the maintainability of the MSOFTX3000 is improved and the maintenance cost and workload is reduced. The MSOFTX3000 supports the following technical features: Mobile originated call to local mobile subscriber Outgoing call of the local mobile subscriber Incoming trunk call The trunk type is Bearer Independent Call Control (BICC) or Integrated Services Digital Network User Part (ISUP). Trunk call transit The trunk type is BICC or ISUP. Inserting, deleting, and querying mobile subscriber data during the call simulation Querying logs of the call simulation Saving trace messages of the call simulation Table 31-1 lists the definitions of the functions. Table 31-1 Definitions of the functions Function Name Call simulation from interface A/Iu to the trunk BICC/ISUP Call simulation from the trunk BICC/ISUP to interface A/Iu Definition The call simulation is originated by interface A/Iu to the trunk BICC or ISUP. The call simulation is originated by the trunk BICC or ISUP to interface A/Iu.
31-2
Issue 02 (2007-06-10)
31 Call Simulation
Function Name Call simulation from interface A/Iu to interface A/Iu Call simulation from the trunk BICC/ISUP to the trunk BICC/ISUP
Definition The call simulation is originated by interface A/Iu to interface A/Iu. The call simulation is originated by the trunk BICC/ISUP to the trunk BICC/ISUP.

Table 31-2 lists the system specifications of the call simulation. Table 31-2 System specifications of the call simulation Item Number of the call simulations triggered Number of concurrent call simulations (the number of call simulations during a specific time period) Specification The number of the triggered call simulations is recorded through BAM log output. In this way, the impact of the call simulation on the traffic statistic and the put-through rate is reflected. BAM: For all the clients, the maximum number of concurrent call simulations allowed is 64. That is, the BAM can support a maximum of 64 clients to perform call simulation at the same time. Host: A subscriber (authentic subscriber or virtual subscriber) can originates only one call simulation at one time. That is, if a subscriber originates a call simulation, the local client or other clients cannot use the same subscriber to originate another call simulation before the previous call simulation is terminated.
NOTE Virtual subscribers are unreal subscribers registered in the VDB during the call simulation.
Message output of the call simulation Call simulation announcement Processing of circuit contention at the trunk side
As the messages are based on the ASN.1 translation mode, they support only English. The call control block (CCB) only outputs the announcement record, no announcement is played. If circuit contention occurs at the trunk side, the call simulation fails.
Issue 02 (2007-06-10)
31-3
31 Call Simulation
Item Services not supported by call simulation
Specification Services not supported by call simulation are as follows: Data services Handover/Switchover Lawful interception Intelligent (IN) service is not supported if call simulation operations are performed by the subscriber. (It is supported when the caller is an authentic subscriber.) Forwarding services during and after paging Call fail short message indication is not supported if the call simulation fails.
Conflict between call simulation and actual call Requirements for the caller originating the call simulation
For the call simulation at the trunk side, if a call simulation is ongoing, and if a normal incoming call occupies the circuit, the call simulation is disconnected to guarantee the normal call. For a call simulation originated by interface A or interface Iu, the caller can be an authentic subscriber or a simulation subscriber, but the callee must be an authentic subscriber. Therefore, if the call simulation is originated by interface A or interface Iu, the caller's number must be registered in the HLR; if the call simulation is originated by ISUP or BICC, no such requirement is set on the caller.
31.1.4 Benefits
Beneficiary Carrier Description During the call simulation, the table querying information, key information (including software parameters), and the call detailed records (CDRs) are reported to messages. By analyzing the messages, the carrier can locate and rectify the fault easily, thus the troubleshooting process is sped up and the maintainability of the system is enhanced. None.
Mobile subscriber

This service is applicable to all the GSM and UMTS R4 markets.

This service is applicable to the mobile switching center (MSC) that does not use the call mediation node (CMN).
31-4
Issue 02 (2007-06-10)
31 Call Simulation
31.2 Availability
The call simulation requires the coordination of related NEs. Table 31-3 lists the NEs related to call simulation. Table 31-3 NEs related to call simulation VLR MSC MGW SCP HLR
stands for the related NEs.

The call simulation is based on the interface trace mechanism. Therefore, you need to obtain license only for the interface trace. No extra license for call simulation is required.

Table 31-4 lists the versions of the HUAWEI UMTS MSC product that support the call simulation. Table 31-4 Versions that support the call simulation Product MSC MSOFTX3000 Version V100R005C10

Functions of the VLR
During the call simulation, the visitor location register (VLR) provides the following functions: Managing the call simulation subscribers by using maintenance commands Inserting virtual subscribers to the VLR database (VDB) by using the maintenance command INS MS Before triggering the call simulation, if the virtual subscriber does not exist in the VLR, the virtual subscriber must be inserted to the local office by using the maintenance
Issue 02 (2007-06-10)
31-5
31 Call Simulation
command INS MS. The VLR stores the virtual subscribers based on the subscriber data sent from the BAM. A VDB can store a maximum of 20 virtual subscribers. Modifying the subscriber data by using the maintenance command MOD MS After receiving the command MOD MS, the VDB searches and modifies the data of the virtual subscriber based on the MSISDN of the virtual subscriber. The data of the virtual subscriber includes:

MSC number VLR number GCI/SAI number Caller category Roaming subscriber type
Querying virtual subscribers in the VDB by using the maintenance command DSP MS You can display all the virtual subscribers in a single VDB by using DSP MS. The message contains the IMSIs and MSISDNs of all the virtual subscribers.
If you select query according to the module number, enter the module number. The system queries the virtual subscribers based on the module number entered. If you select query according to the location, enter the location information. The system queries the virtual subscribers based on the location information entered.
Querying the basic information of virtual subscribers by using the maintenance command DSP USRINF You can query the basic information of a virtual subscriber by using this command. When a call simulation is triggered, the BAM invokes the maintenance command DSP USRINF to query the virtual subscriber. If the virtual subscriber is busy, the system terminates the call simulation. Deleting virtual subscribers by using the maintenance command DEL MS You can delete a virtual subscriber from the local VLR by using this command. Storing call simulation logs The call simulation logs are stored in the BAM installation directory \Msoftx3000\ RUNLOG\SimCall. A maximum of five log files can be stored in this directory. The maximum size of the log file is 2 MB, and the file name is from Simullation0.txt to Simullation4.txt. The contents of the log files are as follows: Information of successful/failed trigger of the call simulation Information of successful/failed call simulation The contents of the logs are associated to HANDLE through the workstation number. The workstation number is used to identify the maintenance terminal, and HANDLE is the number of the triggering window of the call simulation. Figure 31-1 shows an example of the BAM log.
31-6
Issue 02 (2007-06-10)
31 Call Simulation
Figure 31-1 Example of the BAM log
Functions of the MSC

During a call simulation, the MSC provides the following functions: Processing the service access The call simulation ignores the service access process, including the CHECK IMEI operation. As a result, the CHECK IMEI function fails during the call simulation. After receiving the call management (CM) service access request sent from the mobility management (MM), the MAP identifies that the call is a call simulation and obtains directly the information of the access subscriber without performing the following operations:

Authentication Encryption CHECK IMEI TMSI re-allocation
Processing the callee access Call fail short message indication is not triggered if the call simulation fails. Processing of an authentic subscriber during a call simulation The originator of the caller can be an authentic subscriber or a virtual subscriber. In the case of the authentic subscriber, the call simulation cannot affect the authentic subscriber. That is, when an authentic subscriber is busy (for example, the authentic subscriber is making a call), the call simulation fails. Exporting message tracing results and messages During a call simulation, the host performs message trace to query related tables and outputs messages containing the table querying results.
Issue 02 (2007-06-10)
31-7
31 Call Simulation
Functions of Other NEs

The call simulation also requires the coordination of other NEs. The functions of other NEs are as follows: The media gateway (MGW) must be online. During the call simulation, by querying the Trunk Group Info table, the system outputs a message containing the information of the trunk group where the MGW is located. The message can be used to analyze the data configuration. For the authentic subscriber subscribing to the IN service, the call simulation also supports the following IN call modes:

Calling IN mode Called IN mode Calling and called IN mode:
In the above three modes, the service control point (SCP) must online. When the subscriber is an authentic subscriber during a call simulation, the HLR must be online for the location update of the authentic subscriber.

The call simulation is performed by simulating the call process for a call of an authentic subscriber. For the MSOFTX3000, the HLR, MGW, SCP and other related NEs must be online. The call process is as follows: 1. 2. 3. 4. 5. 6. 7. The user enters the parameter on the GUI to start the call simulation. The BAM checks the module number and the number of concurrent call simulations. The host checks the key parameters and the current status of the subscriber. After the check, the BAM sends a triggering message to the host to originate a local originated or trunk incoming call simulation. After the call is originated, the modules transfer the call simulation identifiers and outputs related message by implementing the trace function. The LMT is traced, and the LMT invokes the DLL files generated by using the ASN.1 provided by the host service to obtain the translated messages for the user. As the messages of the call simulation are not directed out of the local office or sent to the access side, the access messages and the messages out of and into the trunk are implemented in the bouncing mode. The bouncing mechanism is based on the basic voice call. After the call simulation is put through, the CDRs and the BILL table querying information can be exported.
The process of the call simulation requires the coordination of the LMT, BAM, host trace, and the service module.
31.4 Service Flow

31.4.1 Selection of LAI/GCI and Circuits
After the call simulation is started, the BAM sends a call simulation request to the host. On receiving the request, the host selects the location area circuit based on the input conditions of subscribers.
31-8
Issue 02 (2007-06-10)
31 Call Simulation
Call Simulation Originated From A Interface or Iu Interface

If the call simulation is originated from interface A or Iu, the MSOFTX3000 acts as follows: If the enter GCI/SAI are valid, the MSOFTX3000 queries the LAI Information table based on the query conditions. If the specified conditions are invalid, the MSOFTX3000 returns information indicating startup failure of call simulation. If no query condition is specified, the MSOFTX3000 queries the LAI Information table and returns a valid GCI.
Call Simulation Originated From the ISUP Trunk

If the call simulation is originated from an ISUP trunk, the MSOFTX3000 acts as follows when the ISUP circuit is queried: If the specified trunk group name is valid, the MSOFTX3000 queries an idle circuit of trunk group based on the trunk group name to initiate a call. If the specified trunk group name is invalid, the MSOFTX300 returns call launch fail message, which indicates that the call simulation fails to be triggered. If the trunk group name is not specified, the MSOFTX300 queries the Trunk Circuit table and returns an idle circuit. If idle circuits cannot be found, the MSOFTX300 returns a call launch fail message indication.
Call Simulation Originated From the BICC Trunk

If the call simulation is originated from a BICC trunk, the MSOFTX3000 acts as follows when the BICC circuit is queried: If the specified office direction name is valid, the MSOFTX3000 queries the BICC Circuits table based on the office direction name and selects an idle circuit in that office direction to launch a call. If idle circuits cannot be found, the MSOFTX3000 returns a call launch fail message. If the specified office direction name is invalid, the MSOFTX3000 returns a call launch fail message, which indicates that the call simulation fails to be triggered. If the office direction name is not specified, the MSOFTX3000 queries the records in the BICC Circuits table one by one and tries to select an idle circuit. If no circuit is found, the MSOFTX3000 returns a call launch fail message.
31.4.2 Handling at the Trunk Side

The BICC trunk or ISUP trunk provides the interface, through which the BAM checks whether the trunk parameters are valid. For the ISUP trunk, the BAM queries the Trunk Group table through the interface and checks whether the trunk group name is configured. For the BICC trunk, the BAM queries the Office Direction table through the interface and checks whether the BICC office direction name is configured. After receiving the call simulation originated message from the BAM, the trunk side selects an idle circuit for the call simulation.
Issue 02 (2007-06-10)
31-9
31 Call Simulation

31.5.1 Configuration Description
Call simulation requires the data configuration of various network elements (NEs) to support real calls. Before the call simulation, ensure that the virtual subscriber data exists in the local VLR and the callee must be a subscriber.

Call simulation requires a virtual subscriber to be registered in the local VLR on the basis of real data configuration. You can run INS MS to insert a virtual subscriber in the VLR of the local office to support corresponding call simulations.

Call simulation requires the data configuration at the UMG8900 side to support real calls.

For the call simulation originated at the A or interface Iu, if the caller is a non-real subscriber, run INS MS to register a virtual subscriber in the local VLR. For the call simulation originated at the trunk BICC/ISUP side, the data configuration is the same as that of a real call.
If a virtual subscriber that meets requirement already exists in the local VLR, run DSP MS to query the user information and use the existing virtual subscriber for call simulation.
The configuration of various scripts is as follows: Table 31-5 lists the script for registering virtual subscriber. Table 31-5 Script for registering virtual subscriber Description Script Explanation Register the virtual subscriber with IMSI "086013907885522" and MSISDN "13907885522". INS MS: IMSI="086013907885522", MSISDN="13907885522"; If one of the following situations occurs, registering virtual subscriber fails. The number of subscribers in the local VLR reaches the maximum. The number of virtual subscribers in the local VLR reaches the maximum 20. The virtual subscriber to be registered in the local VLR already exists.
Table 31-6 lists the script for changing the virtual subscriber data.
31-10
Issue 02 (2007-06-10)
31 Call Simulation
Table 31-6 Script for changing the virtual subscriber data Description Script Change the MSC where the virtual subscriber with MSISDN "13907885522" locates to 08601390778000. MOD MS: D="13907885522", MSCNUMBER="08601390778000";
Table 31-7 lists the script for querying the virtual subscriber information. Table 31-7 Script for querying the virtual subscriber information Description Script Query all the virtual subscribers on the VDB board with module number "102". DSP MS: IM=MOD, MN=102;

31.6.1 Creating a Call Simulation Task
In the operating network, call simulation at the caller side is performed on virtual subscribers to avoid the impact on the services of the online subscribers. The call simulation is originated at the A/Iu interface. To create a call simulation task, perform the following steps: Step 1 Run LST MDU to query the related module information. The number of the module where the WVDB board locates is obtained from the output result. The detailed output result is as shown in Figure 31-2.
Issue 02 (2007-06-10)
31-11
31 Call Simulation
Figure 31-2 Detailed query result
Step 2 According to the number of the module where the WVDB board locates, run DSP MS to query the information of virtual subscribers of the VLR specified by the existing host. Step 3 Specify the query conditions in Figure 31-3, and then press F9 The information of virtual subscribers is displayed, as shown in Figure 31-4. Figure 31-3 Specifying the querying conditions
31-12
Issue 02 (2007-06-10)
31 Call Simulation
Figure 31-4 Displayed query result
Step 4 Click Maintenance, and then double-click Call simulation under the service navigation tree, as shown in Figure 31-5. Figure 31-5 Call simulation node
Step 5 Specify related parameters, and then click Start, as shown in Figure 31-6.
Issue 02 (2007-06-10)
31-13
31 Call Simulation
Figure 31-6 Specifying call simulation related parameters.
----End Until now, a call simulation task is created and the call simulation starts. The message output window will display the table query results during the call simulation and the result of the call simulation. Check the data configuration and location the problem according to the output table query result.
For the trunk BICC/ISUP incoming call simulation, the calling number can be any number. The called number, however, are different in different application scenarios. If the called side is a trunk, the called number consists of the correct call prefix + any number. If the called side is the A/Iu interface, the called number must be the number of a real subscriber. Run LST CNACLD to obtain the prefix.
31.6.2 Message Trace and Logs During the Call Simulation

Message trace and logs are generated during the call simulation, like during a real call. The way to view the message trace and logs of the call simulation is the same as that to view the message trace and logs of a real call. The message output window displays the table query result during the call simulation. The message output format is as shown in Figure 31-7. Figure 31-7 Message output format
Table 31-8 describes the meanings of the contents contained in the message.
31-14
Issue 02 (2007-06-10)
31 Call Simulation
Table 31-8 Meanings of the message contents Message TABLE Meaning It indicates the name of the table queried during the call simulation. For example, in Figure 31-7, the table name is BICC-Trunk-GroupInfo-Table. Query-Condition Trunk-group-name It indicates the query condition. It indicates the name of the trunk group. For example, in Figure 31-7, the trunk group named SCTP-OUT is queried in the BICC trunk group information table. Query-Success Bearer-establishdirection Tunnel-mode It indicates that the query is successful. The content below Query-Success is the query result. It indicates the direction of the trunk group bearer establishment. For example, in Figure 31-7, the bearer establishment direction configured over the trunk group is Forward. It indicates the tunnel mode of the transmission. For example, in Figure 31-7, the tunnel mode of the transmission is Fast. Expectedcontinuity-check It indicates whether to expect the COT message.
31.6.3 Description of the Shortcut Menu of the Message Output Pane

Table 31-9 describes the shortcut menu of the message output pane. Table 31-9 Description of the shortcut menu of the message output pane Menu Copy Select All Clear Save As Autoscroll Description Copy the selected content. Select all the contents in the output pane. Clear all the messages in the window. Save all the existing output messages in the .txt format to the specified path. Click Auto screen scrolling (T). The output pane automatically scrolls down to the last message.
Issue 02 (2007-06-10)
31-15
31 Call Simulation
31.6.4 File Saving

In different scenarios, files are saved in different ways. Generally, files are saved in the following three ways: Before starting a call simulation task, choose in Figure 31-6. Then and
the reported messages are saved in the default path. To save the path, click then specify the path and file name in the displayed dialog box.
After starting a call simulation task, the input pane is locked. If you want to save the message, perform the following steps: 1. 2. 3. Right-click the output pane to display the shortcut menu. Select Save As. A dialog box is displayed, as shown in Figure 31-8. Select the path and file name.
Figure 31-8 Shortcut menu in the output pane
If you do not save files before closing the call simulation window, the system will prompt you whether to save files when you close the call simulation window.

Choose Yes. The system displays a dialog box, in which, you can select the path and file name. Choose No. The files are not saved. Choose Cancel. The call simulation window is not saved.

Carriers can manage virtual subscribers through the following operations: Step 1 Register a virtual subscriber in the local VLR (INS MS). Step 2 Modify the data of a virtual subscriber in the local VLR (MOD MS). Step 3 Query the information of a virtual subscriber of a VDB board (DSP MS).
31-16
Issue 02 (2007-06-10)
31 Call Simulation
Step 4 Delete a virtual subscriber from the local VLR (DEL MS). ----End

The CDR generation scenario of the call simulation is the same as that of a real call. But the CDR generated by the call simulation is not saved to the bill pool. Only the CDR content is displayed as a message on the client. Currently, the MOC, MTC, and HLR CDR are supported. The MOC and MTC CDRs include the charged party number, caller number, called number, trunk route number, and route number. The HLR CDR includes the charged party number.

In the process of call simulation, the traffic statistics console uses the existing traffic statistics mode. The statistics of each traffic statistics index is the same as that during a real call.

None.
31.10 Reference
None.

Glossary
Glossary ASN.1 Meaning Abstract syntax rule 1 It is used to describe the syntax rule of the format of the information transferred between systems and is widely applied to the specification definition of communication protocols.
Issue 02 (2007-06-10)
31-17
31 Call Simulation

Acronyms and Abbreviations 3G 3GPP2 BICC CCB ISUP BAM VDB Full Name The Third Generation 3rd Generation Partnership Project 2 Bearer Independent Call Control Call Control Block Integrated Services Digital Network User Part/ISDN User Part Back Administration Module VLR Database
31.11 FAQ
Q: During the BICC-to-BICC call simulation procedure, the CCB disconnects the call after the BICC sends the Setup message to the CCB. The displayed cause value is "cv bearer capability not permit (185)". A: This is because bit 8 of P144 is set to 1 and the system does not the support the BICC-toBICC tandem call. After bit 8 of P144 is set to 0, the problem is solved.
31-18
Issue 02 (2007-06-10)
Contents
Contents
32 Load-Based Handover ...........................................................................................................32-1
32.1 Service Description ...................................................................................................................................32-2 32.1.1 Function Code..................................................................................................................................32-2 32.1.2 Definition .........................................................................................................................................32-2 32.1.3 System Specifications ......................................................................................................................32-2 32.1.4 Benefits ............................................................................................................................................32-3 32.1.5 Application Scenario ........................................................................................................................32-3 32.1.6 Application Limitation .....................................................................................................................32-3 32.2 Availability ................................................................................................................................................32-3 32.2.1 Requirements for NEs......................................................................................................................32-3 32.2.2 Requirements for License ................................................................................................................32-4 32.2.3 Applicable Versions..........................................................................................................................32-4 32.2.4 Others...............................................................................................................................................32-4 32.3 Working Principle......................................................................................................................................32-4 32.3.1 Functions of the NEs........................................................................................................................32-4 32.3.2 Internal Processing of the System ....................................................................................................32-6 32.3.3 External Interface.............................................................................................................................32-7 32.4 Service Flow..............................................................................................................................................32-7 32.4.1 Intra-MSC Load-Based Handover From 3G to 2G System .............................................................32-7 32.4.2 Inter-MSC Load-Based Handover From 3G to 2G System .............................................................32-8 32.4.3 Intra-MSC Load-Based Handover From 2G to 3G System .............................................................32-9 32.4.4 Inter-MSC Load-Based Handover From 2G to 3G System .............................................................32-9 32.4.5 Intra-MSC Load-Based Handover in 2G System...........................................................................32-10 32.4.6 Inter-MSC Load-Based Handover in 2G System........................................................................... 32-11 32.5 Data Configuration..................................................................................................................................32-12 32.5.1 Overview........................................................................................................................................32-12 32.5.2 Data Configuration at the MSOFTX3000 Side..............................................................................32-12 32.5.3 Data Configuration at the UMG8900 Side.....................................................................................32-13 32.5.4 Data Configuration Example..........................................................................................................32-13 32.5.5 Data Tables Related to Load-Based Handover...............................................................................32-14 32.6 Service Management ...............................................................................................................................32-15 32.6.1 Operations by Carriers ...................................................................................................................32-15
Issue 02 (2007-06-10)
Contents
HUAWEI MSOFTX3000 Feature Description 32.6.2 Operations by Subscribers .............................................................................................................32-16
32.7 Charging and CDR ..................................................................................................................................32-16 32.8 Performance Measurement......................................................................................................................32-16 32.9 Service Interaction ..................................................................................................................................32-16 32.10 Reference...............................................................................................................................................32-16 32.10.1 Specifications...............................................................................................................................32-16 32.10.2 Acronyms and Abbreviations .......................................................................................................32-17 32.11 FAQ .......................................................................................................................................................32-17
ii
Issue 02 (2007-06-10)
Figures
Figures
Figure 32-1 Flow of the intra-MSC handover ..................................................................................................32-6 Figure 32-2 Flow of the inter-MSC handover ..................................................................................................32-6 Figure 32-3 Intra-MSC load-based handover from 3G to 2G system ..............................................................32-7 Figure 32-4 Inter-MSC load-based handover from 3G to 2G system...............................................................32-8 Figure 32-5 Intra-MSC load-based handover from 2G to 3G system ..............................................................32-9 Figure 32-6 Inter-MSC load-based handover from 2G to 3G system.............................................................32-10 Figure 32-7 Intra-MSC load-based handover in the 2G network ................................................................... 32-11 Figure 32-8 Inter-MSC load-based handover in the 2G network ...................................................................32-12
Issue 02 (2007-06-10)
iii
Tables
Tables
Table 32-1 Function code of load-based handover ...........................................................................................32-2 Table 32-2 Specifications of the load-based handover service .........................................................................32-2 Table 32-3 Benefits of the load-based handover service ..................................................................................32-3 Table 32-4 NEs required to implement load-based handover...........................................................................32-4 Table 32-5 The earliest version of the MSOFTX3000 that supports load-based handover ..............................32-4 Table 32-6 Data tables related to load-based handover ..................................................................................32-14 Table 32-7 Operation modes of load-based handover ....................................................................................32-15
iv
Issue 02 (2007-06-10)
32 Load-Based Handover
32
About This Chapter
Load-Based Handover
The following table lists the contents of this chapter. Describes The function code and definition of the service and the benefits of the service to carriers and mobile subscribers. The NEs required to implement the service, requirements for the license, and versions of the products applicable to the service. The functions of the NEs used to implement the service and the requirements on the networking. The flow of the service. The data configuration that must be performed at the MSOFTX3000 side and the UMG8900 side as well as the examples of data configuration. The operations that carrier and mobile subscribers must perform when the service is provided. The procedure for performing charging and generating CDRs when the service is provided. The influence of the service on performance measurement and the implementation of performance measurement. The association between the service and other services as well as the restrictions on each other. The standards and specifications with which the service complies and the glossary, abbreviations, and acronyms used in this chapter. The frequently asked questions related to the service and the solutions.
32.11 FAQ
Issue 02 (2007-06-10)
32-1

Table 32-1 lists the function code of the load-based handover service. Table 32-1 Function code of load-based handover Name Load-Based Handover Function Code WMFD-080900
32.1.2 Definition
Load-based handover is a mechanism for balancing the traffic and load in the UMTS network and GSM network of carriers. For the BSC/RNCs that support load-based handover, when inter-system handover or intraGSM handover happens, the destination BSC/RNC carries the cell load information in the reported message HANDOVER REQUEST ACKNOWLEDGE/RELOCATION REQUEST ACKNOWLEDGE or HANDOVER FAILURE/RELOCATION FAILURE, which is transparently transmitted to the source BSC/RNC through relevant network equipment while the message HANDOVER COMMAND/RELOCATION COMMAND or HANDOVER REQUIRED REJECT/RELOCATION PREPARATION FAILURE is delivered to the source BSC/RNC. If the BSC/RNC does not support this function, handover is performed based on the common process. This function is provided for the following handover: UMTS-to-GSM intra-MSC handover, inter-MSC handover and subsequent handover GSM-to-UMTS intra-MSC handover, inter-MSC handover and subsequent handover GSM-to-GSM intra-MSC inter-BSC handover, basic inter-MSC handover and subsequent handover

Table 32-2 lists the specifications of the load-based handover service. Table 32-2 Specifications of the load-based handover service Item The MSC, through the parameter configuration, controlling whether the BSC/RNC supports loadbased handover Specification For each RNC/BSC, the MSC can configure the capability of whether to support load-based handover, that is, whether to process cell load information as the handover source.
32-2
Issue 02 (2007-06-10)
Item Transparent transmission of cell load information by the MSC during inter-system handover
Specification The MSC can transparently transmit cell load information during inter-system handover such as 3G-to-2G, 2G-to-2G and 2G- to-3G handover.
32.1.4 Benefits
Table 32-3 lists the benefits of the load-based handover service. Table 32-3 Benefits of the load-based handover service Beneficiary Carriers Description The function is used for exchanging load information between the source cell and the destination cell during inter-system handover. With the information, the source BSC/RNC can define a policy to better control the handover. Because the source BSC/RNC learns about the load information of neighboring cells, it can control the handover to some extent. In this case, network load can be balanced and the service experience of mobile subscribers can also be improved.
Mobile subscriber

This service is applicable to the markets of all GSM networks, GSM and UMTS coexistent networks.
32.1.6 Application Limitation

The MSC can transmit load information only when the source BSC/RNC supports processing of load information.
32.2 Availability
The load-based handover service must be implemented by the radio network controller (RNC), base station controller (BSC), and the core network together. Table 32-4 lists the network elements (NEs) required to implement load-based handover.
Other descriptions of the service availability in section 32.2 "Availability" are based on the core network only.
Issue 02 (2007-06-10)
32-3
Table 32-4 NEs required to implement load-based handover UE BSC NodeB RNC MSC Server MGW SGSN GGSN HLR -
"" indicates that the NE is required for the service.

Load-based handover is a basic service of the MSOFTX3000. You can use this service without the License.

Table 32-5 lists the version information of the MSOFTX3000 that supports the load-based handover service. Table 32-5 The earliest version of the MSOFTX3000 that supports load-based handover Product MSC server MSOFTX3000 Applicable Version V100R006
32.2.4 Others
The requirements of the hardware and the NEs for the load-based handover are as follows: RNC and BSC must support sending or receiving the load information element defined in the 3GPP R5 specifications. The mobile phone must be GSM phone or a GSM/UMTS dual-mode phone.

The MSC server and BSC/RNC implement the signaling processing and data analysis related to the handover. For the load-based handover, the required functions of the MSC server and BSC/RNC are as follows: Both of the BSC/RNC at the source side of the handover and the BSC/RNC at the target side must support the load-based handover. If the BSC/RNC at the target side supports the load-based handover, the following messages sent by the BSC/RNC at the target side contain the load information of the target cell:

HANDOVER REQUEST ACKNOWLEDGE/RELOCATION REQUEST ACKNOWLEDGE HANDOVER FAILURE/RELOCATION FAILURE
32-4
Issue 02 (2007-06-10)
If the BSC/RNC at the source side supports the load-based handover and the following messages sent by the MSC contain the load information of the target cell, the BSC/RNC at the source side processes the cell load information according to the specifications:

HANDOVER COMMAND/RELOCATION COMMAND HANDOVER REQUIRED REJECT/RELOCATION PREPARATION FAILURE
The MSC must support the load-based handover. That is, the MSC at the target side must be able to send the load information of the target cell to the source side. The MSC at the source side must be able to send the information to the BSC/RNC. The BSC/RNC data in the MSOFTX3000 can be configured to determine whether the BSC/RNC supports the load-based handover. The software parameter of the MSOFTX3000 controls whether the MSC supports the load-based handover. At the source side of the handover, the MSOFTX3000 checks the capability list of the BSC/RNC. Based on the capability list, the MSOFTX3000 determines whether the BSC/RNC supports the load-based handover, and then, accordingly, decides whether to send the cell load information through messages. At the target side of the inter-MSC handover, the MSOFTX3000, based on the configuration of the software parameter, decides whether to send the cell load information to the source side. The MSOFTX3000 uses three software parameters to control the following types of inter-MSC load-based handover respectively:
Inter-MSC load-based handover from the 3G network to the 2G network If bit 13 of software parameter 157 in the target office is set to 0, indicating the handover is supported, and the target MSC receives the load information from the target BSC, the target MSC sends the load information to the source MSC. If bit 13 of software parameter 157 in the target office is set to 1, indicating the loadbased handover is not supported, the target MSC does not send the load information to the source MSC.
Inter-MSC load-based handover from the 2G network to the 3G network If bit 14 of software parameter 157 in the target office is set to 0, indicating the handover is supported, and the target MSC receives the load information from the target RNC, the target MSC sends the load information to the source MSC. If bit 14 of software parameter 157 in the target office is set to 1, indicating the loadbased handover is not supported, the target MSC does not send the load information to the source MSC.
Inter-MSC load-based handover in the 2G network If bit 15 of software parameter 157 in the target office is set to 0, indicating the handover is supported, and the target MSC receives the load information from the target BSC, the target MSC sends the load information to the source MSC. If bit 15 of software parameter 157 in the target office is set to 1, indicating the loadbased handover is not supported, the target MSC does not send the load information to the source MSC.
The default values of bit 13, 14, and 15 of software parameter 157 are 1.
In the case of intra-MSC handover, the capability of supporting the load-based handover of the BSC/RNC at the source side must be configured on the MSC. The capability of the BSC/RNC at the target side does not require the corresponding configuration on the MSC.
Issue 02 (2007-06-10)
32-5
If the BSC/RNC at the target side can report the load information, the MSC must check whether the BSC/RNC at the source side supports the load-based handover. If the BSC/RNC at the source side supports the load-based handover, the command MOD BSC must be executed on the MSC for the capability of the BSC/RNC. The MSC then sends the load information transparently to the BSC/RNC at the source side.

The internal processing of the system differs with the types of handover, which include: interMSC handover and intra-MSC handover.
Intra-MSC Handover
Figure 32-1 shows the flow of the intra-MSC handover. Figure 32-1 Flow of the intra-MSC handover
(1) (2)
BSC/RNC
(4)
MSC Server
(3)
BSC/RNC
The flow of the intra-MSC handover is as follows: 1. 2. 3. 4. The BSC/RNC at the source side of the handover sends a handover request message to the MSC server. The MSC server sends the handover request message to the BSC/RNC at the target side of the handover. The BSC/RNC at the target side returns a response message containing the load information. The MSC queries the capability of the BSC/RNC at the source side. If the BSC/RNC is configured to support the load-based handover, the MSC sends the load information transparently to the BSC/RNC at the source side.
Inter-MSC Handover
Figure 32-2 shows the flow of the inter-MSC handover. Figure 32-2 Flow of the inter-MSC handover
(1) (2) (3)
BSC/RNC
(6)
MSC Server
(5)
MSC Server
(4)
BSC/RNC
The flow of the inter-MSC handover is as follows:
32-6
Issue 02 (2007-06-10)
1. 2. 3. 4. 5.
The BSC/RNC at the source side of the handover sends a handover request message to the MSC server. The MSC server at the source side sends the handover request to the MSC server at the target side of the handover. The MSC server at the target side sends the handover request message to the BSC/RNC at the target side. The BSC/RNC at the target side sends a response message, containing the load information, to the MSC server at the target side. If the target office supports the load-based handover (the corresponding bit of the software parameter is set to 1), the MSC at the target side sends the load information element to the MSC server at the source side through the response message to the interMSC handover request. The MSC server at the source side queries the capability of the BSC/RNC at the source side. If the BSC/RNC is configured to support the load-based handover, the MSC sends the load information transparently to the BSC/RNC at the source side.
6.
32.3.3 External Interface

None.
32.4 Service Flow

The successful intra- or inter-MSC handover is considered as an example. The flow of transmitting the load information in an unsuccessful handover is the same as the flow in a successful handover.
32.4.1 Intra-MSC Load-Based Handover From 3G to 2G System

Figure 32-3 shows the flow of the intra-MSC load-based handover from the RNC to the BSC. Figure 32-3 Intra-MSC load-based handover from 3G to 2G system
RNC MSOFTX3000 BSC
Iu interface message
RELOCATION REQUIRED
A interface message
HANDOVER REQUEST
A interface message Iu interface message

RELOCATION COMMAND HANDOVER REQUEST ACKNOWLEDGE
The description of the flow of intra-MSC load-based handover from the RNC to the BSC is as follows:
Issue 02 (2007-06-10)
32-7
If the HANDOVER REQUEST ACKNOWLEDGE message sent by the BSC to the MSOFTX3000 contains the cell load information, and the capability of supporting the load-based handover of the RNC at the source side is configured on the MSOFTX3000, the MSOFTX3000 sends the cell load information transparently through the Iu interface message RELOCATION COMMAND. If the handover fails, the HANDOVER FAILURE message sent by the BSC contains the cell load information, and the capability of supporting the load-based handover of the RNC at the source side is configured on the MSOFTX3000, the MSOFTX3000 sends the cell load information transparently through the Iu interface message RELOCATION PREPARATION FAILURE. Whether the handover is re-originated is determined by the RNC at the source side.
32.4.2 Inter-MSC Load-Based Handover From 3G to 2G System

Figure 32-4 shows the flow of the inter-MSC load-based handover from the RNC to the BSC. Figure 32-4 Inter-MSC load-based handover from 3G to 2G system
RNC MSOFTX3000-A Iu interface message RELOCATION REQUIRED E interface message MAP-Prep-Handover req A interface message HANDOVER REQUEST A interface message HANDOVER REQUEST ACKNOWLEDGE BS MSOFTX3000-B C BS BSC C
E interface message MAP-Prep-Handover resp Iu interface message RELOCATION COMMAND
The description of the flow of the inter-MSC load-based handover from the RNC to the BSC is as follows: If the HANDOVER REQUEST ACKNOWLEDGE message sent by the BSC to the MSOFTX3000-B contains the cell load information, and bit 13 of software parameter 157 in the MSOFTX3000-B is set to 0, the MSOFTX3000-B sends the cell load information transparently to the MSOFTX3000-A through the E interface message MAP-Prep-Handover resp. If the capability of supporting the load-based handover of the RNC at the source side is configured on the MSOFTX3000-A, and the MAP-Prep-Handover resp message sent by the MSOFTX3000-B to the MSOFTX3000-A contains the load information of the target cell, the MSOFTX3000-A sends the information transparently to the RNC at the source side through a RELOCATION COMMAND message. If the handover fails, the HANDOVER FAILURE message sent by the BSC contains the cell load information, and bit 13 of software parameter 157 in the MSOFTX3000-B is set to 0, the information is transparently sent to the MSOFTX3000-A. If the capability of supporting the load-based handover of the RNC at the source side is configured on the MSOFTX3000-A, the MSOFTX3000-A sends the cell load information transparently
32-8
Issue 02 (2007-06-10)
through the Iu interface message RELOCATION PREPARATION FAILURE. Whether the handover is re-originated is determined by the RNC at the source side.
32.4.3 Intra-MSC Load-Based Handover From 2G to 3G System

Figure 32-5 shows the flow of the intra-MSC load-based handover from the BSC to the RNC. Figure 32-5 Intra-MSC load-based handover from 2G to 3G system
BSC MSOFTX3000 A interface message HANDOVER REQUIRED Iu interface message RELOCATION REQUEST D-Iu interface message RELOCATION REQUEST ACKNOWLEDGE RNC
A interface message HANDOVER COMMAND
The description of the flow of the intra-MSC load-based handover from the BSC to the RNC is as follows: If the RELOCATION REQUEST ACKNOWLEDGE message sent by the RNC to the MSC contains the cell load information, and the capability of supporting the load-based handover of the BSC at the source side is configured on the MSC, the MSC sends the cell load information transparently through the A interface message HANDOVER COMMAND. If the handover fails, the RELLOCATION FAILURE message sent by the RNC contains the cell load information, and the capability of supporting the load-based handover of the BSC at the source side is configured on the MSC, the MSC sends the cell load information transparently through the A interface message HANDOVER REQUIRED REJECT. Whether the handover is re-originated is determined by the BSC at the source side.
32.4.4 Inter-MSC Load-Based Handover From 2G to 3G System

Figure 32-6 shows the flow of the inter-MSC load-based handover from the BSC to the RNC.
Issue 02 (2007-06-10)
32-9
Figure 32-6 Inter-MSC load-based handover from 2G to 3G system

BSC MSOFTX3000-A A interface message HANDOVER REQUIRED E interface message MAP-Prep-Handover req Iu interface message RELOCATION REQUEST Iu interface message RELOCATION REQUEST ACKNOWLEDGE BS MSOFTX3000-B C BS RNC C
E interface message MAP-Prep-Handover resp A interface message HANDOVER COMMAND
The description of the flow of the inter-MSC load-based handover from the BSC to the RNC is as follows: If the RELOCATION REQUEST ACKNOWLEDGE message sent by the RNC to the MSOFTX3000-B contains the cell load information, and bit 14 of software parameter 157 in the MSOFTX3000-B is set to 0, the MSOFTX3000-B sends the cell load information transparently to the MSOFTX3000-A through the E interface message MAP-Prep-Handover resp. If the capability of supporting the load-based handover of the BSC at the source side is configured on the MSOFTX3000-A, and the MAP-Prep-Handover resp message sent by the MSOFTX3000-B to the MSOFTX3000-A contains the load information of the target cell, the MSOFTX3000-A sends the information transparently to the BSC at the source side through a HANDOVER COMMAND message. If the handover fails, the RELOCATION FAILURE message sent by the RNC contains the cell load information, and bit 14 of software parameter 157 in the MSOFTX3000-B is set to 0, the information is transparently sent to the MSOFTX3000-A. If the capability of supporting the load-based handover of the BSC at the source side is configured on the MSOFTX3000-A, the MSOFTX3000-A sends the cell load information transparently through the A interface message HANDOVER REQUIRED REJECT. Whether the handover is re-originated is determined by the BSC at the source side.
32.4.5 Intra-MSC Load-Based Handover in 2G System

Figure 32-7 shows the flow of the intra-MSC load-based handover from a BSC to another BSC.
32-10
Issue 02 (2007-06-10)
Figure 32-7 Intra-MSC load-based handover in the 2G network

BSC-A MSOFTX3000 BSC-B
A interface message HANDOVER REQUIRED A interface message RELOCATION REQUEST A interface message RELOCATION REQUEST ACKNOWLEDGE
The description of the flow of the intra-MSC load-based handover from a BSC to another BSC is as follows: If the HANDOVER REQUEST ACKNOWLEDGE message sent by the BSC-B to the MSOFTX3000 contains the cell load information, and the capability of supporting the load-based handover of the BSC-A is configured on the MSOFTX3000, the MSOFTX3000 sends the cell load information transparently through the A interface message HANDOVER COMMAND. If the handover fails, the HANDOVER FAILURE message sent by the BSC-B contains the cell load information, and the capability of supporting the load-based handover of the BSC-A is configured on the MSOFTX3000, the MSOFTX3000 sends the cell load information transparently through the A interface message HANDOVER REQUIRED. Whether the handover is re-originated is determined by the BSC at the source side.
32.4.6 Inter-MSC Load-Based Handover in 2G System

Figure 32-8 shows the flow of the intra-MSC load-based handover from a BSC to another BSC.
Issue 02 (2007-06-10)
32-11
Figure 32-8 Inter-MSC load-based handover in the 2G network

BSC-A MSOFTX3000-A BS MSOFTX3000-B C BS BSC-B C
A interface message HANDOVER REQUIRED E interface message MAP-Prep-Handover req A interface message HANDOVER REQUEST A interface message HANDOVER REQUEST ACKNOWLEDGE
E interface message MAP-Prep-Handover resp
The description of the flow of the inter-MSC load-based handover from a BSC to another BSC is as follows: If the HANDOVER REQUEST ACKNOWLEDGE message sent by the BSC-B to the MSOFTX3000-B contains the cell load information, and bit 15 of software parameter 157 in the MSOFTX3000-B is set to 0, the MSOFTX3000-B sends the cell load information transparently to the MSOFTX3000-A through the E interface message MAP-Prep-Handover resp. If the capability of supporting the load-based handover of the BSC-A is configured on the MSOFTX3000-A, and the MAP-Prep-Handover resp message sent by the MSOFTX3000-B to the MSOFTX3000-A contains the load information of the target cell, the MSOFTX3000-A sends the information transparently to the BSC-A through a HANDOVER COMMAND message. If the handover fails, the HANDOVER FAILURE message sent by the BSC-B contains the cell load information, and bit 15 of software parameter 157 in the MSOFTX3000-B is set to 0, the information is transparently sent to the MSOFTX3000-A. If the capability of supporting the load-based handover of the BSC-A is configured on the MSOFTX3000-A, the MSOFTX3000-A sends the cell load information transparently through the A interface message HANDOVER REQUIRED REJECT. Whether the handover is re-originated is determined by the BSC at the source side.

32.5.1 Overview
For this function, relevant data must be configured on the MSOFTX3000 only. Whether data need be configure at the RAN depends on the provider of RAN. For detailed configuration, see section 32.5.2 "Data Configuration at the MSOFTX3000 Side."

To configure the data for the load-based handover service on the MSOFTX3000, perform the following steps:
32-12
Issue 02 (2007-06-10)
Step 1 Run the command MOD BSC to modify the support capability of the source BSC for the cell load information. Step 2 Run the command MOD RNC to modify the support capability of the source RNC for the cell load information Step 3 Run the command MOD MSFP to modify software parameter 157. Set bits 13, 14 and 15 to control whether the destination MSC supports load-based handover. ----End

For this function, no data must be configured on the UMG8900.

There is one or more than one BSC and RNC in an MSC server.
If relevant data tables are not configured in the local office, the procedure of data configuration on the MSOFTX3000 maintenance terminal is as follows: Step 1 Configure the capability of BSC. Description Script Remark Run the command MOD BSC to set whether the BSC supports loadbased handover. MOD BSC: DPC="23", CAPABILITY=LOADHO-1; The value option Support Load-based HO of the parameter List Of BSC Capability is used to configure whether the BSC supports this capability. If the option is selected, load-based handover is supported. If the option is not selected, load-based handover is not supported. By default, load-based handover is not supported.
Step 2 Configure the capability of RNC. Description Script Remark Run the command MOD RNC to set whether the RNC supports loadbased handover. MOD RNC: RNCID=1, CAPABILITY=LOADHO-1; The value option Support Load-based HO of the parameter RNC capability list is used to configure whether the RNC supports this capability. If the option is selected, the load-based handover is supported. If the item is not selected, load-based handover is not supported. By default, load-based handover is not supported.
Issue 02 (2007-06-10)
32-13
Step 3 Set the software parameter. Description Script Run the command MOD MSFP to set software parameters. MOD MSFP: ID=P157, MODTYPE=P1, BIT=13, BITVAL=0; MOD MSFP: ID=P157, MODTYPE=P1, BIT=14, BITVAL=0; MOD MSFP: ID=P157, MODTYPE=P1, BIT=15, BITVAL=0; Remark Bit 13, 14 and 15 of software parameter 157 are used to control whether the MSOFTX3000 supports the load-based handover. Bit 13: used for the inter-MSC load-based handover from the 3G to 2G system. It is used to set whether the destination MSC must send the received load information to the MSC requesting handover. The value 0 indicates that the destination MSC must send the received load information to the MSC requesting handover. The value 1 indicates that the destination MSC does not send the received load information to the MSC requesting handover. By default, bit 13 is set to 1. Bit 14: used for the inter-MSC load-based handover from the 2G to 3G system. It is used to set whether the destination MSC must send the received load information to the MSC requesting handover. The value 0 indicates that the destination MSC must send the received load information to the MSC requesting handover. The value 1 indicates that the destination MSC does not send the received load information to the MSC requesting handover. By default, bit 14 is set to 1. Bit 15: used for the inter-MSC load-based handover in the 2G system. It is used to set whether the destination MSC must send the received load information to the MSC requesting handover. The value 0 indicates that the destination MSC must send the received load information to the MSC requesting handover. The value 1 indicates that the destination MSC does not send the received load information to the MSC requesting handover. By default, bit 15 is set to 1.
32.5.5 Data Tables Related to Load-Based Handover

Table 32-6 lists the data tables related to load-based handover. Table 32-6 Data tables related to load-based handover Table Name BSC table Function There are multiple records in this table. It records the capability of the source BSCs managed by the local MSC for cell load information. Relevant Command MOD BSC
32-14
Issue 02 (2007-06-10)
Table Name RNC table
Function There are multiple records in this table. It records the capability of the source RNCs managed by the local MSC for cell load information.
Relevant Command MOD RNC

The management of the load-based handover service consists the following operations: Adding the capability of supporting the cell load information of the BSC/RNC It is performed by carriers to make the service available. Canceling the capability of supporting the cell load information of the BSC/RNC It is performed by carriers to make the service unavailable. The load-based handover servicecan be managed in two modes listed in Table 32-7. Table 32-7 Operation modes of load-based handover Operation Mode Operation by carriers Operate on MSOFTX3000 operation & maintenance (O&M) system NA Operation Adding or canceling the capability of supporting the cell load information of the BSC/RNC None
Operation by mobile subscribers

The carrier can control load-based handover through the MSOFTX3000 O&M system.
Adding the Capability

To add the capability of supporting the cell load information of the BSC/RNC, perform the following steps: Step 1 Run the command LST BSC/LST RNC to query whether the BSC/RNC supports cell load information when serving as the handover source. Step 2 Run the command MOD BSC/MOD RNC to add the capability of the BSC/RNC for supporting the cell load information when the BSC/RNC serves as the handover source. The parameter List Of BSC Capability/RNC capability list has a value option Support Load-based HO. Step 3 Run the command MOD MSFP to modify bit 13, 14 and 15 of software parameter 157. For description of the software parameter, see section 32.5.4 "Data Configuration Example."
Issue 02 (2007-06-10)
32-15
----End Follow the procedure below to cancel the function:
Canceling the Capability

To cancel the capability of supporting the cell load information of the BSC/RNC, perform the following steps: Step 1 Run the command LST BSC/LST RNC to query whether the BSC/RNC supports cell load information when serving as the handover source. Step 2 Run the command MOD BSC/MOD RNC to cancel the capability of the BSC/RNC for supporting the cell load information when the BSC/RNC serves as the handover source. The parameter List Of BSC Capability/RNC capability list has a value option Support Load-based HO. Step 3 Run the command MOD MSFP to modify bit 13, 14 and 15 of software parameter 157. For description of the software parameter, see section 32.5.4 "Data Configuration Example." ----End

Mobile subscribers do not need to perform any operation for this service.

None.

The load-based handover has no impact on the existing performance measurement tasks.

None.
32.10 Reference
The reference of this service is 3GPP specifications, which are as follows: 3GPP TS 48.008, "Mobile Switching Centre - Base Station System (MSC-BSS) interface; Layer 3 specification,V5.12.0"
32-16
Issue 02 (2007-06-10)
3GPP TS 25.413, "Technical Specification Group Radio Access Network; UTRAN Iu interface RANAP signaling,V5.12.0"

Acronym/Abbreviation 3G 3GPP MSC HLR VLR RNC BSC Full Name The Third Generation 3rd Generation Partnership Project 2 Mobile-services Switching Center Home Location Register Visitor Location Register Radio Network Controller Base Station Controller
32.11 FAQ
Q: During an intra-MSC handover, the message sent by the BSC/RNC at the target side contains the cell load information, but the MSC does not transparently sent the information to the BSC/RNC at the source side. A: Run the command MOD BSC or MOD RNC, and select the value option Support Load-based HO of the parameter List Of BSC Capability or RNC capability list. Q: During an inter-MSC handover, the message sent by the BSC/RNC at the target side contains the cell load information, but the MSC at the target side does not transparently sent the information to the MSC at the source side. A: Run the command MOD MSFP to modify the value of the corresponding bit of software parameter 157, thus to configure the capability of supporting the load-based handover of the MSC at the target side. For the descriptions of software parameter 157, see 32.5.4 Step 3 "Set the software parameter."
Issue 02 (2007-06-10)
32-17
Contents
Contents
33 Union Subscriber Trace ........................................................................................................33-1
33.1 Service Description ...................................................................................................................................33-2 33.1.1 Function Code..................................................................................................................................33-2 33.1.2 Definition .........................................................................................................................................33-2 33.1.3 Benefits ............................................................................................................................................33-3 33.1.4 Application Scenario ........................................................................................................................33-3 33.1.5 Application Limitation .....................................................................................................................33-3 33.1.6 Others...............................................................................................................................................33-3 33.2 Availability ................................................................................................................................................33-4 33.2.1 Requirements for NEs......................................................................................................................33-4 33.2.2 Requirements for License ................................................................................................................33-4 33.2.3 Applicable Version ...........................................................................................................................33-4 33.3 Working Principle......................................................................................................................................33-4 33.3.1 Functions of NEs..............................................................................................................................33-4 33.3.2 Internal Processing of the System ....................................................................................................33-5 33.3.3 External Interface.............................................................................................................................33-5 33.4 Service Flow..............................................................................................................................................33-5 33.4.1 Trace Flow of Activation Message Received from the HLR During Location Update/Data Recovery ....................................................................................................................................................................33-5 33.4.2 Trace Flow of Activation Message Sent by the HLR.......................................................................33-6 33.4.3 Trace Flow of Deactivation Trace Sent by the HLR ........................................................................33-7 33.4.4 Trace Flow of the Initiation Call ......................................................................................................33-8 33.4.5 Trace Flow of the Termination Call .................................................................................................33-8 33.4.6 Trace Flow of the Originated Short Message...................................................................................33-9 33.4.7 Trace Flow of the Terminated Short Message..................................................................................33-9 33.4.8 Trace Flow of Power-On/Location Update ....................................................................................33-10 33.4.9 Trace Flow of Power-Off and Trace File Generated ......................................................................33-10 33.5 Data Configuration.................................................................................................................................. 33-11 33.5.1 Overview........................................................................................................................................ 33-11 33.5.2 Data Configuration at the MSOFTX3000 Side.............................................................................. 33-11 33.5.3 Data Configuration at the HLR Side .............................................................................................. 33-11 33.5.4 Data Configuration Examples ........................................................................................................ 33-11 33.5.5 Related Tables ................................................................................................................................33-12
Issue 02 (2007-06-10)
Contents
33.6 Service Management ...............................................................................................................................33-12 33.6.1 Operation by Carriers.....................................................................................................................33-12 33.6.2 Operations by Subscribers .............................................................................................................33-13 33.7 Charging and CDR ..................................................................................................................................33-13 33.8 Performance Management.......................................................................................................................33-13 33.9 Service Interaction ..................................................................................................................................33-14 33.10 Reference...............................................................................................................................................33-14 33.10.1 Specification ................................................................................................................................33-14 33.10.2 Glossary, Acronyms and Abbreviations .......................................................................................33-14
ii
Issue 02 (2007-06-10)
Figures
Figures
Figure 33-1 Trace flow of the activation message received from the HLR during location update/data recovery ...........................................................................................................................................................................33-6 Figure 33-2 Trace flow of the activation message sent by the HLR.................................................................33-7 Figure 33-3 Flow of the deactivation trace sent by the HLR............................................................................33-7 Figure 33-4 Trace flow of the initiation call.....................................................................................................33-8 Figure 33-5 Trace flow of the termination call.................................................................................................33-8 Figure 33-6 Trace flow of the originated short message ..................................................................................33-9 Figure 33-7 Trace flow of the terminated short message..................................................................................33-9 Figure 33-8 Trace flow of power-on/location update .....................................................................................33-10 Figure 33-9 Trace flow of the power-off ........................................................................................................33-10
Issue 02 (2007-06-10)
iii
Tables
Tables
Table 33-1 Function name and function code in the union subscriber trace.....................................................33-2 Table 33-2 Movements of mobile subscribers ..................................................................................................33-2 Table 33-3 Benefits for carriers ........................................................................................................................33-3 Table 33-4 NEs required to implement the union subscriber trace service.......................................................33-4 Table 33-5 Version of the Huawei UMTS products that support the union subscriber trace service................33-4 Table 33-6 Related tables of the union subscription trace ..............................................................................33-12 Table 33-7 Operation modes of the union subscriber trace.............................................................................33-12
iv
Issue 02 (2007-06-10)
33 Union Subscriber Trace
33
About This Chapter
Union Subscriber Trace
The following table lists the contents of this chapter. Describes The function code and definition of the service and the benefits of the service to carriers and mobile subscribers. The NEs required to implement the service, requirements for the license, and versions of the products applicable to the service. The functions of the NEs used to implement the service and the requirements on the networking. The flow of the service. The data configuration that must be performed at the MSOFTX3000 side and the UMG8900 side as well as the examples of data configuration. The operations that carrier and mobile subscribers must perform when the service is provided. The procedure for performing charging and generating CDRs when the service is provided. The influence of the service on performance measurement and the implementation of performance measurement. The association between the service and other services as well as the restrictions on each other. The standards and specifications with which the service complies and the glossary, abbreviations, and acronyms used in this chapter.
33.6 Service Management 33.7 Charging and CDR 33.8 Performance Management 33.9 Service Interaction 33.10 Reference
Issue 02 (2007-06-10)
33-1

Table 33-1 lists the mapping between function name and function code in the union subscriber trace. Table 33-1 Function name and function code in the union subscriber trace Name Union subscriber trace Code WMFD-121700
33.1.2 Definition
The union subscriber trace service indicates that the MSOFTX3000 can implement the HLRbased subscriber trace in the local office. That is, a subscriber trace task can be created and deleted in the HLR and the HLR notifies the MSC/VLR in which the subscriber is located to perform the trace. The trace mode can provide an efficient way to remove a designated failure, especially to process the complaint from subscribers. With the union subscriber trace, the running status of the network is checked in the view of the terminal subscribers. For each movement of mobile subscribers, including location update, power-on/off, mobile originated call (MOC)/mobile terminated call (MTC), originated/terminated short message or switchover, a trace file is generated and is saved in the UNIONTRACE directory under the installation directory of the BAM in the MSOFTX3000. Besides the messages between entities, the MOSFTX3000 controls whether to trace messages and logs inside each module. Table 33-2 lists the movements of mobile subscribers. Table 33-2 Movements of mobile subscribers Name Activation subscriber trace during location update and data recovery Activation trace sent by the HLR Deactivation trace sent by the HLR MOC trace MTC trace Originated short message trace Terminated short message trace Power-on/Location update trace Definition The activation trace message is received from the HLR in the flow of location update and data recovery. The activation trace sent by the HLR is received. The deactivation trace sent by the HLR is received. The file of MOC trace is generated. The file of MTC trace is generated. The file of originated short message trace is generated. The file of terminated short message trace is generated. The file of power-on/location update is generated.
33-2
Issue 02 (2007-06-10)
Name Power-off trace Switchover trace Subscriber trace record saved in the disk Overtime trace file deleted periodically
Definition The file of power-off trace is generated. The file of switchover trace is generated. The MSOFTX3000 generates the trace file name based on the trace reference and trace dialog number, and saves the trace content to the file. The storage life of trace files of all subscribers is seven days (It can be configured based on the actual conditions). The files exceeding the time limitation will be deleted during the timeout file clearance. The maximum number of trace tasks and days to preserve files can be configured. You can query, add or deleted a trace based on Trace reference and IMSI.
Union trace parameters configuration Trace tasks queried, added and deleted
33.1.3 Benefits
Table 33-3 lists the benefits for carriers. Table 33-3 Benefits for carriers Beneficiary Carriers Description The union subscriber trace is an efficient way to remove a designated failure, especially to process the compliant from subscribers.

The service is applied to all the markets of the GSM and the UMTS R99/R4.
33.1.5 Application Limitation

As a subscriber interface trace, the union subscriber trace occupies the resource of trace tasks. Assume that the system can support 64 trace tasks (subscriber interface trace and signaling trace) simultaneously. If the BAM has started 60 trace tasks, the union subscriber can start only the remained four tasks. At the same time, the number of the union subscriber trace tasks cannot exceed 32. The value can be set in SET UTRCCFG.
33.1.6 Others
The service requires the related HLR to support the union subscriber trace.
Issue 02 (2007-06-10)
33-3
33.2 Availability
The HLR must interwork with the MSC server to implement the union subscriber trace service. Table 33-4 lists the NEs required to implement the union subscriber trace service. Table 33-4 NEs required to implement the union subscriber trace service MS/ UE BTS/No deB BSC/ RNC MSC Server MGW SGSN GGSN HLR

The union subscriber trace is a basic service in the HUAWEI UMTS wireless core network. No license is required for the availability of the service.

Table 33-5 lists the version of the Huawei UMTS products that support the union subscriber trace service. Table 33-5 Version of the Huawei UMTS products that support the union subscriber trace service Product MSC server MSOFTX3000 Applicable Version V100R005C10

The HLR mainly implements the following functions: The HLR allocates the subscriber trace task to the MSOFTX3000 in the flow of location update or data recovery. The HLR allocates the union subscriber tasks to the MSOFTX3000 in an independent flow. The HLR sends the activation and deactivation trace commands to the MSOFTX3000 to start or terminate a trace task. The MSOFTX3000 mainly implements the following functions: The MSOFTX3000 transfers the trace request to the BAM after it receives the trace request from the HLR. The MSOFTX3000 notifies the BAM to delete the existing trace task when it receives the deactivation trace command from the HLR.
33-4
Issue 02 (2007-06-10)

The flow of processing the union subscriber trace inside the system is as follows: 1. The HLR allocates the subscriber trace task to the MSOFTX3000 in the flow of location update or data recovery. The HLR also can allocate the union subscriber tasks to the MSOFTX3000 in an independent flow. After receiving the trace request from the HLR, the MSOFTX3000 transfers the request to the BAM, containing Trace reference, IMSI, Trace type (Union subscriber trace), Inner trace, and Task valid days are added. After receiving the request, the BAM determines whether the number of trace tasks exceeds the limitation. If the number of trace tasks exceeds the limitation, the BAM returns the startup failure result. If the request is allowed, record the cell of the trace task. The BAM sends the trace startup message and the User_TRC to the SMU. Based on the original message (starting the subscriber trace), the Trace reference, Trace type (union subscriber trace), IMSI, Inner trace, and Task valid days. After receiving the trace startup message from the BAM, the SMU generates the trace handle to record the trace task and trace information reported by the BAM. Then, the SMU broadcasts the trace startup message to each CCU module. After the MSOFTX3000 acquires the trace handle, a trace file is generated for each movement of traced subscribers (location update, power-on/off, MOC/MTC and originated/terminated short message). The file is saved in a designated directory on the BAM and it will be deleted when it exceeds a specific period. The format of the trace file must be consistent with that of the .tmf trace file. The trace file must be obtained manually. The HLR can also allocate a deactivation trace command to terminate a trace task. After receiving message, the MSOFTX3000 transfers the message to the BAM. The BAM notifies the TRC module to delete the existing trace task and returns the response to the MSOFTX3000.
2.
3.
4.
5.

The interface and signaling protocol between the MSOFTX3000 and the HLR is based on 3GPP TS 29.002: "Mobile Application Part (MAP) specification".
33.4 Service Flow

33.4.1 Trace Flow of Activation Message Received from the HLR During Location Update/Data Recovery
Figure 33-1 shows the trace flow of the activation message received from the HLR during location update/data recovery.
Issue 02 (2007-06-10)
33-5
Figure 33-1 Trace flow of the activation message received from the HLR during location update/data recovery
MSC server UPDATE_LOCATION_REQ/ RESTORE_DATA_REQ ACTIVATE_TRACE_MODE_IND After the activation subscriber trace message isreceived from the HLR, the union subscriber trace is performed. ACTIVATE_TRACE_MODE_RSP UPDATE_LOCATION_CNF/ RESTORE_DATA_CNF HLR
After the MSOFTX3000 sends the location update/ data recovery message, if the HLR does not sends the activation subscriber request, the processing is the same as that in normal cases. If the HLR sends the activation subscriber trace request, the processing process is as follows: 1. Configure Support UNIONTRC in the function configuration table of the MSOFTX3000. If it is set to No, the SOFTX3000 notifies the HLR that the device does not respond. If it is set to Yes, the MSOFTX3000 determines whether the message contains mandatory information elements, including Trace Reference and Trace Type. (In this case, the IMSI is an optional information element. If the IMSI does not exist, use the IMSI of the current subscriber). If the mandatory information elements are not contained, the MSOFTX3000 sends the data loss message to the HLR. If the IMSI is contained, but it is not consistent with the IMSI of the subscriber after location update/data recovery, the MSOFTX3000 sends the data not expected message to the HLR. If the IMSI contained is consistent with that of the current subscriber, the MSOFTX3000 transfers the trace request of the HLR to the BAM. Then, the BAM performs the union subscriber trace to the subscribers. The MSOFTX3000 returns the union subscriber trace result to the HLR.
2.
3.
4.
33.4.2 Trace Flow of Activation Message Sent by the HLR

Figure 33-2 shows trace flow of the activation message sent by the HLR.
33-6
Issue 02 (2007-06-10)
Figure 33-2 Trace flow of the activation message sent by the HLR
MSC server HLR
ACTIVATE_TRACE_MODE_IND
After the activation subscriber trace message is received from the HLR, the union subscriber trace is performed.
ACTIVATE_TRACE_MODE_RSP
The trace flow of the activation message sent by the HLR is as follows: 1. Configure Support UNIONTRC in the function configuration table of the MSOFTX3000. If Support UNIONTRC is set to No, the SOFTX3000 notifies the HLR that the device does not respond. If Support UNIONTRC is set to Yes, the MSOFTX3000 determines whether the message contains mandatory information elements, including IMSI, Trace Reference and Trace Type. If the mandatory information elements are not contained, the MSOFTX3000 sends the data lost message to the HLR. If the subscriber data exists in the MSOFTX3000, the MSOFTX3000 starts the union subscriber trace. If the subscriber data does not exist in the MSOFTX3000, the MSOFTX3000 returns the unknown subscriber response to the HLR. The MSOFTX3000 returns the union subscriber trace result to the HLR.
2.
3.
4.
33.4.3 Trace Flow of Deactivation Trace Sent by the HLR

Figure 33-3 shows flow of the deactivation trace sent by the HLR. Figure 33-3 Flow of the deactivation trace sent by the HLR
MSC Server HLR
DEACTIVATE_TRACE_MODE_IND
After the deactivation subscriber trace is received from the HLR, the union subscriber trace is deleted.
DEACTIVATE_TRACE_MODE_RSP
The trace flow of the deactivation message sent by the HLR is as follows:
Issue 02 (2007-06-10)
33-7
1.
Configure Support UNIONTRC in the function configuration table of the MSOFTX3000.If Support UNIONTRC is set to No, the SOFTX3000 notifies the HLR that the device does not respond. If Support UNIONTRC is set to Yes, and the trace task to be deleted exists in the MSOFTX3000, the MSOFTX3000 deletes the trace task and returns the deleting succeeded message to the HLR. If the trace task to be deleted does not exist, the MSOFTX3000 returns the deleting failed message to the HLR.
2.
33.4.4 Trace Flow of the Initiation Call

Figure 33-4 shows the trace flow of the initiation call. Figure 33-4 Trace flow of the initiation call
MS MSC Server
CM_Serv_Req
The MOC union subscriber trace is performed and a trace file is generated.
After a mobile subscriber in the local office initiates the call service request, the MSOFTX3000 performs the initiation call trace and generates a union subscriber trace file.
33.4.5 Trace Flow of the Termination Call

Figure 33-5 shows the trace flow of the termination call. Figure 33-5 Trace flow of the termination call
MSC Server
IAM Before the called party's data is acquired, the MTC union subscriber trace is performed and a trace file is generated.
33-8
Issue 02 (2007-06-10)
After receiving the call service request from the peer office, but before acquiring the subscriber data of the called party, the MSOFTX3000 performs the union subscriber trace of the termination call and generates a union subscriber trace file. For an intra-office call, the IAM message does not exist. The MSC server generates the trace file after internal processing of the termination call.
33.4.6 Trace Flow of the Originated Short Message

Figure 33-6 shows the trace flow of the originated short message. Figure 33-6 Trace flow of the originated short message
MS MSC Server
CM_Serv_Req
The union subscriber trace of the originated short message is performed and a trace file is generated.
After a mobile subscriber in the local office initiates the short message service request, the MSOFTX3000 performs the originated trace and generates a union subscriber trace file.
33.4.7 Trace Flow of the Terminated Short Message

Figure 33-7 shows the trace flow of the terminated short message. Figure 33-7 Trace flow of the terminated short message
MSC Server SMC
MT_FORWARD_SM
The unin subscriber trace of the terminated short message is performed and a trace file is generated.
After the SMC sends the short message request, the MSOFTX3000 performs the union subscriber trace of the terminated short message and generates the union subscriber trace file.
Issue 02 (2007-06-10)
33-9
33.4.8 Trace Flow of Power-On/Location Update

Figure 33-8 shows the trace flow of power-on/location update. Figure 33-8 Trace flow of power-on/location update
MS MSC Server
UpdateLocation_Request
The power-on/location update trace is performed and a trace file is generated.
After the power-on/location update of an MS, the MSOFTX3000 performs the union subscriber trace and generates a trace file.
33.4.9 Trace Flow of Power-Off and Trace File Generated

Figure 33-9 shows the trace flow of the power-off. Figure 33-9 Trace flow of the power-off
MS MSC server
IMSIDetach
Before the MS reports the power-off event, the power-off trace file is generated.
When the MS reports the power-off event, the MSOFTX3000 performs the power-off trace and generates s trace file.
33-10
Issue 02 (2007-06-10)

33.5.1 Overview
The union subscriber trace service requires data configuration in the MSOFTX3000 only. You can run SET UTRCCFG to set union subscriber trace function.

Run SET UTRCCFG to set related parameters of the union subscriber trace, including: Support UNIONTRC: It indicates whether the local office supports the union subscriber trace function. Max Trace Number: It indicates that the maximum number of trace tasks performed by the MSOFTX3000. Its value range is from 8 to 32 and it is set to 16 by default. Days To Preserve File: It indicates the days to preserve the trace file. Its value range is from 1 to 10 and it is set to 7 by default. File Delete Time: It indicates the time to delete the trace file when preserved days of the file exceed. The input format is HH:MM, such as 03:10.

For data configuration of the union subscriber trace in the HLR, refer to the related HLR Configuration Guide.

An office needs to enable the union subscriber trace function and add a union subscribe trace task. The HLR connected to the office needs to support the union subscriber trace.
Step 1 Configure that the local office supports the union subscription trace. Description Script Remark To set union subscriber trace configuration, set Support UNIONTRC to Yes. SET UTRCCFG: IFSUPUNIONTRC=YES; Adopt the default value for Max Trace Number, Days To Preserve File and File Delete Time.
Step 2 Add a union subscriber trace task.
Issue 02 (2007-06-10)
33-11
Description
To add a union subscriber trace task, set Trace reference to 1, IMSI to 460077552000322, Trace type to 48, Task valid days to 10 and Inner trace to Yes. ADD UTRCTSK: TRACREFERENCE=1, IMSI=K'460077552000322, TRACETYPE=48, VALIDDAYS=10, IFINNERTRACE=YES;
Script
----End
33.5.5 Related Tables

Table 33-6 lists the related tables of the union subscription trace. Table 33-6 Related tables of the union subscription trace Name tbl_UnionTrcTsk Function To save the trace task Related Commands ADD UTRCTSK LST UTRCTSK RMV UTRCTSK tbl_UnionTrc To set the related parameters of the union subscriber trace LST UTRCCFG SET UTRCCFG

Table 33-7 lists the operation modes of the union subscriber trace. Table 33-7 Operation modes of the union subscriber trace Modes Operation by carriers Where to Operate HLR Service Operations Send the activation and deactivation command of the union subscriber trace. Add and delete the trace task. None
MSOFTX3000 Operation by subscribers None
33.6.1 Operation by Carriers

On the MSOFTX3000 maintenance client, carriers can control whether to support the union subscriber trace in the local office. At the same time, the carriers can add, delete or query trace tasks.
33-12
Issue 02 (2007-06-10)
Adding a Trace Task

To add a trace task, perform as follows: Step 1 Run SET UTRCCFG to configure that the local office supports the union subscriber trace. Set Support UNIONTRC to Yes. Step 2 Run ADD UTRCTSK to add a trace task. TRACREFERENCE is trace reference and IMSI is for the subscriber to be traced. After receiving the request, the BAM queries the tbl_UnionTrc, and checks whether to configure Support UNIONTRC. If it is set to No, the response of not supported is returned to the client. If it is set to Yes, add a trace task. ----End
Deleting a Trace Task

Run RMV UTRCTSK to delete a trace task. TRACREFERENCE is trace reference and IMSI is for the subscriber to be deleted. After receiving the request, the BAM queries the tbl_UnionTrc, and checks whether to configure Support UNIONTRC. If it is set to No, the response of not supported is returned to the client. If it is set to Yes, check whether the task exists. If the task does not exist, the response of no task exist is returned to the client. If the task exists, the MSOFTX3000 transfers the request to the TRC module in the SMU and returns the response to the client. In addition, the MSOFTX3000 deletes timeout trace files and timeout trace task process in a designated time every day.
Querying a Trace Task

Run LST UTRCTSK to query trace tasks on the client through the task reference or the IMSI of the traced subscriber.
Setting Parameters of the Union Subscriber Trace

Run SET UTRCCFG to set Support UNIONTRC, Max Trace Number (from 8 to 32), Days To Preserve File and File Delete Time. (The maximum length is ten days.)

None.

None.
33.8 Performance Management

None.
Issue 02 (2007-06-10)
33-13

None.
33.10 Reference
33.10.1 Specification
The reference lists for the service are as follows: 3GPP TS 29.002: "Mobile Application Part (MAP) specification". 3GPP TS 52.008: "GSM Subscriber and Equipment Trace". 3GPP TS 32.432: "Performance measurement: File format definition".

Glossary
Glossary Trace handle Description Trace handle is a message generated after the SMU receives the trace startup message of the BAM to identify the trace task. The message records the trace task and trace message reported by the BAM and is broadcasted to each CCU module by the SMU.

Acronyms/Abbreviations BAM CCU HLR IMSI LCS SMU USSD Full Name Background Administration Module Calling Control Unit Home Location Register International Mobile Subscriber Identity Location Service System Management Unit Unstructured supplementary service data
33-14
Issue 02 (2007-06-10)
Contents
Contents
34 Service Restriction by Cell ...................................................................................................34-1
34.1 Service Description ...................................................................................................................................34-2 34.1.1 Function Code..................................................................................................................................34-2 34.1.2 Definition .........................................................................................................................................34-2 34.1.3 System Specifications ......................................................................................................................34-3 34.1.4 Benefits ............................................................................................................................................34-3 34.1.5 Application Scenario ........................................................................................................................34-3 34.1.6 Application Limitations....................................................................................................................34-3 34.2 Availability ................................................................................................................................................34-4 34.2.1 Requirement for NEs .......................................................................................................................34-4 34.2.2 Requirement for License..................................................................................................................34-4 34.2.3 Applicable Version ...........................................................................................................................34-4 34.2.4 Others...............................................................................................................................................34-4 34.3 Working Principle......................................................................................................................................34-4 34.3.1 Functions of the NEs........................................................................................................................34-4 34.3.2 Service Implementation ...................................................................................................................34-4 34.3.3 External Interfaces ...........................................................................................................................34-5 34.4 Service Flow..............................................................................................................................................34-5 34.4.1 Location Update Message Flow.......................................................................................................34-6 34.4.2 Originated Service Message Flow ...................................................................................................34-6 34.4.3 Terminated Service Message Flow ..................................................................................................34-8 34.5 Data Configuration....................................................................................................................................34-9 34.5.1 Overview..........................................................................................................................................34-9 34.5.2 Data Configuration at the MSOFTX3000 Side................................................................................34-9 34.5.3 Data Configuration Examples ........................................................................................................34-17 34.6 Service Management ...............................................................................................................................34-24 34.7 Charging and CDR ..................................................................................................................................34-24 34.8 Performance Measurement......................................................................................................................34-24 34.8.1 Index Description...........................................................................................................................34-24 34.8.2 Implementation Principle...............................................................................................................34-24 34.9 Service Interaction ..................................................................................................................................34-24 34.9.1 Enhanced Roaming Restriction and ZC Roaming Restriction .......................................................34-25
Issue 02 (2007-06-10)
Contents
34.10 Reference...............................................................................................................................................34-25 34.10.1 Specifications...............................................................................................................................34-25 34.10.2 Acronyms and Abbreviations .......................................................................................................34-25 34.11 FAQ .......................................................................................................................................................34-26
ii
Issue 02 (2007-06-10)
Figures
Figures
Figure 34-1 Location update message flow......................................................................................................34-6 Figure 34-2 Originated service message flow ..................................................................................................34-7 Figure 34-3 Terminated service message flow .................................................................................................34-8
Issue 02 (2007-06-10)
iii
Tables
Tables
Table 34-1 Function code .................................................................................................................................34-2 Table 34-2 Benefits...........................................................................................................................................34-3 Table 34-3 Earliest version applicable to local-based service restriction, cell-based charging, and service restriction by cell...............................................................................................................................................34-4 Table 34-4 Enabling or disabling command ...................................................................................................34-10 Table 34-5 Commands to set non-preferential cell tariff ................................................................................34-10 Table 34-6 Commands to set cell and location area relationship.................................................................... 34-11 Table 34-7 Commands to add ZC ...................................................................................................................34-13 Table 34-8 Commands to edit location group.................................................................................................34-14 Table 34-9 Commands to edit roaming-restricted groups...............................................................................34-15 Table 34-10 Commands to edit user group roaming right ..............................................................................34-16
iv
Issue 02 (2007-06-10)
34
About This Chapter
Service Restriction by Cell
The following table lists the contents of this chapter. Describes The function code and definition of the service and the benefits of the service to carriers and mobile subscribers. The NEs required to implement the service, requirements for the license, and versions of the products applicable to the service. The functions of the NEs used to implement the service and the requirements on the networking. The flow of the service. The data configuration that must be performed at the MSOFTX3000 side and the UMG8900 side as well as the examples of data configuration. The operations that carrier and mobile subscribers must perform when the service is provided. The procedure for performing charging and generating CDRs when the service is provided. The influence of the service on performance measurement and the implementation of performance measurement. The association between the service and other services as well as the restrictions on each other. The standards and specifications with which the service complies and the glossary, abbreviations, and acronyms used in this chapter. The frequently asked questions related to the service and the solutions.
34.11 FAQ
Issue 02 (2007-06-10)
34-1

The function code is listed in Table 34-1. Table 34-1 Function code Name Service restriction by cell Code WMFD-050800
34.1.2 Definition
Service restriction by cell includes three sub-features: cell-based charging, local-based service restriction, and service restriction by cell. Name Cell-based charging Definition When using a service, the mobile station (MS) checks whether the subscriber's location maps a zone code (ZC) and then writes down traffic code (TC) in the CDR based on the tariff information of the zone code. Also, the MSC informs whether the subscriber is in preferential cell through USSD. The billing center performs preferential billing according to the traffic code. When a subscriber performs location update or uses a service, the MS judges whether the subscriber's location belongs to a zone code, then makes the following logical judgment based on the zone service. Subscriber is allowed or not allowed to perform location update. Subscriber is allowed or not allowed to originate or terminate calls. Subscriber is allowed or not allowed to use short message service (SMS). Subscriber is allowed or not allowed to use supplementary services that are irrelevant to calls. Subscriber is allowed or not allowed to use the location service (LCS). Subscriber is allowed or not allowed to use the unstructured supplementary service data (USSD) service.
Local-based service restriction
34-2
Issue 02 (2007-06-10)
Name Service restriction by cell (SRC)
Definition The current enhanced roaming restriction and ZC roaming restriction can only provide precision at location area level, while service restriction by cell provides cell-based service control. It is classified into two types: SRC in ZC mode SRC in user group mode

None.
34.1.4 Benefits
The benefits are listed in Table 34-2. Table 34-2 Benefits Beneficiary Carriers Description Service restriction by cell allows carriers to set forth customized mobile service plan, attracting more subscribers with diverse means and encouraging consumption. Service restriction by cell allows subscribers to select most suitable mobile service option, obtaining more preferential tariff.
Subscribers

The service is applicable to all GSM and UMTS R99/R4 networks.

A subscriber makes a call in cell 1 where making a call is allowed hands over to cell 2 where making a call is restricted. Under such circumstances, in enhanced roaming restriction, ZC roaming restriction, local-based service restriction, and service restriction by cell, the call can be held but the subscriber cannot use or receive new service in cell 2 (unless otherwise configured). With cell-based charging, when handover occurs, the billing uses the tariff of the cell where the call is set up. For non-traffic service types (short message, USSD, and LCS) and new calls, the billing uses the preferential tariff of the cell where the service is originated. For the USSD service, when a subscriber is using USSD, the system using USSD to notify subscriber may cause problem in subscriber operation. Hence cell-based charging does not use USSD to notify the subscriber of the current tariff information for supplementary services (including USSD service).
Issue 02 (2007-06-10)
34-3
34.2 Availability
Local-based service restriction, cell-based charging, and service restriction by cell require MSC and HLR.

Local-based service restriction, cell-based charging, and service restriction by cell are optional features of Huawei MSOFTX3000. These features need license.

Huawei MSOFTX3000 version applicable to local-based service restriction, cell-based charging, and service restriction by cell is listed in Table 34-3. Table 34-3 Earliest version applicable to local-based service restriction, cell-based charging, and service restriction by cell Product MSC server MSOFTX3000 Applicable Version V100R005C10
34.2.4 Others
None.

The MSC server and VLR perform signaling processing, data analysis, billing, and USSD notice sending for the service. The HLR9820 only needs to support ZC. It inserts the subscriber data with ZC subscription data into VLR.
34.3.2 Service Implementation

With cell-based charging USSD notice, the system uses the subscriber's IMSI or MSISDN to query the cell-based charging USSD notice configuration table to obtain the notice content name, and then uses the cell-based charging USSD notice content table to obtain details about USSD notice. With local-based service restriction, cell-based charging, and SRC in ZC mode, the system first obtains Location number name according to the cell where the subscriber is in, and then obtains Local subscription ZC sets name, Cell billing ZC sets name, or Service restriction by cell ZC sets name, hence using different ZC set names to query ZC table to obtain different attribute values.
34-4
Issue 02 (2007-06-10)
With SRC in user group mode, the system obtains the location number name (based on the cell where the subscriber is in), the location group name, the subscriber group name (based on the subscriber's IMSI, MSISDN or subscriber's roaming subscriber type), and finally SRC restricted service list (based on the location group and subscriber group) and determines whether to restrict roaming. Implementation of local-based service restriction The system uses Local subscription ZC sets name corresponding to the cell to query the ZC table and to obtain all the ZC of the ZC set, obtains intersection with the list of the ZCs subscribed to in the HLR. If intersection exists, it means the subscriber is allowed to continue the service. If intersection does not exist, it means the subscriber is outside the roaming area. The system further obtains the ZC of highest priority in the ZC set. Based on the service list of local-based service restriction, which is configured by ZC, and the service that the subscriber is using, the system determines whether to allow the subscriber to continue the service. Implementation of service restriction by cell Service restriction by cell has two types: SRC in ZC mode & SRC in user group mode.
With SRC in ZC mode, the system uses Service restriction by cell ZC set name to query the ZC table to obtain all ZC of the ZC set, and obtains intersection with the list of the ZCs subscribed to in the HLR. If intersection exists, the system queries the SRC restricted service list and decides whether to allow the subscriber continuing the service. With SRC in user group mode, the system uses location number name of the cell and subscriber identification (IMSI/MSISDN/roaming subscriber type) to query the home subscriber group to check whether roaming is allowed. If not, the system restricts the subscriber from continuing. If yes, the system checks the SRC prohibit service list and then decides whether to allow the subscriber to continue.
Implementation of cell-based charging The system uses Cell billing ZC sets name of the cell to obtain all ZC of the ZC set and then obtains intersection with the list of the ZCs subscribed to in the HLR. If intersection exists, that is, if subscriber is in preferential cell, then the system obtains the tariff corresponding to the ZC of highest priority in the intersection. If intersection does not exist, it means the subscriber is not in preferential cell and the system obtains the default non-preferential tariff value. The system judges whether to deliver USSD notice to subscriber. If yes, the system queries the corresponding USSD notice content depending on whether the subscriber is in preferential cell. If not, no USSD notice is delivered and the subscriber continues the service. After the service is over, the CDR is filled in with the service traffic code.
If delivering USSD notice fails, the service is not affected.

None.
34.4 Service Flow

In the following section, it is assumed that the carrier provides local-based service restriction service restriction by cell, and cell-based charging. If they are not provided, the existing flow is not affected.
Issue 02 (2007-06-10)
34-5
34.4.1 Location Update Message Flow

Figure 34-1 shows the location update message flow. Figure 34-1 Location update message flow
UE/MS MSOFTX3000 HLR
LocationUpdate_REQ
Authentication_Req Authentication_Rsp UpdateLocation_REQ InsertSubscriberData_IND
InsertSubscriberData_RSP UpdateLocation_RSP LocationUpdate_Accept
In the location update flow, upon receiving the InsertSubscriberData_IND message, the VLR performs ZC LIST check to see if the ZC LIST that the subscriber registers in HLR is configured in VLR. When the system supports ZC roaming restriction and local-based service restriction, if they are configured, it means local VLR has areas where subscriber roaming is allowed and hence subscriber registration is allowed; if they are not configured, it means the local VLR has no areas where subscriber roaming is allowed and hence VLR responds with location update refusal. When the system does not support ZC roaming restriction and local-based service restriction, the existing flow is not affected.
34.4.2 Originated Service Message Flow

Figure 34-2 shows the originated service message flow.
34-6
Issue 02 (2007-06-10)
Figure 34-2 Originated service message flow

UE/MS CM_Service_Request Authentication_Req Authentication_Rsp TMSI_Reallocation_Command TMSI_Reallocation_Complete Cm_Service_Accept MSOFTX3000
Setup/CPDATA/(SS)/ In the case of short message origination, it belongs to another independent flow.
Register Facility Release_Complete
The succeeding flow is the same as that of the origination of a normal call or short message.
If the roaming of calls, short messages, and location service are restricted, then the system returns CM_Service_Reject. If roaming is allowed and the subscriber has not subscribed to ZC, then the existing flow is not affected. If roaming is allowed and the subscriber has subscribed to ZC, then the processing is as follows: In case of an originated call, the message upon completion of access flow is Setup. The system determines the new services, local-based service restriction and service restriction by cell, based on GSM BC sent by the MS. If the originated call service is not allowed, then the system returns CMRelease and ends the call flow. If the originated call service is allowed, then the system checks the caller data in the call flow, then inserts USSD billing notice, sends USSSD, and continues the call. In case of an originated short message, the short message upon completion of access flow is CPDATA. Upon completing subscriber data check in the short message flow, the system restarts another flow that is parallel to the originated short message to deliver USSD notice. The short message flow remains unchanged. In the call service, USSD billing notice is embedded in the call flow, whereas in the short message flow, USSD billing notice flow is parallel to the short message flow. The location service does not perform USSD notice and continues the service.
Issue 02 (2007-06-10)
34-7
34.4.3 Terminated Service Message Flow

Figure 34-3 shows the terminated service message flow. Figure 34-3 Terminated service message flow
MSC/VLR MS/UE
Paging
PageResponse
Authentication, encryption, TMSI reallocation
Register Facility Release_Complete
In the case of short message termination, it belongs to another independent flow.
The succeeding flow is the same as that of the origination of a normal call or short message
If roaming of call service, short message service, and location service are restricted, then CMService_Reject is returned. If roaming is allowed and the subscriber has not subscribed to ZC, then the existing flow is not affected; if roaming is allowed and the subscriber has subscribed to ZC, then the processing is as follows: In case of a terminated call, upon completion of the access, the system determines the new services, local-based service restriction and service restriction by cell, based on GSM BC. If the terminated call service is not allowed, then the system returns CMRelease and ends the call flow. If the terminated call service is allowed, then the system completes the access flow, inserts USSD billing notice, sends USSD, and continues the call. In case of a terminated short message, upon completion of the access, the system restarts another flow that is parallel to the originated short message flow to deliver USSD notice.
34-8
Issue 02 (2007-06-10)
The short message flow is not affected. In the call service, USSD billing notice is embedded in the call flow, whereas in the short message service, USSD billing notice flow is parallel to the short message flow. The location service or supplementary service (including USSD service) do not perform USSD notice and continue the service. The location service does not perform USSD notice and continues the service.

34.5.1 Overview
This section describes data configuration at the MSOFTX3000 side.

The data configuration includes configuring data for enabling or disabling the following function: Local-based service restriction Cell-based charging USSD notice function for cell-based charging Service restriction by cell in ZC mode Service restriction by cell in subscriber group mode
Enabling or Disabling
Run SET MAPACCFG to enable or disable local-based service restriction on the MSOFTX3000. The parameters are explained as follows: Support local subscription function This parameter is used to enable or disable local-based service restriction on the MSOFTX3000. The value options are: No Yes Support cell billing function This parameter is used to enable or disable the cell-based charging function of the MSOFTX3000. The value options are: No Yes Cell billing USSD notice list This parameter is used to enable or disable USSD notice function under cell-based charging on the MSOFTX3000, and the services that send USSD notice. The value options are: Select all Clear all Notify when calling Notify when short message
Issue 02 (2007-06-10)
34-9
USSD notice function is a function of cell-based charging. It is effective only when cell-based charging is enabled. If cell-based charging is disabled, even if USSD notice is enabled, no USSD notice will be delivered to handset.
Support SRC in ZC mode This parameter is used to enable or disable service restriction by cell in ZC mode on the MSOFTX3000. The value options are: No Yes Support SRC in user group mode This parameter is used to enable or disable service restriction by cell in subscriber group mode on the MSOFTX3000. The value options are: No Yes The enabling or disabling command is listed in Table 34-4. Table 34-4 Enabling or disabling command Command SET MAPACCFG LST MAPACCFG Description MAP Function Config table. The command enables or disables local-based service restriction. Lists details of MAP Function Config table
Cell-based charging Non-preferential Cell Default Tariff Setting

Run SET MAPPARA to set non-preferential cell default tariff on the MSOFTX3000. The parameters are explained as follows: Default TC value It is a non-preferential cell default tariff, used to set the tariff for a subscriber using service at non-preferential cell. The value range is: 0255. A value within 0255 corresponds to a tariff. The particulars are determined by the carrier according to their marketing policy. Commands to set non-preferential cell tariff are listed in Table 34-5. Table 34-5 Commands to set non-preferential cell tariff Command SET MAPPARA LST MAPPARA Description MAP Function Parameter table. The command sets nonpreferential cell default tariff. Lists details of MAP Function Parameter table.
34-10
Issue 02 (2007-06-10)
Location Area Cell Command Setting

Run ADD LAISAI (LAIGCI) to set the relationship between cell and location area. The parameters are explained as follows: Service area identity It is 3G service area number. When MSOFT3000 is used in 2G network, the corresponding command is ADD LAIGCI and the corresponding parameter is Global cell ID. Location area category It specifies whether the value is location area or cell. The value options are: LAI: Location area ID SAI (GCI in 2G): Cell Location number name It is location number name for identifying. This parameter is referenced by the LOCGRP command. Commands to set cell and location area relationship are listed in Table 34-6. Table 34-6 Commands to set cell and location area relationship Command ADD LAISAI MOD LAISAI RMV LAISAI LST LAISAI Description Adds 3G location area or service area information configurations. The command for 2G is ADD LAIGCI. Modifies 3G location area or service area information configurations. The command for 2G is MOD LAIGCI. Deletes 3G location area or service area information configurations. The command for 2G is RMV LAIGCI. Lists 3G location area or service area information configurations. The command for 2G is LST LAIGCI.
ZC Command Setting
Run ADD ZC to add ZC for local-based service restriction, cell-based charging, and service restriction by cell. The parameters are explained as follows: ZC config name It identifies the name of the new record. Zone code It defines zone code of the local MSC in the global network. Zone code name Zone code name, for easy of identification. Zone code type
Issue 02 (2007-06-10)
34-11
Subscribers specify the functions that ZC is used in. The value options are: ZC roaming restrict: The ZC is used in ZC roaming restriction. ZC cell billing: The ZC is used in cell-based charging. Local-based service restriction: The ZC is used in local-based service restriction. Service restriction by cell: The ZC is used in SRC in ZC mode. Zone code sets name It specifies the name of the ZC set where the ZC belongs to, referenced by the LOCGRP command. Zone code priority It indicates the ZC priority in a ZC set. The value range is 0127. TC value When Zone code type is set to ZC cell billing, this parameter is effective. It is used to set preferential cell tariff. The value range is 0255. A value within 0255 corresponds to a tariff. The particulars are determined by the carrier in their marketing policy. LS permit service list When Zone code type is set to Local-based service restriction, this parameter is effective. It is used to set the list of services where local-based service restriction is enabled. The value options are: Select all Clear all MOCALL (Subscriber originated call) MTCALL (Subscriber terminated call) SMMO (Subscriber originated short message) SMMT (Subscriber terminated short message) MOUSSD (Subscriber originated USSD) MTUSSD (Network originated USSD) MOLCS (Mobile originated location request) MTLCS (Mobile terminated location request) SS (Call-independent supplement service operation) SRC prohibit service list When Zone code type is set to Service restriction by cell, this parameter is effective. It is used to set list of SRC in ZC mode. The value options are: Select all Clear all MOCALL (Subscriber originated call) MTCALL (Subscriber terminated call) SMMO (Subscriber originated short message) SMMT (Subscriber terminated short message) MOUSSD (Subscriber originated USSD) MTUSSD (Network originated USSD)
34-12
Issue 02 (2007-06-10)
MOLCS (Mobile originated location request) MTLCS (Mobile terminated location request) MOGSMBS20(Mobile originated GSMBS20) MTGSMBS20(Mobile terminated GSMBS20) MOGSMBS30(Mobile originated GSMBS30) MTGSMBS30(Mobile terminated GSMBS30) MOGSMTS61(Mobile originated GSMTS61) MTGSMTS61(Mobile terminated GSMTS61) MOGSMTS62(Mobile originated GSMTS62) MTGSMTS62(Mobile terminated GSMTS62) MOGSMTS63(Mobile originated GSMTS63) MTGSMTS63(Mobile terminated GSMTS63) MOALS (Mobile originated ALS) MTALS (Mobile terminated ALS) MOGSMBS40(Mobile originated GSMBS40) MTGSMBS40(Mobile terminated GSMBS40) MOGSMBS50(Mobile originated GSMBS50) MTGSMBS50(Mobile terminated GSMBS50) The commands to add ZC are listed in Table 34-7. Table 34-7 Commands to add ZC Command ADD ZC MOD ZC RMV ZC LST ZC Description Adds zone code configuration. Modifies zone code configuration. Deletes zone code configuration. Lists zone code configuration.
LOCGRP Command Setting

Run ADD LOCGRP to set the relationship between location number and location number group and the relationship between location number and ZC set. The parameters are explained as follows: Location number name This parameter is configured in ADD LAISAI (GCI) command. Local number group name It defines a location group. Multiple location numbers can belong to the same location group. This parameter is referenced in ADD USROAMRT. Roaming restrict ZC sets name
Issue 02 (2007-06-10)
34-13
In the roaming-restriction configuration, ZC is referenced from the ZC table according to the roaming-restricted ZC set. It is related to location number. Cell billing ZC sets name In the cell-based charging configuration, ZC is referenced from the ZC table according to the cell-based charging ZC set. It is related to location number. Local subscription ZC sets name In the local-based service restriction configuration, ZC is referenced from the ZC table according to the ZC set of local-based service restriction. It is related to location number. Service restrict by cell ZC sets name In the SRC in ZC mode, ZC is referenced from the ZC table according to the service restriction by cell configuration. It is related to location number. The commands to edit location group are listed in Table 34-8. Table 34-8 Commands to edit location group Command ADD LOCGRP MOD LOCGRP RMV LOCGRP LST LOCGRP Description Adds location group configuration. Modifies location group configuration. Deletes location group configuration. Lists location group configuration.
ROAMRESTGRP Command Setting

Run ADD ROAMRESTGRP to configure the roaming-restricted user group for the SRC in user group mode. Restriction condition It specifies the policy that the system uses to classify roaming-restricted user group. The value options are: MSISDN IMSI Roaming subscriber type Start subscriber number This parameter is effective only when the Subscriber group type parameter in this command is MSIISDN or IMSI. It specifies the MSISDN number segments and IMSI number segments where the subscribers are allocated to a roaming-restricted subscriber group. End subscriber number This parameter is effective only when the Subscriber group type parameter in this command is MSIISDN or IMSI. It specifies the MSISDN number segment and IMSI number segments where the subscribers will be allocated to a roaming-restricted subscriber group.
34-14
Issue 02 (2007-06-10)
Roaming Subscriber Type This parameter is effective only when the subscriber group type parameter in this command is roaming group type. It specifies the type of roaming subscribers who are to be allocated to a roaming-restricted subscriber group. The value options are: Local MS National home PLMN MS International home PLMN MS National visitor PLMN MS International visitor PLMN MS User group name It defines a roaming-restricted subscriber group in the configuration database of the MSOFTX3000. The commands to edit roaming-restricted groups are listed in Table 34-9. Table 34-9 Commands to edit roaming-restricted groups Command ADD ROAMRESTGRP MOD ROAMRESTGRP RMV ROAMRESTGRP LST ROAMRESTGRP Description Adds roaming-restricted subscriber group configuration. Modifies roaming-restricted subscriber group configuration. Deletes roaming-restricted subscriber group configuration. Lists roaming-restricted subscriber group configuration.
USROAMRT Command Setting

Run ADD USROAMRT to relate a subscriber group and a location group to decide whether to restrict roaming and the list of services restricted. It is used in SRC in user group mode. User group name It specifies the subscriber groups to which the roaming capability data is configured. This parameter is defined in ADD ROAMRESTGRP. Location group name It specifies the location group for which the roaming capability data is configured. This parameter is defined in ADD LOCGRP and is referenced by LGNNAME. Roaming restriction It specifies whether the roaming of a subscriber group is restricted in a specific location group. The value options are: Roaming allowed Roaming restricted SRC prohibit service list
Issue 02 (2007-06-10)
34-15
List of services to which service restriction by cell is unavailable. It specifies the services that are restricted for a subscriber group in a location group. The value options are: Select all Clear all MOCALL (Subscriber originated call) MTCALL (Subscriber terminated call) SMMO (Subscriber originated short message) SMMT (Subscriber terminated short message) MOUSSD (Subscriber originated USSD) MTUSSD (Network originated USSD) MOLCS (Mobile originated location request) MTLCS (Mobile terminated location request) MOGSMBS20(Mobile originated GSMBS20) MTGSMBS20(Mobile terminated GSMBS20) MOGSMBS30(Mobile originated GSMBS30) MTGSMBS30(Mobile terminated GSMBS30) MOGSMTS61(Mobile originated GSMTS61) MTGSMTS61(Mobile terminated GSMTS61) MOGSMTS62(Mobile originated GSMTS62) MTGSMTS62(Mobile terminated GSMTS62) MOGSMTS63(Mobile originated GSMTS63) MTGSMTS63(Mobile terminated GSMTS63) MOALS (Mobile originated ALS) MTALS (Mobile terminated ALS) MOGSMBS40(Mobile originated GSMBS40) MTGSMBS40(Mobile terminated GSMBS40) MOGSMBS50(Mobile originated GSMBS50) MTGSMBS50(Mobile terminated GSMBS50) The commands to edit user group roaming right are listed in Table 34-10 Table 34-10 Commands to edit user group roaming right Command Name ADD USROAMRT MOD USROAMRT RMV USROAMRT LST USROAMRT Description Adds subscriber group roaming right configuration. Modifies subscriber group roaming right configuration. Deletes subscriber group roaming right configuration. Lists subscriber group roaming right configuration.
34-16
Issue 02 (2007-06-10)

Configure local-based service restriction so that subscriber roaming is allowed. The subscriber's HLR subscription zone code is 2345. Roaming in cell 4607600210001 is allowed. The current MSC/VLR number is 8613900888. The call source name is "CALLSRC1".
Assuming that the related tables of local office are not configured, the configuration on the MSOFTX3000 LMT takes the following steps: Step 1 Enable local-based service restriction. Description Script Remark Enable local-based service restriction. SET MAPACCFG: LOCALSUBSCRIPTION=YES; None.
Step 2 Set cells. Description Script Configure Location number name of cell 4607600210001 to be cell1. ADD LAISAI: SAI="4607600210001", MSCN="8613900888", VLRN="8613900888", LAICAT=SAI, LAIT=HVLR, LOCNONAME="cell1", RNCID1=1, CSNAME="CALLSRC1"; If the 2G network is adopted, the corresponding script is: ADD LAIGCI: GCI="4607600210001", MSCN="8613900888", VLRN="8613900888", LAICAT=GCI, LAIT=HVLR, LOCNONAME="cell1", BSCDPC1="123", CSNAME="CALLSRC1"; The parameter RNCID1 must be defined by the ADD RNC command before being referenced here. The parameter Call source name must be defined by the ADD CALLSRC command before being referenced here. The parameter Home BSC DPC 1 must be defined by the ADD BSC command before being referenced here.
Remark
Step 3 Set zone code. Description Script Configure Local subscription zone code to be 2345 and the corresponding Local subscription ZC set to be ZoneCodeSet1. ADD ZC: ZCCFGNAME="ZC config 1", ZC="2345", ZCNAME="ZoneCode1", ZCTYPE=LOCALSUBSCRIPTION, ZCSETSNAME="ZoneCodeSet1"; None.
Remark
Issue 02 (2007-06-10)
34-17
Step 4 Set relationship between location area and zone code. Description Script Remark Configure relationship between location number and zone code ADD LOCGRP: LOCNONAME=" cell1", LSZCSETS=" ZoneCodeSet1"; None.
----End
Configure local-based service restriction so that subscriber is restricted to roam in cell 4607600210001 and that originated and terminated short messages are allowed in this cell. The subscriber's HLR subscription zone code 2345, the current MSC/VLR number is 8613900888. The call source name is "CALLSRC1".
Assuming that the local office has not configured the related tables, the configuration on the MSOFTX3000 LMT takes the following steps: Step 1 Enable local-based service restriction. Description Script Remark Enable local-based service restriction. SET MAPACCFG: LOCALSUBSCRIPTION=YES; None.
Remark
34-18
Issue 02 (2007-06-10)
Step 3 Set zone codes. Description Configure Local subscription zone code to be 3456 and the corresponding ZC set to be ZoneCodeSet1. The allowed services are call origination and short message termination. ADD ZC: ZCCFGNAME="ZC config 1", ZC="3456", ZCNAME="ZoneCode1", ZCTYPE=LOCALSUBSCRIPTION, ZCSETSNAME="ZoneCodeSet1", ZCPRIORITY=127, LOCSUBSERVICE=MOCALL-1&MTCALL-0&SMMO-0&SMMT1&MOUSSD-0&MTUSSD-0&MOLCS-0&MTLCS-0&SS-0; None.
Script
Remark
Step 4 Set the zone code 2345. Description Configure the zone code of local-based service restriction to be 2345. The corresponding ZC set is named "ZoneCodeSet2". The service list can be null. ADD ZC: ZCCFGNAME="ZC config 2", ZC="2345", ZCNAME="ZoneCode2", ZCTYPE=LOCALSUBSCRIPTION, ZCSETSNAME="ZoneCodeSet2", ZCPRIORITY=125, LOCSUBSERVICE=MOCALL-0&MTCALL-0&SMMO-0&SMMT0&MOUSSD-0&MTUSSD-0&MOLCS-0&MTLCS-0&SS-0; The configuration of zone code 2345 indicates that subscribers can roam (register) in a zone served by the local VLR. See section 34.4.1 "Location Update Message Flow."
Script
Remark
Step 5 Set relationship between location number and zone code. Description Script Remark Configure relationship between location number and zone code. ADD LOCGRP: LOCNONAME=" cell1", LSZCSETS=" ZoneCodeSet1"; The subscriber's subscription zone code and the zone code set of localbased service restriction corresponding to the cell do not contain intersection, hence roaming is restricted. The local office is configured with the zone code of the highest priority in the zone code set of local-based service restriction corresponding to the local cell. Its list of allowed services is originated and terminated short messages. Therefore subscribers can send originated and terminated short messages.
----End
The preferential tariff that the subscriber subscribes to cell 4607600210001 is 60. The tariff is USSD-noticed to subscriber.
Issue 02 (2007-06-10)
34-19
The subscriber's HLR subscription zone code is 2345 and the current MSC/VLR number is 8613900888. The call source name is "CALLSRC1".
Assuming that the local office has not configured related tables, the configuration at the MSOFTX3000 LMT takes the following steps: Step 1 Enable cell-based charging and USSD notice. Description Script Remark Enable cell-based charging and USSD notice. SET MAPACCFG: CELLBILLINGFUNCTION=YES, CELLBILLINGUSSDNOTICE=CALLNOTIFY-1&SMSNOTIFY-1; The tariff of non-preferential cell is set by the SET MAPPARA command in the DEFAULTTCVALUE parameter.
Remark
Step 3 Set zone code. Description Configure the cell-based charging zone code to be 2345, the corresponding cell charging ZC set to be ZoneCodeSet1, and the preferential tariff to be 60. ADD ZC: ZCCFGNAME="ZC config 1", ZC="2345", ZCNAME="ZoneCode1", ZCTYPE=ZCCELLBILL, ZCSETSNAME="ZoneCodeSet1", ZCPRIORITY=127, TCVALUE=60; None.
Script
Remark
Step 4 Set relationship between location number and zone code.
34-20
Issue 02 (2007-06-10)
Configure location number and zone code. ADD LOCGRP: LOCNONAME=" cell1", LOCGRPNAME="location group 1", CBZCSETS=" ZoneCodeSet1"; None.
----End
In the SRC in ZC mode, the subscriber is restricted from short message service in cell 4607600210001. The subscriber's HLR subscription zone code is 2345 and the current MSC/VLR number is 8613900888. The call source name is "CALLSRC1".
Configuration script
Assuming that the local office has not configured the related tables, the configuration on the MSOFTX3000 LMT takes the following steps: Step 1 Enable SRC in ZC mode. Description Script Remark Enable SRC in ZC mode. SET MAPACCFG: ZCSRCFUNCTION=YES; None.
Remark
Issue 02 (2007-06-10)
34-21
Step 3 Set zone code. Description Configure the zone code of SRC in ZC mode to be 2345, the corresponding ZC set to be ZoneCodeSet1. The restricted services are originated and terminated short messages. ADD ZC: ZCCFGNAME="ZC config 1", ZC="2345", ZCNAME="ZoneCode1", ZCTYPE=SRVRESTRICTBYCELL, ZCSETSNAME="ZoneCodeSet1", ZCPRIORITY=127, SRCPROHIBITSERVICE=MOCALL-0&MTCALL-0&SMMO1&SMMT-1&MOUSSD-0&MTUSSD-0&MOLCS-0&MTLCS0&MOGSMBS20-0&MTGSMBS20-0&MOGSMBS30-0&MTGSMBS300&MOGSMTS61-0&MTGSMTS61-0&MOGSMTS62-0&MTGSMTS620&MOGSMTS63-0&MTGSMTS62-0&MOALS-0&MTALS0&MOGSMBS40-0&MTGSMBS40-0&MOGSMBS50-0&MTGSMBS500; None.
Script
Remark
Step 4 Set relationship between location number and zone code. Description Script Remark Configure relationship between location number and zone code. ADD LOCGRP: LOCNONAME=" cell1", SRCZCSETS=" ZoneCodeSet1"; None.
----End
In the SRC in user group mode, the subscriber (IMSI 460881104008802) is restricted from originated and terminated short message services in cell 4607600210001. The current MSC/VLR number is 8613900888. The call source name is "CALLSRC1".
Assuming that the local office has not configured the related tables, the configuration on the MSOFTX3000 LMT takes the following steps: Step 1 Enable SRC in user group mode. Description Script Remark Enable SRC in user group mode. SET MAPACCFG: USRGRPSRCFUNCTION=YES; None.
Step 2 Set cells.
34-22
Issue 02 (2007-06-10)
Description Script
Configure Location number name of cell 4607600210001 to be cell1. ADD LAISAI: SAI="4607600210001", MSCN="8613900888", VLRN="8613900888", IFROAMANA=YES, LAICAT=SAI, LAIT=HVLR, LOCNONAME="cell1", RNCID1=1, CSNAME="CALLSRC1"; If the 2G network is adopted, the corresponding script is: ADD LAIGCI: GCI="4607600210001", LAIGCINAME="cell1", MSCN="8613900888", VLRN="8613900888", IFROAMANA=YES, LAICAT=GCI, LAIT=HVLR, BSCDPC1="123", CSNAME="CALLSRC1"; The parameter RNCID1 must be defined by the ADD RNC command before being referenced here. The parameter Call source name must be defined by the ADD CALLSRC command before being referenced here. The parameter Home BSC DPC 1 must be defined by the ADD BSC command before being referenced here.
Remark
Step 3 Set relationship between location number and location group. Description Script Remark Configure relationship between location number and location group. ADD LOCGRP: LOCNONAME=" cell1", LOCGRPNAME="location group 1"; The differences from other features are: In the SRC in user group mode, the relationship is between location number and location group. In other features, the relationship is between location number and the intersection of corresponding ZC sets.
Step 4 Set subscriber group. Description Script Set subscriber group. ADD ROAMRESTGRP: RSTRIBY=IMSI, BEGINNUM=K'460881104008801, ENDNUM=K'460881104008809, UGNAME="user group 1"; None.
Remark
Step 5 Set subscriber group service capability.
Issue 02 (2007-06-10)
34-23
Description Script
Set subscriber group service capability. ADD USROAMRT: UGNAME=" user group 1", LGNNAME=" location group 1", ROAMREST=YES, SRCPROHIBITSERVICE=MOCALL0&MTCALL-0&SMMO-1&SMMT-1&MOUSSD-0&MTUSSD0&MOLCS-0&MTLCS-0&MOGSMBS20-0&MTGSMBS200&MOGSMBS30-0&MTGSMBS30-0&MOGSMTS61-0&MTGSMTS610&MOGSMTS62-0&MTGSMTS62-0&MOGSMTS63-0&MTGSMTS620&MOALS-0&MTALS-0&MOGSMBS40-0&MTGSMBS400&MOGSMBS50-0&MTGSMBS50-0; None.
Remark
----End

None.

Charging Principle
These three features are used in roaming restriction. Charging is unchanged.
CDR
CDR remains unchanged. Only a preferential tariff is added.

34.8.1 Index Description
None.

None.

This section describes the interaction of local-based service restriction, cell-based charging, and service restriction by cell with other functions.
34-24
Issue 02 (2007-06-10)
34.9.1 Enhanced Roaming Restriction and ZC Roaming Restriction

Enhanced roaming restriction, ZC roaming restriction, local-based service restriction, and service restriction by cell are all service-restriction-type features. Enhanced roaming restriction and ZC roaming restriction can restrict at the precision of location area (LAI) and the new local-based service restriction and service restriction by cell can restrict at the precision of cell (GCI/SAI). Local-based service restriction controls whether to allow a subscriber to use the services, such as originating and terminating calls and short messages, outside the roaming-allowed area. With local-based service restriction, when it is disabled, roaming at a certain cell may be restricted, but when it is enabled, roaming at that cell is allowed, so that the subscriber can use the configured services. Service restriction by cell can control whether to allow subscribers to use services at a cell. The services can be simultaneously enabled without affecting each other. The order of providing local-based service restriction, service restriction by cell, enhanced roaming restriction, and ZC roaming restriction is: In location update, enhanced roaming restriction is first analyzed, then ZC roaming restriction is checked, and finally local-based service restriction is analyzed. When a subscriber uses a service, the services ZC roaming restriction, enhanced roaming restriction, local-based service restriction, and service restriction by cell are analyzed in turn. When the services are allowed, cell-based charging is processed.
34.10 Reference
The reference is as follows: 3GPP TS 29.002: "Mobile Application Part (MAP) specification"

Acronym/Abbreviation 3G 3GPP2 ZC SAI GCI USSD TC Full Name The Third Generation 3rd Generation Partnership Project 2 Zone Code SERVICE AREA INDENTITY GLOBAL CELL INDENTITY Unstructured Supplementary Service Data Traffic Code
Issue 02 (2007-06-10)
34-25
34.11 FAQ
None.
34-26
Issue 02 (2007-06-10)
Contents
Contents
35 Dialing Test on Designated TDM Circuit.........................................................................35-1
35.1 Service Description ...................................................................................................................................35-2 35.1.1 Function Code..................................................................................................................................35-2 35.1.2 Definition .........................................................................................................................................35-2 35.1.3 Benefits ............................................................................................................................................35-3 35.1.4 Application Scenario ........................................................................................................................35-3 35.1.5 Application Limitations....................................................................................................................35-3 35.2 Availability ................................................................................................................................................35-3 35.2.1 Requirements for NEs......................................................................................................................35-3 35.2.2 Requirements for License ................................................................................................................35-3 35.2.3 Applicable Versions..........................................................................................................................35-3 35.3 Working Principle......................................................................................................................................35-4 35.3.1 Functions of NEs..............................................................................................................................35-4 35.3.2 Internal Processing of the System ....................................................................................................35-4 35.4 Service Flow..............................................................................................................................................35-5 35.4.1 Dialing Test on the Designated TDM Circuit for the Trunk Outgoing Call .....................................35-5 35.4.2 Dialing Test on the Designated TDM Circuit for the Intra-Office Call............................................35-7 35.4.3 Dialing Test on the Designated TDM Circuit for the Incoming Call ...............................................35-9 35.5 Data Configuration....................................................................................................................................35-9 35.5.1 Configuration Description................................................................................................................35-9 35.5.2 Data Configuration at the MSOFTX3000 Side................................................................................35-9 35.5.3 Data Configuration at the UMG8900 Side.....................................................................................35-10 35.5.4 Data Configuration Examples ........................................................................................................35-10 35.6 Charging and CDR .................................................................................................................................. 35-11 35.7 Performance Measurement......................................................................................................................35-12 35.8 Service Interaction ..................................................................................................................................35-12 35.9 Reference ................................................................................................................................................35-12 35.9.1 Specifications.................................................................................................................................35-12 35.9.2 Acronyms and Abbreviations .........................................................................................................35-12 35.10 FAQ .......................................................................................................................................................35-12
Issue 02 (2007-06-10)
Figures
Figures
Figure 35-1 Dialing test model on the designated TDM circuit. ......................................................................35-2 Figure 35-2 Processing flow inside the system ................................................................................................35-4 Figure 35-3 Flow of the dialing test on the designated TDM circuit for the trunk outgoing call from the MS to the PSTN ...........................................................................................................................................................35-6 Figure 35-4 Message flow of the dialing test on the designated TDM circuit for the intra-office call.............35-8
ii
Issue 02 (2007-06-10)
Tables
Tables
Table 35-1 Function name and function code in the dialing test on the designated TDM circuit.....................35-2 Table 35-2 Benefits for carriers ........................................................................................................................35-3 Table 35-3 NEs required to implement the dialing test on the designated TDM circuit...................................35-3 Table 35-4 Versions of the Huawei UMTS products that support the dialing test on the designated TDM circuit ...........................................................................................................................................................................35-4 Table 35-5 Related software parameters.........................................................................................................35-10
Issue 02 (2007-06-10)
iii
35
Section
Dialing Test on Designated TDM Circuit
About This Chapter

The following table lists the contents of this chapter. Describes The function code and definition of the service and the benefits of the service to carriers and mobile subscribers. The NEs required to implement the service, requirements for the license, and versions of the products applicable to the service. The functions of the NEs used to implement the service and the requirements on the networking. The flow of the service. The data configuration that must be performed at the MSOFTX3000 side and the UMG8900 side as well as the examples of data configuration. The procedure for performing charging and generating CDRs when the service is provided. The influence of the service on performance measurement and the implementation of performance measurement. The association between the service and other services as well as the restrictions on each other. The standards and specifications with which the service complies and the glossary, abbreviations, and acronyms used in this chapter. The frequently asked questions related to the service and the solutions.
35.6 Charging and CDR 35.7 Performance Measurement 35.8 Service Interaction 35.9 Reference
35.10 FAQ
Issue 02 (2007-06-10)
35-1

Table 35-1 lists the mapping between function name and function code in the dialing test on the designated TDM circuit. Table 35-1 Function name and function code in the dialing test on the designated TDM circuit Name Dialing test on the designated TDM circuit Code WMFD-121100
35.1.2 Definition
The dialing test on the designated TDM circuit is to test the availability of the TDM circuit between the two MGWs in the same MSC server, without blocking circuits. The test is performed to check whether the circuits between the MGWs are faulty. It is applied to the running device test and troubleshooting. The result of the trunk dialing test is printed in the trunk trace window and is saved in a file. The designated dialing test indicates when a subscriber dials the same number for multiple times, the MSC server selects the corresponding TDM circuits for test based on the trunk test task table. The dialing test on the designated TDM circuit is to test the timeslot of the E1 cable connecting the two MGWs of the peer office. As shown in Figure 35-1, there are two MGWs, namely MGW1 and MGW2, in the MSC server. The dialing test on the designated TDM circuit can be conducted when a subscriber in the MGW1 calls a subscriber in the MGW2, or a PSTN subscriber. Figure 35-1 Dialing test model on the designated TDM circuit.
MSCserver H248 H248
MGW1
E1 TDM
MGW2
E1 TDM
PSTN
The dialing test on the designated TDM circuit supports the trunk outgoing call, trunk incoming call and intra-office call.
35-2
Issue 02 (2007-06-10)
35.1.3 Benefits
Table 35-2 lists benefits for carriers. Table 35-2 Benefits for carriers Beneficiary Carriers Description The service helps maintenance personnel check the availability of the circuit. It eases to test the circuits and troubleshoot the failure.

The service is applied to all the markets of the GSM and the UMTS R99/R4.

The service supports the dialing test on the call between different MGWs in an office only, but not the call in the same MGW. On the dialing test, you can test a set of E1 ports in series only.
35.2 Availability
The NodeB/BTS and RNC/BSC must interwork with the devices at the core network side to implement the dialing test on the designated TDM circuit. Table 35-3 lists the NEs required to implement the dialing test on the designated TDM circuit. Table 35-3 NEs required to implement the dialing test on the designated TDM circuit UE/ MS NodeB/ BTS RNC/ BSC MSC Server MGW SGSN VLR HLR
refers to the involved NEs.

The dialing test on the designated TDM circuit is a basic feature of the HUAWEI GSM/UMTS core network. It requires no License.

Table 35-4 lists the versions of the Huawei UMTS products that support the dialing test on the designated TDM circuit.
Issue 02 (2007-06-10)
35-3
Table 35-4 Versions of the Huawei UMTS products that support the dialing test on the designated TDM circuit Product MSC server MGW MSOFTX3000 UMG8900 Applicable Version V100R005C10 V200R006

The service requires the MS/PSTN to interwork with the MSC server and MGW. The functions implemented by each NE are as follows: The MSC server implements the processing of each signaling, data analysis and tone announcement. After analyzing the number dialed for test, it obtains the dialing test type and the circuits to be tested, and converts the dialing test number to the actual called number for call connection. The MS/PSTN is performed with the dialing test based on the scheme configured in the trunk test task table. The MGW implements the physical bearer of the dialing test circuits.

Figure 35-2 shows the processing flow of the dialing test on designated circuit inside the system. Figure 35-2 Processing flow inside the system
(1) (2) (7) (4)
Calling party
BTS/Node B (6)
BSC/RNC
(3) MSC server
BSC/RNC
BTS/Node B (5)
Called party
MGW1
MGW2
The processing flow of the dialing test on designated circuit inside the system is as follows: 1. 2. The calling party initiates the designated dialing test request based on the designated trunk dialing test scheme. After receiving the dialing test request, the MSC server analyzes the request and determines one TDM circuit between the MGWs for dialing test.
35-4
Issue 02 (2007-06-10)
3. 4. 5. 6. 7.
The MSC Sever sends the resource to the MGW and notifies the MGW to prepare the termination point of the TDM circuit. The MSC server connects the call to the actual called party. The called party answers the call and the call connection is set up. Check whether the designated circuit is normal through the call connection. Print the designated trunk test result or ultimate test result through the trunk trace window, which is started.
35.4 Service Flow

The dialing test on the designated TDM circuit is to test the availability of the TDM circuit between the two MGWs in the same MSC server. The following takes examples when the calling party is a mobile subscriber.
35.4.1 Dialing Test on the Designated TDM Circuit for the Trunk Outgoing Call
Figure 35-3 shows the message flow of the dialing test on the designated TDM circuit for the trunk outgoing call from the MS to the PSTN.
Issue 02 (2007-06-10)
35-5
Figure 35-3 Flow of the dialing test on the designated TDM circuit for the trunk outgoing call from the MS to the PSTN
MSa MSC Server (1)Setup (2) P1 (3)Add.req (4)Add.rspC1,T1 (5)Add.reqC1,Termination ID (6)Add.rspC1,T2 (7)IAM (8)ACM (9)Alerting (10)ANM (11)Connect (12)Connect_ack MGWa MGWb PSTN
(13) P2
P1: The system analyzes the dialing test type and dialing test circuits. P2: The system prints the test result and refreshes the data in test task buffer area.
The message flow is as follows: 1. Mobile subscriber A initiates the dialing test and dials the number with the prefix of X*.
X* is the call prefix of the called number during the dialing test on the designated circuit. Therein, X stands for the designated number, * stands for the wildcard, and the combination of X and * is the call prefix.
2.
After analyzing the dialing test number, the MSC server determines that Service category is Test and Service attribute is Special number prefix test. The MSC server excludes X* and then queries the trunk test task table through the called number and calling number after the first *. After the query, the MSC server can obtain the detailed circuit number (BSN) through analyzing the data. It connects the call to the actual PSTN subscriber B configured in the trunk test table. The MSC server queries the database to obtain the TDM circuit endpoints between the two MGWs based on the E1 numbers. The MSC server sends the resource request to MGW A to prepare the endpoint of the calling party. MGW A returns the contact 1 and termination 1 (C1, T1) involved in the call to the MSC server.
3. 4.
35-6
Issue 02 (2007-06-10)
5. 6. 7. 8. 9.
The MSC server sends the resource request to MGW B with the endpoint of the MGW designated. MGW B returns the termination 2 (including C1 and T2) to the MSC server. The MSC server sends the IAM message out of the office. The backward office PSTN returns the ACM message. After receiving the ACM message, the MSC server sends the ALERTING message to MS A.
10. After the called party answers the call, the backward office PSTN returns the ANM message. 11. After receiving the ANM message, the MSC server sends the CONNECT message to MS A. 12. The MS A returns the CONNECT_ACK message and the call connection is established. 13. After receiving the CONNECT _ACK message, the MSC server prints the trunk test result in the trunk trace window and refreshes data in the test task buffer area.
35.4.2 Dialing Test on the Designated TDM Circuit for the IntraOffice Call
Figure 35-4 shows the message flow of the dialing test on the designated TDM circuit for the intra-office call.
Issue 02 (2007-06-10)
35-7
Figure 35-4 Message flow of the dialing test on the designated TDM circuit for the intra-office call
MSa (1)Setup (2) P1 (3)SRI (4)SRI ACK PAGE (5)Setup (6)Call Confirmed (7)Add.req (8)Add.rspC1,T1 (9)Add.reqC1,Termination ID (10)Add.rspC1,T2 (11)Alerting (12)Connect (11)Alerting (12)Connect MSC Server MGWa MGWb MSb HLR
(13)Connect_ack (13)Connect_ack (14) P2
P1: The system analyzes the dialing test type and dialing test circuits. P2: The system prints the test result and refreshes the data in test task buffer area.
The message flow is as follows: 1. 2. Mobile subscriber A initiates the dialing test and dials the number with the prefix of X*. After analyzing the dialing test number, the MSC server determines that Service category is Test and Service attribute is Special number prefix test. The MSC server excludes X* and then queries the trunk test task table through the called number and calling number after the first *. After the query, the MSC server can obtain the detailed circuit number (BSN) through analyzing the data. It connects the call to the actual PSTN subscriber B configured in the trunk test table. The MSC server queries the database to obtain the TDM circuit endpoints between the two MGWs. The MSC server requests the roaming number of MS B from the HLR. The HLR returns the roaming number of MS B. The MSC server analyzes the roaming number and determines that the roaming number is allocated by the local office. Then, the MSC server initiates the paging to MS B and MS B returns the corresponding message. The MSC server sends the Setup request to the MS B.
3. 4.
5.
35-8
Issue 02 (2007-06-10)
6. 7. 8. 9.
MS B returns the Call Confirmed message to the MSC server. The MSC server sends the resource request to MGW A to prepare the endpoint of the calling party. MGW A returns the contact 1and termination 1 (C1, T1) involved in the call to the MSC server. The MSC server sends the resource request to MGW B with the endpoint of the trunk MGW designated.
10. MGW B returns the termination T2 (C1, T2) to the MSC server. 11. After receiving the Alerting message from MS B, the MSC server sends the message to MS A. 12. After receiving the Connect message from MS B, the MSC server sends the message to MS A. 13. The MS A returns the CONNECT_ACK message and thus the call connection is set up. 14. After receiving the CONNECT _ACK message, the MSC server prints the trunk test result in the trunk trace window and refreshes data in the test task buffer area.
35.4.3 Dialing Test on the Designated TDM Circuit for the Incoming Call
The message flow of the dialing test on the designated TDM circuit for the incoming call is the same as that of the intra office call.

The principles for configuring the dialing test on the designated TDM circuit are as follows: Add the called number prefix used for the dialing test in the called number analysis table. Set Service category to Test and Service attribute to Special number prefix test. Delete the special prefix to obtain the actual called number in the auxiliary number change table. Configure the trunk test task table. Then, the MSC will perform the trunk dialing test based on the configured data in the trunk test task. Configure the called number analysis table. Analyze the actual called number to set up the call connection.

Dialing Test Task Configuration
To conduct the dialing test on the designated TDM circuit, perform the following steps: Step 1 Run ADD CNACLD to configure the called number analysis table. Set Service category to Test and Service attribute to Special prefix number test. Define the prefix of the dialing test number to the number to be tested.
Issue 02 (2007-06-10)
35-9
Step 2 Run ADD DNC to configure the number change table. The number change table is configured together with the auxiliary number processing table. They are used to convert the dialing test number. Step 3 Run ADD AIDNUMPRO to configure the auxiliary number processing table. Set Number type to Trunk test number and Number prefix to the prefixed designated in Step 1.The Number change name references the record in the number change table. Step 4 Run ADD TKTEST to configure the trunk test task table. Set Circuit type to INTER_MGW and Called number to actual called number. The parameter Step indicates the test step from the last E1 timeslot tested to the next E1 timeslot during the dialing test on the TDM trunk. Step 5 Run ADD CNACLD to configure the number analysis table and analyze the actual called number. ----End

Table 35-5 lists the related software parameters. Table 35-5 Related software parameters Name Bit 2 of P130 (CHG parameter two) Description It determines whether to generate the charging bill during the dialing test on the designated trunk. Value =0: No =1: Yes Default Value 1

The service requires no data configuration at the UMG8900 side.

During the dialing test on the designated TDM trunk, subscriber A's number is 8613807558807 and subscriber B's number is 6660050. The number dialed by subscriber A for test is 13926660050.The subscribers are connected to the network through MGW 1 and MGW 2 respectively. The TDM circuit exists between the two MGWs and the E1 numbers corresponding to the TDM circuit are 0 and 1. The step is 10.The call source name of subscriber A is CALL_SRC and dialed number set is 0.
Assume that the related table of the local office has been configured. The procedure for configuring the MSOFTX3000 client is as follows: Step 1 Configure the called number analysis table.
35-10
Issue 02 (2007-06-10)
Set Service Category of the call prefix 139* to TEST and Service attribute to SPFXT. ADD CNACLD: PFX=K'139*, CSTP=TEST, CSA=SPFXT, MINL=3, MAXL=32; The 139* can be replaced by any defined number prefix.
Step 2 Configure the number change table. Description Define the number change record where the special prefix designated for dialing test is deleted. Delete four special number prefixes from the position 0. ADD DNC: DCN="DEL_TKTEST_SUFFIX", DCT=TYPE6, DCL=4;
Script
Step 3 Configure the auxiliary number processing table. Description Script Delete the special number prefix. Set Number type of the number change to Trunk test number (TY8). ADD AIDNUMPRO: CSCNAME="CALL_SRC", PFX=K'139*, CDN="DEL_TKTEST_SUFFIX"; NUMTY=TY8,
Step 4 Configure the trunk test task table. Description Script Set the trunk test task. ADD TKTEST: TKID=0, CLIN=K'8613807558807, CLDN=K'6660050, DID=INTER_MGW, SE1NO=0, EE1NO=1, STS=1, ETS=31, S=10;
Step 5 Configure the called number analysis. Description Script The MSC server analyzes subscriber B' number for outgoing route selection. Set Route selection name of subscriber B to TO_PSTN. ADD CNACLD: PFX=K'6660050, CSA=MLC, RSNAME=" TO_PSTN ", MINL=5, MAXL=32;
----End

For dialing test on the designated trunk, Bit2of P130 is used to determine whether to generate the bill.
Issue 02 (2007-06-10)
35-11
When it is set to 0, the bill is not generated. When it is set to 1, the bill not generated. It is set to 1 by default. In this case, the bill generated during the dialing test for the designated trunk has no difference with that generated by the common calls.

None.

None.
35.9 Reference
None.

Acronyms/Abbreviations MGW TDM Full Name Media Gateway Time Division Multiplexing
35.10 FAQ
Symptom
The dialing test result is not displayed in the dialing test task window.
Handling Procedure
Open the trace window to set up subscriber trace and observe whether the subscriber trace message contains the message concerning with the dialing test on the trunk and print logs. If not, check the operation based on the data configuration in the guide. The common causes are as follows:
35-12
Issue 02 (2007-06-10)
No special number analysis data is configured to identify that the dialing test is for a designated trunk. The number change is configured incorrectly and thus the number change cannot be conducted.
Result
The dialing test result is displayed normally.
Issue 02 (2007-06-10)
35-13
Contents
Contents
36 IN Service Performance Measurement Enhancement ....................................................36-1
36.1 Service Description ...................................................................................................................................36-3 36.1.1 Function Code..................................................................................................................................36-3 36.1.2 Definition .........................................................................................................................................36-3 36.1.3 System Specifications ......................................................................................................................36-3 36.1.4 Denefits............................................................................................................................................36-4 36.1.5 Application Scenrio..........................................................................................................................36-4 36.1.6 Application Limitations....................................................................................................................36-4 36.2 Availability ................................................................................................................................................36-4 36.2.1 Requirements for NEs......................................................................................................................36-4 36.2.2 Requirement for License..................................................................................................................36-5 36.2.3 Applicable Versions..........................................................................................................................36-5 36.2.4 Others...............................................................................................................................................36-5 36.3 Working Principle......................................................................................................................................36-5 36.3.1 Functions of NEs..............................................................................................................................36-5 36.3.2 Internal Processing of the System ....................................................................................................36-5 36.3.3 External Interfaces ...........................................................................................................................36-8 36.4 Service Flow..............................................................................................................................................36-8 36.4.1 Traffic for WIN User Calling Fixed User ........................................................................................36-8 36.4.2 Traffic for WIN User Calling Other MSC User ...............................................................................36-9 36.4.3 Traffic for Fixed User Calling WIN User ...................................................................................... 36-11 36.4.4 Traffic for Other MSC User Calling WIN User .............................................................................36-12 36.5 Data Configuration..................................................................................................................................36-13 36.5.1 Description.....................................................................................................................................36-13 36.5.2 Data Configuration at the MSOFTX3000 Side..............................................................................36-14 36.5.3 Data Configuration Examples ........................................................................................................36-14 36.6 Service Management ...............................................................................................................................36-18 36.6.1 Operations by Carriers ...................................................................................................................36-18 36.6.2 Operations by Subscribers .............................................................................................................36-18 36.7 Charging and CDR ..................................................................................................................................36-18 36.8 Performance Measurement......................................................................................................................36-19 36.8.1 Specification Descriprion...............................................................................................................36-19
Issue 02 (2007-06-10)
Contents
HUAWEI MSOFTX3000 Feature Description 36.8.2 Implementation Principle...............................................................................................................36-19
36.9 Service Interaction ..................................................................................................................................36-20 36.10 Reference...............................................................................................................................................36-20 36.10.1 Specifications...............................................................................................................................36-20 36.10.2 Glossary, Acronyms, and Abbreviations ......................................................................................36-20 36.11 FAQ .......................................................................................................................................................36-20
ii
Issue 02 (2007-06-10)
Figures
Figures
Figure 36-1 Transiting a call out after caller IN service invoked in the local office ........................................36-6 Figure 36-2 Callee IN service invoked in the local office for a trunk incoming call........................................36-7 Figure 36-3 WIN user calling fixed user ..........................................................................................................36-8 Figure 36-4 WIN user calling other MSC user without acquiring roaming number in the local office............36-9 Figure 36-5 WIN user calling other MSC user with acquiring roaming number in the local office...............36-10 Figure 36-6 Fixed user calling WIN user ....................................................................................................... 36-11 Figure 36-7 Other MSC user calling WIN user..............................................................................................36-12 Figure 36-8 Special flow of the number regulation........................................................................................36-13
Issue 02 (2007-06-10)
iii
Tables
Tables
Table 36-1 Function name and function code in the IN service performance measurement enhancement ......36-3 Table 36-2 System specifications .....................................................................................................................36-3 Table 36-3 Benefits for carriers ........................................................................................................................36-4 Table 36-4 NEs required to implement the IN service performance measurement enhancement ....................36-4 Table 36-5 Version of the Huawei UMTS products that support the IN service performance measurement enhancement......................................................................................................................................................36-5 Table 36-6 Operation modes of the IN performance measurement enhancement ..........................................36-18
iv
Issue 02 (2007-06-10)
36 IN Service Performance Measurement Enhancement
36
IN Service Performance Measurement Enhancement
About This Chapter

Issue 02 (2007-06-10)
36-1
Section 36.11 FAQ
36-2
Issue 02 (2007-06-10)

Table 36-1 lists the mapping between function name and function code in the IN service performance measurement enhancement. Table 36-1 Function name and function code in the IN service performance measurement enhancement Name IN service performance measurement enhancement Code -
36.1.2 Definition
The IN service performance measurement enhancement is to modify the original "Traffic For WIN User Calling Fixed User" and "Traffic For Fixed User Calling WIN User" to "Traffic For WIN User TK Outgoing Call" and "Traffic For TK Incoming Office Calling WIN User". At the same time, the two measurement units are divided into four units to enhance the precision of the IN service performance measurement. Such division helps to estimate the system performance and each performance measurement efficiently. Traffic For WIN User TK Outgoing Call

Traffic For WIN User Calling Fixed User: It is used to perform the statistics for the WIN user calling the fixed user. Traffic For WIN User Calling Other MSC User: It is used to perform the statistics for the WIN user calling the other MSC user. Traffic For Fixed User Calling WIN User: It is used to perform the statistics for the fixed user calling the WIN user. Traffic For Other MSC User Calling WIN User: It is used to perform the statistics for the other MSC user calling the WIN user.
Traffic For TK Incoming Office Calling WIN User


Table 36-2 lists the system specifications. Table 36-2 System specifications Items WIN User Specifications The system has invoked the IN service of the user.
NOTE When the subscription data exists but the IN service is not invoked, the system considers the user as a non-IN user.
Issue 02 (2007-06-10)
36-3
Items WIN relation end
Specifications After the IN relation end, the system does not perform the statistics for the subsequent specifications.
NOTE When the IN relation is complete, the call connection may not be complete.
36.1.4 Denefits
Table 36-3 lists benefits for carriers. Table 36-3 Benefits for carriers Beneficiary Carriers Description The added IN service performance measurement specification helps to efficiently estimate performance and performance measurement of the system.
36.1.5 Application Scenrio

The feature is applied to all markets of the GSM and the UMTS R99/R4. Based on service attributes of the calling party/called party whose IN service is invoked, the system performs the performance measurement in classification, fractionalizes the original traffic specification and enhances the precision of the performance measurement.

None.
36.2 Availability
The IN service performance measurement enhancement feature can be implemented by the MSC server independently. Table 36-4 lists the NEs required to implement the IN service performance measurement enhancement. Table 36-4 NEs required to implement the IN service performance measurement enhancement MS/U E BTS/Node B BSC/RNC MSC Server MGW PSTN VLR SC P HLR
36-4
Issue 02 (2007-06-10)

The IN service performance measurement enhancement is a basic feature of the HUAWEI GSM/UMTS core network. It requires no License.

Table 36-5 lists the version of the Huawei UMTS products that support the IN service performance measurement enhancement. Table 36-5 Version of the Huawei UMTS products that support the IN service performance measurement enhancement Product MSC server MSOFTX3000 Applicable Version V100R006
36.2.4 Others
None.

The functions implemented by each NE are as follows: The MSC server, MGW and VLR implement the call-related signaling processing, data analysis, announcement playing, charging and performance measurement. The PSTN processes the transferred call and connects it to the destination PSTN. The SCP implements the IN service processing.

The system internal processing is different based on the measurement scenario. The detailed processing contains the following: Transiting a call out after the caller IN service is invoked in the local office Callee IN service invoked in the local office for a trunk incoming call
Transiting a Call out after Caller IN Service Invoked in the Local Office
It consists of "Traffic For WIN User Calling Fixed User" and "Traffic For WIN User Calling Other MSC User". Figure 36-1 shows the networking structure.
Issue 02 (2007-06-10)
36-5
Figure 36-1 Transiting a call out after caller IN service invoked in the local office
Called party
Calling party 1
Calling party 2
MSC server C
MSC server A
MSC server B
SCP
PSTN Called party
MSC server B is the IN invocation office. Office B succeeds in invoking the caller IN service and the IN call connection is not complete. If the called party is a fixed user or other MSC user, MSC server B performs the corresponding performance measurement.
Callee IN Service Invoked in the Local Office for a Trunk Incoming Call
It consists of "Traffic For Fixed User Calling WIN User" and "Traffic For Other MSC User Calling WIN User". Figure 36-2 shows the networking structure.
36-6
Issue 02 (2007-06-10)
Figure 36-2 Callee IN service invoked in the local office for a trunk incoming call
Calling party
Called party
Called party
MSC Server A Calling party
MSC Server B
MSC Server C
PSTN SCP
MSC server B is the WIN invocation office. It succeeds in invoking the callee IN service, but the IN call connection is not complete. If the calling party is the PSTN user or other MSC user, MSC server B performs the corresponding performance measurement.
Regulation Principle of the Calling Number

The regulation principle of the calling number is regulation for the calling number temporarily based on "Traffic For Fixed User Calling WIN User" and "Traffic For Other MSC User Calling WIN User". It is independent of the call flow of the system. When the system terminates the two traffic tasks, the regulation for the calling number becomes invalid. Therefore, the regulation described in the document is for the two traffic tasks only. It does not affect the calling number itself during the call connection.
The regulation principle of the calling number for "Traffic For Fixed User Calling WIN User" and "Traffic For Other MSC User Calling WIN User" is as follows: The system queries the Auxiliary Number Processing table. The system queries the record when Number type is set to TK incoming office caller number in ADD AIDNUMPRO in the auxiliary number processing table. If querying Auxiliary Number Processing table is successful, the result of the auxiliary number change is that of the calling number regulation. If the system fails to query the table, the calling number regulation is performed. The format of the calling number after the regulation is as follows:
For an international call: international number prefix + country code of called party + fixed line number/mobile number
Issue 02 (2007-06-10)
36-7

For a national toll call: national number prefix + area code of called party + fixed line number For a mobile call: mobile number For a local PSTN call: fixed line number
Assume that the country code (home country) is 86, the country code of Hong Kong is 852, local area code is 755, Beijing area code is 10, the international number prefix is 00, national number prefix is 0, mobile number is 13907520511, fixed number is 6660050, the format of the calling number after the regulation is as follows:

For an international call: 00 852 13907520511 or 00 852 6660050 For a national toll call: 0 10 6660050 For a mobile call: 13907520511 For a local PSTN call: 6660050
The number regulation data involved in the calling number regulation performed for "Traffic For Fixed User Calling WIN User" and "Traffic For Other MSC User Calling WIN User" comes from the general data tables of number regulation. The tables include Local Information table, Multi-area Statistics Configuration table, Mobile Station information table, Call Source table, Mobile National Access Code table, National Toll Area Code table, and Country Code or Area Code table.

None.
36.4 Service Flow

36.4.1 Traffic for WIN User Calling Fixed User
For a call initiated by office B or a trunk incoming call to office B, office B invokes the caller IN service and determines that the called party is a fixed user. Figure 36-3 shows the message flow. Figure 36-3 WIN user calling fixed user
BSC/RNC (MSC server A) Setup (IAM) IDP RRBE AC Continue IAM MSC server B SCP PSTN
IDP: Initial DP AC: Apply Charging
RRBE: Request Report BCSM Event IAM: Initial Address Message
The flow of the WIN user calling the fixed user is as follows:
36-8
Issue 02 (2007-06-10)
1. 2. 3. 4.
MSC server B receives the Setup message from the mobile side or receives the IAM message from the trunk side. After determining that the calling party is a WIN user, MSC server B invokes the caller IN service and sends the IDP message to the SCP. The SCP sends the RRBE, AC, and Continue message to MSC server B. After receiving the Continue message, MSC server B performs the number analysis and queries the Called Number Analysis table. Service attribute and Called number type of the called party are returned. The system performs the performance measurement based on the specification Traffic For WIN User Calling Fixed User when the following conditions are met: The service attribute parameter is set to Local, Local toll, National toll or International toll. The called number type parameter is set to PSTN or Unknown.
5.
6.
MSC server B sends the IAM message to the PSTN.
36.4.2 Traffic for WIN User Calling Other MSC User

For a call initiated by office B or a trunk incoming call to office B, office B invokes the caller IN service and determines that the called party is other MSC user.
WIN User Calling Other MSC User Without Acquiring Roaming Number in the Local Office
Figure 36-4 shows the message flow of the WIN user calling other MSC user without acquiring roaming number in the local office. Figure 36-4 WIN user calling other MSC user without acquiring roaming number in the local office
BSC/RNC (MSC Server A) Setup (IAM) IDP RRBE AC Continue IAM MSC Server B SCP MSC Server C
The message flow of the WIN user calling other MSC user without acquiring roaming number in the local office is shown as follows: 1. MSC server B receives the Setup message from the mobile side or receives the IAM message from the trunk side.
Issue 02 (2007-06-10)
36-9
2. 3. 4.
After determining that the calling party is a WIN user, MSC server B invokes the caller IN service and sends the IDP message to the SCP. The SCP sends the RRBE, AC, and Continue message to MSC server B. After receiving the Continue message, MSC server B performs the number analysis and queries the Called Number Analysis table. The Service attribute and Called number type parameters of the called party are returned. The system performs the performance measurement based on the specification Traffic For WIN User Calling Other MSC User when the following conditions are met: The Service attribute parameter is PLMN local MSC, PLMN other MSC, PLMN national toll MSC or PLMN international toll MSC. The Called number type parameter is PSTN or Unknown.
5.
6.
MSC server B sends the IAM message to the MSC server C.
WIN User Calling Other MSC User with Acquiring Roaming Number in the Local Office
Figure 36-5 shows the message flow of the WIN user calling other MSC user with acquiring roaming number in the local office. Figure 36-5 WIN user calling other MSC user with acquiring roaming number in the local office
BSC/RNC (MSC server A) Setup (IAM) IDP RRBE AC Continue SRI SRI ACK IAM MSC server B SCP HLR MSC server C
IDP: Initial DP AC: Apply Charging SRI: Send Routing Information
RRBE: Request Report BCSM Event IAM: Initial Address Message SRI ACK: Send Routing Information Acknowledge
The message flow of the WIN user calling other MSC user with acquiring roaming number in the local office is shown as follows: 1. 2. 3. 4. MSC server B receives the Setup message from the mobile side or receives the IAM message from the trunk side. After determining that the calling party is a WIN user, MSC server B invokes the caller IN service and sends the IDP message to the SCP. The SCP sends the RRBE, AC, and Continue message to MSC server B. After receiving the Continue message, MSC server B sends the SRI message to the HLR at which the called party is located to acquire the roaming number.
36-10
Issue 02 (2007-06-10)
5.
After receiving the SRI ACK message, MSC server B analyzes the number contained the roaming number and queries the Called Number Analysis Table. The Service attribute and Called number type parameters of the called party are returned. The system performs the performance measurement based on the specification Traffic For WIN User Calling Other MSC User when the following conditions are met: The Service attribute parameter is PLMN local MSC, PLMN other MSC, PLMN national toll MSC or PLMN international toll MSC. The Called number type parameter is MSRN.
6.
7.
MSC server B sends the IAM message to the MSC server C.
36.4.3 Traffic for Fixed User Calling WIN User

For a trunk incoming call to office B, office B invokes the callee IN service and determines that the calling party is a fixed user. Figure 36-6 shows the message flow. Figure 36-6 Fixed user calling WIN user
PSTN IAM IDP RRBE AC Continue MSC Server B SCP
The flow of the fixed user calling the WIN user is as follows: 1. 2. MSC server B receives the IAM message from the trunk side. MSC server B uses the regulated calling number to query the Called Number Analysis table. According to the maximum matching principle, the called number analysis record matching the calling number is obtained. The service attribute in the record is the service attribute corresponding to the calling number. If Service attribute is Local, Local toll, National toll or International toll, the calling party is a fixed user. If the calling number does not exist or the query fails, the calling party is a fixed number.
When performing the performance measurement for "Traffic For Fixed User Calling WIN User" and "Traffic For Other MSC User Calling WIN User", the system can use the calling number to query the Called Number Analysis table and obtain the service attribute of the calling number. It is the special processing mode of the system.
3. 4.
After determining that the called party is a WIN user, MSC server B invokes the callee IN service and sends the IDP message to the SCP. The SCP sends the RRBE, AC, and Continue message to MSC server B.
Issue 02 (2007-06-10)
36-11
5.
The system performs the performance measurement based on the measurement point of "Traffic For Fixed User Calling WIN User".
36.4.4 Traffic for Other MSC User Calling WIN User

For a trunk incoming call to office B, office B invokes the callee IN service and determines that the calling party is other MSC user. Figure 36-7 shows the message flow. Figure 36-7 Other MSC user calling WIN user
MSC server A IAM
MSC server B
SCP
IDP RRBE AC Continue
The flow of other MSC user calling the WIN user is as follows: 1. 2. MSC server B receives the IAM message from the trunk side. MSC server B uses the regulated calling number to query the Called Number Analysis Table. According to the maximum matching principle, the called number analysis record matching the calling number is obtained. The service attribute in the record is the service attribute corresponding to the calling number. If Service attribute is PLMN intra MSC, PLMN local office, PLMN other MSC, PLMN national toll MSC or PLMN international toll MSC, the calling party is other MSC user. If the calling number does not exist or the query fails, the calling party is a fixed number and is not counted into this statistics unit.
When performing the performance measurement for "Traffic For Fixed User Calling WIN User" and "Traffic For Other MSC User Calling WIN User", the system can use the calling number to query the Called Number Analysis table and obtain the service attribute of the calling number. It is a special processing mode of the system.
3. 4. 5.
After determining that the called party is a WIN user, MSC server B invokes the callee IN service and sends the IDP message to the SCP. The SCP sends the RRBE, AC, and Continue message to MSC server B. The system performs the performance measurement based on the measurement point of "Traffic For Other MSC User Calling WIN User".
36-12
Issue 02 (2007-06-10)

36.5.1 Description
The data configuration for the IN service performance measurement enhancement is as follows: In the current networking, the data configuration in certain offices is not consistent with that specified in specifications. In this case, when the system performs the performance measurement based on the service attribute and number type of the caller, the traffic that does not meet the specifications cannot be measured. Thus, the performance measurement is not accurate. When performing the performance measurement for "Traffic For Fixed User Calling WIN User" and "Traffic For Other MSC User Calling WIN User", the system needs to configure the Auxiliary Number Processing table or performs the special number regulation. Figure 36-8 shows the special flow of the number regulation. Figure 36-8 Special flow of the number regulation
Start
Succeed in querying the auxiluaty number change table Y Change the calling number based on the number change table
Perform the calling number regulation for Traffic For Fixed User Calling WIN User and Traffic For Other MSC User Calling WIN User
Query the called number and obtain the number type and service attribute of the calling number
End
For details on the special flow of number regulation performed for "Traffic For Fixed User Calling WIN User" and "Traffic For Other MSC User Calling WIN User", refer to "Regulation Principle of the Calling Number."
Issue 02 (2007-06-10)
36-13

The data configuration at the MSOFTX3000 side is as follows: Step 1 Run ADD CNACLD/MOD CNACLD to configure the called number analysis table. Set Call prefix to the prefix of the called number. (It corresponds to the calling number when the system queries the data table through the calling number). Set Service attribute to Local, Local toll, National toll, International toll, PLMN intra MSC, PLMN local MSC, PLMN other MSC, PLMN national toll MSC, or PLMN international toll MSC. Set Called number type to MSISDN, PSTN or MSRN/HON.
You need not configure the called number analysis table when the table has been configured with the corresponding data. If Service attribute configured in the called number analysis table, however, is incorrect and may result in performance measurement failure or missing, you need to modify the data table based on the preceding description.
Step 2 Run ADD DNC to configure the number change table.

The number change table is configured with the auxiliary number processing table. If the auxiliary number processing table requires no configuration, you need not modify the current Number Change table. When other data table needs to reference Other conversion number source, you need to configure the number change table.
Step 3 Run ADD AIDNUMPRO to configure the auxiliary number processing table. Set Number type to Trunk incoming calling number.
In normal cases, the national country code and local area code are not configured in the called number analysis table. In some special cases, the called number containing the national country code and local area code is configured in the called number analysis table. To match the called number with the calling number, configure the auxiliary number processing table. To perform statistics for "Traffic For Fixed User Calling WIN User" and "Traffic For Other MSC User Calling WIN User", configure the auxiliary number processing table.
----End

A WIN user calls a fixed user. The calling number is 8613807520511 and the calling party is a WIN user in office B. The called number is 66600050 and the called party is a fixed user in office C. The route selection name from office B to office C is B2C. Office B is where the IN service is invoked and 86 is the national country code.
36-14
Issue 02 (2007-06-10)
Configuration Script 1
Description Script Remark Configure the service attributes of the called number 66600050. ADD CNACLD: P=0, PFX=K'666, CSA=LC, RSNAME="B2C", MINL=7, MAXL=32, ICLDTYPE=PS; Set Service attribute to Local and Called number type to PSTN.
----End
A WIN user calls other MSC user. The calling number is 8613807520511 and the calling party is a WIN user in office B. The called number is 13807520001 and the called party is the mobile user in office C. The roaming number prefix allocated by office C is 13903. The route selection name from office B to office C is B2C.Office B is the local office and 86 is national country code.
The procedure for configuring the MSOFTX3000 is as follows: Step 1 Configure the called number 13807520001, to which the local office allocates the roaming number. Description Script Remark Configure the called number analysis table. ADD CNACLD: P=0, PFX=K'1380752, CSA=MLCT, MINL=11, MAXL=32, ICLDTYPE=MS; Set Service attribute to PLMN other MSC and Called number type to MSISDN.
Step 2 Configure the service attributes of the called number 13903. Description Script Remark Configure the called number analysis table. ADD CNACLD: P=0, PFX=K'13903, CSA=MLCT, RSNAME="B2C", MINL=11, MAXL=32, ICLDTYPE=MSRH; Set Service attribute to PLMN other MSC and Called number type to MSRN/HON.
----End
A fixed user calls a WIN user. The calling number is 075566600050 and the calling party is the fixed user in office A. The called number is 13807520511 and the called party is the WIN
Issue 02 (2007-06-10)
36-15
user in office B. The roaming number prefix allocated by office B is 13902. The route selection name from office B to office A is B2A. Office B is the local office.0 is the national number prefix and 755 is the local area code.
The procedure for configuring the MSOFTX3000 is as follows: Step 1 Configure the service attribute of the called number 075566600050. (It corresponds to the calling number when the system queries the data table through the calling number). Description Script Remark Configure the called number analysis table. ADD CNACLD: P=0, PFX=K'666, CSA=LC, RSNAME="B2A", MINL=7, MAXL=32, ICLDTYPE=PS; Set Call prefix to 666, Service attribute to Local and Called number type to PSTN.
Step 2 Configure the called number 13807520511, to which the local office allocates the roaming number. Description Script Remark Configure the called number analysis table. ADD CNACLD: P=0, PFX=K'1380752, CSA= MLCO, MINL=11, MAXL=32, ICLDTYPE=MS; Set Service attribute to PLMN local MSC and Called number type to MSISDN.
Step 3 Configure the roaming number 13902. Description Script Remark Configure the called number analysis table. ADD CNACLD: P=0, PFX=K'13902, CSA=MLCO, MINL=11, MAXL=32, ICLDTYPE=MSRH; Set Service attribute to PLMN local MSC and Called number type to MSRN/HON.
----End
Other MSC user calls a WIN user. The calling number is 13807520001 and the calling party is the mobile user in office A. The called number is 8613807520511 and the called party is the mobile WIN user. The call source name of office A configured in office B is A2B.The roaming number prefix is 13902.Office B is the local office and 86 is the national country code.
36-16
Issue 02 (2007-06-10)
The procedure for configuring the MSOFTX3000 is as follows: Step 1 Configure the called number analysis table, to which the local office allocates the roaming number. Description Script Remark Configure the called number analysis table. ADD CNACLD: P=0, PFX=K'861380752, CSA= MLCO, MINL=11, MAXL=32, ICLDTYPE=MS; Set Call prefix to 861380752, Service attribute to PLMN local MSC and Called number type to MSISDN.
Step 2 Configure the roaming number 13902. Description Script Remark Configure the called number analysis table. ADD CNACLD: P=0, PFX=K'13902, CSA=MLCO, MINL=11, MAXL=32, ICLDTYPE=MSRH; Set Service attribute to PLMN local MSC and Called number type to MSRN/HON.
Step 3 Configure the number change mode. Description Script Remark Configure the number change table. ADD DNC: DCN="ADD86", DCT=TYPE1, DCP=0, ND=K'86; Set Number change option to Insert number at designated position.
Step 4 Configure the auxiliary number change mode. Description Script Remark Configure the auxiliary number processing table. ADD AIDNUMPRO: CSCNAME="A2B", NUMTY=TY11, PFX=K'1380752, CDN="ADD86"; Set Number type to TK incoming office caller number and Number change name to ADD86.
----End
Issue 02 (2007-06-10)
36-17

The service management of the IN performance measurement enhancement contains creating, modifying, deleting and querying. The definition of each operation is as follows: Creating: It is performed by carriers to enable the performance measurement to be available. The creating operation corresponds to the deleting operation. Modifying: It is performed by carriers to modify the service attributes of the performance measurement. Deleting: It is performed by carriers to enable the performance measurement to be unavailable. The deleting operation corresponds to the creating operation. Querying: It is performed by carriers to query the service attribute or result of the performance measurement. Table 36-6 lists the operation modes of the IN performance measurement enhancement. Table 36-6 Operation modes of the IN performance measurement enhancement Operated by Carriers Where to Operate MSOFTX3000 performance management system Operation Contents Creating, modifying, deleting and querying

Through the MSOFTX3000 performance management system, carriers create, modify, delete or query the performance measurement task of the following units: Traffic For WIN User Calling Fixed User Traffic For WIN User Calling Other MSC User Traffic For Fixed User Calling WIN User Traffic For Other MSC User Calling WIN User For details, refer to the online help of the MSOFTX3000 performance management system.

None.

None.
36-18
Issue 02 (2007-06-10)

The newly added performance measurement units contain the following: Traffice For WIN User Calling Fixed User Traffic For WIN User Calling Other MSC User Traffic For Fixed User Calling WIN User Traffic For Other MSC User Calling WIN User
36.8.1 Specification Descriprion

The measurement units "Traffic For WIN User Calling Fixed User" and "Traffic For WIN User Calling Other MSC User" include the following entities: Attempting number Connecting number Answering number Abandoned number before alerting Abandoned number after alerting Callee busy number No answer number for ringing Seizing traffic Connecting traffic Answering traffic The measurement units "Traffic For Fixed User Calling WIN User" and "Traffic For Other MSC User Calling WIN User" include the following entities: Attempting number Connecting number Answering number Abandoned number before alerting Abandoned number after alerting Callee busy number No answer number for ringing Called determined busy number Seizing traffic Connecting traffic Answering traffic These preceding specifications of the performance measurement can be used only when Service key and Multi-area statistics are set in the system. In the case of non-multi-area networking, you need not set Multi-area statistics.

For details, refer to section 36.3 "Working Principle."
Issue 02 (2007-06-10)
36-19

The feature has no interaction with other services of the system.
36.10 Reference
The reference lists of the feature are as follows: 3GPP 23078, "Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase 3 - Stage 2" 3GPP 24.007, "Mobile Radio Interface Layer 3 specification; Core Network Protocols; Stage 3"

Glossary
Items Fixed user Other MSC user Description It indicates the PSTN user. It indicates the mobile user who is not in the local office.

Acronyms/Abbreviations PSTN MSC RNC BSC SCP HLR Full Name Public Switched Telephony Network Mobile Switching Center Radio Network Controller Base Station Controller Service Control Point Home Location Register
36.11 FAQ
Symptom of Failure
The calling number is 8613907520511 and the calling category is other MSC user. Called prefix configured in the called number analysis table is 861390752. The system, however,
36-20
Issue 02 (2007-06-10)
fails to query the called number analysis table and performs the performance measurement for fixed user calling WIN user.
Handling the Failure

Before configuration, the system regulates the calling number. Through confirmation, Call prefix is configured incorrectly in the called number analysis table. In this case, add the record with Call prefix of 1390752 in the called number analysis table.
Verifying the Failure

The system can perform the performance measurement based on the measurement point of "Traffic For Other MSC User Calling WIN User".
Issue 02 (2007-06-10)
36-21
Contents
Contents
37 Automatic Device Detection ................................................................................................37-1
37.1 Service Description ...................................................................................................................................37-2 37.1.1 Function Code..................................................................................................................................37-2 37.1.2 Definition .........................................................................................................................................37-2 37.1.3 Standard Compliance .......................................................................................................................37-2 37.1.4 System Specifications ......................................................................................................................37-2 37.1.5 Benefits ............................................................................................................................................37-2 37.1.6 Application Scenario ........................................................................................................................37-3 37.1.7 Application Limitations....................................................................................................................37-3 37.2 Availability ................................................................................................................................................37-3 37.2.1 Requirements for NEs......................................................................................................................37-3 37.2.2 Requirements for License ................................................................................................................37-3 37.2.3 Applicable Versions..........................................................................................................................37-3 37.2.4 Other ................................................................................................................................................37-3 37.3 Working Principle......................................................................................................................................37-4 37.3.1 Functions of the NEs........................................................................................................................37-4 37.3.2 Internal Processing of the System ....................................................................................................37-4 37.3.3 External Interfaces ...........................................................................................................................37-5 37.4 Service Flow..............................................................................................................................................37-5 37.5 Data Configuration....................................................................................................................................37-7 37.5.1 Configuration Description................................................................................................................37-7 37.5.2 Data Configuration at the MSOFTX3000........................................................................................37-7 37.5.3 Data Configuration Example............................................................................................................37-8 37.5.4 Table Query Flow of ADD...............................................................................................................37-9 37.6 Service Management ...............................................................................................................................37-10 37.6.1 Overview........................................................................................................................................37-10 37.6.2 Operations by Carriers ................................................................................................................... 37-11 37.6.3 Operations by Subscribers ............................................................................................................. 37-11 37.7 Reference ................................................................................................................................................ 37-11 37.7.1 Specifications................................................................................................................................. 37-11 37.7.2 Acronyms and Abbreviations ......................................................................................................... 37-11 37.8 FAQ .........................................................................................................................................................37-12
Issue 02 (2007-06-10)
Contents
HUAWEI MSOFTX3000 Feature Description 37.8.1 Problem Description ......................................................................................................................37-12 37.8.2 Cause of the Problem .....................................................................................................................37-12 37.8.3 Method ...........................................................................................................................................37-12
ii
Issue 02 (2007-06-10)
Figures
Figures
Figure 37-1 Flow of the ADD service ..............................................................................................................37-4 Figure 37-2 ADD message flow .......................................................................................................................37-5 Figure 37-3 Table query flow of the ADD service .........................................................................................37-10
Issue 02 (2007-06-10)
iii
Tables
Tables
Table 37-1 Name and code of the function.......................................................................................................37-2 Table 37-2 Beneficiaries and description of the benefits of the ADD service ..................................................37-2 Table 37-3 Network elements involved in the ADD service.............................................................................37-3 Table 37-4 Versions supported by the ADD service .........................................................................................37-3 Table 37-5 Operations of data configuration at the MSOFTX3000..................................................................37-7 Table 37-6 Name and function of tables related to the ADD service................................................................37-9 Table 37-7 Operation modes of the ADD service ........................................................................................... 37-11
iv
Issue 02 (2007-06-10)
37 Automatic Device Detection
37
About This Chapter
Automatic Device Detection
The following table lists the contents of this chapter. Describes The function code and definition of the service and the benefits of the service to carriers and mobile subscribers. The NEs required to implement the service, requirements for the license, and versions of the products applicable to the service. The functions of the NEs used to implement the service and the requirements on the networking. The flow of the service. The data configuration that must be performed at the MSOFTX3000 side and the UMG8900 side as well as the examples of data configuration. The operations that carrier and mobile subscribers must perform when the service is provided. The standards and specifications with which the service complies and the glossary, abbreviations, and acronyms used in this chapter. The frequently asked questions related to the service and the solutions.
37.6 Service Management 37.7 Reference
37.8 FAQ
Issue 02 (2007-06-10)
37-1

Table 37-1 lists the name and code of the function. Table 37-1 Name and code of the function Name Automatic device detection Code WMFD-122100
37.1.2 Definition
International mobile equipment identity software version (IMEISV) is used to mark the software version of the mobile equipment. The MSOFTX3000 supports the automatic detection function of the IMEISV. That is, the IMEISV information of the mobile station is updated in real time in the HLR so that the network knows the changes of the subscriber equipment. Automatic device detection (ADD) service requires that the MAP protocol of both the MSOFTX3000 and the HLR support the location update message carrying add-info information. Therefore, the MSOFTX3000 can send the updated IMEISV information of the mobile station (MS) to the HLR in real time during the location update of mobile subscribers.

None.

None.
37.1.5 Benefits
Table 37-2 lists the beneficiaries and description of the benefits of the ADD service. Table 37-2 Beneficiaries and description of the benefits of the ADD service Beneficiary Carriers Description Carriers can provide new services that are applicable to the equipment version by obtaining the IMEISV. The ADD service helps carriers with the market orientation and improves the satisfaction of the subscriber. The subscriber can provide more related information of equipments to the network. Thus, the subscriber has more chances to select the new services supported by the software.
Mobile subscribers
37-2
Issue 02 (2007-06-10)

It is applicable to the GSM and UMTS R99/R4 network.

None.
37.2 Availability
Table 37-3 lists the network elements involved in the ADD service. Table 37-3 Network elements involved in the ADD service MS/UE BTS/NodeB BSC/R NC MSC server MGW SGSN GGSN HLR
The symbol indicates that the network element is involved.

The ADD service is an optional service of the HUAWEI GSM&UMTS network. No license is required to obtain the service.

Table 37-4 lists the versions supported by the ADD service. Table 37-4 Versions supported by the ADD service Product MSC server MSOFTX3000 Applicable Versions V100R005C10
37.2.4 Other
To support the ADD service, the MAP version used must be set to MAP phase2+ or later version
Issue 02 (2007-06-10)
37-3

The functions of the network elements involved in the ADD service are as follows: The RNC/BSC, MSC server, and HLR carry out the operations related to signaling in the location update. When the MSC server and the HLR support the ADD service, the MSC server obtains the IMEISV from the subscriber and saves it in the HLR.

To realize the ADD service, IMEISV processing is added in the original flow of location update. Figure 37-1 shows the flow of the ADD service. Figure 37-1 Flow of the ADD service
MS
D1
D2
D4
D3 MSOFTX3000 HLR
The flow of the ADD service is as follows: 1. 2. 3. 4. The MSC server checks whether both of the local HLR and peer HLR support the ADD service. If yes, the MSC server sends a request to the MS to obtain IMEISV. The MS sends the IMEISV to the MSC server. After receiving the IMEISV from the MS, the MSC server originates location update request to the HLR. The HLR responds to the location update request. Based on the response from the HLR and the local office configuration, the MSC server determines whether to update the capabilities of supporting the ADD service of the peer HLR in the local HLR list.
37-4
Issue 02 (2007-06-10)

The interface between the MSC server and the HLR complies with the definition in 29002 protocol.
37.4 Service Flow

Figure 37-2 shows the ADD message flow. Figure 37-2 ADD message flow
MS MSC Server Location_Updating_Request Identity_Qeuest Identity_Response MAP_UPDATE_LOCATION_REQ MAP_UPDATE_LOCATION_CNF Location_Updating_Accept HLR
The ADD message flow in location update is as follows: 1. After receiving the location update request, the MSC server determines whether the local office supports the ADD service, by querying the Local Office Information table and determines whether the peer HLR supports the ADD service, by querying the local office configuration. If both the local office and the peer HLR in the local HLR list support the ADD service, the MSC server decides whether to send the request for obtaining the IMEISV (through the Identity_Request message) to the MS based on the type of current location update. The judging principle is as follows:

2.
For periodic location update, if the local office stores the IMEISV of the subscriber, it is not required to obtain IMEISV from the MS. For periodic location update, if the local office does not store the IMEISV of the subscriber, the MSC server must obtain the IMEISV from the MS. For the location update of other types, the IMEISV must be obtained from the MS.
3.
If the local office or peer HLR does not support the ADD service, the flow is the same as that of the location update. If the IMEISV must be obtained from MS in the flow, the software parameter is used to control whether to obtain the IMEI or IMEISV. The description of the software parameter is as follows: Bit 8 of P190 (MM_FETCH_IMEI): determines whether the mobile management (MM) module sends a request for the IMEI or IMEISV to the MS.
Issue 02 (2007-06-10)
37-5
=0: IMEISV =1: IMEI Default value: 1 4. If IMEISV fails to be obtained from the MS, and both the local office and the peer HLR support the ADD service, the MSC server determines whether to terminate the flow of location update based on bit 0 of P650. If bit 0 of P650 is set to 0, the location update flow continues and IMEI is no longer obtained. If bit 0 of P650 is set to 1, the location update flow is terminated. In the following flow, the local office judges whether to carry out location update in the HLR. The cases are as follows:
5.
In the original flow, location update need be carried out in the HLR. The local office and peer HLR support the ADD service. If the IMEISV is successfully obtained, the IMEISV is sent to the HLR through the information element add_info. In the original flow, location update need be carried out in the HLR. The local office and peer HLR support the ADD service. If IMEISV fails to be obtained from the MS, but the flow controlled by the software parameter continues, the original IMEISV of the local office is updated in the HLR. If the local office does not save the IMEISV, the location update request sent to the HLR does not carry IMEISV. In the original flow, location update need not be carried out in the HLR. The local office and peer HLR support the ADD service. If IMEISV is successfully obtained from the MS, the obtained IMEISV is compared with the saved IMEISV. If the new and old IMEISV are different, such as the local office does not save the IMEISV, location update need be carried out in the HLR; If the new and old IMEISV are the same, but the local office does not support ADD in the location update of last time, location update need be carried out in the HLR; If the new and old IMEISV are the same, and the IMEISV is updated to the HLR in the location update of last time, location update need not be carried out in the HLR.
If the local office or the peer HLR does not support the ADD service, the flow continues in the same way as the original one.
6.
After receiving the location update response, the local office updates the ADD support capability of the HLR in the local HLR list based on the response. If bit 1 of P650 is set to 1, the response from the HLR must be sent to the other WCCU/WCSU boards. If the ADD support capability is configured as Peremptory Support or Peremptory Not Support, the MSOFTX3000 does not update the ADD support capability of the HLR in local HLR list. The description of the software parameter is as follows: Bit 1 of P650 (IF_BROADCAST_WHEN_ADD_SUPPORT_HLR_LIST_CHANGE): determines whether to send the response to the other WCCU/WCSU boards when the response from the HLR to the location update request leads to the global update of ADDSupportHLRList. =0: Not send the response to the other WCCU/WCSU boards =1: Send the response to the other WCCU/WCSU boards Default value: 0
37-6
Issue 02 (2007-06-10)

Run SET MAPACCFG to configure local office to enable ADD service on the MSOFTX3000 client. Run ADD ADDSUPHLR and SET ADDSUPHLR to configure ADD support strategy and the local HLR list.
37.5.2 Data Configuration at the MSOFTX3000

Table 37-5 lists the operations of data configuration at the MSOFTX3000. Table 37-5 Operations of data configuration at the MSOFTX3000 Serial Number 1 2 3 4 5 Operation Run ADD IMSIHOME to configure the HLR number of the subscriber. Run SET MAPACCFG to configure local office for the support of the ADD service. Run SET ADDSUPHLR to configure the ADD support strategy of the local office for the HLRs that have no matched index in the HLR list. Run ADD ADDSUPHLR to configure HLR number prefix and ADD support strategy in the HLR list. Run LST ADDSUPHLR to query configuration of HLR.
When you run the command SETADDSUPHLR/ADD ADDSUPHLR to configure the local HLR list, you can configure the support of the ADD service of the HLR through the parameter Support ADD. The value options of Support ADD are described in the following: Default Not Support: The initial configuration of the system determines that the HLRs with the specified HLR number prefix do not support the ADD service. If the system configuration determines that the local office supports ADD, the data is updated subsequently based on the location update response from the HLR. Default Support: The initial configuration of the system determines that the HLRs with the specified HLR number prefix support the ADD service. If the system configuration determines that the local office does not support ADD, the data of ADD support capability is updated subsequently based on the location update response from the HLR. Peremptory Support: The initial configuration of the system determines that the HLRs with the specified HLR number prefix support the ADD service. The data of ADD support capability is not updated subsequently based on the location update response from the HLR. Peremptory Not Support: The initial configuration of the system determines that the HLRs with the specified HLR number prefix do not support the ADD service. The data of ADD support capability is not updated subsequently based on the location update response from the HLR.
Issue 02 (2007-06-10)
37-7

Configure the local office data to support the ADD service. The HLR with number prefix 8613755 is configured to support the ADD service.
The configuration flow of the ADD service is as follows: Step 1 Configure the data in the local office to support the ADD service. Description Script Remark Configure the data in the local office to support the ADD service. SET MAPACCFG: IFSUPADD=YES; None.
Step 2 Configure the ADD support strategy of the HLR in the default HLR list. Description Script Remark Configure the Peremptory Support in the default HLR list. SET ADDSUPHLR: IFSUPADD=PS; It is used to configure whether to support ADD by default. It is saved in No.0 record in the data table. If HLR number does not match with any record in course of table query, the value of No.0 record is used to decide whether this HLR supports the ADD service.
Step 3 Configure the HLR list. Description Script Remark Configure the HLR with number prefix 8613755 to peremptorily support the ADD service. ADD ADDSUPHLR: HLRNUMPREFIX=K'8613755, IFSUPADD=PS; 127 HLR items can be configured at most by running this command.
Step 4 Query the configuration items of the list. Description Script Remark Query the configuration item of HLR with number prefix 8613755 in the HLR list. LST ADDSUPHLR: HLRNUMPREFIX=K'8613755; If the prefix of HLR number is not entered, all HLR lists and configuration items are listed.
37-8
Issue 02 (2007-06-10)
----End
37.5.4 Table Query Flow of ADD

Table 37-6 lists the name and function of tables related to the ADD service. Table 37-6 Name and function of tables related to the ADD service Table Name tbl_MAPCfg Function To store the related configuration information of local office To store the HLR numbers of subscribers. To store the information of the HLR list Related MML Command SET MAPACCFG
tbl_ImsiHome tbl_HLRADDList
ADD IMSIHOME ADD ADDSUPHLR MOD ADDSUPHLR RMV ADDSUPHLR LST ADDSUPHLR SET ADDSUPHLR DSP ADDSUPHLR
Figure 37-3 shows the table query flow of the ADD service.
Issue 02 (2007-06-10)
37-9
Figure 37-3 Table query flow of the ADD service

Start
Querying the tbl_MAPCfg table to determine whether the local MSC supports ADD is successful. Yes
No
The local MSC supports the ADD service.
No
Yes Querying the tbl_ImsiHome table to obtain the HLR number of the subscriber is successful. Yes Querying the tbl_HLRADDList table to check whether the No.0 record determines the peer HLR supports ADD by default Yes
No
No
Carrying out the original location update flow.
Querying the tbl_HLRADDList table to determine whether the peer HLR supports ADD Yes Obtaining the IMEISV from the MS and carry out the following location update flow.
No

37.6.1 Overview
The ADD service has two operation modes, as listed in Table 37-7. Table 37-7 Operation modes of the ADD service Operation Mode Operations by carriers Operation Interface MSOFTX3000 Service Operations None.
37-10
Issue 02 (2007-06-10)
Operation Mode Operations by mobile subscribers
Operation Interface MS
Service Operations None.

Carriers can control whether the local office and the peer HLR support the ADD service through the operation on LMT of the MSOFTX3000. The configuration flow is as follows: Step 1 Run SET MAPACCFG to enable the ADD service of the local office. Step 2 Run SET ADDSUPHLR to configure the default ADD support strategy. Step 3 Run ADD ADDSUPHLR to configure the HLR list option. ----End

None.
37.7 Reference
Reference list of this service is as follows: 3GPP TS 23012 3GPP TS 29002.

Acronym/Abbreviation ADD IMEISV Full Name Automatic device detection International mobile station equipment identity software version
Issue 02 (2007-06-10)
37-11
37.8 FAQ
37.8.1 Problem Description
The command ADD ADDSUPHLR is run and the home HLR is configured for the support of ADD, but the IMEISV is not carried in HLR location update message.
37.8.2 Cause of the Problem

The HLR number of the subscriber is not saved in the VLR.
37.8.3 Method
Run ADD IMSIHOME to match the IMSI of the subscriber with the HLR number.
37-12
Issue 02 (2007-06-10)
Contents
Contents
38 Noise Suppression .................................................................................................................38-1
38.1 Service Description ...................................................................................................................................38-2 38.1.1 Function Code..................................................................................................................................38-2 38.1.2 Definition .........................................................................................................................................38-2 38.1.3 Standard Compliance .......................................................................................................................38-2 38.1.4 System Specifications ......................................................................................................................38-3 38.1.5 Benefits ............................................................................................................................................38-3 38.1.6 Application Scenario ........................................................................................................................38-3 38.1.7 Application Limitations....................................................................................................................38-3 38.2 Availability ................................................................................................................................................38-4 38.2.1 Requirements for NEs......................................................................................................................38-4 38.2.2 Requirements for License ................................................................................................................38-4 38.2.3 Supporting Versions .........................................................................................................................38-4 38.2.4 Others...............................................................................................................................................38-4 38.3 Working Principle......................................................................................................................................38-4 38.3.1 Functions of NEs..............................................................................................................................38-4 38.3.2 Internal Processing...........................................................................................................................38-5 38.3.3 External Interfaces ...........................................................................................................................38-5 38.4 Service Flow..............................................................................................................................................38-5 38.5 Data Configuration....................................................................................................................................38-6 38.5.1 Overview..........................................................................................................................................38-6 38.5.2 Configuration at the MSOFTX3000 Side ........................................................................................38-7 38.5.3 Configuration on the UMG8900 Side ..............................................................................................38-7 38.5.4 Data Configuration Examples ..........................................................................................................38-8 38.5.5 Table Query Flow of Noise Suppression Feature.............................................................................38-9 38.5.6 Table Query Flow of Noise Suppression Feature...........................................................................38-10 38.6 Service Management ............................................................................................................................... 38-11 38.6.1 Operations by Carriers ................................................................................................................... 38-11 38.6.2 Operations by Subscribers ............................................................................................................. 38-11 38.7 Charging and CDR .................................................................................................................................. 38-11 38.8 Performance Measurement......................................................................................................................38-12 38.9 Service Interaction ..................................................................................................................................38-12
Issue 02 (2007-06-10)
Contents
38.10 Reference...............................................................................................................................................38-12 38.10.1 Specifications...............................................................................................................................38-12 38.10.2 Glossary, Acronyms and Abbreviations .......................................................................................38-12 38.11 FAQ .......................................................................................................................................................38-13
ii
Issue 02 (2007-06-10)
Figures
Figures
Figure 38-1 Networking of the system internal processing..............................................................................38-5 Figure 38-2 Service flow of the noise suppression feature...............................................................................38-6 Figure 38-3 Table query flow of noise suppression service (Support noise removing benefit local end) ......38-10 Figure 38-4 Table query flow of noise suppression service (Support noise removing benefit peer end) ....... 38-11
Issue 02 (2007-06-10)
iii
Tables
Tables
Table 38-1 Function code of the noise suppression feature ..............................................................................38-2 Table 38-2 NEs related to the noise suppression service ..................................................................................38-4 Table 38-3 Versions supporting the noise suppression service .........................................................................38-4
iv
Issue 02 (2007-06-10)
38 Noise Suppression
38
About This Chapter
Section 38.1 Service Description 38.2 Availability Describes
Noise Suppression
38.11 FAQ
Issue 02 (2007-06-10)
38-1

Table 38-1 lists the function code of the noise suppression feature. Table 38-1 Function code of the noise suppression feature Name Noise suppression feature Code -
38.1.2 Definition
Name Noise suppression feature Definition The feature provides the following two functions: Noise removing benefit local end and Noise removing benefit peer end. Noise removing benefit local end: When this function is selected, the system effectively reduces the noise brought by the background sound of the peer end during the call in order that the local end receives higher-quality voice. Noise removing benefit peer end: When this function is selected, the system effectively reduces the noise brought by the background sound of the local end during the call in order that the peer end receives higher-quality voice.

ITU-T G.160 draft
38-2
Issue 02 (2007-06-10)

Item Noise suppression feature Describes After configured with the MGW and trunk group information, the MSC server sends messages to support noise suppression service when the network bearer is set up. The functions provided by the noise suppression service are subordinated to the enhanced voice service. Currently, noise suppression provides only two functions: noise suppression beneficial to the local end and noise suppression beneficial to the peer end. The noise suppression is applied to only voice service and cannot be used with data service. The switch and direction (local end beneficial, peer end beneficial or mutually beneficial) of the noise suppression are controlled by the MSC server through the MC interface. The degree of noise suppression is configured by the SET VQEPARA command. (In this manual, the MGW delivered with the MSC Server is the UMG8900 of Huawei. For configuring other MGWs, refer to the UMG8900.)
38.1.5 Benefits
Beneficiary Carrier Mobile subscriber Describes The service satisfies the needs of subscribers and improves the quality of call and the satisfaction of subscribers. Subscribers receive high-quality calls after the system supports the noise suppression feature.

The service is applied to the GSM and UMTS R99/R4.

The function can only be enabled on trunk group at present. The UMG8900 of Huawei is required for the function. The description of the function in the following text is also on the basis of realizing the auxiliary function of the UMG8900 (The function depends on the VQE resource configured on the MGW. A VPU board. Can be configured with only one VQE subboard. Configure related parameters of the noise suppression by the SET VQEPARA command on the MGW properly before using the function).
Issue 02 (2007-06-10)
38-3
38.2 Availability
The function of the noise suppression service is implemented by the MSC Server and MGW. See Table 38-2. Table 38-2 NEs related to the noise suppression service UE NodeB RNC MSC Server MGW SGSN GGSN HLR -
NE is short for network element. The symbol "" indicates that the NE is required. The symbol "-" indicates that the NE is not required.

The noise suppression service can be enabled without license.
38.2.3 Supporting Versions

The following versions of MSOFTX3000 and UMG8900 applied to the noise suppression service, as shown in Table 38-3. Table 38-3 Versions supporting the noise suppression service Product MSC Server MGW MSOFTX3000 UMG8900 Supporting Versions V100R005C10 V200R005C02B062SP05 V200R005C10B031
38.2.4 Others
None.

The MSC Server supports the configuration of the noise suppression service, and sends messages of noise suppression parameters to the MGW.
38-4
Issue 02 (2007-06-10)
The MGW analyzes the received messages of noise suppression parameters and enables the noise suppression function on the corresponding port.
38.3.2 Internal Processing

Figure 38-1 shows the networking of system internal processing. Figure 38-1 Networking of the system internal processing
MSC Server (MSOFTX3000-1)
MGW1 Bearer network
Subscriber B
Trunk group1 Subscriber A
As shown in Figure 38-1, the calls of subscribers A and B are borne over trunk group1 and MGW1. On the MSC Server, the operator must configure the noise suppression function for trunk group1 and MGW1. If the noises that are caused by subscriber B's background voice and that subscriber A hears must be reduced, set Enhanced voice attribute to Noise removing benefit local end. If the noises that are caused by subscriber A's background voice and that subscriber B hears must be reduced, set Enhanced voice attribute to Noise removing benefit peer end.
Whether the MSC Server sends noise suppression parameters to the MGW is determined by the MGW noise suppression configuration and trunk group noise suppression configuration in the MSC Server. Only when the noise suppression function is configured for the MGW and trunk group in the MSC Server database, the information that the MSC Server sends to the MGW carries the noise suppression parameters and the noise suppression is valid.

None.
38.4 Service Flow

Figure 38-2 shows the flow of the noise suppression feature.
Issue 02 (2007-06-10)
38-5
Figure 38-2 Service flow of the noise suppression feature

MSC Server MGW
ADD(NR/NRDIR) ADD Reply Call Connection
The processing flow of the noise suppression feature is as follows: 1. The MSC Server instructs the MGW to build a bearer. When the bearer mode is TDM, the system finds out whether the noise suppression function is enabled by querying the trunk group configuration information, and whether the noise suppression function is enabled by querying the gateway configuration information. If the trunk group configuration information instructs to enable the noise suppression function, and the gateway configuration information instructs to support the noise suppression function, the MSC Serve adds noise suppression information element in related messages sent to the MGW to instruct the MGW to enable the noise suppression service. The noise suppression is applied to voice service only. The MGW sends the response message back to the MSC server.
Whether the noise suppression service is supported depends on the VQE resource configured on the UMG8900. Only one VQE subboard can be inserted in a VPU board. Configure related parameters of the noise suppression by the SET VQEPARA command on the MGW before using the function. After that, configure related parameters of the noise suppression by the following parameters on the MSOFTX3000:
2.
Special attributes in ADD/MOD MGW
Enhanced voice attribute in ADD/MOD N7TG, ADD/MOD CASTG, ADD/MOD PRATG and ADD/MOD AIETG
When the common channel signaling connects the voice call, the trunk group table is queried before the bearer is established. If the A interface trunk module connects the voice call, the module obtains the information of noise suppression from the result returned from A interface routing. If the R2 trunk is used, the noise suppression function is enabled. The system can enable the noise suppression function only in the state of Ringing Mode or listening to the ring back tone. If the common channel trunk, the A interface trunk or R2 trunk is used, the noise suppression function is disabled. If the noise suppression function is enabled, and the handover from voice to data during the call occurs, the MSC server sends the Modify messages to the MGW, indicating disabling the noise suppression service.

38.5.1 Overview
To use the noise suppression function, perform the data configuration on the UMG8900 and MSOFTX3000.
38-6
Issue 02 (2007-06-10)
38.5.2 Configuration at the MSOFTX3000 Side

Adding an MGW
Operators must select Support Noise removing benefit local end and Support Noise removing benefit peer end for Special attribute in ADD/MOD MGW. Special attributes Support Noise removing benefit local end: It specifies whether the MGW supports the function that the local end benefits from the noise removing. By default, the function is not supported. If the function is supported, this value can be selected. To ensure that both the local and the peer ends can benefit from noise removing, select both Support Noise removing benefit local end and Support Noise removing benefit peer end. Support Noise removing benefit peer end: It specifies whether the MGW supports the function that the peer end benefits from the noise removing. By default, this function is not supported. If the function is supported, this value can be selected. To ensure that both the local and the peer ends can benefit from noise removing, select both Support Noise removing benefit local end and Support Noise removing benefit peer end.
Adding a Trunk Group

Operators must select Noise removing benefit local end and Noise removing benefit peer end for Enhanced voice attribute in ADD/MOD N7TG, ADD/MOD PRATG, ADD/MOD CASTG, and ADD/MOD AIETG. Enhanced voice attribute It specifies the voice enhancement function of a trunk group. By default, the function is disabled. Values: Noise removing benefit local end: The system reduces the noise caused by the background sound of the peer end to provide a high-quality voice for the local end. Noise removing benefit peer end: The system reduces the noise caused by the background sound of the local end to provide a high-quality voice for the peer end. To enable this function, certain data must be configured for the MGW by running ADD MGW or MOD MGW on the MSOFTX3000.
38.5.3 Configuration on the UMG8900 Side

Operators configure the noise reduction degree by the SET VQEPARA command on the UMG8900. The noise reduction degree is 9db by default when it is not configured. Change the noise reduction degree by the command SET VQEPARA. For example, if you set the noise reduction degree to 10db, run the following command on the UMG8900: (Note: The more the value is, the higher becomes noise reduction degree.)
SET VQEPAPA: NRGN=10;
Issue 02 (2007-06-10)
38-7

The configurations of Enhanced voice attribute on ADD N7TG, ADD PRATG, ADD CASTG and ADD AIETG are almost the same. Thus, the configuration of ADD N7TG is described in this manual. For the configurations of ADD PRATG, ADD CASTG and ADD AIETG, refer to the configuration of ADD N7TG.
As shown in Figure 38-1, the preconditions on MSOFTX3000-1 are as follows: The link between MSOFTX3000-1 and MGW1 is configured and activated. Office direction, route, sub-route, route analysis and call prefix are all configured, and the hardware is normal. Noise removing benefit local end and Noise removing benefit peer end are not configured on MGW1. Trunk group name is set to NRTG, MGW name to MGW1, Circuit type to ISUP, Sub-route name to PSTN, DPC to 123456, and Call source name to CALLSRC. The operator must perform the noise suppression for the calls between subscribers A and B on trunk group1 to reduce the noises caused by the peer background voice.
Configuration Scripts at the MSOFTX3000 Side

Assume that related tables of the local office are configured. The configuration procedure of the noise suppression feature is as follows: Step 1 Add a trunk group. Description Set Trunk group name to NRTG, MGW name to MGW1, Circuit type to ISUP, Sub-route name to PSTN, DPC to 123456, and Call source name to CALLSRC, and select Noise removing benefit local end and Noise removing benefit peer end for Enhanced voice attribute. ADD N7TG: TGN="NRTG", MGWNAME="MGW1", CT=ISUP, SRN="PSTN", SDPC="123456", CSCNAME="CALLSRC", RELRED=NO, EVA=NRLE-1&NRPE-1; If noise suppression parameters are not configured on MSOFTX3000-1, Noise removing benefit local end and Noise removing benefit peer end are not selected by default. When Enhanced voice attribute is set to Noise removing benefit local end, it indicates that the noises caused by subscriber B's background voice must be reduced. When Enhanced voice attribute is set to Noise removing benefit peer end, it indicates that the noises caused by subscriber A's background voice must be reduced.
Script
Note
Step 2 List trunk group configuration.
38-8
Issue 02 (2007-06-10)
Description Script Note
List the trunk group of which Enhanced voice attribute is configured. LST N7TG: TGN="NRTG", QR=LOCAL; or LST TG: TGN="NRTG", QR=LOCAL; None.
Step 3 Configure the information of the MGW. Description Script Note Select Support Noise removing benefit local end and Support Noise removing benefit peer end for Special attribute. MOD MGW: MGWNAME="MGW1", TRNST=SCTP, SPCATTR=NRBENEFITLOCAL-1&NRBENEFITREER-1; None.
----End
Configuration Scripts at the UMG8900 Side

Description Script Note Set Noise reduction Degree (db) to 10 on the UMG8900. SET VQEPARA: NRGN=10; None.
38.5.5 Table Query Flow of Noise Suppression Feature

The following table shows the tables related to the noise suppression service. Table Name Trunk group table Function It records related information of configured trunk group, which includes a new function enhanced voice attribute. Related MML Command ADD/MOD N7TG ADD/MOD PRATG ADD/MOD CASTG ADD/MOD AIETG MGW configuration table It records related data of configured MGW. ADD/MOD MGW
Issue 02 (2007-06-10)
38-9
38.5.6 Table Query Flow of Noise Suppression Feature

The commands ADD/MOD N7TG, ADD/MOD PRATG, ADD/MOD CASTG, ADD/MOD AIETG activate noise suppression feature, and record Enhanced voice attribute to the trunk group table. The command ADD/MOD MGW activates noise suppression feature, and records Support Noise removing benefit local end and Support Noise removing benefit peer end in Special attribute to MGW configuration table. Figure 38-3 and Figure 38-4 show the table query flows of noise suppression feature. Figure 38-3 Table query flow of noise suppression service (Support noise removing benefit local end)
Start
Is Enhanced voice attribute in the trunk group table set to Support noise removing benefit local end?
No
Yes
Is Special attribute in the MGW configuration table set to Support noise removing benefit local end ?
No
Yes The MSC Server sends the noise suppression information element that indicates Support noise removing benefit local end.
The MSC Server does not send the noise suppression information element that indicates Support noise removing benefit local end.
38-10
Issue 02 (2007-06-10)
Figure 38-4 Table query flow of noise suppression service (Support noise removing benefit peer end)
Start
Is Enhanced voice attribute in the trunk group table set to Support noise removing benefit peer end?
No
Yes
Is Special attribute in the MGW configuration table set to Support noise removing benefit peer end ?
No
Yes The MSC Server sends the noise suppression information element that indicates Support noise removing benefit peer end.
The MSC Server does not send the noise suppression information element that indicates Support noise removing benefit peer end.

The noise suppression feature is set for the trunk group. Its operation is the same as the data configuration in section 38.5 "Data Configuration."

None.

None.
Issue 02 (2007-06-10)
38-11

None.

The noise suppression feature is applied to only the voice services. For data services (fax and KPN data services), the noise suppression parameters are not delivered. When the noise suppression feature is enabled, the MSC delivers parameters that instruct the MGW to disable the noise suppression function.
38.10 Reference
ITU-T G.160 draft

Glossary
Glossary VPU Description It is a logical board, corresponding to three physical boards-MVPB, MVGU and MVPD. It provides the following functions: code switch of voice service flow and echo counteract. It provides announcement resource and realizes number receiving and announcement service. MVGU board provides video coding and decoding functions.
Acronym
Acronym MSC GSM NR MML UMTS Full Name Mobile Switching Center Global System for Mobile communications Noise Reduction, or Noise Removing Human-Machine Language (formerly Man-Machine Language) Universal Mobile Telecommunications System/Universal Mobile Telecommunication System/Universal Mobile Telecommunication Services Voice Quality Enhance Voice Processing Unit
VQE VPU
38-12
Issue 02 (2007-06-10)
38.11 FAQ
None.
Issue 02 (2007-06-10)
38-13
Contents
Contents
39 TDM Circuit Selection Based on Service Type................................................................39-1
39.1 Service Description ...................................................................................................................................39-2 39.1.1 Function Code..................................................................................................................................39-2 39.1.2 Definition .........................................................................................................................................39-2 39.1.3 Standard Compliance .......................................................................................................................39-2 39.1.4 System Specifications ......................................................................................................................39-2 39.1.5 Benefits ............................................................................................................................................39-3 39.1.6 Application Scenario ........................................................................................................................39-3 39.2 Availability ................................................................................................................................................39-3 39.2.1 Requirements for NEs......................................................................................................................39-3 39.2.2 Requirements for License ................................................................................................................39-3 39.2.3 Supporting Versions .........................................................................................................................39-3 39.2.4 Others...............................................................................................................................................39-4 39.3 Working Principle......................................................................................................................................39-4 39.3.1 Functions of the NEs........................................................................................................................39-4 39.3.2 External Interface.............................................................................................................................39-5 39.4 Data Configuration....................................................................................................................................39-5 39.4.1 Overview of Configuration ..............................................................................................................39-5 39.4.2 Data Configuration at the MSOFTX3000 Side................................................................................39-5 39.4.3 Configuration Examples ..................................................................................................................39-6 39.4.4 Data Configuration at the UMG8900 Side.....................................................................................39-10 39.5 Service Management ...............................................................................................................................39-10 39.6 Charging and CDR ..................................................................................................................................39-10 39.7 Performance Measurement......................................................................................................................39-10 39.8 Service Interaction ..................................................................................................................................39-10 39.9 FAQ .........................................................................................................................................................39-10
Issue 02 (2007-06-10)
Figures
Figures
Figure 39-1 TDM circuit selection based on the service type ..........................................................................39-4
ii
Issue 02 (2007-06-10)
Tables
Tables
Table 39-1 NE required to implement the function of TDM circuit selection based on service type ...............39-3 Table 39-2 The version of the Huawei UMTS CS product that supports TDM circuit selection based on service type....................................................................................................................................................................39-4
Issue 02 (2007-06-10)
iii
39
Section
TDM Circuit Selection Based on Service Type
About This Chapter

The following table lists the contents of this chapter. Describes The function code and definition of the service and the benefits of the service to carriers and mobile subscribers. The NEs required to implement the service, requirements for the license, and versions of the products applicable to the service. The functions of the NEs used to implement the service and the requirements on the networking. The data configuration that must be performed at the MSOFTX3000 side and the UMG8900 side as well as the examples of data configuration. The operations that carrier and mobile subscribers must perform when the service is provided. The procedure for performing charging and generating CDRs when the service is provided. The influence of the service on performance measurement and the implementation of performance measurement. The association between the service and other services as well as the restrictions on each other. The frequently asked questions related to the service and the solutions.
39.3 Working Principle 39.4 Data Configuration
39.5 Service Management 39.6 Charging and CDR 39.7 Performance Measurement 39.8 Service Interaction 39.9 FAQ
Issue 02 (2007-06-10)
39-1

Function Name TDM circuit selection based on service type Function Code WMFD-164900
39.1.2 Definition
If the TDM bearer is adopted between two media gateways (MGWs), the carrier can use the compression device for data transmission. Thus, when a service with a large amount of data, such as the video phone (VP) service, is used, the data may be long delayed after processed by the compression device. To reduce the transmission cost in the MGW, this function solves this problem with the following methods: The traffic of the services with a large amount of data (such as VP calls) goes through the TDM circuits that are not connected to the compression device. The traffic of the services with small amount of data (such as voice calls) goes through the TDM circuits that are connected to the compression device.

None.

Item TDM circuits Compression circuits and non-compression circuits Specifications The number of TDM circuits between MGWs in the local office must not be more than 100,000. The TDM circuits that are connected to the compression device are called compression circuits. The TDM circuits that are not connected to the compression device are called non-compression circuits. The compression attribute of a TDM circuit must be consistent with the connection of the circuit to the compression device.
39-2
Issue 02 (2007-06-10)
39.1.5 Benefits
Beneficiary Carrier Description The carrier can choose the TDM bearer (compression circuits or non-compression circuits) based on the service requirement. Thus, not only the requirement of subscribers can be fulfilled, but also the quantity of the transmission devices can be reduced.

When multiple MGWs are equipped in an office or used to connect offices, the TDM bearer may be adopted between MGWs. In this case, to reduce the cost, the carrier can connect the TDM circuits to the compression device. If services with a large amount of data, such as the VP service, are processed by the compression device, the data transmission may be long delayed. For services with small amount of data, such as the voice call, even if the data is processed by the compression device, the delay of data transmission is short and acceptable. Therefore, based on the data configuration and service requirement, the MSC Server can decide whether to transmit the data of calls through the compression TDM circuits or non-compression TDM circuits. Thus, the cost can be reduced and at the same time, long delay of data transmission can be avoided.
39.2 Availability
To implement TDM circuit selection based on service type, the MSC Server and the MGW are required, as described in Table 39-1. Table 39-1 NE required to implement the function of TDM circuit selection based on service type UE NodeB RNC MSC Server MGW SGSN GGSN HLR -
The symbol "" indicates that the NE is required to implement the function.

The function of TDM circuit selection based on service type can be used without a license.

Table 39-2 describes the version of the Huawei GSM/UMTS CS product that supports the function of TDM circuit selection based on service type.
Issue 02 (2007-06-10)
39-3
Table 39-2 The version of the Huawei UMTS CS product that supports TDM circuit selection based on service type Product MSC Server MSOFTX3000 Supporting Version V100R005C10
39.2.4 Others
None.

Based on the service type, the MSC Server can decide whether to use the compression circuits or non-compression circuits for data transmission to shorten the delay of a call. Figure 39-1 shows the TDM circuit selection based on the service type. Figure 39-1 TDM circuit selection based on the service type
MSC Server A MSC Server B
MGW B Circuit A MGW A Circuit A MGW C
Circuit B
Circuit B
Circuit B
Circuit B
Compression device
Compression device
Circuit A is the non-compression circuit. Data transmission is not delayed when the data is transmitted through circuit A. Circuit B is the compression circuit. Data transmission is delayed when transmitted through circuit B. The delay of the transmission for a service with small amount of data, however, does not affect the usage of the service.
For intra-office data transmission, the MSC Server can implement the selection of TDM circuits based on the service type, in either of the following modes:
39-4
Issue 02 (2007-06-10)
For calls that require a certain bearer capability, only one type of TDM circuit is selected. For example, for the VP service, only the non-compression TDM circuits are selected. For a type of calls, a certain type of circuit is assigned with higher priority. When the circuits with higher priority are unavailable, the circuits of the other type can be selected. For example, the compression TDM circuits are selected in preference to voice services. When all the circuits of this type are seized, the non-compression TDM circuits are selected. For inter-office data transmission, the MSC Server implements the selection of TDM circuits based on the service type, in the following mode: The transmission capability of circuits is configured through ADD RTANA. When calls are routed out of the office, the ISUP trunk groups (compression circuits or non-compression circuits) are selected based on the service. Thus, data of calls with a large amount of data are not transmitted through the compression device. The data transmission is not delayed and therefore, the quality of the calls can be ensured. Calls with a small amount of data are processed by the compression device. The delay of data transmission, however, is not long and therefore is acceptable.

None.

39.4.1 Overview of Configuration
To enable TDM circuit selection based on the service type, data must be configured at the MSOFTX3000 side.

Adding Internal TDM Circuits
Run ADD INTTERM to add internal TDM circuits. The parameter of this command related to TDM circuit selection based on the service type is as follows: Compress Flag It specifies whether the E1 circuit to be added supports compression. By default, E1 circuits do not support compression. The values of this parameter are as follows: Non Compress: The E1 circuit does not support compression. Compress: The E1 circuit supports compression.
Adding Mapping Between Transmission Capability and Compression Flag

Run ADD TRCAPTOCFLAG to add mapping between the transmission capability and the compression flag. The parameters of this command related to TDM circuit selection based on the service type are as follows: Transmission Capability
Issue 02 (2007-06-10)
39-5
It specifies the type of services that can be carried out during calls, for example, the voice, data, or audio service. Compress Flag It is one of the match check conditions for TDM circuit selection during a call. For the specified transmission capability, this parameter specifies the type of TDM circuit used by the service carried out during the call: TDM circuit with the compress capability or TDM circuit without the compress capability. This parameter is used in ADD INTTERM. Allow Select Other TDM Circuit It is one of the match check conditions for TDM circuit selection during a call. In the condition that Compress Flag is set for the specified transmission capability, if no TDM circuit with the specified compress capability is available, this parameter specifies whether the other type of TDM circuit or no TDM circuit is selected. If no TDM circuit is selected, the call is released.
Adding Route Analysis Data

Run ADD RTANA to add route analysis data. The parameter of this command related to TDM circuit selection based on the service type is as follows: Transmission capability It is one of the conditions for route selection. It specifies the type of services that can be carried out during calls, for example, the voice, data, or audio service. Generally, this parameter is set to All categories. During the route analysis, if Transmission capability defined in more than one (usually two) data records of route analysis can match the current call, All categories has the lowest priority. That is, the system selects other matching options in preference.
Adding No.7 Trunk Group

Run ADD N7TG to add No.7 trunk groups. The parameter of this command related to TDM circuit selection based on the service type is as follows: Transmission capability It specifies the type of services that the trunk group can bear, for example, the voice, data, or audio service. Generally, this parameter is set to All. For TDM circuit selection based on the service type, the trunk groups bearing the voice service and those bearing the video service must be configured separately.
39.4.3 Configuration Examples

Adding an internal TDM circuit whose parameters are as follows:

MGW1 name: set to mgw_1 Terminal ID of MGW1 slot 0: set to 0 MGW2 name: set to mgw_2 Terminal ID of MGW2 slot 0: set to 32 Compress Flag: set to Compress
39-6
Issue 02 (2007-06-10)
Adding an internal TDM circuit whose parameters are as follows:

MGW1 name: set to mgw_1 Terminal ID of MGW1 slot 0: set to 64 MGW2 name: set to mgw_2 Terminal ID of MGW2 slot 0: set to 96 Compress Flag: set to Non Compress
Adding the mapping, whose parameters are as follows, between the transmission capability and the compression flag:

Transmission Capability: set to Voice Compress Flag: set to Compress Allow Select Other TDM Circuit: set to Allow
Adding the mapping, whose parameters are as follows, between the transmission capability and the compression flag:

Transmission Capability: set to Video service Compress Flag: set to Not to be Compressed Allow Select Other TDM Circuit: set to Allow
Step 1 Add an internal TDM circuit. Description Script Remark Add an internal TDM circuit. ADD INTTERM: MGWNAME1="mgw_1", TID1=0, MGWNAME2="mgw_2", TID2=32, COMPRESSFLAG=COMPRESS; The parameter Compress Flag is newly added. It specifies whether the TDM circuit is a compression circuit or a non-compression circuit. Note: The compression TDM circuits are configured by the E1 line. That is, an E1 line cannot include both compression TDM circuits and non-compression TDM circuits.
Step 2 Add an internal TDM circuit.
Issue 02 (2007-06-10)
39-7
Description Script
Add an internal TDM circuit. ADD INTTERM: MGWNAME1="mgw_1", MGWNAME2="mgw_2", COMPRESSFLAG=UNCOMPRESS; TID1=64, TID2=96,
Remark
The parameter Compress Flag is newly added. It specifies whether the TDM circuit is a compression circuit or a non-compression circuit. Note: The compression TDM circuits are configured by the E1 line. That is, an E1 line cannot include both compression TDM circuits and non-compression TDM circuits.
Step 3 Add the mapping between the transmission capability and the compression flag. Description Script Remark Add the mapping between the transmission capability and the compression flag. ADD TRCAPTOCFLAG: SLCTTDM=ALLOW; TC=VOICE, CF=COMP,
This command is used to define that the compression TDM circuits are used in preference for the voice service and the other type of TDM circuits can also be used.
Step 4 Add the mapping between the transmission capability and the compression flag. Description Script Remark Add the mapping between the transmission capability and the compression flag. ADD TRCAPTOCFLAG: SLCTTDM=ALLOW; TC= VIDEO, CF=NOCOMP,
This command is used to define that the non-compression TDM circuits are used in preference for the video service and the other type of TDM circuits can also be used.
----End
Adding route analysis data in which the parameters are as follows:

Route selection name: set to rt_sel_1 Route selection source name: set to rt_src_sel_1 Transmission capability: set to All categories Route name: set to rt_1 Signaling priority: set to Prefer to select ISUP
39-8
Issue 02 (2007-06-10)
Adding a No.7 trunk group whose parameters are as follows:

Trunk group name: set to tg_1 MGW name: set to mgw_1 Circuit type: set to ISUP Sub-route name: set to srt_1 Call source name: set to MCC Transmission Capability: set to Voice service Trunk group name: set to tg_2 MGW name: set to mgw_1 Circuit type: set to ISUP Sub-route name: set to srt_1 Call source name: set to MCC Transmission Capability: set to Video service
Adding a No.7 trunk group whose parameters are as follows:

Step 1 Add route analysis data. Description Script Remark Add route analysis data. ADD RTANA: RSN="rt_sel_1", RN="rt_1", ISUP=ISUP_F; RSSN="rt_src_sel_1", TP=ALL,
This command is used to define that the route can bear all types of services. The trunk groups in the route must be able to bear the voice service and video service.
Step 2 Add a No.7 trunk group. Description Script Remark Add a No.7 trunk group. ADD N7TG: TGN="tg_1", MGWNAME="mgw_1", CT=ISUP, SRN="srt_1", CSCNAME=" MCC", TC=AUDIO-1, RELRED=NO; This command is used to add an inter-office ISUP trunk group that can bear the voice service only. All the circuits in this trunk group are connected to the compression device.
Step 3 Add a No.7 trunk group.
Issue 02 (2007-06-10)
39-9
Add a No.7 trunk group. ADD N7TG: TGN="tg_2", MGWNAME="mgw_1", CT=ISUP, SRN="srt_1", CSCNAME=" MCC", TC= VIDEO-1, RELRED=NO; This command is used to add an inter-office ISUP trunk group that can bear the video service only. None of the circuits in this trunk group is connected to the compression device.
----End

To enable TDM circuit selection based on the service type, data configuration at the UMG8900 side is not required.

None.

None.

None.

None.
39.9 FAQ
None.
39-10
Issue 02 (2007-06-10)
Contents
Contents
40 BICC and ISUP Route Allowed for the Same Office Direction....................................40-1
40.1 Service Description ...................................................................................................................................40-2 40.1.1 Function Code..................................................................................................................................40-2 40.1.2 Definition .........................................................................................................................................40-2 40.1.3 Standard Compliance .......................................................................................................................40-3 40.1.4 System Specifications ......................................................................................................................40-3 40.1.5 Benefits ............................................................................................................................................40-4 40.1.6 Application Scenario ........................................................................................................................40-4 40.1.7 Application Limitations....................................................................................................................40-5 40.2 Availability ................................................................................................................................................40-6 40.2.1 Requirements for NEs......................................................................................................................40-6 40.2.2 Requirements for License ................................................................................................................40-6 40.2.3 Supporting Versions .........................................................................................................................40-6 40.2.4 Others...............................................................................................................................................40-6 40.3 Working Principle......................................................................................................................................40-6 40.3.1 Functions of the NEs........................................................................................................................40-6 40.3.2 Internal Processing of the System ....................................................................................................40-6 40.3.3 External Interfaces ...........................................................................................................................40-8 40.4 Service Flow..............................................................................................................................................40-8 40.5 Data Configuration....................................................................................................................................40-8 40.5.1 Overview..........................................................................................................................................40-8 40.5.2 Data Configuration at the MSOFTX3000 Side................................................................................40-8 40.5.3 Data Configuration at the UMG8900 Side..................................................................................... 40-11 40.5.4 Data Configuration Examples ........................................................................................................40-12 40.6 Service Management ...............................................................................................................................40-16 40.6.1 Operations by Carriers ...................................................................................................................40-16 40.6.2 Operations by Mobile Subscribers .................................................................................................40-16 40.7 Charging and CDR ..................................................................................................................................40-16 40.8 Performance Measurement......................................................................................................................40-16 40.9 Service Interaction ..................................................................................................................................40-16 40.10 References .............................................................................................................................................40-17 40.10.1 Standards and Specifications........................................................................................................40-17
Issue 02 (2007-06-10)
Contents
HUAWEI MSOFTX3000 Feature Description 40.10.2 Acronyms and Abbreviations .......................................................................................................40-17
40.11 FAQ .......................................................................................................................................................40-17
ii
Issue 02 (2007-06-10)
Figures
Figures
Figure 40-1 Current networking of China Mobile............................................................................................40-3 Figure 40-2 Scenario 1 .....................................................................................................................................40-4 Figure 40-3 Scenario 2 .....................................................................................................................................40-5 Figure 40-4 Scenario 3 .....................................................................................................................................40-5
Issue 02 (2007-06-10)
iii
Tables
Tables
Table 40-1 Function code of the BICC and ISUP route allowed for the same office direction service ............40-2 Table 40-2 Key parameter used in this service .................................................................................................40-3 Table 40-3 Benefits of the BICC and ISUP route allowed for the same office direction service .....................40-4 Table 40-4 NE required to implement this service ...........................................................................................40-6 Table 40-5 Version of Huawei MSOFTX3000 that supports the service..........................................................40-6
iv
Issue 02 (2007-06-10)
40
BICC and ISUP Route Allowed for the Same Office Direction
About This Chapter

40.6 Service Management 40.7 Charging and CDR 40.8 Performance Measurement 40.9 Service Interaction 40.10 References
Issue 02 (2007-06-10)
40-1
Section 40.11 FAQ

Table 40-1 lists the function code of the BICC and ISUP route allowed for the same office direction service. Table 40-1 Function code of the BICC and ISUP route allowed for the same office direction service Name BICC and ISUP route allowed for the same office direction Code WMFD-165000
40.1.2 Definition
At present, in networks of China Mobile, the signaling transmitted between the end office and tandem office is ISUP signaling. The ISUP signaling is transferred by the MGW and transmitted over an M3UA/MTP route. During network consolidation, the signaling transmitted between the end office and tandem office changes gradually from ISUP signaling to BICC signaling. In addition, BICC signaling must be transmitted over direct M3UA routes. That is, for the same office direction, BICC signaling can be transmitted over direct M3UA routes and ISUP signaling can be transmitted over M3UA/MTP routes at the same time for a certain period, as shown in Figure 40-1.
40-2
Issue 02 (2007-06-10)
Figure 40-1 Current networking of China Mobile
MSC Server A BICC M3UA
MSC Server B
ISUP
M3UA/MTP
ISUP
M3UA/MTP
ISUP
MTP MGW MGW
This service requires that ISUP signaling should be transmitted over an existing non-direct route (such as MSC Server A -> MGW -> MGW -> MSC Server B) and should be transferred by the MGW. It also requires that BICC signaling should be transmitted over a direct M3UA route (such as MSC Server A -> MSC Server B). Moreover, the non-direct M3UA/MTP route and direct M3UA route are not required to provide the disaster tolerance function. In other word, when the transmission of BICC signaling over the direct M3UA route fails, the BICC signaling cannot be transmitted over the route over which ISUP signaling is transmitted. When the transmission of ISUP signaling over the non-direct route fails, the ISUP signaling cannot be transmitted over the direct route over which BICC signaling is transmitted.

None.

Table 40-2 describes the key parameter used in this service. Table 40-2 Key parameter used in this service Parameter Bearer select mode Description It specifies the selection mode of the bearer for message transmission. In other words, it specifies whether the system attempts to use other bearers such as MTP routes to send subscriber messages after the failure of transmission over M3UA routes. By default, subscriber messages are sent through M3UA routes. If the transmission fails, the system attempts to use MTP routes.
Issue 02 (2007-06-10)
40-3
40.1.5 Benefits
Table 40-3 lists the benefits of the BICC and ISUP route allowed for the same office direction service. Table 40-3 Benefits of the BICC and ISUP route allowed for the same office direction service Beneficiary Carriers Description This service enables carriers to gradually cut over from ISUP signaling links to BICC signaling links without changing the current networking mode.

Based on the current networking of China Mobile, this service can be applied to the following scenarios:
Scenario 1
BICC signaling is transmitted over a direct M3UA route, while ISUP signaling is transmitted over a non-direct M3UA route and transferred by the MGW. The two routes do not provide the disaster tolerance function. Figure 40-2 shows the scenario. Figure 40-2 Scenario 1
MSC Server A BICC M3UA MSC Server B
ISUP
M3UA
M3UA
MGW
Scenario 2
BICC signaling is transmitted over a direct M3UA route, while ISUP signaling is transmitted over an alternative MTP route. The two routes do not provide the disaster tolerance function. Figure 40-3 shows the scenario.
40-4
Issue 02 (2007-06-10)
Figure 40-3 Scenario 2

ISUP
MTP
MTP
MGW
Scenario 3
BICC signaling is transmitted over a direct M3UA route, while ISUP signaling is transmitted over a direct MTP route. The two routes do not provide the disaster tolerance function. Figure 40-4 shows the scenario. Figure 40-4 Scenario 3
ISUP
MTP(M2UA)
MTP2
MGW

None.
Issue 02 (2007-06-10)
40-5
40.2 Availability
The service is implemented by only the MSC Server, as shown in Table 40-4. Table 40-4 NE required to implement this service UE NodeB RNC MSC Server MGW SGSN GGSN HLR -
The symbol indicates that the NE is required to implement the service.

None.

Table 40-5 lists the version of Huawei MSOFTX3000 that supports the service. Table 40-5 Version of Huawei MSOFTX3000 that supports the service Product UMTS MSOFTX3000 Supporting Version V100R005C10
40.2.4 Others
None.

Only MSOFTX3000 is required to implement this service.

When routing an upper-layer user message, the lower-layer link (such as M3UA) selects a route based on the Service Indicator (SI) contained in the message. When a fault occurs in the route over which an upper-layer user message is transmitted, the system can determine whether to transmit the message over an MTP route through data configuration.
40-6
Issue 02 (2007-06-10)
Through data configuration, BICC signaling and ISUP signaling can be in the same office direction. The office direction of the following sub-routes can be configured to the same: Narrowband sub-route: SS7 trunk, CAS trunk, and PRA trunk can be configured. Broadband sub-route: SIP trunk and BICC trunk can be configured.
Internal Processing When Fault Occurs in M3UA Route

This section describes the internal processing of the system when a fault occurs in an M3UA route. Based on data configuration, the system determines whether to use an MTP route as the bearer. 1. When the network layer selects the route over which upper-layer user messages are transmitted, the system first selects an M3UA route. Run ADD M3DS to configure a non-exclusive destination entity and the corresponding destination service. Use Service indicator to specify the upper-layer user message borne by the destination entity. The non-exclusive destination entity shares a signaling point code (SPC) with other NEs. In other word, the non-exclusive destination entity works in a non-exclusive mode. An exclusive destination entity occupies an SPC exclusively. The network mode can be configured by running ADD M3DE. 2. After you set Bearer select mode by running ADD M3DS, the system cannot select an MTP3 route to transmit upper-layer user messages in case a fault occurs in the M3UA route.
If the parameter is set to Select other bearers (default value), the system selects an MTP3 route to transmit upper-layer user messages when the M3UA destination entity is unreachable. If the parameter is set to M3UA Only, the system does not select an MTP3 route to transmit upper-layer user messages when the M3UA destination entity is unreachable.
3.
After an upper-layer user message carrying a certain SI is sent over an M3UA route, the system determines that the destination entity corresponding to the SI is unreachable. In this case, if the parameter is set to M3UA Only, M3UA sends a UPU message destined for the user message. The UPU message contains the internal cause value "M3UA destination service unavailable". The UPU message is generated by the local end; therefore, the system need not broadcast the message to other destination entities. If the upper-layer user receives the UPU message sent by M3UA and the cause value in the UPU message is "M3UA destination service unavailable", the system starts the timing test of the status of the M3UA destination service. When the destination entity corresponding to the M3UA destination service recovers, the system resumes the original signaling mode.
4.
Data Configuration of Routes in the Same Office Direction

Through ADD SRT, the routing policy of the inter-office TDM/IP bearer can be configured. In addition, the office direction of the following sub-routes can be configured to the same: Narrowband sub-route: SS7 trunk, CAS trunk, and PRA trunk can be configured. Broadband sub-route: SIP trunk and BICC trunk can be configured. The selection type of the IP/TDM bearer network can be configured by running ADD RT. For example, 60% of sub-routes of an IP bearer network are selected, and 40% of sub-routes of a TDM bearer network are selected. That is, the percentages of narrowband sub-routes and broadband sub-routes can be configured. If Sub-route selection mode is set to Select by
Issue 02 (2007-06-10)
40-7
percentage, the central database board selects a sub-route based on the percentage. This ensures load sharing of the bearer network.

None.
40.4 Service Flow

None.

40.5.1 Overview
M3UA, ISUP, and BICC modules are involved in this service. You need configure data at the MSOFTX3000 side only.

The data configuration varies with the module.
M3UA Module
Preconditions of running ADD M3DS To add an M3UA destination entity additional service, you must run ADD M3DE to add an M3UA destination entity. The method of configuring the parameters is the same as before. The setting of Bearer select mode of ADD/MOD M3DS is involved in this service. Before adding an M3UA destination entity additional service, you must set Destination entity type to Signaling gateway or Application server, and Network mode to Shared SPC by running ADD M3DE. ADD M3DE The following describes the key parameters of ADD M3DE. For details, refer to the online help. Destination entity name It specifies an M3UA destination entity in the MSOFTX3000 configuration database. The value range is a character string of up to 32 characters. The rules for setting the parameter are as follows:
When there are direct M3UA signaling routes between the MSOFTX3000 and the peer signaling device, you must specify the signaling device as a destination entity. For example, if the MSOFTX3000 interconnects directly with the SG, MSC Server, HLR, SCP and softswitch devices through M3UA links, these devices have to be defined to be destination entities. When the peer signaling device is a destination signaling point (DSP), the signaling device must be defined to be a destination entity. For example, the MSOFTX3000 interconnects with five MSCs and two PSTN switches through the transfer of the SG
40-8
Issue 02 (2007-06-10)
and signaling transfer point (STP). You must specify seven destination entities (STP is excluded). Destination entity type It is a parameter for interworking between the MSOFTX3000 and M3UA signaling device. The parameter specifies the application mode of the destination entity in an M3UA link set. The rules for setting the parameter are as follows:
For a non-peer-to-peer network, if the destination entity is MSC, BSC, RNC, HRL or SCP that interconnects with the MSOFTX3000 through the SG, set this parameter to Signaling point. For a non-peer-to-peer network, if the destination entity is an SG that is directly connected to the MSOFTX3000, set this parameter to Signaling gateway. For a non-peer-to-peer network, if the MSOFTX3000 functions as an integrated SG, set this parameter to Application server, that is, the destination entity is an AS. For a peer-to-peer network, if the destination entity is an MSC Server, HRL, SCP or softswitch that directly interconnects with the MSOFTX3000 through M3UA links (not transferred through the SG), set this parameter to Application server.
Network mode It specifies whether the M3UA destination entity interconnected with the MSOFTX3000 has an exclusive signaling point code or shares a signaling point code with other network elements. The parameter is valid only when Destination entity type is set to Application server or Signaling gateway. The value options are Exclusive SPC and Shared SPC. The default value is Exclusive SPC. If it is set to Shared SPC, the M3UA destination services must be configured (ADD M3DS). ADD M3DS The following introduces the key parameter description of ADD M3DS. For details, refer to the online help. Additional service name It specifies an M3UA additional service name in the configuration database. Destination entity name It specifies the destination entity to which the MSOFTX3000 transfers the received M3UA messages from the originating signaling point. The parameter must be defined by ADD M3DE. Service indicator It specifies the scope in which the MSOFTX3000 transfers the M3UA messages. That is, the MSOFTX3000 transfers only the M3UA messages which the value of Service indicator field matches the service indicator defined here. Otherwise, the MSOFTX3000 discards the M3UA message. When Service indicator is set to All, it indicates that the MSOFTX3000 does not analyze the Service indicator field in the M3UA messages. Bearer select mode It specifies the selection mode of the bearer for message transmission. In other words, it specifies whether other bearers such as MTP are used to send subscriber messages after the failure of transmission through M3UA. By default, subscriber messages are sent through M3UA. If the transmission fails, MTP is used instead. If you need to enable this service, configure this parameter. Start CIC and End CIC The parameter is valid only when Service indicator is set to TUP, ISUP, or BICC. It specifies the scope in which the MSOFTX3000 transfers the M3UA messages. That is,
Issue 02 (2007-06-10)
40-9
the MSOFTX3000 transfers only the M3UA messages in which the value of the CIC field matches the CIC value defined here. Otherwise, the MSOFTX3000 discards the M3UA message. If Start CIC and End CIC are not specified, it indicates that the MSOFTX3000 does not analyze the CIC field in the M3UA messages.
BICC Module
ADD/MOD/LST OFC is required for data configuration at the MSOFTX3000 side. ADD OFC The following introduces the key parameter description of ADD OFC. For details, refer to the online help. Office Type It specifies the type of an office direction. When the parameter is set to Common Office, only ISUP trunk or BICC trunk can be configured for this office direction. When the parameter is set to Mix Office, both ISUP trunk and BICC trunk can be configured for this office direction; however, Signaling type can be set to BICC over MTP3/M3UA_272, BICC over MTP3B, BICC over SCTP, or BICC over M3UA_4096 only. The default value is Common Office. Signaling type It is valid when Office Type is set to Common Office. The value options are as follows: Non-BICC signaling BICC over MTP3/M3UA_272 BICC over MTP3B BICC over SCTP BICC over M3UA_4096 IMS Ofc NGN Ofc The default value is Non-BICC signaling. BICC Signaling type It is valid when Office Type is set to Mix Office. The value options are as follows: BICC over MTP3/M3UA_272 BICC over SCTP BICC over M3UA_4096 The parameter is mandatory. There is no default value. MOD OFC The parameters of MOD OFC involved in this service are the same as those of ADD OFC. All the parameters of MOD OFC do not have default values. When modifying an office type, you must comply with the following rules: To modify the value of Office Type from Mix Office to Common Office, do as follows:
If you modify an office direction with both ISUP/TUP signaling and BICC signaling to the one with only BICC signaling by modifying Office Type, ensure that the value
40-10
Issue 02 (2007-06-10)
of Signaling type is the same as that of BICC signaling type and no ISUP trunk group is configured for the common office direction.
If you modify an office direction with both ISUP/TUP signaling and BICC signaling to the one with only ISUP/TUP signaling by modifying Office Type, ensure that Signaling type is set to Non-BICC signaling (instead of IMS Ofc and NGN Ofc). In addition, you must ensure that the following conditions are met: If you modify the value of Signaling type from BICC over SCTP to Non-BICC signaling, ensure that no SCTP link or BICC trunk group exists. If you modify the value of Signaling type from BICC over MTP3/M3UA_272 to Non-BICC signaling, ensure that no BICC trunk group exists.
Condition 1
Condition 2
To modify the value of Office Type from Common Office to Mix Office, do as follows:
If you modify an office direction with only ISUP/TUP signaling to the one with both ISUP/TUP signaling and BICC signaling by modifying Office Type, you can modify the value of Signaling type to only BICC over MTP3/M3UA_272, BICC over SCTP, or BICC over M3UA_4096. If Signaling type is set to IMS Ofc or NGN Ofc, you cannot modify the value of Office Type to Mix Office. If you modify an office direction with only BICC signaling to the one with both ISUP signaling and BICC signaling by modifying Office Type, ensure that the value of BICC Signaling type (after modification) is the same as that of Signaling type (before modification).
LST OFC LST OFC is used to query the information of the office direction data record in the configuration database.
ISUP Module
When you run ADD N7TG to add an ISUP trunk group before enabling this service, if Signaling type of ADD OFC is not set to Non-BICC signaling, you will fail to add the ISUP trunk group. When you run ADD N7TG to add an ISUP trunk group after enabling this service, if Signaling type of ADD OFC is not set to Non-BICC signaling and Office Type is set to Common Office, you will fail to add the ISUP trunk group. When you run ADD N7TG to add an ISUP trunk group after enabling this service, if Signaling type of ADD OFC is not set to Non-BICC signaling and Office Type is set to Mix Office, you will succeed in adding the ISUP trunk group. The rules for setting other parameters are the same as those used before this service is enabled.

None.
Issue 02 (2007-06-10)
40-11

Assume that: The WBSG module number is 143. The local IP address is 173.40.200.10. The local/peer port number is 8888. The peer IP address is 173.40.200.30. The MSOFTX3000 is configured to act as the client. The M3UA link set is 1. The M3UA Link Set table and FE Interface Configuration table are configured.
Data Configuration of M3UA Destination Entity

Description Set Destination entity name to M3DE, Signaling point code of destination entity to F3333F, Destination entity type to Signaling gateway, and Network mode to Shared SPC. ADD M3DE: DENM="M3DE", DPC="F3333F", DET=SG, NM=INCLUSIVE; Destination entity type can also be set to Application server.
Script Remark
Data Configuration of M3UA Destination Entity Additional Service

First use the default values of the parameters of ADD M3DS to configure an M3UA destination entity additional service, and then modify Bearer select mode. Perform the following steps: Step 1 Add an M3UA destination entity additional service. Description Use the default values to configure an M3UA destination entity additional service. Set Additional service name to M3DS, Destination entity name to M3DE, and Service indicator to BICC. ADD M3DS: DSNM="M3DS", DENM="M3DE", SI=BICC; Bearer select mode is set to Select other bearers by default.
Script Remark
Step 2 Modify the M3UA destination entity additional service. Description Script Set Bearer select mode to M3UA Only, and Additional service name to M3DS. MOD M3DS: DSNM="M3DS", BSM=M3UA;
40-12
Issue 02 (2007-06-10)
----End
Data Configuration Related to BICC

Scenario 1: add a mix office direction For the same office direction, configure BICC and ISUP trunk routes as follows: Step 1 Add an office direction. Description Set Office direction name to BICC_MTP3, Peer office type to Toll,urban&rural office, Peer office level to Same, Peer office attribute to MSC, Office Type to Mix Office, BICC Signaling type to BICC over MTP3/M3UA_272, DPC1 to 2a1113, BICC OPC to 2a1114, BICC call source name to BICC_CALLSRC, BICC force use office direction codec to YES, BICC office codec to UMTS AMR 2, FR AMR, G.711 A, and UMTS AMR, Multi-area statistics name to BICC_MTP3, and Office param to Set OM to Zero. ADD OFC: ON=" BICC_MTP3", OOFFICT=CMPX, DOL=SAME, DOA=MSC, OFCTYPE=MIX, BICCSIG=MTP3, DPC1="2a1113", OPC="2a1114", CSCNAME="BICC_CALLSRC", IFFORCECODEC=YES, OFFICECODEC=UMTSAMR2-1&FRAMR-1&PCMA-1&UMTSAMR-1, AN=" BICC_MTP3", BOFFICEPARA=SETOMZERO-1; When configuring the office direction, you must first configure BICC OPC and DPC1. For the BICC office direction, you also need configure BICC call source name and BICC Multi-area name.
Script
Remark
Step 2 Add a BICC sub-route. Description Script Set Sub-route name to BICC_MTP3, and Office direction name to BICC_MTP3. ADD SRT: SRN="BICC_MTP3", ON="BICC_MTP3";
Step 3 Add an ISUP sub-route. Description Script Set Sub-route name to BICC_MTP3, and Office direction name to BICC_MTP3. ADD SRT: SRN="ISUP_MTP3", ON="BICC_MTP3";
Step 4 Add a route.
Issue 02 (2007-06-10)
40-13
Description
Set Route name to MIX_MTP3, Sub-route selection mode to Select by percentage, Sub-route 1 to BICC_MTP3, Sub-route 2 to ISUP_MTP3, Percentage of sub-route 1 to 50, and Percentage of sub-route 2 to 50. ADD RT: RN="MIX_MTP3", SRSM=PERC, SR1N="BICC_MTP3", SR2N="ISUP_MTP3", PSR1=50, PSR2=50;
Script
Step 5 Add a BICC trunk group. Description Set Trunk group name to BICC_MTP3, MGW name to MGW1, Sub-route name to BICC_MTP3, Circuit type to BICC_IP, and Support REL redirection to Not support. ADD BICCTG: TGN="BICC_MTP3", MGWNAME="MGW1", SRCN="BICC_MTP3", CT=BICC_IP, RELRED=NO;
Script
Step 6 Add an ISUP trunk group. Description Set Trunk group name to ISUP_MTP3, MGW name to MGW1, Circuit type to ISUP, Sub-route name to ISUP_MTP3, OPC to 2a1114, DPC to 2a1113, and Call source name to CALLSRC. ADD N7TG: TGN="ISUP_MTP3", MGWNAME="MGW1", CT=ISUP, SRN="ISUP_MTP3", SOPC="2a1114", SDPC="2a1113", CSCNAME="CALLSRC", RELRED=NO;
Script
----End Scenario 2: modify a common non-BICC office direction to a mix office direction Step 1 Add a common non-BICC office direction. Description Set Office name to COMMTOMIX, Peer office type to Toll,urban&rural office, Office Type to Common Office, Signaling type to Non-BICC signaling, Peer office level to Same, and DPC1 to f7. ADD OFC: ON=" COMMTOMIX ", OOFFICT=CMPX, DOL=SAME, OFCTYPE=COM, SIG=NONBICC, DPC1="f7";
Script
Step 2 Modify the common office direction to a mix office direction.
40-14
Issue 02 (2007-06-10)
Description
Set Office direction name to COMMTOMIX, Peer office type to National toll office, Office Type to Mix Office, BICC Signaling type to BICC over MTP3/M3UA_272, BICC OPC to f10, and DPC1 to f8. MOD OFC: ON=" COMMTOMIX ", OOFFICT=NATT, OFCTYPE=MIX, BICCSIG=MTP3, OPC="f10", DPC1="f8"; When modifying the office direction, you must comply with the rules described in BICC Module.
Script Remark
----End Scenario 3: modify a common BICC office direction to a mix office direction Step 1 Add a common BICC office direction. Description Set Office direction name to COMMTOMIX, Peer office type to Toll,urban&rural office, Office Type to Common Office, BICC Signaling type to BICC over MTP3/M3UA_272, DPC1 to 2a1113, BICC OPC to 2a1114, BICC call source name to BICC_CALLSRC, and BICC Multi-area name to BICC_MTP3. ADD OFC: ON="COMMTOMIX", OOFFICT=CMPX, DOL=SAME, OFCTYPE=COM, SIG=MTP3, DPC1="2a1113", OPC="2a1114", CSCNAME="BICC_CALLSRC", AN="BICC_MTP3";
Script
Step 2 Modify the common office direction to a mix office direction. Description Set Office direction name to COMMTOMIX, Peer office type to National toll office, Office Type to Mix Office, and BICC Signaling type to BICC over MTP3/M3UA_272. MOD OFC: ON=" COMMTOMIX ", OOFFICT=NATT, OFCTYPE=MIX, BICCSIG=MTP3; When modifying the office direction, you must comply with the rules described in BICC Module.
Script Remark
----End Scenario 4: query the office direction Description Script Set Office Type to Mix Office, and BICC Signaling type to BICC over MTP3/M3UA_272. LST OFC: OFCTYPE=MIX, BICCSIG=MTP3;
Issue 02 (2007-06-10)
40-15

For this service, you can perform the following operations on the LMT: Add an M3UA destination entity additional service by running ADD M3DS and setting Bearer select mode. Modify an M3UA destination entity additional service by running MOD M3DS and modifying Bearer select mode. Query an M3UA destination entity additional service by running LST M3DS and querying Bearer select mode.

The operations by carriers include the following:
Configure Bearer Select Mode

Step 1 Run LST M3DS to check whether Bearer select mode is configured. Step 2 Run ADD M3DS to configure Bearer select mode. ----End
Modify Bearer Select Mode

Step 1 Run LST M3DS to check whether Bearer select mode is configured. Step 2 Run MOD M3DS to modify Bearer select mode. ----End

None.

None.

None.

None.
40-16
Issue 02 (2007-06-10)
40.10 References
None.

Abbreviation BICC M3UA Full Name Bearer Independent Call Control MTP3 User Adapt
40.11 FAQ
None.
Issue 02 (2007-06-10)
40-17

MSOFTX3000

Uploaded by

Copyright:

Available Formats

MSOFTX3000

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MSOFTX3000

Uploaded by

Copyright:

Available Formats

HUAWEI MSOFTX3000 Mobile Softswitch Center V100R005C10

Issue Date Part Number

Huawei Technologies Proprietary

Huawei Technologies Co., Ltd.

Copyright Huawei Technologies Co., Ltd. 2007. All rights reserved.

Trademarks and Permissions

Huawei Technologies Proprietary

HUAWEI MSOFTX3000 Feature Description

Huawei Technologies Proprietary

HUAWEI MSOFTX3000 Feature Description

Huawei Technologies Proprietary

HUAWEI MSOFTX3000 Feature Description

Huawei Technologies Proprietary

HUAWEI MSOFTX3000 Feature Description

Huawei Technologies Proprietary

HUAWEI MSOFTX3000 Feature Description

Huawei Technologies Proprietary

HUAWEI MSOFTX3000 Feature Description

Huawei Technologies Proprietary

HUAWEI MSOFTX3000 Feature Description 1.9.2 Acronyms and Abbreviations ..........................................................................................................1-26

2 Short Message Service ..............................................................................................................2-1

3 Call Forwarding Supplementary Service ..............................................................................3-1

Huawei Technologies Proprietary

HUAWEI MSOFTX3000 Feature Description

4 Line Identification Service .......................................................................................................4-1

Huawei Technologies Proprietary

5 Call Completion Supplementary Service..............................................................................5-1

Huawei Technologies Proprietary

HUAWEI MSOFTX3000 Feature Description

6 Multiparty Service .....................................................................................................................6-1

7 Call Barring Service ...................................................................................................................7-1

Huawei Technologies Proprietary

8 Explicit Call Transfer Service ..................................................................................................8-1

Huawei Technologies Proprietary

HUAWEI MSOFTX3000 Feature Description

9 ODB Service ................................................................................................................................9-1

Huawei Technologies Proprietary

HUAWEI MSOFTX3000 Feature Description

11 Enhanced MSRN Allocation Feature .................................................................................11-1

Huawei Technologies Proprietary

HUAWEI MSOFTX3000 Feature Description

12 Early and Late Assignment Feature....................................................................................12-1

Huawei Technologies Proprietary

HUAWEI MSOFTX3000 Feature Description 12.9.2 Acronyms and Abbreviations ......................................................................................................12-23

13 IN Service Triggering Feature .............................................................................................13-1

14 MNP Feature ...........................................................................................................................14-1

Huawei Technologies Proprietary

HUAWEI MSOFTX3000 Feature Description

16 License Feature .......................................................................................................................16-1

Huawei Technologies Proprietary

17 NE User Dynamic Monitoring Feature ..............................................................................17-1

Huawei Technologies Proprietary

HUAWEI MSOFTX3000 Feature Description

18 SMS Notification for Call Failure Feature ........................................................................18-1

Huawei Technologies Proprietary

19 Summer Time Feature of Wireless Time Zone ................................................................19-1

20 Version Software Management Feature ............................................................................20-1

21 Configuration Rollback Feature..........................................................................................21-1

HUAWEI MSOFTX3000 Feature Description

22 CAMEL4 Service ....................................................................................................................22-1