UMTS CS Protocols and Signaling Analysis

Part 1 Overview
Table of Contents i .........................................................................................

Chapter 1 Overview 1-1 ......................................................................................
1.1 Introduction 1-1 .......................................................................................
1.2 CSCN Interfaces and Protocols 1-1 ........................................................
1.3 Brief Introduction to Interfaces 1-3 ..........................................................
1.4 CSCN Protocol System 1-7 .....................................................................
1.4.1 MSOFTX3000 Protocol System 1-7 ...............................................
1.4.2 UMG8900 Protocol System 1-9 ......................................................
1.4.3 HLR9820 Protocol System 1-9 .......................................................
1.5 CSCN Protocol Types 1-10 .......................................................................
1.5.1 SS7 Signaling Protocols 1-10 ...........................................................
1.5.2 BICC Protocol 1-12 ...........................................................................
1.5.3 H.248 Protocol 1-12 ..........................................................................
1.5.4 Nb UP and Iu UP Protocols 1-13 ......................................................
Part 2 Transport Protocols
Chapter 1 Narrowband MTP 1-1 ........................................................................
1.1 MTP1 1-1 ................................................................................................
1.2 MTP2 1-1 ................................................................................................
1.3 MTP3 1-2 ................................................................................................
1.3.1 Functions 1-2 ..................................................................................
1.3.2 Message Format 1-4 .......................................................................
1.3.3 Signaling Procedures 1-14 ...............................................................
Chapter 2 Broadband MTP 2-1 ..........................................................................
2.1 Overview 2-1 ...........................................................................................
2.2 MTP3b 2-2 ..............................................................................................
2.2.1 Introduction of MTP3b 2-2 ..............................................................
2.2.2 MTP3b Message Structure 2-4 .......................................................
2.3 SAAL 2-5 .................................................................................................
2.3.1 SAAL Function Structure 2-5 ..........................................................
2.3.2 SSCOP 2-6 .....................................................................................
2.3.3 SSCF 2-11 ........................................................................................
2.3.4 LM 2-13 .............................................................................................
Chapter 3 SCTP 3-1 ...........................................................................................
3.1 Overview 3-1 ...........................................................................................
3.1.1 SCTP Concept 3-1 ..........................................................................
3.1.2 Terminology 3-1 ..............................................................................
3.1.3 SCTP Functions 3-3 .......................................................................
3.1.4 SCTP Implementation in CSCN 3-4 ...............................................
3.2 SCTP Messages 3-4 ...............................................................................
3.3 Message Procedures 3-5 ........................................................................
Chapter 4 M3UA 4-1 ...........................................................................................
4.1 Overview 4-1 ...........................................................................................
4.1.1 Brief Introduction of SIGTRAN 4-1 .................................................
4.1.2 Introduction of M3UA 4-2 ................................................................
4.1.3 Terminology 4-3 ..............................................................................
4.1.4 M3UA Implementation in CSCN 4-11 ...............................................
4.1.5 Work Modes of M3UA in CSCN 4-11 ...............................................
4.2 Message Structure 4-12 ............................................................................
4.2.1 M3UA Message Format 4-12 ............................................................
4.2.2 M3UA Messages 4-12 ......................................................................
4.2.3 Message Example 4-14 ....................................................................
4.3 Message Procedures 4-15 ........................................................................
Chapter 5 SCCP 5-1 ...........................................................................................
5.1 Overview 5-1 ...........................................................................................
5.1.1 SCCP Functions 5-1 .......................................................................
5.1.2 SCCP Basic Services 5-1 ...............................................................
5.1.3 SCCP Implementation in CSCN 5-2 ...............................................
5.2.1 SCCP Message Types 5-4 .............................................................
5.2.2 SCCP Message Parameters 5-6 ....................................................
5.2.3 Examples of Parameter Formats and Codes 5-8 ...........................
5.2.4 Format Components of SCCP Messages 5-12 ................................
Chapter 6 TCAP 6-1 ...........................................................................................
6.1 Overview 6-1 ...........................................................................................
Chapter 7 RTP and RTCP 7-1 ............................................................................
7.1 Brief Introduction 7-1 ...............................................................................
7.2 RTP/RTCP Applications 7-1 ....................................................................
7.3 Packet Format and Meaning 7-2 .............................................................
7.3.1 RTP Header Format 7-2 .................................................................
7.3.2 RTCP Packet Format 7-3 ...............................................................
7.3.3 RTCP Functions 7-4 .......................................................................
7.3.4 RTCP Transmission Interval 7-4 .....................................................
Part 3 Application Protocols
Chapter 1 RANAP and Iu UP 1-1 .......................................................................
1.1 Overview 1-1 ...........................................................................................
1.1.1 Definition and Functions of Iu Interface 1-1 ....................................
1.1.2 Protocol Structure for Iu-CS Interface 1-2 ......................................
1.1.3 Protocol Implementation for Iu-CS Interface 1-3 ............................
1.2 Introduction of RANAP Protocol 1-3 ........................................................
1.2.1 Structure of the RANAP Protocol Stack 1-3 ...................................
1.2.2 Classification of RANAP Elementary Procedures 1-4 ....................
1.2.3 Description of RANAP Elementary Procedures 1-7 ........................
1.2.4 Typical Procedures 1-21 ...................................................................
1.3 Introduction of Iu UP Protocol 1-27 ...........................................................
1.3.1 Functions 1-27 ..................................................................................
1.3.2 Operational Modes 1-28 ...................................................................
1.3.3 Transparent Mode (TrM) 1-29 ..........................................................
1.3.4 Support Mode (SMpSDU: Support Mode for predefined
SDU size) 1-30 ..........................................................................................
1.3.5 Elementary Procedures 1-34 ............................................................
Chapter 2 BSSAP 2-1 .........................................................................................
2.1 Overview 2-1 ...........................................................................................
2.1.1 Definition and Functions of the A Interface 2-1 ...............................
2.1.2 BSSAP Implementation in MSOFTX3000 2-1 ................................
2.1.3 Structure of the Protocol Stack 2-2 .................................................
2.2 Introduction of BSSAP Protocol 2-3 ........................................................
2.2.1 BSSAP Messages 2-3 ....................................................................
2.2.2 Message Structure 2-4 ...................................................................
2.2.3 BSSMAP Procedures 2-4 ...............................................................
Chapter 3 MAP 3-1 .............................................................................................
3.1 Overview 3-1 ...........................................................................................
3.1.1 Definition of the MAP Interfaces 3-1 ...............................................
3.1.2 Functions of the MAP Interfaces 3-3 ..............................................
3.1.3 MAP Implementation in CSCN 3-4 .................................................
3.2 Introduction of MAP Protocol 3-5 ............................................................
3.2.2 Operation Types 3-5 .......................................................................
3.3 Signaling Procedures 3-8 ........................................................................
Chapter 4 H.248/MEGACO 4-1 ..........................................................................
4.1 Overview 4-1 ...........................................................................................
4.1.1 Definition and Functions of the Mc Interface 4-1 ............................
4.1.2 H.248 Implementation in CSCN 4-1 ...............................................
4.2 Introduction of H.248 Protocol 4-3 ..........................................................
4.2.1 Overview 4-3 ...................................................................................
Chapter 5 BICC 5-1 ............................................................................................
5.1 Overview 5-1 ...........................................................................................
5.1.1 Definition and Functions of the Nc Interface 5-1 .............................
5.1.2 BICC Implementation in MSOFTX3000 5-1 ....................................
5.2 Introduction of BICC Protocol 5-3 ...........................................................
5.2.1 Basic Concepts 5-3 .........................................................................
Chapter 6 BSSAP+ 6-1 ......................................................................................
6.1 Overview 6-1 ...........................................................................................
6.1.1 Definition and Functions of the Interface 6-1 ..................................
6.1.2 BSSAP+ Implementation in MSOFTX3000 6-1 ..............................
Chapter 7 CAP 7-1 .............................................................................................
7.1 Overview 7-1 ...........................................................................................
7.1.2 CAP Implementation in MSOFTX3000 7-1 .....................................
7.2 CAP Operations 7-3 ................................................................................
7.2.1 Call Related Operations 7-3 ...........................................................
7.2.2 SMS Related Operations 7-8 ..........................................................
7.3 Basic Signaling Procedures 7-9 ..............................................................
Chapter 8 ISUP 8-1 ............................................................................................
8.1 Overview 8-1 ...........................................................................................
8.1.1 ISUP Implementation in MSOFTX3000 8-2 ....................................
Chapter 9 Nb UP and IPBCP 9-1 .......................................................................
9.1 Overview 9-1 ...........................................................................................
9.1.1 Brief Introduction to the Nb Interface 9-1 ........................................
9.1.2 Definition and Function of the Nb 9-1 .............................................
9.1.3 Protocol Structure 9-2 .....................................................................
9.2 Introduction to the Nb UP 9-4 ..................................................................
9.2.1 Functions 9-5 ..................................................................................
9.2.2 Operational Modes 9-5 ...................................................................
9.3 Introduction to the IPBCP 9-6 .................................................................
9.3.1 Functions 9-7 ..................................................................................
9.3.2 Primitive and Message Structure 9-7 ..............................................
Part 4 Signaling Procedures
Chapter 1 MGW Registration Procedures 1-1 ....................................................
1.1 MGW Registration Procedure 1-1 ...........................................................
1.2 MGW Deregistration Procedure 1-1 ........................................................
Chapter 2 Mobility Management 2-1 ..................................................................
2.1 Overview 2-1 ...........................................................................................
2.2 Location Management 2-1 ......................................................................
2.2.1 Basic Procedures 2-2 .....................................................................
2.2.2 Major Procedures 2-5 .....................................................................
2.3 Handover 2-12 ..........................................................................................
2.3.1 Overview 2-12 ...................................................................................
2.3.2 Classification 2-12 ............................................................................
2.3.3 Intra-UMTS Handover 2-14 ..............................................................
2.3.4 Inter-System Handover 2-22 .............................................................
2.4 Roaming Restriction 2-30 ..........................................................................
Chapter 3 Security Management 3-1 ..................................................................
3.1 Overview 3-1 ...........................................................................................
3.2 Authentication 3-1 ...................................................................................
3.2.1 GSM Authentication 3-1 ..................................................................
3.2.2 UMTS Authentication 3-4 ................................................................
3.2.3 Dual-Mode MS Authentication 3-7 ..................................................
3.3 Encryption 3-9 .........................................................................................
3.4 Integrity Protection 3-10 ............................................................................
3.5 TMSI Reallocation 3-11 .............................................................................
Chapter 4 Call Procedures 4-1 ...........................................................................
4.1 Mobile Subscriber Calling Mobile Subscriber 4-1 ...................................
4.1.1 Call Model 4-1 .................................................................................
4.1.2 Diagram of Call Procedures 4-1 .....................................................
4.1.3 Calling Procedures (Early Assignment Procedures) 4-4 ................
4.1.4 Called Procedures (Early Assignment Procedures) 4-5 .................
4.1.5 Disconnection Procedures 4-6 ........................................................
4.2 Mobile Subscriber Calling PSTN Subscriber 4-6 ....................................
4.2.1 Call Model 4-6 .................................................................................
4.2.2 Diagram of Call Procedures 4-7 .....................................................
4.2.3 Call Procedures 4-9 ........................................................................
4.3 PSTN Subscriber Calling Mobile Subscriber 4-11 ....................................
4.4 Pre-paging 4-12 ........................................................................................
4.5 Call Forwarding Services 4-13 ..................................................................
4.5.1 CFU 4-14 ..........................................................................................
4.5.2 CFB 4-15 ..........................................................................................
4.5.3 CFNRy 4-19 ......................................................................................
4.5.4 CFNRc 4-22 ......................................................................................
Chapter 5 SMS Procedures 5-1 .........................................................................
5.1 Overview 5-1 ...........................................................................................
5.2 Mobile Originated SMS 5-1 .....................................................................
5.3 Mobile Terminated SMS 5-2 ...................................................................
5.4 SMS Alerting Procedures 5-3 ..................................................................
Chapter 6 IN Service Handling Procedures 6-1 .................................................
6.1 Pre-paid Service Handling Procedures 6-1 .............................................
6.1.1 Mobile Pre-paid Subscriber Calling Ordinary WCDMA
Subscriber 6-1 .........................................................................................
6.1.2 PSTN or Ordinary WCDMA Subscriber Calling Pre-paid
Subscriber 6-2 .........................................................................................
6.1.3 Pre-Paid Subscriber Calling Pre-paid Subscriber 6-3 .....................
6.1.4 Pre-paid Subscriber Calling Ordinary WCDMA Subscriber
with CFU to Pre-paid Subscriber 6-5 .......................................................
6.1.5 Recharge Procedure 6-6 ................................................................
6.2 Mobile Originated SMS Handling Procedure 6-7 ....................................
6.3 Mobility Management Event Notification Handling Procedure 6-8 ..........
Chapter 7 Location Service Procedures 7-1 .......................................................
7.1 Overview 7-1 ...........................................................................................
7.2 General LCS Architecture 7-1 .................................................................
7.3 General Network Location Procedures 7-3 .............................................
7.3.1 Mobile Terminated Location Request 7-3 .......................................
7.3.2 Mobile Originated Location Request 7-5 ........................................
7.3.3 Network Induced Location Request 7-7 ..........................................
Part 5 Signaling Analysis
Chapter 1 Analysis of Location Update Signaling 1-1 ........................................
1.1 Overview of Location Update Signaling 1-1 ............................................
1.2 IMSI Attach 1-1 .......................................................................................
1.2.1 IMSI Attach Procedure 1-1 .............................................................
1.2.2 Interface Tracing Example of IMSI Attach 1-2 ................................
1.2.3 Key Messages of IMSI Attach 1-3 ..................................................
1.3 IMSI Detach 1-15 ......................................................................................
1.3.1 IMSI Detach Procedure 1-15 ............................................................
1.3.2 Interface Tracing Example of IMSI Detach 1-16 ...............................
1.3.3 Key Messages of IMSI Detach 1-16 .................................................
1.4 Normal Updating 1-19 ...............................................................................
1.4.1 Normal Updating Procedure 1-19 .....................................................
1.4.2 Interface Tracing Example of Normal Updating 1-19 ........................
1.4.3 Main Tracing Messages of Normal Updating 1-20 ...........................
1.4.4 Normal Updating Failure Procedure 1-30 .........................................
1.4.5 Interface Tracing Example of Normal Updating Failure 1-30 ............
1.4.6 Main Tracing Messages of Normal Updating 1-30 ...........................
Chapter 2 Analysis of Relocation Signaling 2-1 .................................................
2.1 Overview of Relocation Signaling 2-1 .....................................................
2.1.1 Relocation Procedure 2-1 ...............................................................
2.1.2 Interface Tracing Example of Relocation 2-1 ..................................
2.1.3 Key Messages of Relocation 2-2 ....................................................
2.1.4 Relocation Failure Messages 2-6 ...................................................
2.1.5 Interface Tracing Example of Relocation Failure 2-7 ......................
2.1.6 Key Messages of Relocation Failure 2-7 ........................................
Chapter 3 Analysis of Call Signaling 3-1 ............................................................
3.1 Intra-Office Calls 3-1 ...............................................................................
3.1.1 Intra-Office Call Procedure 3-1 .......................................................
3.1.2 Interface Tracing Example of Intra-Office Call 3-2 ..........................
3.1.3 Key Messages of Intra-Office Call 3-2 ............................................
3.1.4 Call Failure Procedure 3-21 ..............................................................
3.1.5 Call Failure Messages Traced 3-22 ..................................................
Chapter 4 Analysis of Iu Interface Protocol 4-1 ..................................................
4.1 Overview 4-1 ...........................................................................................
4.2 Q.AAL2 Protocol Application 4-1 .............................................................
4.2.1 The process of Normal Establishment 4-2 ......................................
4.2.2 Establishment Failure 4-2 ...............................................................
4.2.3 Normal Release 4-4 ........................................................................
4.2.4 Example of Q.AAL2 Trace 4-5 ........................................................
4.2.5 Examples of Important Messages of Q.AAL2 4-5 ...........................
4.3 Iu UP Application 4-9 ..............................................................................
4.3.2 Major Functions of Iu UP 4-9 ..........................................................
4.3.3 Example of lu UP Trace in Voice Call 4-10 .......................................
4.4 Basic Signaling Procedure at Iu Interface 4-11 .........................................
4.4.2 Voice Call Establishment and Release 4-11 .....................................
4.4.3 VP Call Establishment and Release 4-12 .........................................
4.4.4 Examples of Iu UP Important Messages 4-12 ..................................
4.5 Case Analysis of Iu Interface Fault 4-14 ...................................................
4.5.1 Overview 4-14 ...................................................................................
4.5.2 Unsuccessful Q.AAL2 Signaling Establishment 4-15 .......................
4.5.3 Unsuccessful Iu UP Initialization 4-17 ..............................................
Appendix A Abbreviations A-1 ............................................................................

HUAWEI

1. Overview

2. Transport Protocols

3. Application Protocols

4. Signaling Procedures

5. Signaling Analysis

HUAWEI UMTS Circuit-Switched Core Network
Protocols and Signaling Analysis
V100R001


Manual Version T2-030240-20041020-C-1.00
Product Version V100R001
BOM 31026440

Huawei Technologies Co., Ltd. provides customers with comprehensive technical support
and service. Please feel free to contact our local office or company headquarters.

Huawei Technologies Co., Ltd.
Address: Administration Building, Huawei Technologies Co., Ltd.,
Bantian, Longgang District, Shenzhen, P. R. China
Postal Code: 518129
Website: http://www.huawei.com
Email: support@huawei.com

Copyright 2004 Huawei Technologies Co., Ltd.

All Rights Reserved
No part of this manual may be reproduced or transmitted in any form or by any
means without prior written consent of Huawei Technologies Co., Ltd.
Trademarks
, HUAWEI, C&C08, EAST8000, HONET, , ViewPoint, INtess, ETS, DMC,
TELLIN, InfoLink, Netkey, Quidway, SYNLOCK, Radium, M900/M1800,
TELESIGHT, Quidview, Musa, Airbridge, Tellwin, Inmedia, VRP, DOPRA, iTELLIN,
HUAWEI OptiX, C&C08 iNET, NETENGINE, OptiX, iSite, U-SYS, iMUSE, OpenEye,
Lansway, SmartAX, infoX, TopEng are trademarks of Huawei Technologies Co.,
Ltd.
All other trademarks mentioned in this manual are the property of their respective
holders.

Notice
The information in this manual is subject to change without notice. Every effort has
been made in the preparation of this manual to ensure accuracy of the contents, but
all statements, information, and recommendations in this manual do not constitute
the warranty of any kind, express or implied.

Summary of Updates
This section provides the update history of this manual and introduces the contents of
subsequent updates.
Update History
This manual is updated for a major product version to maintain consistency with system
hardware or software versions and to incorporate customer suggestions.
Manual Version Notes
T2-030240-20041020-C-1.00 Initial commercial release

Updates of Contents
None.
About This Manual
Release Notes
The manual applies to UMTS circuit-switched core network V100R001.
Organization
The manual focuses on functions, hierarchical architecture, and message structures of
protocols and signaling processes in the UMTS circuit-switched core network.
There are five parts and an appendix in the manual.
PART 1 Overview profiles the external interfaces and the running protocols of the
interfaces in the UMTS circuit-switched core network.
PART 2 Transport Protocols details the transport protocols used in the UMTS
circuit-switched core network, including narrowband MTP, broadband MTP, SCTP,
SIGTRAN, SCCP, TCAP, RTP, and RTCP.
PART 3 Application Protocols focuses on the application protocols used in the
UMTS circuit-switched core network, including H.248/MEGACO, ISUP, CAP,
MAP, BSSAP, BSSAP+, RANAP, BICC, Iu UP, Nb UP, and IPBCP.
PART 4 Signaling Procedures presents typical service procedures.
PART 5 Signaling Analysis describes the method of analyzing signaling
procedures through interface tracing, which is helpful for troubleshooting and
handling.
Appendix lists the acronyms and abbreviations used in the manual.
Intended Audience
The manual is intended for the following readers:
Marketing technical specialists
Project engineering technicians
Operation and maintenance personnel
Conventions
The manual uses the following conventions:
I. General conventions
Convention Description
Arial Normal paragraphs are in Arial.
Arial Narrow Warnings, Cautions, Notes and Tips are in Arial Narrow.
Boldface Headings are in Boldface.
Courier New Terminal Display is in Courier New.

II. Symbols
Eye-catching symbols are also used in the manual to highlight the points worthy of
special attention during the operation. They are defined as follows:
Caution Means reader be extremely careful during the operation.
Note Means a complementary description.
Feature Description
HUAWEI UMTS Circuit-Switched Core Network Table of contents

i
Table of Contents
Part 1 Overview
Chapter 1 Overview....................................................................................................................... 1-1
1.1 Introduction ........................................................................................................................ 1-1
1.2 CSCN Interfaces and Protocols......................................................................................... 1-1
1.3 Brief Introduction to Interfaces........................................................................................... 1-3
1.4 CSCN Protocol System ..................................................................................................... 1-7
1.4.1 MSOFTX3000 Protocol System.............................................................................. 1-7
1.4.2 UMG8900 Protocol System..................................................................................... 1-9
1.4.3 HLR9820 Protocol System...................................................................................... 1-9
1.5 CSCN Protocol Types...................................................................................................... 1-10
1.5.1 SS7 Signaling Protocols........................................................................................ 1-10
1.5.2 BICC Protocol........................................................................................................ 1-12
1.5.3 H.248 Protocol ...................................................................................................... 1-12
1.5.4 Nb UP and Iu UP Protocols................................................................................... 1-13
Chapter 1 Narrowband MTP......................................................................................................... 1-1
1.1 MTP1 ................................................................................................................................. 1-1
1.2 MTP2 ................................................................................................................................. 1-1
1.3 MTP3 ................................................................................................................................. 1-2
1.3.1 Functions................................................................................................................. 1-2
1.3.2 Message Format ..................................................................................................... 1-4
1.3.3 Signaling Procedures ............................................................................................ 1-14
Chapter 2 Broadband MTP ........................................................................................................... 2-1
2.1 Overview............................................................................................................................ 2-1
2.2 MTP3b ............................................................................................................................... 2-2
2.2.1 Introduction of MTP3b............................................................................................. 2-2
2.2.2 MTP3b Message Structure ..................................................................................... 2-4
2.3 SAAL.................................................................................................................................. 2-5
2.3.1 SAAL Function Structure......................................................................................... 2-5
2.3.2 SSCOP.................................................................................................................... 2-6
2.3.3 SSCF..................................................................................................................... 2-11
2.3.4 LM ......................................................................................................................... 2-13
Chapter 3 SCTP ............................................................................................................................. 3-1
3.1 Overview............................................................................................................................ 3-1
3.1.1 SCTP Concept ........................................................................................................ 3-1
3.1.2 Terminology............................................................................................................. 3-1
Feature Description

ii
3.1.3 SCTP Functions ...................................................................................................... 3-3
3.1.4 SCTP Implementation in CSCN.............................................................................. 3-4
3.2 SCTP Messages................................................................................................................ 3-4
3.3 Message Procedures......................................................................................................... 3-5
Chapter 4 M3UA............................................................................................................................. 4-1
4.1 Overview............................................................................................................................ 4-1
4.1.1 Brief Introduction of SIGTRAN................................................................................ 4-1
4.1.2 Introduction of M3UA .............................................................................................. 4-2
4.1.3 Terminology............................................................................................................. 4-3
4.1.4 M3UA Implementation in CSCN............................................................................ 4-11
4.1.5 Work Modes of M3UA in CSCN............................................................................ 4-11
4.2 Message Structure........................................................................................................... 4-12
4.2.1 M3UA Message Format ........................................................................................ 4-12
4.2.2 M3UA Messages................................................................................................... 4-12
4.2.3 Message Example................................................................................................. 4-14
4.3 Message Procedures....................................................................................................... 4-15
Chapter 5 SCCP............................................................................................................................. 5-1
5.1 Overview............................................................................................................................ 5-1
5.1.1 SCCP Functions...................................................................................................... 5-1
5.1.2 SCCP Basic Services.............................................................................................. 5-1
5.1.3 SCCP Implementation in CSCN.............................................................................. 5-2
5.2 Message Structure............................................................................................................. 5-3
5.2.1 SCCP Message Types............................................................................................ 5-4
5.2.2 SCCP Message Parameters................................................................................... 5-6
5.2.3 Examples of Parameter Formats and Codes.......................................................... 5-8
5.2.4 Format Components of SCCP Messages............................................................. 5-12
Chapter 6 TCAP............................................................................................................................. 6-1
6.1 Overview............................................................................................................................ 6-1
Chapter 7 RTP and RTCP ............................................................................................................. 7-1
7.1 Brief Introduction................................................................................................................ 7-1
7.2 RTP/RTCP Applications .................................................................................................... 7-1
7.3 Packet Format and Meaning.............................................................................................. 7-2
7.3.1 RTP Header Format ................................................................................................ 7-2
7.3.2 RTCP Packet Format .............................................................................................. 7-3
7.3.3 RTCP Functions...................................................................................................... 7-4
7.3.4 RTCP Transmission Interval ................................................................................... 7-4
Chapter 1 RANAP and Iu UP ........................................................................................................ 1-1
1.1 Overview............................................................................................................................ 1-1
1.1.1 Definition and Functions of Iu Interface .................................................................. 1-1
Feature Description

iii
1.1.2 Protocol Structure for Iu-CS Interface..................................................................... 1-2
1.1.3 Protocol Implementation for Iu-CS Interface........................................................... 1-3
1.2 Introduction of RANAP Protocol ........................................................................................ 1-3
1.2.1 Structure of the RANAP Protocol Stack.................................................................. 1-3
1.2.2 Classification of RANAP Elementary Procedures................................................... 1-4
1.2.3 Description of RANAP Elementary Procedures...................................................... 1-7
1.2.4 Typical Procedures ............................................................................................... 1-21
1.3 Introduction of Iu UP Protocol .......................................................................................... 1-27
1.3.1 Functions............................................................................................................... 1-27
1.3.2 Operational Modes................................................................................................ 1-28
1.3.3 Transparent Mode (TrM) ....................................................................................... 1-29
1.3.4 Support Mode (SMpSDU: Support Mode for predefined SDU size) ..................... 1-30
1.3.5 Elementary Procedures......................................................................................... 1-34
Chapter 2 BSSAP........................................................................................................................... 2-1
2.1 Overview............................................................................................................................ 2-1
2.1.1 Definition and Functions of the A Interface............................................................. 2-1
2.1.2 BSSAP Implementation in MSOFTX3000............................................................... 2-1
2.1.3 Structure of the Protocol Stack ............................................................................... 2-2
2.2 Introduction of BSSAP Protocol......................................................................................... 2-3
2.2.1 BSSAP Messages................................................................................................... 2-3
2.2.2 Message Structure.................................................................................................. 2-4
2.2.3 BSSMAP Procedures.............................................................................................. 2-4
Chapter 3 MAP............................................................................................................................... 3-1
3.1 Overview............................................................................................................................ 3-1
3.1.1 Definition of the MAP Interfaces.............................................................................. 3-1
3.1.2 Functions of the MAP Interfaces............................................................................. 3-3
3.1.3 MAP Implementation in CSCN................................................................................ 3-4
3.2 Introduction of MAP Protocol ............................................................................................. 3-5
3.2.2 Operation Types...................................................................................................... 3-5
3.3 Signaling Procedures......................................................................................................... 3-8
Chapter 4 H.248/MEGACO............................................................................................................ 4-1
4.1 Overview............................................................................................................................ 4-1
4.1.1 Definition and Functions of the Mc Interface........................................................... 4-1
4.1.2 H.248 Implementation in CSCN.............................................................................. 4-1
4.2 Introduction of H.248 Protocol ........................................................................................... 4-3
4.2.1 Overview ................................................................................................................. 4-3
4.3 Signaling Procedures....................................................................................................... 4-13
Feature Description

iv
Chapter 5 BICC.............................................................................................................................. 5-1
5.1 Overview............................................................................................................................ 5-1
5.1.1 Definition and Functions of the Nc Interface........................................................... 5-1
5.1.2 BICC Implementation in MSOFTX3000.................................................................. 5-1
5.2 Introduction of BICC Protocol ............................................................................................ 5-3
5.2.1 Basic Concepts ....................................................................................................... 5-3
5.2.2 Message Structure................................................................................................ 5-12
Chapter 6 BSSAP+ ........................................................................................................................ 6-1
6.1 Overview............................................................................................................................ 6-1
6.1.1 Definition and Functions of the Interface ................................................................ 6-1
6.1.2 BSSAP+ Implementation in MSOFTX3000............................................................. 6-1
Chapter 7 CAP ............................................................................................................................... 7-1
7.1 Overview............................................................................................................................ 7-1
7.1.2 CAP Implementation in MSOFTX3000 ................................................................... 7-1
7.2 CAP Operations................................................................................................................. 7-3
7.2.1 Call Related Operations.......................................................................................... 7-3
7.2.2 SMS Related Operations ........................................................................................ 7-8
7.3 Basic Signaling Procedures............................................................................................... 7-9
Chapter 8 ISUP............................................................................................................................... 8-1
8.1 Overview............................................................................................................................ 8-1
8.1.1 ISUP Implementation in MSOFTX3000 .................................................................. 8-2
Chapter 9 Nb UP and IPBCP......................................................................................................... 9-1
9.1 Overview............................................................................................................................ 9-1
9.1.1 Brief Introduction to the Nb Interface ...................................................................... 9-1
9.1.2 Definition and Function of the Nb............................................................................ 9-1
9.1.3 Protocol Structure.................................................................................................... 9-2
9.2 Introduction to the Nb UP .................................................................................................. 9-4
9.2.1 Functions................................................................................................................. 9-5
9.2.2 Operational Modes.................................................................................................. 9-5
Feature Description

v
9.2.3 Elementary Procedures........................................................................................... 9-6
9.3 Introduction to the IPBCP.................................................................................................. 9-6
9.3.1 Functions................................................................................................................. 9-7
9.3.2 Primitive and Message Structure ............................................................................ 9-7
Chapter 1 MGW Registration Procedures................................................................................... 1-1
1.1 MGW Registration Procedure............................................................................................ 1-1
1.2 MGW Deregistration Procedure......................................................................................... 1-1
Chapter 2 Mobility Management .................................................................................................. 2-1
2.1 Overview............................................................................................................................ 2-1
2.2 Location Management ....................................................................................................... 2-1
2.2.1 Basic Procedures .................................................................................................... 2-2
2.2.2 Major Procedures.................................................................................................... 2-5
2.3 Handover ......................................................................................................................... 2-12
2.3.1 Overview ............................................................................................................... 2-12
2.3.2 Classification ......................................................................................................... 2-12
2.3.3 Intra-UMTS Handover ........................................................................................... 2-14
2.3.4 Inter-System Handover ......................................................................................... 2-22
2.4 Roaming Restriction ........................................................................................................ 2-30
Chapter 3 Security Management.................................................................................................. 3-1
3.1 Overview............................................................................................................................ 3-1
3.2 Authentication .................................................................................................................... 3-1
3.2.1 GSM Authentication ................................................................................................ 3-1
3.2.2 UMTS Authentication .............................................................................................. 3-4
3.2.3 Dual-Mode MS Authentication ................................................................................ 3-7
3.3 Encryption.......................................................................................................................... 3-9
3.4 Integrity Protection........................................................................................................... 3-10
3.5 TMSI Reallocation............................................................................................................ 3-11
Chapter 4 Call Procedures ........................................................................................................... 4-1
4.1 Mobile Subscriber Calling Mobile Subscriber .................................................................... 4-1
4.1.1 Call Model ............................................................................................................... 4-1
4.1.2 Diagram of Call Procedures.................................................................................... 4-1
4.1.3 Calling Procedures (Early Assignment Procedures)............................................... 4-4
4.1.4 Called Procedures (Early Assignment Procedures)................................................ 4-5
4.1.5 Disconnection Procedures ...................................................................................... 4-6
4.2 Mobile Subscriber Calling PSTN Subscriber ..................................................................... 4-6
4.2.1 Call Model ............................................................................................................... 4-6
4.2.3 Call Procedures....................................................................................................... 4-9
4.3 PSTN Subscriber Calling Mobile Subscriber ................................................................... 4-11
Feature Description

vi
4.4 Pre-paging ....................................................................................................................... 4-12
4.5 Call Forwarding Services................................................................................................. 4-13
4.5.1 CFU....................................................................................................................... 4-14
4.5.2 CFB....................................................................................................................... 4-15
4.5.3 CFNRy................................................................................................................... 4-19
4.5.4 CFNRc................................................................................................................... 4-22
Chapter 5 SMS Procedures .......................................................................................................... 5-1
5.1 Overview............................................................................................................................ 5-1
5.2 Mobile Originated SMS...................................................................................................... 5-1
5.3 Mobile Terminated SMS.................................................................................................... 5-2
5.4 SMS Alerting Procedures .................................................................................................. 5-3
Chapter 6 IN Service Handling Procedures................................................................................ 6-1
6.1 Pre-paid Service Handling Procedures ............................................................................. 6-1
6.1.1 Mobile Pre-paid Subscriber Calling Ordinary WCDMA Subscriber ........................ 6-1
6.1.2 PSTN or Ordinary WCDMA Subscriber Calling Pre-paid Subscriber ..................... 6-2
6.1.3 Pre-Paid Subscriber Calling Pre-paid Subscriber ................................................... 6-3
6.1.4 Pre-paid Subscriber Calling Ordinary WCDMA Subscriber with CFU to Pre-paid
Subscriber ........................................................................................................................ 6-5
6.1.5 Recharge Procedure............................................................................................... 6-6
6.2 Mobile Originated SMS Handling Procedure..................................................................... 6-7
6.3 Mobility Management Event Notification Handling Procedure .......................................... 6-8
Chapter 7 Location Service Procedures..................................................................................... 7-1
7.1 Overview............................................................................................................................ 7-1
7.2 General LCS Architecture.................................................................................................. 7-1
7.3 General Network Location Procedures.............................................................................. 7-3
7.3.1 Mobile Terminated Location Request ..................................................................... 7-3
7.3.2 Mobile Originated Location Request ....................................................................... 7-5
7.3.3 Network Induced Location Request ........................................................................ 7-7
Chapter 1 Analysis of Location Update Signaling..................................................................... 1-1
1.1 Overview of Location Update Signaling............................................................................. 1-1
1.2 IMSI Attach ........................................................................................................................ 1-1
1.2.1 IMSI Attach Procedure............................................................................................ 1-1
1.2.2 Interface Tracing Example of IMSI Attach .............................................................. 1-2
1.2.3 Key Messages of IMSI Attach................................................................................. 1-3
1.3 IMSI Detach ..................................................................................................................... 1-15
1.3.1 IMSI Detach Procedure......................................................................................... 1-15
1.3.2 Interface Tracing Example of IMSI Detach ........................................................... 1-16
1.3.3 Key Messages of IMSI Detach.............................................................................. 1-16
1.4 Normal Updating.............................................................................................................. 1-19
1.4.1 Normal Updating Procedure.................................................................................. 1-19
Feature Description

vii
1.4.2 Interface Tracing Example of Normal Updating.................................................... 1-19
1.4.3 Main Tracing Messages of Normal Updating........................................................ 1-20
1.4.4 Normal Updating Failure Procedure...................................................................... 1-30
1.4.5 Interface Tracing Example of Normal Updating Failure........................................ 1-30
Chapter 2 Analysis of Relocation Signaling............................................................................... 2-1
2.1 Overview of Relocation Signaling...................................................................................... 2-1
2.1.1 Relocation Procedure.............................................................................................. 2-1
2.1.2 Interface Tracing Example of Relocation................................................................ 2-1
2.1.3 Key Messages of Relocation................................................................................... 2-2
2.1.4 Relocation Failure Messages.................................................................................. 2-6
2.1.5 Interface Tracing Example of Relocation Failure.................................................... 2-7
2.1.6 Key Messages of Relocation Failure ...................................................................... 2-7
Chapter 3 Analysis of Call Signaling........................................................................................... 3-1
3.1 Intra-Office Calls ................................................................................................................ 3-1
3.1.1 Intra-Office Call Procedure...................................................................................... 3-1
3.1.2 Interface Tracing Example of Intra-Office Call ........................................................ 3-2
3.1.3 Key Messages of Intra-Office Call........................................................................... 3-2
3.1.4 Call Failure Procedure .......................................................................................... 3-21
3.1.5 Call Failure Messages Traced .............................................................................. 3-22
Chapter 4 Analysis of Iu Interface Protocol................................................................................ 4-1
4.1 Overview............................................................................................................................ 4-1
4.2 Q.AAL2 Protocol Application ............................................................................................. 4-1
4.2.1 The process of Normal Establishment .................................................................... 4-2
4.2.2 Establishment Failure.............................................................................................. 4-2
4.2.3 Normal Release....................................................................................................... 4-4
4.2.4 Example of Q.AAL2 Trace ...................................................................................... 4-5
4.2.5 Examples of Important Messages of Q.AAL2......................................................... 4-5
4.3 Iu UP Application ............................................................................................................... 4-9
4.3.2 Major Functions of Iu UP......................................................................................... 4-9
4.3.3 Example of lu UP Trace in Voice Call ................................................................... 4-10
4.4 Basic Signaling Procedure at Iu Interface ....................................................................... 4-11
4.4.2 Voice Call Establishment and Release................................................................. 4-11
4.4.3 VP Call Establishment and Release ..................................................................... 4-12
4.4.4 Examples of Iu UP Important Messages............................................................... 4-12
4.5 Case Analysis of Iu Interface Fault .................................................................................. 4-14
4.5.1 Overview ............................................................................................................... 4-14
4.5.2 Unsuccessful Q.AAL2 Signaling Establishment.................................................... 4-15
4.5.3 Unsuccessful Iu UP Initialization........................................................................... 4-17

HUAWEI

UMTS Circuit-Switched Core Network
Part 1 Overview

HUAWEI UMTS Circuit-Switched Core Network Table of Contents

i
Table of Contents
Chapter 1 Overview....................................................................................................................... 1-1
1.1 Introduction ........................................................................................................................ 1-1
1.2 CSCN Interfaces and Protocols......................................................................................... 1-1
1.3 Brief Introduction to Interfaces........................................................................................... 1-3
1.4 CSCN Protocol System ..................................................................................................... 1-7
1.4.1 MSOFTX3000 Protocol System.............................................................................. 1-7
1.4.2 UMG8900 Protocol System..................................................................................... 1-9
1.4.3 HLR9820 Protocol System...................................................................................... 1-9
1.5 CSCN Protocol Types...................................................................................................... 1-10
1.5.1 SS7 Signaling Protocols........................................................................................ 1-10
1.5.2 BICC Protocol........................................................................................................ 1-12
1.5.3 H.248 Protocol....................................................................................................... 1-12
1.5.4 Nb UP and Iu UP Protocols................................................................................... 1-13

HUAWEI UMTS Circuit-Switched Core Network Chapter 1 Overview

1-1
Chapter 1 Overview
1.1 Introduction
The universal mobile telecommunications system (UMTS) is distributed into separate
physical entities. These entities must cooperate with each other to implement a task,
and the devices and subsystems must be interconnected through various interfaces
according to the specified protocols.
In the UMTS, signaling refers to the information required by different entities. A
signaling system directs entities to cooperate with each other. What embody the
signaling messages are interface and protocols:
An interface represents the connection point between two adjacent network
entities.
A protocol defines the rules for information exchange on interfaces.
Protocols are hierarchical. In general, the application layer protocol is used to
describe the protocol over an interface.
This chapter gives a general introduction of the interface types and protocols applying
to variors interface of the circuit switched core network (CSCN), including:
CSCN Interfaces and Protocols
Brief Introduction to Interfaces
CSCN Protocol System
CSCN Protocol System
1.2 CSCN Interfaces and Protocols
The equipment of Huawei WCDMA CSCN involves:
(G) Mobile switching center (MSC) Server
Media gateway
Home Location Register
MSC Server and MGW can be integrated as an MSC.
As open network entities, the above equipment and external interfaces must adopt
open protocols. Figure 1-1 shows the external interfaces and protocols of various CS
entities.

1-2
MSC Server
SCP
HLR
MGW
GMLC
SMC C/D
Mc
(G)MSC Server
MGW
Mc
Nc/E
Nb
BSC
RNC
A
Iu-CS
C
PSTN
SG
TUP/
ISUP
SIGTRAN
CAP/L
Lg
E
CS
SGSN
Gs

BSC: Base Station Controller CAP: CAMEL Application Part HLR: Home Location Register
GMLC: Gateway Mobile Location Cente MGW: Media Gateway RNC: Radio Network Controller
SGSN: Serving GPRS Support Node SIGTRAN: Signaling Transport SMC: Short Massgae Center
SCP: Service Control Point SG: Signaling Gateway PSTN: Public Switched Telephone
Network
Figure 1-1 CNCS interface
Table 1-1 lists the external interfaces and protocols of various CS network entities.
Table 1-1 Interfaces and protocol of CS network entities
Interconnected entities Interface Signaling and protocols
MSCRNC Iu-CS RANAP, Iu UP
MSCBSC A BSSAP
MSC ServerVLR B Internal protocol
MSC ServerHLR C MAP
VLRHLR D MAP
MSC ServerMGW Mc H.248
MSC ServerMSC Server Nc, E BICC/ISUP, MAP
MSCMSC
MSC ServerSMC
E MAP
VLRVLR G MAP
MSC ServerGMLC Lg MAP
SSPSCP CAP, L CAP, MAP
MSCPSTN
MSCPLMN
- ISUP/TUP

1-3
Interconnected entities Interface Signaling and protocols
MSC ServerSGSN Gs BSSAP+
MSC ServerSG - SIGTRAN
HLRAuC H Internal protocol
HLRSCP
HLRSGSN
MGWMGW Nb Nb UP

Note:
The interface and the protocol adopted between the physical entities have no one-to-one relationship.
One protocol may be adopted over several different interfaces.
For instance, the Mobile Application Part (MAP) protocol is adopted on the C, D, E, G, Lg, and L
interfaces.
Several interfaces may exist between two entities while different protocols are adopted for each
interface.
For instance, both Nc and E interfaces are defined between two MSC Servers, where the Bearer
Independent Call Control (BICC) protocol is adopted for the Nc interface and the MAP protocol for the E
interface.

1.3 Brief Introduction to Interfaces
I. Iu-CS Interface
Iu-CS interface refers to the interface between the CS and the UMTS terrestial radio
access network (UTRAN) in the WCDMA network. It is embodied as the interface
between the MSC and the RNC. It comprises:
Control panel (CP)
The interface between the MSC Server and the RNC, also called lu CP.
User panel (UP)
The interface between the MGW and the RNC, also celled lu UP.
Iu-CS interface adopts the Radio Access Network Application Part (RANAP) as the
protocol of the lu CP, which is used to send the following information:
UTRAN management
Call handling
Mobility management

1-4
Iu-CS interface adopts the Iu UP protocol to bear and transmit the traffic.
II. A Interface
A interface refers to the interface between the cicuit switched (CS) domain of the
GSM network subsystem (NSS) and the base station subsystem (BSS). It is
embodied as the interface between the MSC and the BSC.
A interface adopts the Base Station Subsystem Application Part (BSSAP) protocol in
the SS7 signaling system. It comprises voice channel and signaling channel. It is
used to pass the following information:
Mobile station (MS) management
Base transceiver station (BTS) management
Mobility management
Call handling
III. B Interface
B interface refers to the interface between the MSC Server and the VLR. It has no
specific regulation on the signaling mode. It adopts the internal protocols. Through it:
MSC Server obtains user informaton from VLR.
When a MS implements the location update, MSC Server notifies VLR to record
the location information.
When a MS activates a specific supplementary service or modifies related
service data, MSC Server notifies HLR to update the data through VLR.
IV. C Interface
C interface refers to the interface between the MSC Server and HLR. It adopts the
MAP protocol in the SS7 signaling system. Its functions include:
When a MS is called, HLR sends routing information to MSC Server.
It is used to pass short messages.
For CAMEL application, it is used to obtain the rouging information, user status,
and subscriptioin information when a MS is called.
V. D Interface
D interface refers to the interface between the VLR and the HLR. It adopts the MAP
protocol in the SS7 signaling system. It is used to pass the following information.
Authentication data
Location update information
User data in call setup
Supplementary data
VLR restoration information

1-5
For CAMEL application, it is used to pass CAMEL user data and provide the mobile
station roaming number (MSRN) to the public land mobile network (PLMN) visited.
VI. E Interface
E interface refers to the MAP interface between the MSC Server and the (G) MSC
Server or the interface between the MSC Server and SMC. It adopts the MAP
protocol in the SS7 signaling system. It is used to pass the following information:
Switchover information
Short messages
Call control after inter-MSC switchover
VII. F Interface
F interface refers to the interface between the MSC Server and the equipment identity
register (EIR). It adopts the MAP protocol in the SS7 signaling system.
When the MSC Server needs to check the validity of the international mobile station
equipment identity (IMEI), it must exchange information related to the IMEI with the
EIR through F interface.
VIII. G Interface
G interface refers to the interface between the VLRs. It adopts the MAP protocol in
the SS7 signaling system. It is used to pass the following information:
Location update data
When a MS roams to a new VLR, it obtains the IMSI from the former VLR.
Authentication data
The authentication parameter is sent from the former VLR to the current one.
Because the MSC Server and the VLR are integrated, G and E interfaces are
combined as E interface.
IX. Lg Interface
Lg interface refers to the interface between the MSC Server and the GMLC. It is used
to support the location service (LCS). It adopts the MAP protocol in the SS7 signaling
system. Through it:
GMLC originates a location request of a destination user to the current MSC
Server.
MSC Server returns a result.
MSC Server reports the location inforamtion of the destination user to GMLC.

1-6
X. L Interface
L interface refers to the MAP interface between the SSP and the SCP. It adopts the
MAP protocol in the SS7 signaling system. It is used to report the invoke notification
of the supplementary service.

Note:
The aboveC, D, E, F, G, Lg, and L interfaces all adopt the MAP prototocl. Sometimes, all these
interfaces are called MAP interfaces.

XI. Gs Interface
Gs interface refers to the interface between the MSC Server and the SGSN. It adopts
the base station system application part+ (BSSAP+) protocol in the SS7 signaling
protocol. Its functions include:
SGSN sends MS location information to MSC Server.
SGSN receives paging information from MSC Server.
MSC Server announces that the MS is implementing the service handled by
MSC Server.
XII. H Interface
H interface refers to the interface between the HLR and the AuC. It has no specific
regulation on the signaling mode. It is used to pass the user authentication and
encryption data.
XIII. Mc Interface
Mc interface refers to the interface between the MSC Server and the MGW. It adopts
the H.248 protocol. Throug it:
During call handling process, MSC Server controls static and dynamic resources
(including terminal properties, terminal connection relation, and media stream) of
various transmission modes (IP/ATM/TDM).
MSC Server sends status maintenance and management information to the
MGW.
XIV. Nc Interface
Nc interface refers to the interface between the MSC Servers. It adopts the bearer
independent call controller protocol (BICC). It provides inter-MSC call control ability

1-7
independent of the UP bearer technology and CP signaling transmission technology
for the UMTS narrowband CS domain service.
XV. Nb Interface
Nb interface refers to the interface between the MGWs. It is used to bearer control
and transmission. The transmission mode of the user data can be RTP/UDP/IP or
AAL2.
XVI. CAP Interface
CAMEL application part (CAP) interface refers to the interface between the SSP and
the SCP, between the HLR and SCP. It adopts the CAP protocol in the SS7 signaling
system. It is used to realize the signaling exchange between functional entities (SSP,
IP, and SCP) of the intelligent network, thus supporting CAMEL services.
XVII. ISUP/TUP Interface
When the MSOFTX3000 functions as the GMSC Server, it provides the interface for
the fixed network switching equipment or other mobile network equipment, and
controls incoming/outgoing calls through the integrated services digital network user
part (ISUP) or the telephone user part (TUP) of the SS7 signaling system.
XVIII. MSC Server and SG Interface
In the UMTS network, this interface is used to pass the switched circuit network (SCN)
signaling through the IP network. It adopts the SIGTRAN protocol stack.
1.4 CSCN Protocol System
Huawei CSCN products includs:
MSC Server (MSOFTX3000)
MGW (UMG8900)
HLR (HLR9820)
Their protocol development complies with the standard protocol specification.
1.4.1 MSOFTX3000 Protocol System
From the view of different protocol functions, MSOFTX3000 protocol system includes:
SS7 application protocols
ISUP
MAP
CAP

1-8
Radio access network application part (RANAP)
BSSAP
BSSAP+
BICC protocols
H.248 protocols
The overall architecture of MSOFTX3000 protocol system is illustrated in Figure 1-2.
SCCP
TCAP
I
S
U
P
R
A
N
A
P
B
S
S
A
P
+
M
A
P
C
A
P
SCTP
IP
MAC
MTP3
MTP2
MTP1
MTP3b
SSCF-NNI
SSCOP
ATM
BICC H.248
M3UA
1
2
3
4
5
6
7
OSI
layers
TDM based IP based ATM based
Application
Protocols
Transport
Protocols
B
S
S
A
P
SCCP
TCAP
I
S
U
P
R
A
N
A
P
B
S
S
A
P
+
M
A
P
C
A
P
SCTP
IP
MAC
MTP3
MTP2
MTP1
MTP3b
SSCF-NNI
SSCOP
ATM
BICC H.248
M3UA
1
2
3
4
5
6
7
OSI
layers
Application
Protocols
Transport
Protocols
B
S
S
A
P

Figure 1-2 MSOFTX3000 protocol system
MSOFTX3000 protocol system is hierarchical. For the hierarchical structure of each
protocol, Open Systems Interconnection (OSI) can be referenced except that some of
the seven OSI layers are combined.
MSOFTX3000 signaling and protocols can be carried through a variety of transport
media. For instance, the BICC protocol messages can be conveyed in the following
four manners:
TDM based MTP transmission
IP based SIGTRAN (M3UA/SCTP) transmission
SCTP transmission
ATM based MTP3b transmission
One transport protocol can provide transmission service for multiple application
protocol systems.
For convenient description and understanding, MSOFTX3000 protocol system is
divided into:
Application protocols
Transport protocols

1-9
I. Application Protocols
The application protocols are at the top of the protocol stack, implementing the
information interaction function on the interfaces between the communication entities.
The application protocols use the service provided by the transport protocols at the
lower layers.
II. Transport Protocols
The transport protocols refer to all the lower-layer protocols below the application
protocols. (The transport protocola mentioned here are protocol stack). They
provide message transmission service for the application protocols according to the
application protocols requirements.
1.4.2 UMG8900 Protocol System
UMG8900 protocol system includes:
Media gateway control protocol (H.248)
Protocols over ATM
Protocols over IP
SIGTRAN protocol (based on the signaling gateway function embedded in the
UMG8900)
Figure 1-3 shows the general structure of UMG8900 protocols.
Iu UP
AAL2 SAR
SSCS
Q.AAL2
MTP-3b
SAAL AAL2
ATM
STC
M3UA
IP
SCTP UDP
H.248
RTP RTCP
Nb UP
ATM-based
IP-based

Figure 1-3 UMG8900 protocol system
1.4.3 HLR9820 Protocol System
In CSCN application, HLR9820 protocol system includes the MAP protocol in the SS7
signaling system. It is based on TDM, IP, or ATM, as shown in Figure 1-4.

1-10
MAP
SCCP
SCTP
IP
MAC
MTP3
MTP2
MTP1
MTP3b
SSCF-NNI
SSCOP
ATM
TDM-based
A
p
p
l
i
c
a
t
i
o
n
p
a
r
t
s
M
e
s
s
a
g
e

T
r
a
n
s
f
e
r
P
a
r
t
M3UA
TCAP
IP-based ATM-based

Figure 1-4 HLR9820 protocol system
1.5 CSCN Protocol Types
Based on the above analysis, the CS product protocols can be divided into:
SS7 signaling protocols
Apply to MSOFTX3000 and HLR9820, based on TDM, IP, and ATM.
The user part includes TUP/ISUP, MAP, CAP, and BSSAP.
BICC protocol
Applies to MSOFTX3000 only, based on IP.
H.248 protocol
Applies to MSOFTX3000 and UMG8900, based on IP.
Nb UP and Iu UP protocols
Applies to UMG8900 only, Nb UP protocol based on IP and ATM, and Iu UP
protocol based on ATM.
1.5.1 SS7 Signaling Protocols
In CSCN, the SS7 application protocols are used on multiple interfaces.
For instance, the RANAP protocol is used on the Iu-CS interface, and BSSAP used
on the A interface.

1-11
The SS7 has a 4-layer structure. In view of its functions, the SS7 is divided into User
Part and Message Transfer Part. See Figure 1-5.
SCCP
TCAP
I
S
U
P
R
A
N
A
P
B
S
S
A
P
+
M
A
P
C
A
P
SCTP
IP
MAC
MTP3
MTP2
MTP1
MTP3b
SSCF-NNI
SSCOP
ATM
Application Parts
Message Transfer Part
B
S
S
A
P
M3UA
SCCP
TCAP
I
S
U
P
R
A
N
A
P
B
S
S
A
P
+
M
A
P
C
A
P
SCTP
IP
MAC
MTP3
MTP2
MTP1
MTP3b
SSCF-NNI
SSCOP
ATM
Application Parts
Message Transfer Part
B
S
S
A
P
M3UA

Figure 1-5 SS7 signaling protocol
I. MTP Protocol
Message Transfer Part (MTP) protocol enables reliable transport of signaling
messages between user functions. MSOFTX3000 provides three approaches for SS7
signaling transport:
Over narrowband TDM transport network
The Signaling Gateway (SG) built in MSOFTX3000 provides the TDM interface
for direct interconnection with the SCN signaling device.
Over broadband IP network in SS7 MTP3-User Adaptation Layer (M3UA)
protocol of SIGTRAN
Applies to MSOFTX3000 interworking with the SCN by means of independent
SG.
Over ATM through Message Transfer Part (broadband) (MTP3b)
Applies to the interface between MSOFTX3000 and Radio Access Network
(RAN), namely, the Iu-CS interface, for the purpose of provisioning RANAP
message transmission service.
II. User Part Protocol
UP protocol is the functional entity that uses the MTP capability. It is resident at the
top of the SS7 and is used to achieve a variety of services and applications. The SS7
UP protocol is composed of several independent user protocols, including:

1-12
ISUP
MAP
CAP
RANAP
BSSAP
BSSAP+
1.5.2 BICC Protocol
The BICC protocol applies to the Nc interface of the UMTS network for interworking
between the MSC Servers. As one of the application layer control protocols, it is used
to establish, modify, and terminate calls. It can bear comprehensive
PLMN/PSTN/ISDN services.
The BICC protocol evolves from the ISUP protocol and has it developed. It is
characterized by the separation between the call control level and the bearer control
level, thus the Call Service Function is independent of the Bearer Control Function.
MSOFTX3000 provides four modes to convey BICC messages, as shown in Figure
1-6.
SCTP
IP
MAC
MTP3
MTP2
MTP1
MTP3b
SSCF-NNI
SSCOP
ATM
BICC
M3UA
Application Protocol
Transport Protocols
SCTP
IP
MAC
MTP3
MTP2
MTP1
MTP3b
SSCF-NNI
SSCOP
ATM
BICC
M3UA
Transport Protocols

Figure 1-6 BICC protocol in MSOFTX3000
At current networking application, only SCTP/IP transmission protocol is adopted.
1.5.3 H.248 Protocol
H.248/MEGACO protocol is jointly developed within the International
Telecommunication Union (ITU) and the Internet Engineering Task Force (IETF). It is
named H.248 by the ITU-T and MEGACO by the IETF. Hereinafter, both are called
H.248 in this manual. H.248 protocol is used in the decomposed gateway model for
the Media Gateway Controller controlling Media Gateways.

1-13
H.248 protocol is the subsequent protocol of the media gateway control protocol
(MGCP), but their concepts are totally different.
The transport layer of the H.248 signaling messages may be IP based Stream
Control Transmission Protocol (SCTP) or ATM based MTP3b. See Figure 1-7.
SCTP
IP
MAC
MTP3b
SSCF-NNI
SSCOP
ATM
H.248
IP based ATM based
Transport Protocols
SCTP
IP
MAC
MTP3b
SSCF-NNI
SSCOP
ATM
H.248
IP based ATM based
Transport Protocols

Figure 1-7 H.248 protocol
At the current network application, only SCTP/IP transmission protocol is adopted.
1.5.4 Nb UP and Iu UP Protocols
Nb UP protocol applies to Nb interface between the MGWs, and Iu UP protocol
applies to the lu CS UP between the MGW and the RNC.
Between two MGWs, three connection modes are supported, including:
TDM mode (no adaptation protocol)
ATM mode (consistent with lu UP interface)
IP mode (the transmission mode is based on RTP/UDP)
I. Protocols over IP
Figure 1-8 shows the structure of Nb UP protocols over IP.
Nb UP
UDP
IP
RTP RTCP
IP
UDP

Figure 1-8 Structure of Nb protocols over IP
Protocols related to Nb interface over IP includes:

1-14
Nb UP
RTP
RTCP
UDP
IP
II. Protocols over ATM
Figure 1-9 shows the structure of Nb UP protocol over IP, which is consistent with that
of lu UP.
Iu UP/Nb UP
AAL2 SAR
SSCS
Q.AAL2
MTP-3b
SAAL AAL2
User panel Control panel
Application layer
Transmission layer
ATM
STC

Figure 1-9 Structure of Iu protocols over ATM
Protocols related to lu interface includes:
Nb UP/Iu UP
AAL2
Q.AAL2
STC
MTP3b
SAAL (including SSCOF, SSCOP, and AAL5)

HUAWEI


Transport Protocols
Table of Contents

i
Table of Contents
Chapter 1 Narrowband MTP ......................................................................................................... 1-1
1.1 MTP1 ................................................................................................................................. 1-1
1.2 MTP2 ................................................................................................................................. 1-1
1.3 MTP3 ................................................................................................................................. 1-2
1.3.1 Functions................................................................................................................. 1-2
1.3.2 Message Format ..................................................................................................... 1-4
1.3.3 Signaling Procedures............................................................................................ 1-14
Chapter 2 Broadband MTP ........................................................................................................... 2-1
2.1 Overview............................................................................................................................ 2-1
2.2 MTP3b ............................................................................................................................... 2-2
2.2.1 Introduction of MTP3b............................................................................................. 2-2
2.2.2 MTP3b Message Structure ..................................................................................... 2-4
2.3 SAAL.................................................................................................................................. 2-5
2.3.1 SAAL Function Structure......................................................................................... 2-5
2.3.2 SSCOP.................................................................................................................... 2-6
2.3.3 SSCF..................................................................................................................... 2-11
2.3.4 LM ......................................................................................................................... 2-13
Chapter 3 SCTP ............................................................................................................................. 3-1
3.1 Overview............................................................................................................................ 3-1
3.1.1 SCTP Concept ........................................................................................................ 3-1
3.1.2 Terminology............................................................................................................. 3-1
3.1.3 SCTP Functions ...................................................................................................... 3-3
3.1.4 SCTP Implementation in CSCN.............................................................................. 3-4
3.2 SCTP Messages................................................................................................................ 3-4
3.3 Message Procedures......................................................................................................... 3-5
Chapter 4 M3UA............................................................................................................................. 4-1
4.1 Overview............................................................................................................................ 4-1
4.1.1 Brief Introduction of SIGTRAN................................................................................ 4-1
4.1.2 Introduction of M3UA .............................................................................................. 4-2
4.1.3 Terminology............................................................................................................. 4-3
4.1.4 M3UA Implementation in CSCN............................................................................ 4-11
4.1.5 Work Modes of M3UA in CSCN............................................................................ 4-11
4.2 Message Structure........................................................................................................... 4-12
4.2.1 M3UA Message Format ........................................................................................ 4-12
4.2.2 M3UA Messages................................................................................................... 4-12
4.2.3 Message Example................................................................................................. 4-14
4.3 Message Procedures....................................................................................................... 4-15
Transport Protocols
Table of Contents

ii
Chapter 5 SCCP............................................................................................................................. 5-1
5.1 Overview............................................................................................................................ 5-1
5.1.1 SCCP Functions...................................................................................................... 5-1
5.1.2 SCCP Basic Services.............................................................................................. 5-1
5.1.3 SCCP Implementation in CSCN.............................................................................. 5-2
5.2.1 SCCP Message Types............................................................................................ 5-4
5.2.2 SCCP Message Parameters................................................................................... 5-6
5.2.3 Examples of Parameter Formats and Codes.......................................................... 5-8
5.2.4 Format Components of SCCP Messages............................................................. 5-12
Chapter 6 TCAP............................................................................................................................. 6-1
6.1 Overview............................................................................................................................ 6-1
Chapter 7 RTP and RTCP ............................................................................................................. 7-1
7.1 Brief Introduction................................................................................................................ 7-1
7.2 RTP/RTCP Applications .................................................................................................... 7-1
7.3 Packet Format and Meaning.............................................................................................. 7-2
7.3.1 RTP Header Format ................................................................................................ 7-2
7.3.2 RTCP Packet Format .............................................................................................. 7-3
7.3.3 RTCP Functions...................................................................................................... 7-4
7.3.4 RTCP Transmission Interval ................................................................................... 7-4

Transport Protocols
Chapter 1 Narrowband MTP

1-1
Narrowband Message Transfer Part (MTP) is the traditional TDM based transmission
system. Its major function is to enable reliable transmission of signaling messages
over signaling network, and to take measures to avoid or minimize message loss,
duplication or mis-sequencing in case of system fault or signaling network fault. The
functions of the MTP are separated into three functional levels: signaling data link
(MTP1), signaling link functions (MTP2) and signaling network functions (MTP3). The
structure of the MTP protocol stack is illustrated in Figure 1-1.
SCCP
ISUP
MTP3
MTP2
MTP1
MTP User
MTP

Figure 1-1 Structure of the MTP protocol stack
The MTP in the signaling-processing module of MSC and HLR is used to convey SS7
user signaling (ISUP/SCCP). It is designed completely in compliance with the ITU-T
Recommendations Q.701 to Q.710 Series.
1.1 MTP1
Signaling data link is the level 1 function (MTP1) of the MTP. It defines the physical,
electrical and functional characteristics of a signaling data link and the means to
access it. It is equivalent to the physical layer of the OSI reference model and is used
to generate and receive the signals through the physical channels.
A signaling data link is a bidirectional transmission path for signaling, comprising two
data channels operating together in opposite directions at the same data rate. The
standard bit rate on a digital bearer is 64kbit/s. A transmission link at a lower bit rate
(for example, 4.8kbit/s) or at a higher bit rate (for example, 2048kbit/s) may also be
applied.
1.2 MTP2
Signaling link functions are the level 2 functions (MTP2) of the MTP. They are used to
transfer signaling to a data link. The level 2 functions together with a level 1 signaling
Transport Protocols

1-2
data link provide a signaling link for reliable signaling transfer between two directly
associated signaling points.
The signaling link functions include signal unit delimitation, signal unit alignment, error
detection, error correction, initial alignment, processor outage, level 2 flow control and
signaling link error monitoring.
1.3 MTP3
Signaling network functions are the level 3 functions (MTP3) of the MTP. They
implement the functions of the network layer of the OSI reference model, and are
used to enable management message transmission between the signaling points for
the purpose of ensuring a reliable transfer of the signaling messages over the
signaling network in case that signaling links and signaling transfer points fail.
1.3.1 Functions
The signaling network functions provided by the MTP3 must ensure a reliable transfer
of the signaling messages even in the case of the failure of signaling links and
signaling transfer points. Therefore, they include the appropriate functions and
procedures necessary both to inform the remote parts of the signaling network of the
consequences of a fault, and to appropriately reconfigure the routing of messages
through the signaling network
The signaling network functions are divided into two basic categories, namely
signaling message handling and signaling network management. See Figure 1-2.
Transport Protocols

1-3
Message
distribution
Signaling message processing
Message
discrimination
Message
routing
Outgoing
Incoming
Signaling traffic
management
Signaling network management
Signaling route
management
Signaling link
management
Signaling network function
Level 4 Level 3 message transfer part Level 2
Test and maintenance
Signaling message stream
---- Indication and control
Incoming
Test and maintenance

Figure 1-2 Signaling network functions
I. Signaling Message Handling
The purpose of the signaling message handling functions is to ensure that the
signaling messages originated by a particular User Part at a signaling point
(originating point) are delivered to the same User Part at the destination point
indicated by the sending User Part.
The signaling message handling functions are divided into:
the message routing function, used at each signaling point to determine the
outgoing signaling link on which a message has to be sent towards its
destination point;
the message discrimination function, used at a signaling point to determine
whether or not a received message is destined to the point itself. When the
signaling point has the transfer capability and a message is not destined to it,
that message is transferred to the message routing function;
the message distribution function, used at each signaling point to deliver the
received messages (destined to the point itself) to the appropriate User Part.
II. Signaling Network Management
The purpose of the signaling network management functions is to provide
reconfiguration of the signaling network in the case of failures and to control traffic in
case of congestion. Such a reconfiguration is effected by use of appropriate
procedures to change the routing of signaling traffic in order to bypass the faulty links
Transport Protocols

1-4
or signaling points. Moreover, in some circumstances it is necessary to activate and
align new signaling links, in order to restore the required signaling traffic capacity
between two signaling points. When the faulty link or signaling point is restored, the
opposite actions and procedures take place, in order to reestablish the normal
configuration of the signaling network.
The signaling network management functions are divided into:
Signaling traffic management
Signaling link management
Signaling route management
These three signaling network management functions are activated in the appropriate
circumstances when some change occurs to the state of a signaling link, route or
signaling point. The details are described as follows:
1) Signaling traffic management function: This function is used for the diversion of
signaling traffic from one link or route to one or more alternative link or route,
used for MTP restart of signaling points, or used to temporarily slow down
signaling traffic in the case of congestion at signaling points.
2) Signaling link management function: This function is used to restore a faulty
signaling link, activate an idle (unaligned) link, and deactivate an aligned
signaling link.
3) Signaling route management function: This function is used to distribute the
information about the signaling network status with the objective of blocking or
unblocking a signaling route.
1.3.2 Message Format
For the purpose of meeting the requirements of the MTP for transmitting a variety of
signaling messages, three basic types of signal unit are defined: Message Signal Unit
(MSU), Link Status Signal Unit (LSSU), and Fill-In Signal Unit (FISU).
Message signal units are used to carry messages of the user parts, signaling
network management messages, and signaling network testing and maintenance
messages.
Link status signal units provide the information about the link status in order to
perform control actions such as connection and restoration on the signaling link.
Under normal conditions, when no message signal units or link status signal
units are to be transmitted over the signaling links, fill-in signal units are sent
continuously with the feeding objective, for the purpose of maintaining the normal
operation of the signaling links.
The structure of the signal units is illustrated in Figure 1-3.
Transport Protocols

1-5
MSU F CK SIF SIO LI FIB FSN BIB BSN F
8 16 8N(N 2) 8 2 6 1 7 1 7 8
Basic format of a message signal unit (MSU)
First bit
transmitted
LSSU F CK SF LI FIB FSN BIB BSN F
8 16 8 or 16 2 6 1 7 1 7 8
Format of a link status signal unit (LSSU)
First bit
transmitted
FISU F CK LI FIB FSN BIB BSN F
8 16 2 6 1 7 1 7 8
Format of a fill-in signal unit (FISU)
First bit
transmitted
8 16 8N(N 2) 8 2 6 1 7 1 7 8
First bit
transmitted
8 16 8N(N 2) 8 2 6 1 7 1 7 8
First bit
transmitted
8 16 8 or 16 2 6 1 7 1 7 8
First bit
transmitted
8 16 8 or 16 2 6 1 7 1 7 8
First bit
transmitted
8 16 2 6 1 7 1 7 8
First bit
transmitted
8 16 2 6 1 7 1 7 8
First bit
transmitted

Figure 1-3 Format of the signal units
A signal unit is divided into two parts from the structure point of view. One is shared
by the variety of signal units and required by the MTP processing; this part comprises
8 fixed length fields. The other contains the signaling information to be handled by the
user part.
I. The Part Required by the MTP Processing
This part includes Flag (F), Forward Sequence Number (FSN), Forward Indicator Bit
(FIB), Backward Sequence Number (BSN), Backward Indicator Bit (BIB), Length
Indicator (LI), Check bits (CK), Status Field (SF), and Service Information Octet (SIO)
(SIO only exists in message signal units).
Flag (F)
There is a flag at the start and the end of every signal unit. In the transmission of
signal units, the opening flag of a signal unit is normally the closing flag of the
preceding signal unit. Therefore, a signal unit will be delimitated once the opening
and closing flags are successfully found from the information stream.
The bit pattern for the flag is 01111110.
In addition to signal unit delimitation, several flags may be inserted between signal
units, in case that the signaling links are overloaded, in order to cancel controlling and
reduce loading.
Forward sequence number (FSN)
The forward sequence number is the 7-bit sequence number of the message signal
unit in which it is carried. At the transmitting terminal, all the transmitted message
signal units are allocated with a forward sequence number which is numbered from a
cyclic sequence ranging from 0 to 127. At the receiving terminal, the forward
sequence numbers of the received message signal units are used to detect the order
of the message signal units, as a part of the acknowledgement function. If
retransmission is required, the forward sequence number also serves to identify the
Transport Protocols

1-6
signal unit to be retransmitted. A fill-in signal unit and a link status signal unit share
the forward sequence number of the last transmitted message signal unit instead of
being assigned again.
Forward indicator bit (FIB)
One bit is occupied. The forward indicator bit is used in the retransmission procedure
of message signal units. It has the same status as the received backward indicator bit
during non-error operation. A change made to the value of the received backward
indicator bit indicates a request for retransmission. The signaling terminal also
changes the value of the forward indicator bit (changing 1 to 0 or 0 to 1) when
retransmitting the message signal unit, in order to keep consistent with the backward
indicator bit value, until the value of the backward indicator bit changes at receiving
another retransmission request.
Backward sequence number (BSN)
The backward sequence number is the sequence number of a message signal unit
being acknowledged. It is sent by the receiving terminal to indicate to the transmitting
terminal that the message signal unit is acknowledged (accepted successfully).
In the case of a request for a retransmission, the backward sequence number
indicates the sequence number for starting the retransmission.
In the operation of the signaling network, the transmitting terminal and the receiving
terminal of a message independent assign the forward sequence number.
Limited by the forward sequence number and the backward sequence number, not
more than 127 signal units can be transmitted while not be acknowledged.
Backward indicator bit (BIB)
The backward indicator bit provides a retransmission request for the received error
signal unit. If the received message signal unit is correct its value will be invariable
when a new signal unit is sent; otherwise this bit will be sent with a conversed value
(that is, 0 is changed to 1 or 1 is changed to 0), requesting the terminal peer to
retransmit the error message signal unit.
Length indicator (LI)
The length indicator is used to indicate the number of octets following the length
indicator octet and preceding the check bits. The length indicator differentiates
between the three types of signal units.
The 6-bit length indicator field is a number in binary code in the range 0~63 (decimal).
The length indicator values of the three types of signal units are as follows:
Length indicator = 0 Fill-in signal unit
Length indicator = 1 or 2 Link status signal unit
Length indicator > 2 Message signal unit
Transport Protocols

1-7
In the national signaling network, the length indicator is invariably set to 63 if the
signaling information field of a message signal unit is more than 62 octets. In the case
that the length indicator equals 63, the maximum length indicated by it cannot be
more than 272 octets.
Note that it is necessary to calculate the number of bits and the number of octets
between two flags in the receiving process of signal units. According to the CCITT,
the number of bits between two signal unit flags must be an integral multiple of 8. The
number of octets may be equal to 0 (if only flags are sent), be equal to 5 (fill-in signal
unit), or be less than or equal to m+7 (m is 272). For a number out of such range, the
signal unit is treated as error.
Check bits (CK)
The check bits field is used for error detection of a signal unit. It is composed of 16
bits.
The seven fields described above appear in all the three types of signal units. (Eight
such fields are mentioned in the previous section, where the closing flag is included.)
They are mandatory to every signal unit.
Status field (SF)
The status field is unique to link status signal units and is used to indicate the status
of a signal link.
The length of the status field may be one octet (8 bits) or two octets (16 bits).
If the status field is one octet, the link status is indicated by the lower three bits
currently, as shown in Table 1-1:
Table 1-1 Meanings of the link status indications in the status field
CBA Bits Identifier Indication Meaning
000 SIO Status indication O Out of alignment
001 SIN Status indication N Normal alignment
010 SIE Status indication E Emergency alignment
011 SIOS Status indication OS Out of service
100 SIPO Status indication PO Processor outage
101 ISB Status indication B Busy (link congestion)

Service information octet (SIO)
The service information octet field is unique to the message signal units. It contains
the service indicator (SI) and the sub-service field (SSF), as shown in Figure 1-4.
The field has 8 bits. The service indicator and the sub-service field occupy 4
respectively.
Transport Protocols

1-8
SI SSF
Meaning DCBA
International network
Spare (for international use only)
National network
Reserved for national use
0 0 0 0
0 1 0 0
1 0 0 0
1 1 0 0
Meaning DCBA
Signaling network management messages
Signaling network testing and maintenance messages
Spare
SCCP
Telephone User Part
ISDN User Part
Data User Part
Spare
0 0 0 0
0 0 0 1
0 0 1 0
0 0 1 1
0 1 0 0
0 1 0 1
0 1 1 0
0 1 1 1
1 0 0 0
1 1 1 1
F CK SIF SIO
SI SSF
Meaning DCBA
International network
Spare (for international use only)
National network
Reserved for national use
0 0 0 0
0 1 0 0
1 0 0 0
1 1 0 0
Meaning DCBA
Spare
SCCP
Telephone User Part
ISDN User Part
Data User Part
Spare
0 0 0 0
0 0 0 1
0 0 1 0
0 0 1 1
0 1 0 0
0 1 0 1
0 1 1 0
0 1 1 1
1 0 0 0
1 1 1 1
Meaning DCBA
Spare
SCCP
Telephone User Part
ISDN User Part
Data User Part
Spare
0 0 0 0
0 0 0 1
0 0 1 0
0 0 1 1
0 1 0 0
0 1 0 1
0 1 1 0
0 1 1 1
1 0 0 0
1 1 1 1
F CK SIF SIO

Figure 1-4 Format and codes of the service information octet
1) Service indicator (SI)
The service indicator is used to indicate the particular user part associated with the
transmitted message. In the message transfer part of the signaling network, the
message handling functions will base the service indicator to distribute the message
to the specified user part.
The code allocation for the service indicator is shown in Figure 1-4. The service
indicator capacity is enough to indicate 16 types of user part messages. Several
common types are listed in the figure.
2) Sub-service field (SSF)
It is composed of 4 bits. The higher two bits are the network indicator; the lower two
are currently spare bits, coded 00.
The network indicator is used to identify the nature of the network where the message
is transferred, that is,, it is an international or national signaling network message.
The code allocation of the sub-service field is shown in Figure 1-4.
According to the CCITT, the spare bits in the sub-service field may be used as per the
national signaling network. For example, the network indicator may be set to 10 or 11
to indicate the local signaling network or toll signaling network in case of 14-bit
signaling point encoding scheme. If the unified 24-bit encoding scheme is utilized, the
network indicator is set to 10 or 11 in order to identify the unified 24-bit encoding
scheme or temporary 24-bit encoding scheme (where ten 0 at the higher bit is
added/removed).
Transport Protocols

1-9
II. The Signaling Information Part Processed by a User Part
The signaling information part processed by the user parts is the signaling information
field (SIF) in the message signal unit format. The signaling information field only
exists in a message signal unit. It consists of three parts: the label for message
addressing, the heading code of the user signaling information, and the user signaling
information.
Label
The label contains the information necessary to deliver the message to its the
destination point. The standard routing label has a length of 32 bits and is placed at
the beginning of the signaling information field. The label includes the destination
point code (DPC), the originating point code (OPC) and the signaling link selection
(SLS) field.
A signaling point code is a numeric address, uniquely identifying one signaling point
in the SS7 network. When the destination point code contained in the message
indicates the receiving signaling point, the message is distributed to the
corresponding user part (such as ISUP or SCCP) identified by the service indicator in
the service information octet.
The signaling link selection is used in the following cases:
1) In ensuring message sequencing. Any two transmitted messages with the same
signaling link selection will normally arrive at the destination in the order in which
they were first transmitted.
2) In performing average load sharing of the stream between all available links. If a
certain user part periodically transmits messages and the signaling link selection
value is assigned in the cyclic manner, all the traffic to the destination has the
same traffic level.
The label structure determines four types of label as shown in Figure 1-5:
Type A MTP management messages
Type B TUP messages
Type C ISUP messages
Type D SCCP messages
As TCAP messages have to be transferred by the SCCP, the TCAP messages are
classified as SCCP messages, that is, type D.
Transport Protocols

1-10
F CK SIF FIB LI FSN SIO BIB BSN
Management message SLC OPC DPC Type A: MTP management messages
Signaling message
CIC
OPC DPC Type B: TUP messages
SLS
Signaling message OPC DPC Type C: ISUP messages CIC SLC
F
SCCP user data SLS OPC DPC Type D: SCCP messages
Management message SLC OPC DPC Type A: MTP management messages
Signaling message
CIC
OPC DPC Type B: TUP messages
SLS
Signaling message OPC DPC Type C: ISUP messages CIC SLC
F
SCCP user data SLS OPC DPC Type D: SCCP messages

Figure 1-5 Label structure of the four types
Heading code
The heading code is a field following the label It is composed of the 4-bit heading
code H0 and the 4-bit heading code H1, and identifies the message group and the
message type. For instance, in a TUP message, the heading code H0 coded 0001
and the heading code H1 coded 0001 indicate an Initial Address Message (IAM); the
heading code H0 coded 0001 and the heading code H1 coded 0100 indicate an
Address Complete Message (ACM). Another example is about a signaling network
management message. The H0 coded 0001 and the H1 coded 0001 indicate a
Changeover-order signal (COO); the H0 coded 0001 and the H1 coded 0100 indicate
a Transfer-prohibited signal. As both the H0 and the H1 occupy 4 bits, the maximum
capacity of a class of user messages is 256.
Signaling information
The signaling information part is also named service information part. This part is
further divided into several sub-fields. These sub-fields may be mandatory or optional
with fixed length or variable length in order to meet the requirements of various
functions and supplements, which makes it possible for message signal units to be
suitable for a variety of user messages and also makes it possible for the variety of
user message to be conveyed through common signaling channels.
For the format and encoding of the service information field, please reference the
user messages.
III. MTP Messages
In a signal unit, the flag, the backward sequence number, the backward indicator bit,
the forward sequence number, the forward indicator bit, the length indicator and the
check bits are mainly used for transmission, receiving sequence, error detection and
correction of the message signal unit. These fields are all analyzed and handled at
the second functional level of the signaling network, that is, the signaling link level.
Transport Protocols

1-11
Fill-in signal units are used for feeding purpose on a signaling link and composed of
several fields that mainly involve transmission control. Fill-in signal units are
generated and handled by the level 2 functions.
Link status signal units are used to carry the status indication information of a
signaling link. They are also generated and handled at the functional level 2. The
functional level 2 may base both the related indication from the level 3 and the
judgment of itself to generate a corresponding status signal unit and transmit it out;
the functional level 2 may also accept the status indication of the signaling link from
the peer and process it. If necessary, the information relating to congestion and
processor outage will be reported to the level 3.
Message signal units are divided into three classes according to their role in the
signaling network: the message signal units used for signaling network management
(MSU-SNM), the message signal units used for signaling network testing and
maintenance (MSU-SNT), and the message signal units generated by user parts
(MSU-UP). The first two classes utilize the type A label structure and are transmitted
between the MTPs. They are generated at the functional level 3 of the signaling
network and also processed at the level 3. The third class includes the messages of
type B, C and D label structure. Through the MTP, these messages are delivered to a
particular user part. The level 3 functions of the signaling network are responsible for
analyzing the label contained in the message to determine where the message will be
distributed. The generating and handling of the signaling information part (service
information part) is implemented by the functional level 4, that is, the user parts.
The signaling network management messages are critical to the MTP, and described
in details in the following section.
General format for the signaling network management messages
In the signaling network, the signaling network management messages are
distinguished by the configuration 0000 of the service indicator (SI) contained in the
service information octet in the signal unit.
As a type of message signal unit, the signaling information of a signaling network
management message is carried by the service information field. It structure is
illustrated in Figure 1-6.
Management
information
H1 OPC SLC H0 DPC
8n
(n 0)
4 24/14 24/14 4 4 4
First bit
transmitted

Figure 1-6 General format for the signaling network management messages
Label
It comprises the destination point code (DPC), the originating point code (OPC) and
the signaling link code (SLC).
Transport Protocols

1-12
The destination point code and the originating point code are described the same as
the preceding section.
The signaling link code indicates the signaling link interconnecting the destination and
originating points. If the message is not related to a signaling link, or another
particular code is not specified, it is coded 0000. Currently 4 bits are used. The spare
4 bits are coded 0000.
Heading code
The heading codes include the 4-bit heading code H0 and the 4-bit heading code H1.
The heading code H0 identifies the management message group. The heading code
H1 determines the specific message from the message group. As both the H0 and
the H1 occupy 4 bits, the message capacity reaches 256 types. That is, there are 16
message groups and 16 message types in each group are available. Now not all of
them are used. See Table 1-2.
Table 1-2 Heading code allocation of signaling network management messages
Message
Group
H1
H0
0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111

0000
CHM 0001 COO COA CBD CBA
ECM 0010 ECO ECA
FCM 0011 RCT TFC
TFM 0100 TFP * TFR TFA *
RSM 0101 RST RSR
MIM 0110 LIN LUN LIA LUA LID LFU LLT LRT
TRM 0111 TRA
DLM 1000 DLC CSS CNS CNP

1001
UFC 1010 UPU

1011

1100

1101

1110

1111

The meaning of the signaling network management messages is listed in Table 1-3.
Transport Protocols

1-13
Table 1-3 Signaling network management messages
Message Full name
CHM Changeover and changeback messages
COO Changeover-order signal
COA Changeover-acknowledgement signal
CBD Changeback-declaration signal
CBA Changeback-acknowledgement signal
ECM Emergency-changeover message
ECO Emergency-changeover-order signal
ECA Emergency-changeover-acknowledgement signal
FCM Signaling-traffic-flow-control messages
RCT Signaling-route-set-congestion-test signal
TFC Transfer-controlled signal
TFP Transfer-prohibited signal
TFR Transfer-restricted signal (national option)
TFA Transfer-allowed signal
RSM Signaling-route-set-test message
RST Signaling-route-set-test signal for prohibited destination
RSR Signaling-route-set-test signal for restricted destination (national option)
MIM Management inhibit messages
LIN Link inhibit signal
LUN Link uninhibit signal
LIA Link inhibit acknowledgement signal
LUA Link uninhibit acknowledgement signal
LID Link inhibit denied signal
LFU Link forced uninhibit signal
LLT Link local inhibit test signal
LRT Link remote inhibit test signal
TRM Traffic-restart-allowed message
TRA Traffic-restart-allowed signal
DLM Signaling-data-link-connection-order message
DLC Signaling-data-link-connection-order signal
CSS Connection-successful signal
Transport Protocols

1-14
Message Full name
CNS Connection-not-successful signal
CNP Connection-not-possible signal
UFC User part flow control messages
UPU User part unavailable signal

IV. Message Examples
Transfer-allowed message (TFA)
The format of the transfer-allowed message is shown as follows:
Destination
Heading
Code H1
Heading
Code H0
Label
DCBA 0100
First bit
transmitted
24 4 4 56
Destination
Heading
Code H1
Heading
Code H0
Label
DCBA 0100
First bit
transmitted
24 4 4 56

The heading code H1 contains one signal code as follows:
D C B A
0 1 0 1 Transfer-allowed signal

1.3.3 Signaling Procedures
I. Message Routing
The message routing function is based on the information contained in the routing
label, namely on the destination point code and on the signaling link selection field.
Each signaling point has the routing information that enables it to determine the
signaling link over which a message is sent on the basis of the destination point code
and the signaling link selection field.
Typically the destination point code is associated with more than one signaling link
that may be used to carry the message; the selection of the particular signaling link is
made by means of the signaling link selection field, thus effecting load sharing.
There are two basic cases of load sharing, namely:
load sharing between the links belonging to the same link set;
load sharing between the links not belonging to the same link set.
Messages not related to a signaling link may be assigned any signaling link code
(SLC) to allow load sharing of the messages, or may be assigned a default SLC such
Transport Protocols

1-15
as 0000. They are routed in accordance with the normal routing function, where the
(SLC) is used as SLS for load sharing.
II. Changeover
The purpose of the changeover procedure is to ensure the signaling traffic carried by
the unavailable signaling link is diverted to the alternative signaling link(s) as quickly
as possible while avoiding message loss, duplication or mis-sequencing.
To implement this purpose, in the normal case the changeover procedure includes
buffer updating and retrieval, which are performed before reopening the alternative
signaling link(s) to the diverted traffic. Buffer updating consists of identifying all the
messages in the retransmission buffer of the unavailable signaling link which have not
been received by the far end. Retrieval consists of transferring the concerned
messages to the transmission buffer(s) of the alternative link(s).
In the case of unavailability of a signaling link, changeover is initiated at a signaling
point. The following actions are then made:
transmission and acceptance of message signal units on the concerned
signaling link is terminated;
transmission of link status signal units or fill-in signal units takes place;
the alternative signaling link(s) are determined;
a procedure to update the content of the retransmission buffer of the unavailable
signaling link is performed;
signaling traffic is diverted to the alternative signaling link(s).
III. Changeback
The objective of the changeback procedure is to ensure that signaling traffic is
diverted from the alternative signaling link(s) to the signaling link made available as
quickly as possible, while avoiding message loss, duplication or mis-sequencing.
Changeback includes the basic procedures to be used to perform the opposite action
to changeover.
Changeback is initiated at a signaling point when a signaling link is reconnected,
restored, or unblocked, and therefore it becomes once again available. The following
actions are then made:
the alternative signaling link(s) to which traffic normally carried by the signaling
link made available was previously diverted are determined;
transmission of the concerned traffic on the alternative signaling link(s) is
stopped, and such traffic is stored in a changeback buffer;
a changeback declaration is sent to the remote signaling point of the signaling
link made available through the concerned alternative signaling link; this
message indicates that message traffic on the alternative signaling link will be
sent by the signaling link made available;
Transport Protocols

1-16
the concerned signaling point will restart diverted traffic over the signaling link
made available when it receives a changeback acknowledgement from the far
signaling point of the link made available.
IV. Signaling Link Activation
When a decision is taken to activate an inactive signaling link, initial alignment starts:
if the initial alignment procedure is successful, the signaling link is active and a
signaling link test is started;
if the signaling link test is successful, the link becomes ready to convey signaling
traffic;
in the case when initial alignment is not possible, new initial alignment
procedures are started on the same signaling link after the timer expires;
if the signaling link test fails, link restoration starts until the signaling link is
activated or a manual intervention is made.
V. Signaling Link Restoration
After a signaling link failure is detected, signaling link initial alignment will take place.
if the initial alignment procedure is successful, a signaling link test is started;
if the signaling link test is successful, the link becomes restored and thus
available for signaling;
if the initial alignment is not possible, new initial alignment procedures may be
started on the same signaling link;
if the signaling link test fails, the restoration procedure is repeated until the link is
restored or a manual intervention made.
VI. Signaling Link Deactivation
An active signaling link may be made inactive by means of a deactivation procedure,
provided that no signaling traffic is carried on that signaling link. When a decision has
been taken to deactivate a signaling link, the signaling terminal of the signaling link is
taken out of service.
VII. Signaling Route Management Procedures
The purpose of the signaling route management function is to ensure a reliable
exchange of information between the signaling points (to ensure the availability of the
signaling routes).
The unavailability, restriction and availability of a signaling route is communicated by
means of the transfer-prohibited, transfer-restricted and transfer-allowed procedures.
Transport Protocols

1-17
VIII. Transfer Prohibited
For the purpose of being described conveniently, it is assumed that Y is the
originating signaling point, X is the destination signaling point, and Z is a signaling
transfer point.
when the signaling point Y starts to route signaling destined to the signaling point
X through the signaling transfer point Z which is currently unavailable for the
signaling point Y, the transfer-prohibited message is sent to the signaling transfer
point Z;
when the signaling transfer point Y recognizes the inaccessibility of the signaling
point X, the transfer-prohibited message is sent to all accessible adjacent
signaling points (broadcast method);
when a message destined to the signaling point X is received at the signaling
transfer point Y and Y is unable to transfer the message, the transfer-prohibited
message is sent to the adjacent signaling point from which the concerned
message was received.
Transport Protocols
Chapter 2 Broadband MTP

2-1
2.1 Overview
Broadband MTP provides the transfer capability of broadband signaling cross the
ATM network and consists of Message Transfer Part (broadband) (MTP3b) and
Signaling ATM Adaptation Layer (SAAL).
The major differences between the broadband SS7 and narrowband SS7 are the
relevant modifications of the MTP layer. To widen the signaling bandwidth, the MTP-1
and the MTP-2 are changed to SAAL (Service Specific Connection Oriented Protocol,
Service Specific Coordination Function) and the MTP-3 is changed to MTP3b. In the
aspect of physical connection, E1 trunk connections are changed to ATM (Permanent
Virtual Channel) connections.
In MSOFTX3000, the broadband MTP provides signaling transfer services for the
SCCP, BICC and H.248 protocols, as shown in Figure 2-1.
ATM
AAL5
SSCOP
SSCF AT NNI
MTP3b
LM
SAAL
SCCP/BICC/H.248
User Part
Broadband MTP
ATM
AAL5
SSCOP
SSCF AT NNI
MTP3b
LM
SAAL
SCCP/BICC/H.248
User Part
Broadband MTP

Figure 2-1 Structure of the broadband MTP
Currently in UMTS, the broadband MTP is mainly applicable to the Iu-CS interface
and provides signaling transfer services for the RANAP/SCCP. If necessary, the
broadband MTP is also used on the Nc interface and provides services for the BICC
protocol.
Transport Protocols

2-2
2.2 MTP3b
2.2.1 Introduction of MTP3b
MTP3b is a protocol specification designed for ATM features on the basis of the
MTP3. The MTP3b is not only responsible for carrying signaling messages, but also
responsible for managing the signaling network and signaling links. The MTP3b uses
the services provided by the SAAL for message exchange.
I. MTP3b Structure
Similar to the MTP3, the functional structure of the MTP3b protocol is composed of
signaling message handling and signaling network management.
1) Signaling message handling
The purpose of the signaling message handling functions is to ensure that the
signaling messages originated by a particular User Part at a signaling point are
delivered to the same User Part at the destination point indicated by the related field
in the message signal unit (there are only SCCP and STC user parts at the Iu
interface). To achieve these functions, signaling message handling is further divided
into message routing, discrimination and distribution functions.
2) Signaling network management
The purpose of the signaling network management functions is to provide
reconfiguration of the signaling network in the case of failures. Activation and
alignment of a new signaling link is also included. With the enlargement of a signaling
network and increasing of the load over signaling links, congestion may appear in the
signaling network. Thus controlling congestion is one of the signaling network
management functions. The signaling network management functions comprise
signaling traffic management, signaling link management and signaling route
management.
II. MTP3b Functions
The major functions provided by the components in the MTP3b protocol structure are
described as follows:
1) Message discrimination
The purpose of the message discrimination function is to examine the standard field
in the message header to judge whether or not a received message from the lower
layer (SAAL) is valid and, if valid, to determine where the message will be delivered.
If the message is not valid, the message will be discarded.
If the message is valid, there are the following possibilities:
Transport Protocols

2-3
a) When the received message is destined to the signaling point itself, the message
will be delivered to the message distribution module;
b) When the received message is not destined to the point itself and the signaling
point has no the transfer capability, the message will be discarded; otherwise, the
message will be delivered to the message routing module for further handling.
2) Message distribution
The purpose of the message distribution function is to direct a received message to
the appropriate upper-layer module which is the destination for processing the
message. If the message does not exist in the particular level 4 module indicating to
process it or the field is not valid, the message will be discarded.
3) Message routing
The purpose of the message routing function is to base the header information of a
received message to select an appropriate route for it, base the route to select a link
set, base the link set to select a link, and use the selected link to finally transmit the
message out. The handled message has the following possibilities:
The message is delivered from the upper-layer. The message routing module
has to determine an available route to transmit it. An exception is there is not
such a satisfactory route.
When the message is not destined to the point itself and the signaling point has
the signaling transfer function, its destination signaling point can be found from
the destination signaling point table at this signaling point, so as to direct the
message out.
When the message is not destined to the point itself and the signaling point has
the signaling transfer function but the destination signaling point of the message
cannot be found from the destination signaling point table at this signaling point,
the message will be discarded.
4) Signaling traffic management
The purpose of the signaling traffic management function is to ensure a reliable and
in-sequence transfer of signaling messages. In the case of unreliability or
unavailability of a link, the function is used to divert the messages to one or more
alternative links with the objective of avoiding message loss or mis-sequencing.
5) Signaling route management
The purpose of the signaling route management function is to provide the basis for
message routing and, in the case of unavailability or unreliability of the currently
applied route, provides rerouting function and re-configures the network in order to
provision a reliable route to achieve signaling transfer.
6) Signaling link management
The purpose of the signaling link management function is to perform a proper
handling procedure on a signaling link in the case of unavailability or unreliability, in
Transport Protocols

2-4
order to stop using the unreliable link and repeatedly restart the link with the objective
of making it available again. The link management function also provides the link
testing function which periodically performs testing on a link so as to confirm the
availability of the link.
2.2.2 MTP3b Message Structure
The message structure of the MTP3b is basically same as that of the MTP3. Please
reference Narrowband MTP for more information. Here in this chapter only their
differences are covered.
I. Length of User Data
The MTP3b extends the length of the user data contained in a signal unit. The
maximum amount of the user data supported by MTP3b signaling links is 4091 octets
(that supported by narrowband MTP is 272 octets).
II. Service Indicator (SI)
The following codes of the service indicator are additionally used in the MTP3b:
SI code Meaning
1 0 0 1 Broadband ISDN User Part
1 0 1 0 Satellite ISDN User Part

In MSOFTX3000 product, the MTP3b has three users, namely SCCP, BICC and
H.248. The service indicator codes respectively corresponding to them are as follows:
SI code Indicating user
0 0 1 1 SCCP
1 1 0 1 BICC
1 1 1 0 H.248

III. Changeover Procedure
By contrast with the narrowband MTP, the MTP3b changeover procedure applies with
the following exceptions and clarifications:
The signaling link failure indication causes by MTP2 link do not apply, here is In
Service to Out Of Service state causes by SAAL or when a request (automatic or
manual) is obtained from a management or maintenance system.
Transport Protocols

2-5
Moreover a signaling link that is available is recognized by level 3 as failed when
an extended changeover order or an emergency changeover order is received.
The changeover message of the signaling network management messages is
modified by using XCO/XCA to replace COO/COA. Heading code allocation of
MTP3b signaling network management messages is shown in the following
table:
Message
Group
H1

H0 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111

0000

CHM 0001 COO COA XCO XCA CBD CBA

ECM 0010 ECO ECA

FCM 0011 RCT TFC

TFM 0100 TFP * TFR TFA *

RSM 0101 RST RSR

MIM 0110 LIN LUN LIA LUA LID LFU LLT LRT

TRM 0111 TRA

DLM 1000 DLC CSS CNS CNP

1001

UFC 1010 UPU

1011

1100

1101

1110

1111

2.3 SAAL
2.3.1 SAAL Function Structure
In the broadband network, signaling adaptation is required in the transmission of
signaling information across ATM network. That is to say, signaling information in a
variety of message formats has to be converted to a format suitable for transportation
over ATM network and ATM Adaptation Layer (AAL) connections have to be set up for
Transport Protocols

2-6
signaling. What implements this function is the Signaling ATM Adaptation Layer
(SAAL).
The SAAL protocol used in MSOFTX3000 product is in full compliance with the ITU-T
Recommendations Q.2110, Q.2140 and Q.2144.
The SAAL makes use of the specification of AAL type 5 (AAL5). As shown in Figure
2-2, The SAAL comprises the Convergence Sublayer (CS) and the Segmentation And
Reassembly (SAR). The CS is divided into the Service Specific Convergence
Sublayer (SSCS) and the Common Part Convergence Sublayer (CPCS). Further, the
SSCS includes three parts: the Service Specific Coordination Function (SSCF)
sublayer (ITU-T Q.2140), the Service Specific Connection Oriented Protocol (SSCOP)
sublayer (ITU-T Q.2110), and the Layer Management (LM) (ITU-T Q.2144).
SSCF-NNI
SSCO
P
L
M
CPCS -
SAR
MTP3
B
O
M
SAAL

Figure 2-2 Structure of the SAAL protocol in MSOFTX3000
In MSOFTX3000, the CPCS and the SAR are implemented by the BSG hardware,
thus the SSCOP, the SSCF and the LM constitute the core of the SAAL protocol.
2.3.2 SSCOP
I. SSCOP Functions
The SSCOP performs the following functions:
Sequence integrity: This function preserves the order of SSCOP SD PDUs that
were submitted for transfer by SSCOP.
Error correction by selective retransmission: Through retransmission, sequence
errors are corrected when the receiving SSCOP entity detects missing SSCOP
Service Data Units (SDUs).
Flow control: By sending the movement of the sliding window, this function
allows to adjust the information transmission rate to perform flow control.
Transport Protocols

2-7
Error reporting to Layer Management: This function indicates to layer
management errors which have occurred.
Keep alive: This function verifies that the two peer SSCOP entities participating
in a connection are remaining in a link connection established state even in the
case of a prolonged absence of data transfer.
Local data retrieval: This function allows the local SSCOP user to retrieve
in-sequence SDUs which have not yet been released by the SSCOP entity when
a link changeover procedure takes place at the higher layer.
Connection control: This function performs the establishment, release, and
resynchronization of an SSCOP connection. It also allows the transmission of
variable length user-to-user information without a guarantee of delivery.
Transfer of user data: This function is used for the conveyance of user data
between users of the SSCOP. SSCOP supports both assured and unassured
data transfer.
Protocol error detection and recovery: This function detects and recovers from
errors in the operation of the protocol.
Status reporting: This function allows the transmitter and receiver peer entities to
exchange status information.
II. SSCOP Protocol Data Units
What are conveyed between two SSCOP peer layers for the establishment or release
of a connection and for the guarantee of a reliable message transmission are protocol
data units (PDUs) of the SSCOP. Basic PDUs are listed and described as follows:
BGN PDU (Begin): The BGN PDU is used to establish an SSCOP connection
between two peer entities. The BGN PDU requests the clearing of the peers
transmitter and receiver buffers, and the initialization of the peers transmitter
and receiver state variables and counters.
BGAK PDU (Begin Acknowledge): The BGAK PDU is used to acknowledge the
acceptance of a connection request from the peer.
BGREJ PDU (Begin Reject): The BGREJ PDU is used to reject the connection
request of the peer SSCOP entity.
END PDU (End): The END PDU is used to release an SSCOP connection
between two peer entities.
ENDAK PDU (End Acknowledge): The ENDAK PDU is used to confirm the
release of an SSCOP connection.
RS PDU (Resynchronization): The RS PDU is used for the routine
connection-oriented reset in other connection-oriented protocols. The RS PDU is
used to resynchronize the buffers and the transmitter and receiver state
variables (counters).
RSAK PDU (Resynchronization Acknowledge): The RSAK PDU is used to
acknowledge the acceptance of a resynchronization requested by the peer
SSCOP entity.
Transport Protocols

2-8
ER PDU (Error Recovery): The ER PDU is used to recover from protocol errors
in the operation of a connection.
ERAK PDU (Error Recovery Acknowledge): The ERAK PDU is used to
acknowledge the recovery from protocol error.
SD PDU (Sequenced Data): The SD PDU is used to transfer user service data to
the peer entity after an SSCOP connection is set up.
POLL PDU (Status Request): The POLL PDU is used to request, across an
SSCOP connection, status information about the peer SSCOP entity.
STAT PDU (Solicited Status Response): The STAT PDU is used to respond to a
status request (POLL PDU) received from a peer SSCOP entity. It is used to
notify the peer SSCOP entity of correct receipt of concerned SD PDUs and also
used to acknowledge which SD PDUs are successfully accepted and which fail
to be received. It is also used to update the position of the transmitting window.
In this way, the maximum transmitting sequence number of SD PDUs that can
be sent currently is controlled. The STAT PDU also contains the sequence
number [N(PS)] of the POLL PDU to which it is in response.
USTAT PDU (Unsolicited Status Response): The USTAT PDU is used to
respond to a detection of one or more new missing SD PDUs, based on the
examination of the sequence number of the SD PDU. It contains the data for
updating the transmitting window of the peer, but there is not the N(PS) field.
UD PDU (Unnumbered Data): The UD PDU is used for unassured data transfer
between two SSCOP users, without affecting connection-oriented sequencing in
progress, without changing the entities counters or variables, without
re-transmitting lost data.
MD PDU (Management Data): The MD PDU is used for unassured management
data transfer between two SSCOP management entities. Similar to the UD PDU,
the MD PDU does not ensure a reliable receipt by the peer.
III. SSCOP States
The states of an SSCOP protocol entity reflect general conditions of the SSCOP
entity in the sequences of signals and PDU exchanges with its user and peer,
respectively. The basic states are:
State 1 - Idle: Each SSCOP entity is conceptually initiated in the Idle state (State
1) and returns to this state upon the release of a connection.
State 2 - Outgoing Connection Pending: An SSCOP entity requesting a
connection with its peer is in the Outgoing Connection Pending state (State 2)
until it receives acknowledgement from its peer
State 3 - Incoming Connection Pending: An SSCOP entity that has received a
connection request from its peer and is waiting for its users response is in the
Incoming Connection Pending state (State 3).
State 4 - Outgoing Disconnection Pending: An SSCOP entity requesting release
of the peer-to-peer connection goes to the Outgoing Disconnection Pending
Transport Protocols

2-9
state (State 4) until it receives confirmation that the peer entity has released and
transitioned to the Idle state (State 1), after which it does the same.
State 5 - Outgoing Resynchronization Pending: An SSCOP entity requesting
resynchronization of the connection with its peer is in the Outgoing
Resynchronization Pending state (State 5).
State 6 - Incoming Resynchronization Pending: An SSCOP entity that has
received a resynchronization request from its peer and is waiting for its users
response is in the Incoming Resynchronization Pending state (State 6).
State 7 - Outgoing Recovery Pending: An SSCOP entity requesting recovery
with its peer of an existing connection is in the Outgoing Recovery Pending state
(State 7).
State 8 - Recovery Response Pending: An SSCOP entity which has completed
recovery, notified its user, and is awaiting response is in the Recovery Response
Pending state (State 8).
State 9 - Incoming Recovery Pending: An SSCOP entity that has received a
recovery request from its peer and is waiting for its users response is in the
Incoming Recovery Pending state (State 9).
State 10 - Data Transfer Ready: Upon successful completion of the connection
establishment, resynchronization, or error recovery procedures, both peer
SSCOP entities will be in Data Transfer Ready state (State 10) and assured data
transfer can take place.
IV. SSCOP Operating Mechanism
Connection establishment of SSCOP
In order to establish a connection between two peer SSCOP entities, the SSCF sends
an AA-ESTABLISH.req primitive to the SSCOP. This primitive contains SSCOP-UU
and BR parameters used by SSCOP to generate a BGN message. The BGN
message is sent to the receiving SSCOP where it is decoded, processed and mapped
to an AA-ESTABLISH.ind signal which will be sent to the receiving SSCF. The SSCF
responds to the SSCOP with an AA-ESTABLISH.res primitive containing also
SSCOP-UU and BR primitives. Whereas, the SSCOP sends a BGAK message back
to the originating SSCOP and the originating SSCOP decodes and processes it and
sends it to the SSCF. These actions establish a connection between two SAAL
entities in two broadband signaling exchanges. See Figure 2-3.
Transport Protocols

2-10
SSCOP A SSCOP B
AA-ESTABLISH.req
PDU BGN
AA-ESTABLISH.ind.
AA-ESTABLISH.rsp.
PDU BGAK
AA-ESTABLISH.con.

Figure 2-3 Connection establishment of SSCOP
Data transfer and error recovery of SSCOP
As shown in Figure 2-4, SSCOP A sends to SSCOP B four SD PDUs in the N(S)
sequence numbered from 1 to 4. Only the PDU1 and PDU2 succeed in arriving at
SSCOP B without error. The SSCOP delivers the PDU1 and PDU2 to the proper user.
The SSCOP A sends a POLL PDU. Contained in the message is N(S)=5 indicating
the N(S) value of the next new SD PDU (that is, the next SD PDU to be transmitted).
The POLL also contains N(PS)=1 which is the sequence number of the POLL PDU.
The SSCOP B responds to the POLL PDU with a STAT PDU, and the STAT PDU is
coded N(R)=3 to acknowledge the acceptance of the PDU1 and PDU2. In addition, it
is also indicated that it is expecting the next PDU, that is, PDU3. The N(PS) field
contained in the STAT must be the same as the value of the N(PS) field contained in
the concerned POLL PDU. The list element is set to 3 and 5. The information
indicated by it is described as follows. The odd element (valued 3) indicates the PDU
of a certain loss interval; the even element (valued 5) indicates the first PDU in the
next correctly accepted sequence. This message notifies the SSCOP A that 1) it must
re-transmit PDU3 and PDU4; 2) it can release PDU1 and PDU2 from the buffer; and 3)
it must preserve PDU3 and PDU4 as there is not enough information about the final
result of PDU3 and PDU4. The SSCOP A then sends 3 SD PDUs to the SSCOP B,
and only the PDU7 is received. As the SSCOP is not allowed to exchange
out-of-sequence service with the user, the SSCOP B keeps PDU7 in the buffer. It
sends to the SSCOP A a USTAT PDU (where N(R)=3).
Transport Protocols

2-11
1 (0)
2 (0)
3 (0)
4 (0)
1
2
X
X
X
X

5 (1)
6 (1)
7 (1)
X
X
7
T1160080-94/d82
5 (1)
6 (1)
3
4
X
X
Free 1, 2
Action Delivered Tx Rx
FI GURE I I .9/ Q.2110
Er r or r ecover y via solicited and unsolicited ST ATs
of the last tr ansmitted SD PDUs
POLL(5.1)
STAT (3,1,N (MR), {3,5})
USTAT (3, N (MR), {5,7})

Figure 2-4 Data transfer of SSCOP
Connection release of SSCOP
After an SSCOP receives a release request message AA-RELEASE.request, it sends
an END PDU to the peer SSCOP. On receipt of the END PDU, the peer sends an
AA-RELEASE.indication. After the connection is released, the peer sends an ENDAK
PDU. After receiving it, the receiving end sends an AA-RELEASE.confirm message to
the concerned SSCF, and releases the connection. See Figure 2-5.
SSCOP
A
SSCOP
B
END
ENDAK
AA-RELEASE.request
AA-RELEASE.confirm
AA-RELEASE.indicatio

Figure 2-5 Connection release of SSCOP
2.3.3 SSCF
The SSCF is used to coordinate the interface between the SSCOP and the
upper-layer MTP3b. It maps primitives from the MTP3b to required SSCOP signals,
and vice versa. In nature, the SSCF only transfers the signals between the SSCOP
Transport Protocols

2-12
and the MTP3b to and fro, playing an intermediate role. The SSCF does not transmit
any PDUs to the peer entity in the receiver; instead, by relying on the SSCOP, its
information is carried in SSCOP PDUs.
I. SSCF Functions
Primitive mapping: The SSCF maps primitives received from SAAL user to
signals defined at the SSCOP upper layer boundary and maps signals received
from the SSCOP to primitives implicitly defined at the MTP-3 lower layer
boundary.
Local retrieve: In the case of a changeover procedure performed on a faulty link,
this function makes it possible to obtain back the data not yet transmitted and
divert the data to alternative link(s).
Flow control: The SSCF reports to the user the congestion level (or no
congestion) to avoid unnecessary cell loss. It also diverts its own PDU flow to the
lower layer in order to prevent from congestion happening at the other end.
Link status maintenance: This SSCF function receives primitives from the MTP-3
or signals from the SSCOP and maintains information pertaining to the status of
the link, such as In Service and Out Of Service. Based on the information, it can
provide primitives/signals to the MTP3 and the SSCOP as an aid to maintaining
the link.
Reporting to layer management: This SSCF function transmits MAAL primitives
to the layer management so that the layer management can perform statistics
and measurements. For instance, upon release of a link, the SSCF reports the
release to the layer management, and then the layer management can measure
the In-service duration. With the help of the layer management, the error
monitoring function can be implemented.
Performing link alignment.
II. SSCF Link Alignment
Alignment procedure: The procedure initiated according to user's request to detect
the status of a link before it is put into service in the case of successful establishment.
On receipt of the users (MTP3b) request (by sending a STAR_req primitive), the
SSCF transmits a BGN PDU to the peer entity in the receiving exchange to start the
alignment procedure, and moves a link from the Out Of Service status to the
Alignment status.
These operations require the SSCOP to establish a link between the two exchanges.
After the link is successfully established, the SSCF indicates the layer management
to start the monitoring action. Then the SSCF enters the Proving status for the link.
At this moment, proving PDUs are transported between the exchanges. A links proves
to be good by the means that n (1000 by default) proving PDUs can be successfully
transmitted. In the end, if 1000 proving PDUs are really transmitted successfully and
Transport Protocols

2-13
errors are not found then the link is recognized as passing the alignment and can be
put into service.
The SSCF alignment procedure provides a normal or emergency proving. Whether to
begin proving can be initiated by the layer management and the MTP3b. In the
normal proving,
The proving algorithm on SAAL link is based on the alignment error rate monitoring
process used for proving a link. Transmission of testing PDUs of N1 amount (1000 by
default) at a specified rate (one PDU per millisecond by default) must be completed
within 30 seconds from the start to the proving success. If one or two (one by default)
of the transmitted N1 PDUs are re-transmitted, the proving fails. If no error occurs, the
link succeeds in being proved and moves to In Service.
2.3.4 LM
The position of the Layer Management (LM) in the SAAL is shown in Figure 2-2. The
SSCS LM is the layer management entity of the Service Specific Convergence
Sublayer. It makes a direct interaction with the sublayers to implement a number of
Operation Administration and Maintenance (OAM) functions. Therefore, the SSCS LM
is described as an entity having interactions with all SAAL layers since CPCS and
SAR (AAL Type 5) are implemented by the hardware and there are no interactions
defined at these two layers. The SSCS LM is responsible for conducting the following
tasks:
Determining whether a link should be out of service or in service. As a
component of these operations, a link has to be monitored against excessive
delays during service transmission. In order to avoid unnecessary alteration, the
layer management allows a certain number of errors occurring at the link.
Periodically conducting a number of measurements. For instance, the layer
management uses counters to count how long each link is in service, how
frequent faults take place, how frequent congestions happen, as well as other
information.
Performing alarm handling.
The layer management has the following states:
Out Of Service
Alignment
Proving
Aligned Ready
In Service
Transport Protocols

2-14
I. LM Error Monitoring Algorithms
The layer management provides three algorithms for error monitoring. These
algorithms ensure to detect an error burst keeping for more than 400ms.
Algorithm 1 is mainly used for heavy load. If the volume of the transmitted data is
too large, the receiver has not enough time to handle the data. This causes the
fact that the data in the sending buffer cannot be released so long that the sum
of the transmission queue continues to increase to a particular value. At this
moment, the link will be released.
Algorithm 2 is mainly used for intermediate load. This algorithm monitors data
retransmissions. When data retransmissions occur so frequently within a
particular interval that the occurrence sum exceeds a threshold, it indicates a
bad quality on the link. Once the delay is beyond tolerance, the link will be
released.
Algorithm 3 is mainly used for light load. If within a particular interval the
difference between the number of transmitted POLL PDUs and the number of
accepted STAT PDUs (the difference is actually the number of lost STAT PDUs)
exceeds a threshold, it also indicates a bad quality on the link. In this case, the
link will be released.
II. SAAL Compound States
The states for coordinative operation among the three sub-layers are defined as
follows: (m indicates the state number of SSCF; n indicates the state number of
SSCOP; r indicates the state number of LM; and m/n/r indicates the compound
state of the three sub-layers.)
1/1/1 Out Of Service/Idle: In this state, the connection is idle.
1/4/1 Out Of Service/ Outgoing Disconnection Pending: In this state the MTP3b,
or alternatively the Layer Management, has issued an AAL-STOP-request, or an
AA-RELEASE-request or an MAAL_RELEASE-Request, respectively, which
caused the SSCF to issue an AA-RELEASE-request, and the SSCF is waiting for
a confirmation of the SSCOP connection release, AA-RELEASE-confirm.
2/1/2 Alignment/Idle: In this state, the SAAL user requested the SSCF to provide
an AAL connection. This request was passed to SSCOP by means of an
AA-ESTABLISH-request, but the connection establishment or proving was
unsuccessful. SSCF is waiting to reattempt this process. This process will be
repeated until a supervisory function indicates that the establishment of an AAL
connection is to be abandoned.
2/2/2 Alignment/Outgoing Connection Pending: In this state, the user has issued
an AAL-START-request, and the SSCF is waiting for a confirmation of SSCOP
connection.
2/4/2 Alignment/Outgoing Disconnection Pending: In this state the SSCF, or in
the case of unsuccessful proving, the Layer Management, requested the release
Transport Protocols

2-15
of the SSCOP connection. This request was passed to SSCOP by means of an
AA-RELEASE-request, and the SSCF is waiting for a confirmation of the SSCOP
connection release, AA-RELEASE-confirm. This state transition within SSCF is
not indicated to the SAAL user.
3/10/5 In Service/Data Transfer Ready: In this state, the signaling
connection is in service and may be used by the user to transfer signaling
messages.
2/10/3 Proving/Data Transfer Ready: In this state, an SSCOP connection
has been established, and SSCS layer management is conducting alignment
error rate monitoring to verify the quality of the link.
2/10/4 Aligned Ready/Data Transfer Ready: In this state, the SSCF has
completed proving and is awaiting an indication from its peer that the signaling
link can be put into service.
Figure 2-6 is the normal start flow diagram of the SAAL protocol. The transition of the
eight states above mentioned is shown in the figure.
Transport Protocols

2-16
T1167200-94/d06
. . . . . . . . . . . . . . . . . . . . . . . .
AAL-START-req.
MAL-REPORT-ind.
(-,ALN,-)
1 1
2
2
2 2
1 1 1
2
2
3
4
5
3
1/1/1
2/2/2
2/10/3
3/10/5
2/10/4
10 10
1/1/1
2/2/2
2/10/3
2/10/4
3/10/5
5
3
4
3
MAAL-PROVING-ind.
T3 expires
C1 > 0
T3 expires
C1 > 0
T3 expires
C1 = 0
MAAL-STOP_PROVING-ind.
AAL-IN_SERVICE-ind.
MAAL-REPORT-ind.
(-,INS,-)
AA-ESTABLISH-req.
AA-ESTABLISH-conf.
AA-DATA-req.(NM)
AA-DATA-ind.(NM)
AA-DATA-req.(IS)
AA-DATA-ind.(IS)
BG
N BGN
BGAK BGAK
SD
SD
POLL P
OLL
STAT
STA
T
P
O
LL
AA-ESTABLISH-req.
AA-ESTABLISH-conf.
AA-DATA-req.(NM)
AA-DATA-ind.(NM)
AA-DATA-req.(IS)
AA-DATA-ind.(IS)
AAL-START-req.
MAL-REPORT-ind.
(-,ALN,-)
MAAL-PROVING-ind.
T3 expires
C1 > 0
T3 expires
C1 > 0
T3 expires
C1 = 0
MAAL-STOP_PROVING-ind.
AAL-IN_SERVICE-ind.
MAAL-REPORT-ind.
(-,INS,-)
LM MTP3 SSCF-NNI SSCOP SSCOP SSCF-NNI MTP3 LM
FIGURE I I.1/Q.2140
Time flow diagram for connection estabishment Both UPS=Normal, Case 1
AA-DATA-req.(NM)
AA-DATA-ind.(NM)
SD SD
AA-DATA-req.(NM)
AA-DATA-ind.(NM)
STAT
S
TAT
SD
SD
POLL
1

Figure 2-6 Normal start flow diagram of SAAL
Transport Protocols
Chapter 3 SCTP

3-1
Chapter 3 SCTP
3.1 Overview
3.1.1 SCTP Concept
Stream Control Transmission Protocol (SCTP) is a reliable transport protocol that
operates over a potentially unreliable connectionless packet service such as IP. SCTP
is designed to transfer SCN narrowband signaling over IP network. Compared with
the TCP, SCTP features higher reliability, real-time and multi-homed performance.
SCTP is usually view as a transport layer protocol, whose upper layer is SCTP
application, and lower layer is packet-switched network.
SCTP features as follows:
Transport protocol based on subscribers message packets.
Support for orderly/disorderly transmission of subscriber datagram in the flow.
Multiple streams can be established in one association, and the data in the
streams do not interfere with each other.
Multi-home can be supported at one end or both ends of the association to
improve the reliability of the link.
The association must pass the COOKIE authentication before establishment to
guarantee the security.
Path fault detection in real-time.
3.1.2 Terminology
1) Transport address and IP address
A transport address of Stream Control Transmission Protocol (SCTP) is defined by
the combination of an IP address and an SCTP port number. SCTP port number is
used for the identification of the users at the same address, and it is identical to that
of TCP port number in the concept. For example, the IP address 10.105.28.92 and
SCTP port number 1024 indicate one transport address, while 10.105.28.93 and 1024
mean another transport address. 10.105.28.92 and 1023 indicate the different
transport addresses.
2) Host and endpoint
A Host is a computer, configured with one or multiple IP addresses. It is a typical
physical entity.
Transport Protocols
Chapter 3 SCTP

3-2
Endpoint is one of basic concepts of SCTP. An endpoint is the logical sender/receiver
of SCTP packets. It is a typical logical entity.
As prescribed in SCTP, only one association can be established between two
endpoints, and there may be multiple endpoints on a host.
3) Association and stream
An association is the logic relationship, or channel, established between two SCTP
endpoints for data transmission, through the four-way handshake mechanism
prescribed in SCTP.
SCTP is characterized by Stream. In an SCTP association, stream is a uni-directional
logic channel established from one endpoint to the other associated endpoint. The
data to be delivered in sequence has to be conveyed within a stream.
Multiple streams may be in the same association.
4) TSN and SSN
Transmission Sequence Number (TSN) is a 32-bit sequence number used internally
by SCTP. One TSN is attached to each chunk containing user data to permit the
receiving SCTP endpoint to acknowledge its receipt and detect duplicate deliveries.
TSN is maintained on the basis of association.
SSN is the acronym of Stream Sequence Number. In each stream of an SCTP
association, a 16-bit sequence number is assigned to each data chunk sent in the
stream by the local end, in order to ensure the sequenced transmission in the stream.
SSN is maintained on the basis of stream.
The assignments of TSN and SSN are independent to each other.
5) Others
CWND: Congestion Window. An SCTP variable that limits the data, in number of
bytes, a sender can transmit to a particular destination transport address before
receiving an acknowledgement. SCTP is a sliding window protocol. CWND is
maintained on the basis of each destination address and it will be adjusted according
to the network condition. Once the length of the unacknowledged message sent from
the destination address is greater than the CWND value, the endpoint will stop
transmitting data to this address.
RWND: Receiver Window. An SCTP variable that a data sender uses to store the
most recently calculated receiver window of its peer, in number of bytes. This gives
the sender an indication of the space available in the receiver's inbound buffer. During
the association establishment, both data sender and receiver will exchange their
RWND value to each other and the two RWND values will vary with data transmission
and acknowledgement. This is, in effect, restricting the amount of data it can transmit.
If the RWND is equal to 0, the data sender can always have one packet in flight to the
Transport Protocols
Chapter 3 SCTP

3-3
receiver, which allows the sender to probe for a change in buffer of the data receiver
by means of the acknowledgement message.
3.1.3 SCTP Functions
The functions of SCTP mainly include association startup and takedown, sequenced
delivery within streams, user data fragmentation, acknowledgement and congestion
avoidance, chunk bundling, packet validation and path management.
Association startup and takedown
SCTP is an association-oriented transmission protocol. Generally, data only can be
transmitted between two endpoints that have been established an association (SCTP
allows the data to be transmitted in certain steps during the startup of association).
Therefore, the startup and takedown of association are the preconditions for other
services.
Sequenced delivery within streams
SCTP can transport the datagrams in sequence. The datagrams sent in sequence
must be put in one stream, and the stream is the basis for sequenced transmission.
User data fragmentation
SCTP fragments and packets the user data on the SCTP layer by means of detecting
the path Maximum Transmission Unit (MTU), thus avoiding multiple times of
fragmentation and reassembly, and reducing the workload of IP layer of router.
Acknowledgement and congestion avoidance
Acknowledgement and retransmission are the basic methods to ensure the
transmission reliability. In SCTP, acknowledgement is also applied. Moreover,
congestion avoidance succeeds the window mechanism of TCP to perform
appropriate flow control.
Chunk bundling
If small sized user data carries large SCTP message header, the transmission
efficiency will be lowered much. In this case, the SCTP user can request bundling of
more than one user messages into a single SCTP packet, so as to improve the
utilization ratio of bandwidth.
Packet validation
Packet validation is the basis for SCTP to provide reliable transmission service. SCTP
uses the ADLER-32 algorithm to figure out a 32 bit checksum for user data, which will
be checked at the receiving end to see whether the checksum is the same, thus
judging whether the user data is broken.
Path management
Transport Protocols
Chapter 3 SCTP

3-4
The path management function monitors reachability through heartbeats when other
packet traffic is inadequate to provide this information and advises the SCTP user
when reachability of any far-end transport address changes.
From the above description, we can conclude the differences between SCTP and
TCP.
1) TCP is transmitted on the basis of character stream and its upper layer must
have its own delimitation mechanism. SCTP is transmitted on the basis of
datagram and needs no upper-layer demarcation.
2) SCTP supports the configuration of multiple IP addresses.
3) SCTP defines stream, within which the data is transmitted in sequence.
3.1.4 SCTP Implementation in CSCN
SCTP, as a transport layer protocol, is applied in CSCN as shown in Figure 3-1.
M3UA
MAC
IP
SCTP
BICC H.248 M3UA
MAC
IP
SCTP
BICC H.248

Figure 3-1 SCTP implementation in CSCN
In CSCN, the lower layer of SCTP is IP network, and its upper layer users include:
Adaptation module M3UA of SCN signaling in SIGTRAN protocol stack
BICC application protocol in BICC protocol stack
H.248 application protocol in H.248 protocol stack
3.2 SCTP Messages
SCTP messges are encapsulated in user data fields of IP packets. Table 3-1 lists the
major SCTP message types:
Table 3-1 SCTP messages
Message name Description
DATA The payload user data
INIT This chunk is used to initiate a SCTP association between two endpoints.
Transport Protocols
Chapter 3 SCTP

3-5
Message name Description
INIT ACK
The INIT ACK chunk is used to acknowledge the initiation of an SCTP
association.
SACK
This chunk is sent to the peer endpoint to acknowledge received DATA
chunks and to inform the peer endpoint of gaps in the received
subsequences of DATA chunks.
HEARTBEAT
An endpoint should send this chunk to its peer endpoint to probe the
reachability of a particular destination transport address defined in the
present association.
HEARTBEAT ACK
An endpoint should send this chunk to its peer endpoint as a response to
a HEARTBEAT chunk.
ABORT
The ABORT chunk is sent to the peer of an association to close the
association.
SHUTDOWN
An endpoint in an association MUST use this chunk to initiate a graceful
close of the association with its peer.
SHUTDOWN ACK
This chunk MUST be used to acknowledge the receipt of the
SHUTDOWN chunk at the completion of the shutdown process.
ERROR
An endpoint sends this chunk to its peer endpoint to notify it of certain
error conditions.
COOKIE ECHO
This chunk is used only during the initialization of an association. It is
sent by the initiator of an association to its peer to complete the
initialization process.
COOKIE ACK It is used to acknowledge the receipt of a COOKIE ECHO chunk.
SHUTDOWN
COMPLETE
This chunk is used to acknowledge the receipt of the SHUTDOWN ACK
chunk at the completion of the shutdown process

3.3 Message Procedures
SCTP serves as a connection-oriented protocol in the transport layer. Its process
includes: startup of association, takedown of association, transmission and validation
of data, congestion control mechanism, and path management mechanism.
I. Startup of Association
The startup of SCTP association is a four-way handshake process, which has four
message interactions: INIT, INIT ACK, COOKIE ECHO and COOKIE ACK, as shown
in Figure 3-2.
Transport Protocols
Chapter 3 SCTP

3-6
INIT(Tag_A)
T1-
init
INIT ACK(Tag_Z, connection information Z)
Endpoint A
Endpoint Z
T1-cookie
COOKIE ECHO(connection information Z)
+ DATA
COOKIE ACK+DATA + SACK
Established
Established
SACK
Italic items: optional information chunks
T3-rtx

Figure 3-2 Interaction during the startup of SCTP association
1) The initiating end of the association must create a data structure TCB
(Transmission Control Block) to describe the association (including the
fundamental information) to be initiated, and then send INIT message to the peer
end. In this message, the parameter usually carries one or multiple IP addresses
used by local end. If no IP address is carried, the peer end will take the source IP
address of the INIT message as the IP address of the end. In common header,
the Verification Tag field is set to 0, because the Tag of peer end is unknown.
In the message parameter, the Tag of local end and the expected
inbound/outbound stream numbers should be included. After sending, the timer
INIT is started, for waiting the INIT ACK message from peer end. If the timer
timeouts, the INIT message will be resent till the maximum retransmission time is
reached. After such actions, the sender enters COOKIE-WAIT status.
2) Upon receiving the INIT message, the receiver of the association will generate a
Tag, which will act as the initial Tag of the local end and will be put into the
parameter of INIT ACK message. Then a TCB will be generated according to the
basic information of association. However, this TCB is a temporary TCB. After
the TCB is generated, the mandatory information in it (including the time stamp
and life period of COOKIE) and the secret key in local end are calculated into a
32-bit MAC (Message Authentication Code) through the algorithm described in
RFC2401 (this calculation is irreversible). After that, the mandatory information
and the MAC are combined into a parameter called STATE COOKIE, which is
included in the INIT ACK message. The Verification Tag in INIT ACK message is
set to the initial Tag value in INIT message. The INIT ACK message usually
carries the information such as the IP address used by local end,
inbound/outbound streams. When the INIT ACK message is sent to the peer end,
the temporary TCB is deleted (then the receiver does not reserve any resources
for this association).
3) When the initiating end of the association receives the INIT ACK message, the
INIT timer will be stopped. Its own TCB will be updated, and the information
obtained from INIT ACK will be filled in. then COOKIE ECHO message will be
Transport Protocols
Chapter 3 SCTP

3-7
generated to carry back the STATE COOKIE in the INIT ACK message. The
timer COOKIE is started, and the status is changed into COOKIE-ECHOED.
4) After receiving the COOKIE ECHO message, the receiver of the association will
perform COOKIE check. The TCB in the STATE COOKIE and the local secret
key will be calculated into an MAC, according to the MAC algorithm described in
RFC2401. This MAC will be compared with that in the STATE COOKIE message.
If they are different, this message will be discarded. If they are identical, the time
stamp in the TCB will be taken out to compare with the current time. If the time
has exceeds the life time of COOKIE, the message will be discarded, otherwise,
an association to the peer end will be set up according to the information in TCB.
The status will be changed into ESTABLISHED, and COOKIE ACK message will
be sent back.
5) Upon receiving the COOKIE ACK message, the initiating end of the association
will stop the timer COOKIE, and the status will be changed into ESTABLISHED.
So the startup of association is finished.
II. Termination of Association
SCTP association can be terminated in two ways: One is GRACEFUL close, the other
is UNGRACEFUL close. Just as their names imply, the former means that all data in
queue by either endpoint is delivered to the respective peers before the association is
shut down. The latter means that the association is directly aborted and the data is
directly discarded.
GRACEFUL close
GRACEFUL close of association is implemented through three-way handshake:
1) Firstly, the user at the initiating end of the termination sends a GRACEFUL
request to SCTP for terminating the association. Then SCTP association is
changed from the ESTABLISHED status to the SHUTDOWN-PENDING status,
in which SCTP will no longer accept any requests from upper layer for data
transmission on this association. At the same time, the association will wait for
the validation of all the data sent from local end but has not been validated yet.
2) When all the data has been validated, SHUTDOWN message will be sent to the
peer end. The association will be changed into SHUTDOWN-SENT status, and
the SHUTDOWN timer will be started to wait for the SHUTDOWN-ACK message
from peer end. In this status, the data received from peer end will be validated
immediately (the slowdown validation mechanism of SCTP application will be
introduced in the following part).
3) When the peer end receives the SHUT DOWN message, it will enter the
SHUTDOWN-RECEIVED status, in which SCTP will no longer accept any
requests from upper layer for data transmission on this association. When all the
un-transmitted data and un-validated data sent from local end has been sent and
Transport Protocols
Chapter 3 SCTP

3-8
validated, the SHUTDOWN ACK message will be sent. The SHUTDOWN timer
will be started to wait for the SHUTDOWN COMPLETE message.
4) Upon receiving the SHUTDOWN ACK message, the initiating end of the
termination will stop the SHUTDOWN timer, send the SHUTDOWN COMPLETE
message to the peer end, and then delete the TCB of the association.
5) The peer end deletes the TCB of association after it receives the SHUTDOWN
COMPLETE message.
UNGRACEFUL close
Since this close mode does not care for the security of the data, it is relatively simple.
When the initiating end sends an ABORT message to the peer end, the TCB of
association will be deleted immediately. When the peer end receives the ABORT
message, it will delete the TCB of the association immediately.
Transport Protocols
Chapter 4 M3UA

4-1
Chapter 4 M3UA
4.1 Overview
Signaling System No. 7 MTP3-User Adaptation layer (M3UA) is the user adaptation
protocol of the Signaling Transport (SIGTRAN) protocol stack. M3UA provides primitive
communication service for MTP3 users over IP network and MTP3 (in a signaling
gateway) at the edge of a network, so as to implement interworking between TDM SS7
and IP.
4.1.1 Brief Introduction of SIGTRAN
SIGTRAN stack is the protocol stack that supports transmission of Switched Circuit
Network (SCN) signaling through IP network. This protocol stack supports the
inter-layer standard primitive interface defined in SCN signaling protocol hierarchy
model, so as to ensure utilization of the existing SCN signaling application without
modification. It also uses the standard IP transport protocol as the transmission bottom
layer, and satisfies the special transmission requirements of SCN signaling through
adding its own functions.
The SIGTRAN protocol stack is responsible for the communication between the
Signaling Gateway and the Media Gateway Controller. It has two functions: adaptation
and transmission. Accordingly, two layers of protocols are included in the SIGTRAN
protocol stack, that is,, transmission protocols (such as SCTP/IP) and adaptation
protocols (such as M3UA, IUA). Figure 4-1 illustrates the model.
IP
SCTP
M3UA M2UA IUA SUA M2PA V5UA
MAC

M3UA: MTP3-User Adaptation Layer M2UA: MTP2-User
Adaptation Layer
IUA: ISDN User Adaptation Layer
M2PA: MTP2 Peer Adaptation Layer V5UA: V5 User Adaptation
Layer
SUA: SCCP User Adaptation Layer
SCTP: Stream Control Transmission
Protocol
IP: Internet Protocol MAC: Media Access Control
Figure 4-1 SIGTRAN protocol model
Transport Protocols
Chapter 4 M3UA

4-2
SCTP is introduced in this model for the purpose of ensuring reliable transmission
since the SIGTRAN stack only achieves adaptation and transmission of SCN signaling
over IP network, leaving user layer signaling messages unchanged.
The SIGTRAN protocol stack used in CSCN consists of the MAC, IP, SCTP and M3UA.
Its protocols under the network layer (MAC, IP) are the standard TCP/IP protocols.
4.1.2 Introduction of M3UA
M3UA (MTP3 User Adaptation) protocol supports the transport of any SS7 MTP3-User
signaling (for example,, ISUP and SCCP messages) over IP using the services of the
Stream Control Transmission Protocol. Also, provision is made for protocol elements
that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains.
This protocol would be used between a Signaling Gateway (SG) and a Media Gateway
Controller (MGC) or IP-resident Database, or between two IP-based applications.
SEP MGC
ISUP
MTP3
MTP2
MTP1
ISUP
M3UA
SCTP
IP
M3UA
SCTP
IP
MTP2
MTP1
SS7 SIGTRAN
SG
PSTN IP
MTP3
NIF

Figure 4-2 SEP accesses MGC in the IP network through M3UA
SEP: Signaling endpoint; SG: Signaling gateway; MGC: Media gateway controller
As illustrated above, in the SIGTRAN protocol stack, M3UA runs on top of SCTP and is
the SCTP user. The upper layer user of M3UA at the MGC side is ISUP (MTP 3 User),
and is NIF at the SG side.
The M3UA layer can also be used for point-to-point signaling between two IP Server
Processes (IPSPs). In this case, the M3UA layer provides the same set of primitives
and services at its upper layer as the MTP3.
Transport Protocols
Chapter 4 M3UA

4-3
IP
MGC
MGC
User
M3UA
SCTP
IP
User
M3UA
SCTP
IP

Figure 4-3 MGC-MGC peer communication using M3UA
4.1.3 Terminology
Application Server (AS)
A logical entity serving a specific Routing Key. An example of an Application Server is a
virtual switch element handling all call processing for a unique range of PSTN trunks,
identified by an SS7 SIO/DPC/OPC/CIC_range.
Application Server Process (ASP)
A process instance of an Application Server.
Association
An association refers to an SCTP association. The association provides the transport
for the delivery of MTP3-User protocol data units and M3UA adaptation layer peer
messages.
IP Server Process (IPSP)
A process instance of an IP-based application. An IPSP is essentially the same as an
ASP, except that it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does
not use the services of a Signaling Gateway node.
Signaling Gateway (SG)
An SG is a signaling agent that receives/sends SCN native signaling at the edge of the
IP network. An SG appears to the SS7 network as an SS7 Signaling Point.
Signaling Gateway Process (SGP)
A process instance of a Signaling Gateway.
Stream
A stream refers to an SCTP stream; a unidirectional logical channel established from
one SCTP endpoint to another associated SCTP endpoint, within which all user
messages are delivered in-sequence except for those submitted to the unordered
delivery service.
Following new terminologies have been introduced in M3UA as implemented in CSCN:
Transport Protocols
Chapter 4 M3UA

4-4
M3UA Link
M3UA Linkset
M3UA Route
M3UA Entity
These concepts have enhanced the functionality provided by the protocol in the
following manner:
1) The concept of M3UA Route has been introduced to apply in large-scale networks.
Two M3UA entities separated by large geographical distances can access each
other using M3UA Route.
2) It helps in easy understanding of the network, which leads to better network
planning.
3) It also helps users to configure M3UA faster as all these concepts are compatible
with MTP3 concepts.
SGP1
SGP2
SGP3
SGP1
SGP2
SGP3
SG1
SG2
MGC
M3UA link set
M3UA route
SP
ASP1
ASP2
ASP3
M3UA link
M3UA entity MTP link

Figure 4-4 Relationship among M3UA Link, Linkset, Route and Entity
These concepts are valid for both SGP-ASP and IPSP-IPSP model.
I. Introduction of M3UA Link
The relationship between SGP-ASP and IPSP-IPSP established through SCTP
association is called M3UA LINK. The home terminal attribute of M3UA LINK can be
SGP, ASP or IPSP. M3UA link can be in one of the following states:
M3UA_LINK_UNESTABLISH, M3UA_LINK_DOWN, M3UA_LINK_INACTIVE and
M3UA_LINK_ACTIVE.
The management of M3UA link state is same to that of ASP or SCTP state.
Transport Protocols
Chapter 4 M3UA

4-5
M3UA_LINK_UNESTABLISH: When M3UA at client end has not established an SCTP
association to peer node or M3UA at server end has not received the indication of
SCTP association established successfully, the M3UA LINK state is
M3UA_LINK_UNESTABLISH.
M3UA_LINK_DOWN: When M3UA at ASP/IPSP (client end) has not received ASP UP
ACK message or M3UA at SGP/IPSP (server end) have not received ASP UP message
after SCTP association has been successfully established, M3UA LINK state is
M3UA_LINK_DOWN. When M3UA LINK state in this state, it can send and receive
ASPSM (ASP UP,ASP DOWN,ASP UP ACK,ASP DOWN ACK), but can not send and
receive any ASPTM (ASP ACTIVE, ASP ACTIVE ACK, ASP INACTIVE, ASP
INACTIVE ACK), SSNM (NOTIFY, ERROR) and DATA message.
M3UA_LINK_INACTIVE: When M3UA LINK is in M3UA_LINK_DOWN state, and if
M3UA layer at ASP/IPSP (acting as client) receives ASP UP ACK or M3UA at
SGP/IPSP (server end) has received ASP UP, the M3UA LINK state becomes
M3UA_LINK_INACTIVE. When M3UA LINK is in M3UA_LINK_ACTIVE state, and if
M3UA Layer at ASP/IPSP (acting as client) receives ASP INACTIVE ACK or ASP
INACTIVE, then also M3UA LINK state changes to M3UA_LINK_INACTIVE. In this
state, M3UA can send all non-data message, such as ASPSM, ASPTM, SSNM.
M3UA_LINK_ACTIVE: When M3UA LINK is in M3UA_LINK_INACTIVE state, and
M3UA layer at ASP/IPSP (acting as client) receives ASP ACTIVE ACK or ASP ACTIVE,
M3UA LINK state changes to M3UA_LINK_ACTIVE. In this state, M3UA can send all
message, include both non-data message and data message, such as ASPSM,
ASPTM, SSNM, and DATA.
M3UA_LINK_
INACTIVE
M3UA_LINK_
UNESTABLISH
M3UA_LINK_DOWN
Asp Inactive/Asp Inactive Ack/
Asp Alt Notify
Asp Active/Asp Active Ack
M3UA backout successful/Sctp-CDI
M3UA_LINK_ACTIVE
SCTP-RI
Asp Down or
Asp Down Ack
or SCTP-RI
SCTP-CDI
SCTP
CDI
M3UA establish successful
Asp Up or
Asp Up Ack

Figure 4-5 M3UA Link State Transition
Transport Protocols
Chapter 4 M3UA

4-6
II. Introduction of M3UA Linkset
M3UA LINKSET is made up of all the M3UA links between SG and MGC (SGP-ASP) or
between MGC and MGC (IPSP-IPSP) that serve the same AS. The state of the links in
any Linkset decides the state of the M3UA Linkset.
There are three kinds of M3UA Linkset states at ASP/IPSP (at client end):
M3UA_LINKSET_DOWN, M3UA_LINKSET_INACTIVE and
M3UA_LINKSET_ACTIVE.
While there are four kinds of M3UA Linkset states in SGP/IPSP (at server end):
M3UA_LINKSET_DOWN, M3UA_LINKSET_INACTIVE, M3UA_LINKSET_ACTIVE
and M3UA_LINKSET_PENDING.
The management of M3UA Linkset state is same to that of AS state.
M3UA_LINKSET_DOWN: M3UA Linkset is said to be in DOWN state if all the links in
the given Linkset are in either M3UA_LINK_DOWN or M3UA_LINK_UNESTABLISH
state.
M3UA_LINKSET_INACTIVE: M3UA Linkset is said to be in INACTIVE state if all the
links in the given Linkset are in either M3UA_LINK_ INACTIVE state and at the same
time none of the link is in M3UA_LINK_ACTIVE state in the M3UA Linkset.
M3UA_LINKSET_ACTIVE: M3UA Linkset is said to be in ACTIVE state if all the links in
the given Linkset are in either M3UA_LINK_ACTIVE state.
M3UA_LINKSET_PENDING: When the last link in a given Linkset whose previous
state was M3UA_LINK_ACTIVE changes to M3UA_LINK_INACTIVE or
M3UA_LINK_DOWN or M3UA_LINK_UNESTABLISH, the M3UA Linkset state
becomes M3UA_LINKSET_PENDING.
This Linkset state can only be valid in SGP/IPSP (act as server). When Linkset state
becomes M3UA_LINKSET_PENDING, it should start a PENDING timer and assign a
PENDING buffer to save the data. At this time, if there are some service data to peer
M3UA, it should send the service data to PENDING buffer. If any link in the given
Linkset becomes ACTIVE again before PENDING timer expires, M3UA Linkset state
changes from M3UA_LINKSET_PENDING to M3UA_LINKSET_ACTIVE, it gets the
service data from PENDING buffer, and sends it to peer M3UA in ordered sequence. If
PENDING timer expires before any M3UA link becomes M3UA_LINK_ACTIVE, the
SGP M3UA stops queuing messages and discards all previously queued messages.
The M3UA LINKSET state will move to the M3UA_LINKSET_INACTIVE state if at least
one M3UA link is in ASP-INACTIVE state, otherwise it will move to
M3UA_LINKSET_DOWN state.
Transport Protocols
Chapter 4 M3UA

4-7
one link
state
change
to inactive
M3UA_LINKSET
-DOWN
one link change
to ACTIVE
all of the
link state
in the
linkset
become
to down
all of the link state in the
linkset become to down
when pending timer expire
at least one link
state in the
linkset become to
inactive when
pending timer
expire
The last active
link in linkset
change to down
or inactivetraffic
mode is
over-ride mode)
one link
state
change
to active
The last active link in linkset
change to inactivetraffic mode
is load-share mode
all the link in
linkset change to
downtraffic mode
is load-share mode
M3UA_LINKSET
-INACTIVE
M3UA_LINKSET
-PENDING
M3UA_LINKSET
-ACTIVE

Figure 4-6 M3UA Linkset State Transition
III. Introduction of M3UA Route
The path from source entity to destination entity is called a M3UA route. One M3UA
route corresponds to one M3UA Linkset at the home terminal. In ASP or IPSP (client)
side, usually there is only one route from a local entity to a special destination entity. But
in SGP or IPSP (server) side, there may be more than one route from a local entity to a
special destination entity. There can be two route states:
M3UA_ROUTE_AVAILABLE and M3UA_ROUTE_UNAVAILABLE.
In IPSP-IPSP model, M3UA route state entirely depends on M3UA LINKSET state.
In SGP-ASP network model, M3UA ROUTE state maintained in SGP M3UA entirely
depends on M3UA LINKSET state and M3UA ROUTE state maintained in ASP M3UA
depends on both M3UA LINKSET state and the route state from SG to SS7 network
signaling point.
M3UA_ROUTE_AVAILABLE: In SGP/IPSP (act as server), if M3UA Linkset state
related to the M3UA ROUTE is M3UA_LINKSET_ACTIVE or
M3UA_LINKSET_PENDING, the corresponding route state is
M3UA_ROUTE_AVAILABLE. In ASP/IPSP (act as client), if M3UA Linkset state related
to the M3UA ROUTE is M3UA_LINKSET_ACTIVE and it can access SS7 network
signaling point through SG, the corresponding M3UA route state is also
M3UA_ROUTE_AVAILABLE.
M3UA_ROUTE_UNAVAILABLE: In SGP/IPSP (act as server) M3UA, if M3UA Linkset
state related to the M3UA ROUTE is neither M3UA_LINKSET_ACTIVE nor
M3UA_LINKSET_PENDING, the corresponding route state is
Transport Protocols
Chapter 4 M3UA

4-8
M3UA_ROUTE_UNAVAILABLE. In ASP/IPSP (act as client), if M3UA Linkset state
related to the M3UA ROUTE is not M3UA_LINKSET_ACTIVE or it cannot access SS7
network signaling point through SG, the corresponding route state is also
M3UA_ROUTE_UNAVAILABLE.
M3UA_ROUTE_
AVAILABLE
M3UA_ROUTE_
UNAVAILABLE
linkset state
change to
ACTIVE or
PENDING
linkset state
change to
INACTIVE
or DOWN

Figure 4-7 M3UA ROUTE state transitions at SGP/IPSP (at server)
M3UA_ROUTE_
AVAILABLE
M3UA_ROUTE_
UNAVAILABLE
linkset state
change to
ACTIVE and
the route from
SG to SS7
signal point is
accessible
linkset state
change to
DOWN or
the route from
SG to SS7
signal point is
inaccessible

Figure 4-8 M3UA ROUTE state transitions at ASP/IPSP (at client)
IV. Introduction of M3UA Entity
The logical processing unit that accomplishes some special functions, such as AS, SP
or a logic unit that only implements special message transfer function, such as SG can
be classified as M3UA Entity. Each M3UA Entity is identified by a unique signaling point
code.
Incase all AS share the same point code then they are said to be in Inclusive SPC
mode and if all AS have different point codes then they are said to be in Exclusive SPC
mode. In other words, if one AS is servicing all the services related to one signaling one
point code then it is said to be in Exclusive mode, else its is in Inclusive mode.
Transport Protocols
Chapter 4 M3UA

4-9
If an AS is configured in Inclusive SPC mode, then M3UA Destination Service is
required to be added to identify traffic for that AS. In such cases a Routing Key
identifies each AS, which is a combination of SI and CIC range.
M3UA Entity further falls under two categories: M3UA Local Entity and M3UA
Destination Entity.
M3UA LOCAL ENTITY: The logical entity to accomplish special function in local side. In
ASP/IPSP M3UA, local entity is related to AS. In SGP M3UA, local entity is related to
SG.
M3UA DESTINATION ENTITY: The logic entity to accomplish special function in peer
side. In IPSP-IPSP model, the destination entity maintained by IPSP M3UA is related to
the peer AS. In SGP-ASP model, the destination entity maintained by SGP M3UA is
also related to peer AS; whereas the destination entity maintained by ASP M3UA can
SG or destination signaling point in SS7 network. There can be two destination entity
states:
M3UA_DEST_ENTITY_ACCESSIBLE and M3UA_DEST_ENTITY_INACCESSIBLE.
Its state depends on M3UA ROUTE state.
M3UA_DEST_ENTITY_ACCESSIBLE: If at least one route from local entity to
destination entity is Available, and then the corresponding M3UA DESTINATION
ENTITY state is M3UA_DEST_ENTITY_ACCESSIBLE.
M3UA_DEST_ENTITY_INACCESSIBLE:If all the routes from local entity to destination
entity are in M3UA_ROUTE_UNAVAILABLE state, then the corresponding M3UA
DESTINATION ENTITY state is M3UA_DEST_ENTITY_INACCESSIBLE.
M3UA_DEST_ENTITY_
ACCESSIBE
M3UA_DEST_ENTITY_
INACCESSIBLE
all of the
m3ua route
state to the
given dest
entity are
unavailable
At least one
of m3ua route
tothe given
dest entity
is available

Figure 4-9 M3UA DEST ENTITY state transition
M3UA SPMC: All the M3UA destination entities related to the same local entity consists
of a complete SPMC, if the OPC of local entity is same as DPC in M3UA destination
Transport Protocols
Chapter 4 M3UA

4-10
entity; the local entity is also a part of SPMC. SPMC is maintained only in SGP side.
There are two kinds of M3UA SPMC state:
M3UA_SPMC_ACCESSIBLE and M3UA_SPMC_INACCESSIBLE. Its state depends
on the state of destination entities belonging to that particular SPMC.
M3UA_SPMC_ACCESSIBLE: If at least one M3UA destination entity in the SPMC is
accessible, then the corresponding M3UA SPMC state is
M3UA_SPMC_ACCESSIBLE.
M3UA_SPMC_INACCESSIBLE: If all M3UA destination entities in the SPMC are
inaccessible, then the corresponding M3UA SPMC state is
M3UA_SPMC_INACCESSIBLE.
M3UA_SPMC_
ACCESSIBE
M3UA_SPMC_
INACCESSIBLE
all of the m3ua
dest entity state
in the SPMC
are inaccessiable
At least one of
m3ua dest entity
in the SPMC is
accessiable

Figure 4-10 M3UA SPMC State Transition
The relationships between M3UA Entity, M3UA Route, M3UA Linkset and M3UA Link
are shown in Figure 4-4. The M3UA destination entity can be reached through one or
more M3UA routes. Each M3UA route at home terminal corresponds to one M3UA link
set. Different routes implements signaling service load sharing according to the
user-defined M3UA routing mask and the SLS in the signaling message. Meanwhile,
different priorities can be set for each M3UA route. Therefore, in routing, the M3UA
route with a higher priority will be selected first. That is to say, the routing is based on
the priority. One M3UA link set is composed of one or more M3UA links. Each M3UA
link corresponds to one SCTP association. Different M3UA links employ two working
modes: active/standby mode or load-sharing mode. With load-sharing mode, different
M3UA links in the same link set can implement signaling service load-sharing
according to the user-defined routing mask and the SLS in the signaling message;
meanwhile, different priorities can be set for each M3UA link, and the M3UA link with a
higher priority in the same link set will be selected first.
Transport Protocols
Chapter 4 M3UA

4-11
4.1.4 M3UA Implementation in CSCN
Usage of M3UA with CSCN in 3G solutions is shown in Figure 4-11. The M3UA is used
to carry user-signaling information over IP domain.
GMLC/SMLC
BSS
UTRAN
HLR/EIR
MSC Server
GMSC server
SCP
SMS-C
SG
PSTN / ISDN
MGW MGW
RANAP
CAP
MAP
MAP
BICC
BSSAP
H.248
MAP
MAP / IP
AAL2
TDM
TDM/G.711
RTP(AAL2)/AMR
GSM / R99 PLMN
IP (ATM)
BackBone
SS7
SS7
ISUP / IP
ISUP
MAP
M3UA
M3UA
M3UA
M3UA
M3UA
M3UA
M3UA
M3UA
M3UA
M3UA
M3UA
M3UA

Figure 4-11 M3UA implementation in CSCN
At SG-MSOFTX3000 interface, M3UA carries SS7 user information, while at the Nc
interface M3UA is used to carry BICC signaling information. M3UA is also used to carry
MAP/IP signaling information. M3UA can also be used for Iu-CS interface and to carry
RANAP protocol.
4.1.5 Work Modes of M3UA in CSCN
In CSCN, the local attribute of M3UA link can be SGP, ASP or IPSP. M3UA can support
following two work modes:
Agent Mode
In agent mode SG and all AS have the same signaling point code and each AS has
different combination of CIC, SSN and SI. The destination entity is distinguished by the
combination of CIC, SSN and SI.
Transfer mode
In Transfer mode, AS and SG have the different signaling point code and each AS has
can have either a different signaling point code (AS in exclusive mode) or same
signaling point code (AS in inclusive mode). In this mode, SG have the STP
functionality, each AS can access destination signaling point in SS7 network through
more than one SG.
Transport Protocols
Chapter 4 M3UA

4-12
4.2 Message Structure
4.2.1 M3UA Message Format
The general M3UA message format includes a common message header followed by
zero or more variable length parameters.
I. Common Message Header
The protocol messages for MTP3-User Adaptation require a message structure, which
contains a version, message class, message type, message length, and message
contents. This message header is common among all signaling protocol adaptation
layers.
Version(8) Reserved(8)
Message Class(8)
Message Type(8)
Message Length(32)

II. Message Parameters
All the parameters contained in a message are defined in a Tag Length-Value format as
shown below.
Parameter Length (16)
Parameter Value(32)
Parameter Tag (16)

4.2.2 M3UA Messages
I. Management Messages
Table 4-1 Management messages
Message name Message description
Error The Error message is used to notify a peer of an error event associated with
an incoming message.
Notify The Notify message used to provide an autonomous indication of M3UA
events to an M3UA peer.

Transport Protocols
Chapter 4 M3UA

4-13
II. Transfer Messages
Table 4-2 Transfer message
Message
name
Message description
Data
The DATA message contains the SS7 MTP3-User protocol data, which is an
MTP-TRANSFER primitive, including the complete MTP3 Routing Label.

III. SS7 Signaling Network Management Messages
Table 4-3 SS7 Signaling Network Management messages
Message
name
Message description
DUNA
The DUNA message is sent from an SGP in an SG to all concerned ASPs to indicate
that the SG has determined that one or more SS7 destinations are unreachable.
DAVA
The DAVA message is sent from an SGP to all concerned ASPs to indicate that the SG
has determined that one or more SS7 destinations are now reachable (and not
restricted), or in response to a DAUD message if appropriate.
DAUD
The DAUD message is sent from the ASP to the SGP to audit the
availability/congestion state of SS7 routes from the SG to one or more affected
destinations.
SCON
The SCON message is sent from an SGP to all concerned ASPs to indicate that an SG
has determined that there is congestion in the SS7 network to one or more
destinations, or to an ASP in response to a DATA or DAUD message as appropriate.
DUPU
The DUPU message is used by an SGP to inform concerned ASPs that a remote peer
MTP3-User Part (for example,, ISUP or SCCP) at an SS7 node is unavailable.
DRST
The DRST message is sent from the SGP to all concerned ASPs to indicate that the SG
has determined that one or more SS7 destinations are now restricted from the point of
view of the SG, or in response to a DAUD message if appropriate.

IV. ASP State Maintenance Messages
Table 4-4 ASP State Maintenance messages
Message
name
Message description
ASP Up
The ASP Up message is used to indicate to a remote M3UA peer that the
Adaptation layer is ready to receive any ASPSM/ASPTM messages for all
Routing Keys that the ASP is configured to serve.
Transport Protocols
Chapter 4 M3UA

4-14
Message
name
Message description
ASP Down
The ASP Down message is used to indicate to a remote M3UA peer that the
adaptation layer is NOT ready to receive DATA, SSNM, RKM or ASPTM messages.
ASP Up Ack
The ASP UP Ack message is used to acknowledge an ASP Up message received
from a remote M3UA peer.
ASP Down
Ack
The ASP Down Ack message is used to acknowledge an ASP Down message
Received from a remote M3UA peer.

V. ASP Traffic Maintenance Messages
Table 4-5 ASP Traffic Maintenance messages
Message name Message description
ASP Active
The ASP Active message is sent by an ASP to indicate to a remote M3UA peer that it
is ready to process signaling traffic for a particular
Application Server.
ASP Inactive
The ASP Inactive message is sent by an ASP to indicate to a remote M3UA peer that
it is no longer an active ASP to be used from within a list of ASPs.
ASP Active Ack
The ASP Active Ack message is used to acknowledge an ASP Active message
received from a remote M3UA peer.

ASP Inactive
Ack
The ASP Inactive Ack message is used to acknowledge an ASP Inactive message
received from a remote M3UA peer.

4.2.3 Message Example
An example of M3UA messages is DATA that will be described in the following part to
help you to form an idea of the structure of M3UA messages.
The DATA message contains the SS7 MTP3-User protocol data, which is an
MTP-TRANSFER primitive, including the complete MTP3 Routing Label.
The DATA message contains the following variable length parameters:
Network Appearance Optional
Routing Context Optional
Protocol Data Mandatory
Correlation Id Optional
Transport Protocols
Chapter 4 M3UA

4-15
Tag = 0x0200
Tag = 0x0013
Tag = 0x0210
Tag = 0x0006
Length = 8
Length = 8
Length = 8
Length = 8
Protocol Data
Correlation Id
Routing Context
Network Appearance

Figure 4-12 M3UA DATA Message Format
The mandatory Protocol Data field contains the original SS7 MTP3 message, including
Service Information Octet and Routing Label.
User Protocol Data
Originating Point Code
Destination Point Code
SI NI MP SLS

Figure 4-13 M3UA Protocol Data Parameter
4.3 Message Procedures
I. Establishment Procedure
The following scenario in Figure 4-14 shows the example M3UA message flows for the
establishment of traffic between an SGP and an ASP or between two IPSPs. It is
assumed that the SCTP association is already set up.
Transport Protocols
Chapter 4 M3UA

4-16
SGP ASP
ASP UP
ASP UP ACK
AS INACTIVE NOTIFY
ASP ACTIVE
ASP ACTIVE ACK
AS ACTIVE NOTIFY

Figure 4-14 Establishment procedure of the M3UA service environment
Here ASP is the client, which will first send the request to establish the M3UA Link.
Once link is ready, all types of M3UA messages can be transmitted between the peers.
II. Data Transfer Procedure
When the M3UA layer on the ASP has a M3UA User message to be sent to the SG, it
will do the following:
1) Determine the correct Destination Entity.
2) If the destination Entity is Accessible, then get the Available route to that
destination entity.
3) Get an Active Linkset belonging to this Route.
4) Determine an Active Link in the given Linkset.
5) Determine whether to complete the optional fields of the DATA message.
6) Map the MTP-TRANSFER request primitive into the Protocol Data field of a DATA
message
7) Send the DATA message to the remote M3UA peer at the SGP, over the chosen
M3UA link.
Transport Protocols
Chapter 4 M3UA

4-17
MTP_TRANSFER
ASP
Choose the right
link and map
Transfer
primitive to
DATA message
SGP
DATA message

Figure 4-15 MTP_TRANSFER primitive handling at ASP
When the M3UA layer on the SG has a M3UA User message to be sent to the ASP, it
will do the following:
1) Determine the correct Destination Entity.
2) If the destination Entity is Accessible, then get the Available route to that
destination entity.
3) Get an Active Linkset belonging to this Route.
4) Determine an Active Link in the given Linkset.
5) Map the MTP-TRANSFER request primitive into the Protocol Data field of a DATA
message
6) Send the DATA message to the remote M3UA peer at the ASP, over the chosen
M3UA link.
Transport Protocols
Chapter 4 M3UA

4-18
MTP_TRANSFER
ASP
Choose the right
link and map
Transfer
primitive to
DATA message
SGP
DATA message

Figure 4-16 MTP_TRANSFER handling at SGP
III. Release Procedure
Release procedure of the M3UA service environment is illustrated in Figure 4-17 below:
SGP ASP
ASP INACTIVE
ASP INACTIVE ACK
AS PENDING NOTIFY
Pending Timer Expires
AS INACTIVE NOTIFY
ASP DOWN
ASP DOWN ACK
AS DOWN NOTIFY

Figure 4-17 Release procedure of the M3UA service environment
Transport Protocols
Chapter 4 M3UA

4-19
When the M3UA link needs to be withdrawn, the ASP will start the above procedure. At
the end of this procedure the SCTP association will be shut down.
T Protocols and Signaling Analysis
Transport Protocols
Chapter 5 SCCP

5-1
Chapter 5 SCCP
5.1 Overview
The Signaling Connection Control Part (SCCP) is one of the user parts in the
hierarchical architecture of the Signaling System No. 7, and resident at the functional
level 4. The SCCP also provides additional functions to the Message Transfer Part
(MTP) to cater for both connectionless as well as connection-oriented network
services to transfer circuit related and non-circuit related signaling information and
other types of information between exchanges and specialized centers in
telecommunication networks through a SS7 network, thus forming the network layer
of the OSI reference model.
5.1.1 SCCP Functions
The overall objectives of the SCCP are to provide the data information transfer means
for:
Logical signaling connections within the common channel signaling network;
A transfer capability for signaling data units with or without the use of logical
signaling connections.
Functions of the SCCP are also used for the transfer of circuit related and non circuit
related signaling information of the ISDN user part with or without setup of end-to-end
signaling connections.
5.1.2 SCCP Basic Services
The services provided by the SCCP can be grouped into four classes:
0: Basic connectionless class.
1: In-sequence delivery connectionless class.
2: Basic connection-oriented class.
3: Flow control connection-oriented class.
The classes 0 and 1 are connectionless services; the classes 2 and 3 are
connection-oriented services.
The connectionless services allow signaling information to be transferred through the
signaling network without setup of a signaling connection made. The SCCP
connectionless services are equivalent to data network data services. The class 0
Transport Protocols
Chapter 5 SCCP

5-2
service is without guaranteed in-sequence delivery of messages; the class 1 service
is with guaranteed in-sequence delivery of messages by means of SLS.
For the connection-oriented services, control information exchange is made between
the SCCPs before data transfer for the purpose of reaching a certain protocol where
the routing for data transfer, the service class to be transferred (basic
connection-oriented class or flow control connection-oriented class), and possibly the
quantity of the data to be transferred are included.
Connection-oriented services include temporary signaling connections and
permanent signaling connections.
Establishment of a temporary signaling connection is controlled by the service user.
The temporary signaling connection is similar to the connection of dialup telephones.
Permanent signaling connections are established and controlled by the local (or
remote) operation and maintenance function or by the management function of the
node and they are provided for the user on a semi-permanent basis, thus similar to
leased telephone lines. Connection-oriented described here refers to the temporary
signaling connection.
5.1.3 SCCP Implementation in CSCN
The SCCP provides the transfer service for multiple application protocols of CSCN,
as shown in Figure 5-1.
SCCP
TCAP
ISUP
SCTP
IP
MAC
MTP3
MTP2
MTP1
MTP3b
SSCF-NNI
SSCOP
ATM
M3UA
BSSAP BSSAP+ RANAP
MAP CAP
SCCP
TCAP
ISUP
SCTP
IP
MAC
MTP3
MTP2
MTP1
MTP3b
SSCF-NNI
SSCOP
ATM
M3UA
BSSAP BSSAP+ RANAP
MAP CAP

Figure 5-1 SCCP in CSCN protocol system
The SCCP exists in CSCN to serve as the intermediate layer for transferring
messages. Its upper-layer users are ISUP, BSSAP, BSSAP+, RANAP and TCAP;
according to the transfer media, its lower-layer protocols are MTP3, M3UA and
MTP3b.
SCCP messages are processed at the WCCU board of CSCN.
Transport Protocols
Chapter 5 SCCP

5-3
SCCP message is a kind of message signal unit (MSU) of SS7. Its message contents
are contained in the signaling information field (SIF) of the MSU. A SCCP message is
identified by the SI coded 0011 contained in the service information octet (SIO) of the
MSU. See Figure 5-2.
The routing label in Figure 5-2 has been introduced in Section MTP. 8-bit coding is
used for the variety of message types. Each code identifies one SCCP message.
Those parameters that are mandatory and of fixed length for a particular message
type are contained in the mandatory fixed part; those mandatory parameters of
variable length are included in the mandatory variable part. A particular message
may also consist of an optional part. The optional parameters may be of fixed length
or variable length. For those mandatory variable parameters, pointers are used to
indicate their location. For the optional parameters, the beginning of each parameter
should be indicated, and the code and the length of each parameter should be given.
Transport Protocols
Chapter 5 SCCP

5-4
DPC
OPC
SLS
Message t ype
Point t o paramet er M
Point t o paramet er P
Point t o st art bit of
opt ional paramet er
Lengt h of paramet er M
Paramet er M
Lengt h of paramet er P
Paramet er P
Code of paramet er X
Lengt h of paramet er X
Paramet er X
Code of paramet er Z
Lengt h of paramet er Z
Paramet er Z
0 0 0 0 0 0 0 0
7 6 1 0
0 0 0 0 0 0 0 0
bit
BI B BSN
FI B FSN
LI
Sub-service f ield SI
SI F
ck
0 1 1 1 1 1 1 0
Mandat ory paramet er A
wit h f ixed lengt h

Mandat ory paramet er B
wit h f ixed lengt h
Mandat ory paramet er B wit h f ixed lengt h

Figure 5-2 Format for SCCP messages
5.2.1 SCCP Message Types
Transmission of various SCCP messages is required in the implementation of a
SCCP function and procedure, such as the process of conveying data signaling units
with or without setup of logical signaling connections. SCCP messages are grouped
into connectionless service messages and connection-oriented service messages.
The SCCP messages and their corresponding protocol class and code are shown in
Table 5-1.
Transport Protocols
Chapter 5 SCCP

5-5
Table 5-1 SCCP messages
Protocol class
Message type 0 1 2 3 Code
CR Connection request 00000001
CC Connection confirm 00000010
CREF Connection refused 00000011
RLSD Released 00000100
RLC Release complete 00000101
DT1 Data form 1 00000110
DT2 Data form 2 00000111
AK Data acknowledgement 00001000
UDT Unitdata 00001001
UDTS Unitdata service 00001010
ED Expedited data 00001011
EA Expedited data acknowledgement 00001100
RSR Reset request 00001101
RSC Reset confirm 00001110
ERR Protocol data unit error 00001111
IT Inactivity test 00010000
x: The message can be used in the corresponding protocol class.

The meaning of some major message types is described as follows:
CR and CC messages are used for the setup of a signaling connection.
During the setup of a signaling connection, an intermediate node SCCP or the
destination node SCCP may have no enough resources to establish the signaling
connection, and thus a CREF message is initiated to the originating node.
DT1, DT2 and ED messages are used to carry the data after the signaling connection
is established. The DT1 serves for the protocol class 2, and the DT2 and the ED
serve for the protocol class 3. In addition, the DT2 and ED must be acknowledged by
a AK and a EA respectively.
RLSD and RLC messages are used to release the signaling connection after data
transmission is completed.
RSR and RSC messages are used to re-initialize the sequence numbers of the data
during the data transfer phase in the protocol class 3.
Transport Protocols
Chapter 5 SCCP

5-6
A ERR message is sent on detection of any protocol errors. A IT message is used to
check if the signaling connection is active at both ends.
UDT, XUDT, UDTS and XUDTS are connectionless service messages. UDT and
XUDT are used to transfer the data of the connectionless services. If the UDT
and XUDT fail to be delivered to the destination due to some cause and the
cause has to be returned required by the UDT and XUDT, a UDTS or XUDTS
message is used to indicate to the originating node what is the exact cause.
5.2.2 SCCP Message Parameters
Parameters are required to provide a variety of information to implement any function
of SCCP messages For instance, a Connection Request message must have the
parameter called party address, thus accessing the called party and completing the
signaling connection. Another example is a Protocol Data Unit Error message that
must contain the parameter error cause in order to indicate what is the exact
protocol error. If a parameter must occur in a particular message, the parameter is
called the mandatory parameter (M) of this particular message. There are two kinds
of mandatory parameters: mandatory parameter of fixed length (F) and mandatory
parameter of variable length (V). If a parameter may or may not occur in a particular
message type, the parameter is called an optional parameter (O) of the message. In
addition, some parameters may be mandatory for a certain message while optional
for another message. Therefore, a parameter cannot be treated invariably as a
mandatory one or optional one; it is subject to the specific message. The parameters
used in the SCCP messages are listed in Table 5-2.
Table 5-2 SCCP message parameters
Parameter name Code
End of optional parameters 00000000
Destination local reference 00000001
Source local reference 00000010
Called party address 00000011
Calling party address 00000100
Protocol class 00000101
Segmenting/reassembling 00000110
Receive sequence number P(R) 00000111
Sequencing/segmenting 00001000
Credit 00001001
Release cause 00001010
Transport Protocols
Chapter 5 SCCP

5-7
Parameter name Code
Return cause 00001011
Reset cause 00001100
Error cause 00001101
Refusal cause 00001110
Data 00001111

The meaning of the parameters in Table 5-2 is described as follows:
The destination local reference and the source local reference uniquely determine
a signaling connection.
The called party address and the calling party address are used to identify the
originating/destination signaling point and (or) the SCCP service access point.
The protocol class defines the four classes of protocols used for connectionless
services and connection-oriented services.
If the length of the network service data unit (NSDU) exceeds the maximum length
allowed by the message transferred as data, it is required to segment one network
service data for deliver individually. After reaching the destination, the segments will
be reassembled. The purpose of the segmenting/reassembling parameter is to
achieve this. This parameter is only used in DT1 messages.
The receive sequence number P(R) parameter indicates the sequence number of
the next expected message. The parameter is used in DT2 and AK messages in the
protocol class 3, for the purpose of acknowledging that the remote node has already
received all the messages before P(R)-1.
The comprehensive sequencing/segmenting parameter consists of the
segmenting/reassembling, the send sequence number" P(S) and the receive
sequence number P(R). The send sequence number should be in the range of the
window value specified by the protocol, in order to implement flow control in the
protocol class 3.
The credit parameter is used in CR and CC messages to determine how many
messages can be sent by the signaling connection sending part, that is, signaling
connection window size, for achieving flow control of the protocol class 3. During the
data transfer phase, the credit in the AK message can modify the window.
The release cause", the reset cause and the refusal cause are used to
respectively indicate the reason why the signaling connection was release, reset, or
refused. The error cause is used in the ERR message in order to indicate what is
the exact error. The return cause is used in the UDTS or XUDTS message of a
Transport Protocols
Chapter 5 SCCP

5-8
connectionless service to indicate the reason why the UDT or XUDT message failed
to be delivered to the destination.
The data parameter contains the network service data (NSD) to be delivered to the
destination by the user.
5.2.3 Examples of Parameter Formats and Codes
Address: The called/calling party address is a variable length parameter. Its structure
is shown in Figure 5-3.
Address indicator
Address
Address indicator
Address

Figure 5-3 Structure of address
I. Address Indicator
The address indicator indicates the type of address information contained in the
address field. See Table 5-3.
Table 5-3 Address indicator
7 6 5 4 3 2 1 0 Bi
t
Reserved Routing
indicator
Global title indicator SSN
indicator
Point
code
indicator

Bit 0: 1 indicates the address contains a signaling point code.
0 indicates that the address does not contain a signaling point code.
Bit 1: 1 indicates that the address contains a subsystem number.
0 indicates that the address does not contain a subsystem number.
Bits 5-2 contain the global title indicator, which is encoded as follows:
0000 No global title included.
0001 Global title includes nature of address indicator only.
0010 Global title includes translation type only.
Transport Protocols
Chapter 5 SCCP

5-9
0011 Global title includes translation type, numbering plan and encoding
scheme.
0100 Global title includes translation type, numbering plan, encoding scheme
and nature of address indicator.
Spare international
Spare national
0 1 0 1
0 1 1 1
1 0 0 0
1 1 1 0
~
~ Spare international
Spare national
0 1 0 1
0 1 1 1
1 0 0 0
1 1 1 0
~
~

II. Reserved for Extension
Bit 6: 0 indicates that routing is based on the global title contained in the address;
1 indicates that routing is based on the destination point code contained in the MTP
routing label and the subsystem number contained in the called party address
(DPC+SSN).
Bit 7 reserved for national use.
III. Address
The various elements, when provided, occur in the order: destination point code,
subsystem number, global title, as shown in Figure 5-4.
DPC
SSN
GT

Figure 5-4 Ordering of address elements
Destination point code (DPC)
Reference the DPC part in Section MTP.
Subsystem number (SSN)
The subsystem number identifies an SCCP user function and, when provided,
consists of one octet coded as follows:
Bits: 76543210
00000000 SSN not known
Transport Protocols
Chapter 5 SCCP

5-10
00000001 SCCP management
00000010 reserved
00000011 ISDN user part
00000100 OMAP (Operation, Maintenance and Administration Part)
00000101 MAP (Mobile Application Part)
00000110 HLR (Home Location Register)
00000111 VLR (Visitor Location Register)
00001000 MSC (Mobile Switching Center)
00001001
~ Idle
11111110
00001001
~ Idle
11111110

11111111 reserved for expansion
Global title (GT)
The format of the global title is of variable length. The following part describes one of
the four possible formats for global title.
Global title indicator = 0001
Figure 5-5 shows the format of the global title, if the global title indicator equals 0001.
O/E
Nature of address
indicator
Address information
Figure 5-5 Global title format for indicator 0001
If the global title indicator equals 0001, the bits 6~0 of the octet 1 contain the Nature
of Address Indicator (NAI) and are coded as follows:
Bits 6~0:
0000000 idle
0000001 subscriber number
0000010 reserved for national use
0000011 national significant number
0000100 international number
Transport Protocols
Chapter 5 SCCP

5-11
00000101
~ Idle
11111111
00000101
~ Idle
11111111

Bit 7 contains the odd/even indicator and is coded as follows:
0: even number of address signals
1: odd number of address signals
If the global title indicator equals 0001, the octets 2 and further contain a number of
address signals as shown in Figure 5-6.
2nd address signal 1st address signal

Filler 0 (if necessary) nth address signal
Figure 5-6 Address information
Each address signal is coded as follows:
0000 digit 0
0001 digit 1
0010 digit 2
0011 digit 3
0100 digit 4
0101 digit 5
0110 digit 6
0111 digit 7
1000 digit 8
1001 digit 9
1010 spare
1011 code 11
1100 code 12
1101 spare
1110 spare
Transport Protocols
Chapter 5 SCCP

5-12
1111 ST
In case of an odd number of address signals, a filler code 0000 is inserted after the
last address signal.
Protocol class and return selection
The protocol class is used to define the service class of the SCCP. During the
signaling connection setup phase, the protocol class field is required and is
negotiated between the SCCP peers.
The protocol class is a 4-bit parameter.
Bits 3210
0000 class 0
0001 class 1
0010 class 2
0011 class 3
When the bits 0-3 are coded to indicate a connection-oriented protocol class (class 2,
class 3), the bits 4-7 are spare.
When the bits 0-3 are coded to indicate a connectionless protocol class (class 0,
class 1), the bits 4-7 are coded as follows:
Bits 7654
0000 no special options
0001
to spare
0111
1000 return message on error
1001
to spare
1111
5.2.4 Format Components of SCCP Messages
The format and the parameters used for SCCP messages have been described in the
above sections. Each SCCP message consists of several parameters including the
mandatory part and possibly optional part. The corresponding parameters constituting
each message are shown in Table 5-4.
Transport Protocols
Chapter 5 SCCP

5-13
Table 5-4 Inclusion of parameters in SCCP messages
Parameter
C
R
C
C
CR
EF
RL
SD
RL
C
DT
1
DT
2
A
K
E
D
E
A
RS
R
RS
C
ER
R
I
T
UD
T
UD
TS
Destination local
reference
M M M M M M M M M M M M M
Source local
reference
M M M M M M M
Called party
address
M o o M M
Calling party
address
o M M
Protocol class M M M
Segmenting/reass
embling
M
Receive sequence
number
M
Sequencing/segm
enting
M M
Credit M M
Release cause M
Return cause
Reset cause M
Error cause M
User data o o o o M M M
Refusal cause M
End of optional
parameters
o o o o
m: mandatory parameter (including fixed length part and variable length part)
o: optional parameter

The constitution of messages is illustrated by the following examples.
Connection Request (CR) message
The CR message contains:
Routing label
Message type code
Two pointers
The parameters are indicated in Table 5-5.
Transport Protocols
Chapter 5 SCCP

5-14
Table 5-5 CR message parameters
Parameter Type (F V O) Length (octets)
Source local reference F 3
Protocol class F 1
Called party address V 3 (minimum)
Credit 0 3
Calling party address 0 4 (minimum)
Data 0 3-130
End of optional parameters 0 1

1) Unitdata (UDT) message
The UDT message contains:
Routing label
Message type code
Three pointers
Table 5-6 UDT message parameters
Protocol class F 1
Calling party address V 2 (minimum)
Data V 2-X
X: variable.

2) Unitdata service (UDTS) message
The UDTS message contains:
Routing label
Message type code
Three pointers
Table 5-7 UDTS message parameters
Return cause F 1
Transport Protocols
Chapter 5 SCCP

5-15
Data V 2-X
X: variable.

Reference Q.713 Recommendation for other messages.
3) Extended unitdata (XUDT) message
The XUDT message contains:
Routing label
Message type code
Four pointers
Table 5-8 XUDT message parameters
Protocol class F 1
Data V 2-X
Optional O 6
X: variable.

4) Extended unitdata service (XUDTS) message
The XUDTS message contains:
Routing label
Message type code
Four pointers
Table 5-9 XUDTS message parameters
Return cause F 1
Transport Protocols
Chapter 5 SCCP

5-16
Data V 2-X
Optional O 6
X: variable.

Transport Protocols
Chapter 6 TCAP

6-1
Chapter 6 TCAP
6.1 Overview
The term Transaction Capabilities (TC) refers to a set of communication capabilities
that provide an interface between applications and a network layer service.
Transaction capabilities provide specific application irrelevant functions and
procedures to a large variety of applications distributed over switches and specialized
centers in telecommunication networks. The Transaction Capabilities Application Part
(TCAP) uses SCCP-supported addressing mode and is based on connection-oriented
and connectionless services of the SCCP. A TCAP process is divided into the
component sub-layer process and the transaction sub-layer process as shown in
Figure 6-1.
TC user
Component sub-layer
Transaction sub-layer
SCCP
TC user
Component sub-layer
Transaction sub-layer
SCCP

Figure 6-1 Structure of TC
I. Component Sub-Layer
The component sub-layer includes components and dialogues.
A component is the means by which TC conveys a request to perform an operation,
or a reply. An operation is an action to be performed by the remote entity peer
required by a particular application of TC user. An operation is identified by an Invoke
ID. Four classes of operations (INVOKE) are considered:
Class 1: Both success and failure are reported.
Class 2: Only failure is reported.
Class 3: Only success is reported.
Class 4: Neither success nor failure is reported.
Transport Protocols
Chapter 6 TCAP

6-2
The class of the operation is determined by the TC user. The TCAP can identify these
classes. Each operation has at most one reply. The reply may be:
a return result indicating success (RESULT);
a return error indicating operation failure (ERROR);
a reject indicating inability to perform the operation (REJECT);
Expiry of the operation invocation (CANCEL), only having the local meaning.
The component portion implements the handling of the components, including
temporary ones, between two TC-users. According to the particular type of operation
carried by the component, management is performed on the state machine of the
component.
Successive components exchanged between two TC-users constitute a dialogue.
Components are carried by means of dialogue to the corresponding TC user part at
the remote end. The Component sub-layer provides dialogue facilities, allowing
several dialogues to run concurrently between two given TC-users. There are two
kinds of dialogue: unstructured dialogue and structured dialogue. TC-users can send
components that do not expect replies. This is referred to as the unstructured
dialogue (TC_UNI) case. TC-users indicate the beginning, the continuation, and the
end of a dialogue; this is referred to as a structured dialogue. Each dialogue is
identified by a particular dialogue ID. The basic process of a dialogue is described as
follows:
A dialogue begins (TC_BEGIN).
1) A dialogue confirmation (TC_CONTINUE): The first one backwards continues to
indicate that the dialogue is already established and can be continued.
2) A dialogue continues (TC_CONTINUE): The TC-users continue an established
dialogue, and full-duplex exchange of the carried components is possible.
3) A dialogue ends: The sending side will not send more components, nor will it
accept any more components. There are the following ways to terminate a
dialogue:
a) Pre-arranged end (TC_END): Both TC-users have decided by prior arrangement
when to end the dialogue; the ending is only locally effective.
b) Basic end (TC_END): The local dialogue is ended; the pending components are
delivered to the remote end and the remote TC-user is informed of the ending of the
dialogue.
c) Abort of a dialogue (TC_ABORT, TC_NOTICE): The dialogue is ended immediately;
all pending operations are terminated and the cause of the abort is indicated.
II. Transaction Sub-Layer
The transaction sub-layer is used for transaction handling control. Components are
transferred in the transaction sub-layer messages between TC-users by means of
Transport Protocols
Chapter 6 TCAP

6-3
end-to-end connection. There is a one-to-one relationship between the transaction
handling and the dialogue handling of the component sub-layer.
TCAP messages are the SCCP user data and structured by information elements.
Each element has the same structure and consists of three fields as shown in Figure
6-2.
Tag

Length

Tag

Contents

Length

Contents
Figure 6-2 TCAP message structure
I. Tag
The Tag distinguishes one information element from another and governs the
interpretation of the Contents. It is one or more octets in length. The Tag is composed
of Class, Form and Tag code, as shown in Figure 6-3.
7 6 5 4 3 2 1 0
Class Form Tag code
Figure 6-3 Format of Tag
Coding of Tag class. See Table 6-1.
Table 6-1 Coding of Tag class
00 Universal
01 Application-wide
10 Context-specific
11 Private use

Form of the element: 0 indicates a primitive; 1 indicates a constructor.
Tag code: The Tag code is in the range 00000~11110. 11111 indicates extension.
If the highest bit of the following octet is 1, then the following octet is also used
for extension of the Tag code. If it is 0, no further octets for this tag are used. The
Transport Protocols
Chapter 6 TCAP

6-4
resultant Tag consists of bits 0 to 6 of each extension octet, with bit 6 of the first
extension octet being most significant (MSB) and bit 0 of the last extension octet
being least significant (LSB).
II. Length
It is the length of the Contents. The Length uses the short, long or indefinite form. In
the indefinite form, a special primitive (Tag EOC=0; Length=0; Contents is unused
and absent) is used to terminate the Contents. See Figure 6-4.
7 6 5 4 3 2 1 0
0 MSB Length of Contents LSB
a) Short form
7 6 5 4 3 2 1 0

1 MSB (Length of Field Size)-1 LSB 1
MSB

2

Length of Contents

LSB N
b) Long form
7 6 5 4 3 2 1 0
1 0 0 0 0 0 0 0

Informatio
n element

.....

Informatio
n element

EOC Tag = 00000000
EOC Length = 00000000
c) Indefinite form
Figure 6-4 Three forms
Transport Protocols
Chapter 6 TCAP

6-5
III. Contents
The contents may be a value along with the Tag and the Length constituting a
primitive, or one or more information elements along with the Tag and the Length
constituting a constructor. The contents is interpreted according to the tag value.
IV. TCAP Message Structure
The structure of the TCAP message is shown in Figure 6-5.
Transaction Portion Information Element
Dialogue Portion Information Element
Component Portion Tag
Component Portion Length
Component Type Tag
Component Length
Component Portion Information Element
Message Type Tag
Total Message Length
Component

Figure 6-5 Structure of TCAP message
V. Structure of the Transaction Portion
Structure of the Transaction Portion is shown in Table 6-2.
Table 6-2 Structure of the Transaction Portion
Message
Parameter
Unidirectional Begin Continue End Abort
Originating Transaction ID

M M

Destination Transaction ID

M M M
Abort Cause

O
Dialogue Portion O O O O O
Transport Protocols
Chapter 6 TCAP

6-6
Message
Parameter
Unidirectional Begin Continue End Abort
Component Portion M O O O

M means mandatory; O means optional.
VI. Structure of the Dialogue Portion
Unstructured dialogue: Object Identifier Tag (M), Protocol Version (M), Application
Context Name (M), User Information (O).
Structured dialogue:
1) Dialogue Request: Protocol Version (O), Application Context Name (M), User
Information (O).
2) Dialogue Response: Protocol Version (O), Application Context Name (M), Result
(M), Result Source Diagnostic (M), User Information (O).
3) Dialogue Abort: Abort Source (M), User Information (O).
Structure of the Component Portion
a) Invoke: Invoke ID (M), Linked ID (O), Operation Code (M), Parameter (O).
b) Return Result (last and non-last): Invoke ID (M), Sequence Tag (O), Operation
Code (O), Parameter (O).
c) Return Error: Invoke ID (M), Error Code (M), Parameter (O).
d) Reject: Invoke ID (M), Problem Code (M).
Transport Protocols
Chapter 7 RTP and RTCP

7-1
7.1 Brief Introduction
The IP bearer voice services are transmitted based on UDP, which however doesnt
take real-time service transmission into account (media stream synchronization, for
example), as it is designed to be dedicated to data stream transmission. So the
functionality of UDP needs to be expanded when real-time services are transferred
based on it. For that purpose, IETF defines a new protocol RTP (Real-time Transport
Protocol).
RTP provides real-time end-to-end data delivery services, such as interactive audio
and, including payload type identification, sequence numbering, time stamping and
delivery monitoring. RTP itself does not provide any mechanism to ensure timely
delivery or provide other quality-of-service guarantees, but relies on lower-layer
protocols to do so.
At present, RTP/RTCP is widely used in IP bearer voice service flow transmission. RTP
can also provide end-to-end network transport functions over multicast or unicast
network services, which are suitable for applications transmitting various real-time data,
such as video and simulation data.
RTP involves two closely correlated parts.
Real-time Transport Protocol (RTP): transports the information featured with real
time.
RTP Control Protocol (RTCP): monitors quality of service and the information
about members involving a transfer or a session.
RTP guarantees timely transmission and synchronization of audio and video; and
RCTP is used to monitor RTP and QoS. For details about the protocols, please refer to
related RFC documents. RTP does not address resource reservation and does not
guarantee quality-of-service for real-time services. The data transport is augmented by
RTCP to allow monitoring of the data delivery in a manner scalable to large multicast
networks, and to provide minimal control and identification functionality. RTP/RTCP is
designed to be independent from the underlying transport layer and network layer.
7.2 RTP/RTCP Applications
The IP bearer of voice services is mainly accomplished by RTP. In the UMG8900
device, as for bearer handovers between ATM to IP and between TDM to IP,
RTP/RTCP is responsible for IP bearer service processing and adaptation. The
functions of RTP/TCP are provided and fulfilled by MRPU of the UMG8900 device. The
application of RTP/RTCP in MRPU is shown in Figure 7-1.
Transport Protocols

7-2
Nb UP
RTP
UDP
IP
ETH
IP
MRPU
RTCP

Figure 7-1 Applications of RTP/RTCP in the UMG8900 device
RTP/RTCP is the protocol on top of the transport layer. RTP accomplishes Nb UP
adaptation and RTCP monitors RTP packets.
7.3 Packet Format and Meaning
7.3.1 RTP Header Format
A RTP header contains many fields as shown in Table 7-1.
Table 7-1 The meaning of RTP header fields
Field Length
(bit)
Meaning
Version 2 The field defines the version of RTP. The version defined here is two.
Padding(P) 1 If the padding bit is set to 1, the packet contains one or more additional
padding octets at the end of the header. The last octet of the padding
contains a count of padding octets. Padding may be needed by some
encryption algorithms or for carrying several RTP packets in a
lower-layer protocol data packet.
Extension (X) 1 If the extension bit is set to 1, the RTP header is followed by exactly one
header extension.
CSRC Count
(CC)
4 The CSRC count contains the number of CSRC identifiers that follow
the header.
Mark (M) 1 It is set by specific protocols. In IP calls, it is set to 1 in the first RTP data
packet transferred after mute, and it is set to 0 in other cases.
Payload Type
(PT)
7 This field identifies the format of the RTP payload.
Sequence
Number
16 The sequence number is used by the receiver to detect packet loss and
to restore packet sequence. The initial value of the sequence number is
random and increments by one for each RTP data packet sent.
Transport Protocols

7-3
Field Length
(bit)
Meaning
Timestamp 32 The timestamp reflects the sampling instant of the first octet in the RTP
data packet. The sampling instant must accommodate to
synchronization to allow synchronization and jitter calculations. The
initial value of the timestamp is random, and increments with the size of
packet data.
SSRC 32 The SSRC field identifies the RTP packet sender. This identifier is
chosen randomly, with the intent that no two RTP packet senders within
the same gateway will have the same SSRC identifier. Although the
probability of multiple sources choosing the same identifier is low, all
RTP implementations must be prepared to detect and resolve
collisions. If a source changes its source transport address, it must also
choose a new SSRC identifier to avoid being interpreted as a looped
source.
CSRC List 0-480 0 to 15 items, 32 bits each. The CSRC list identifies CSRC in packets.
The number of identifiers is given by the CC field. At most 15 CSRC
identifiers are defined and are inserted by mixers, using the SSRC
identifiers

7.3.2 RTCP Packet Format
RTCP defines several types of RCTP packets to carry a variety of control information as
shown in Table 7-2.
Table 7-2 RTCP packets
Control information Description
SR (sender report) Describe transmission and reception statistics from the gateways that are
active senders
RR (receiver report) Describe reception statistics from the gateways that are receivers
SDES (source description
item)
Describe the sources sending RTCP packets, including CNAME.
BYE Indicates end of voice transfer.
APP Application specific functionality extension.

Each RTCP packet begins with a fixed part similar to that of RTP data packets, followed
by structured elements that may be of variable length according to the packet type but
always end on a 32-bit boundary. The alignment requirement and a length field in the
fixed part make RTCP packets "stackable", that is, multiple RTCP packets form a
compound RTCP packet that is sent in a single packet of the lower layer protocol, for
example UDP. There is no explicit count of individual RTCP packets in the compound
packet since the lower layer protocols are expected to provide an overall length to
determine the end of the compound packet.
Transport Protocols

7-4
7.3.3 RTCP Functions
RTCP transmits RTP control packets based on the periodic transmission, using the
same distribution mechanism as the data packets. RTCP chiefly performs two
functions.
The primary function is to provide feedback on the quality of the data distribution.
The receiver diagnoses faults on transport lines and controls RTP packet transfer
according to the feedback information in RTCP packets. The feedback function is
accomplished through sending and receiving reports by RTCP.
RTCP carries a persistent identifier for a RTP source, which is called the canonical
name (CNAME). Since the RTP header may change if a conflict is discovered or a
program is restarted, receivers require the CNAME to keep track of each
participant.
7.3.4 RTCP Transmission Interval
The interval between RTCP packets transmitted is varied randomly over the range [0.5,
1.5] times the calculated interval to avoid unintended synchronization of all participants.
The first RTCP packet sent after joining a session is also delayed by a random variation
of half the minimum RTCP interval in case the application is started at multiple sites
simultaneously.

HUAWEI


Application Protocols
Table of Contents

i
Table of Contents
Chapter 1 RANAP and Iu UP ........................................................................................................ 1-1
1.1 Overview............................................................................................................................ 1-1
1.1.1 Definition and Functions of Iu Interface .................................................................. 1-1
1.1.2 Protocol Structure for Iu-CS Interface..................................................................... 1-2
1.1.3 Protocol Implementation for Iu-CS Interface........................................................... 1-3
1.2 Introduction of RANAP Protocol ........................................................................................ 1-3
1.2.1 Structure of the RANAP Protocol Stack.................................................................. 1-3
1.2.2 Classification of RANAP Elementary Procedures................................................... 1-4
1.2.3 Description of RANAP Elementary Procedures...................................................... 1-7
1.2.4 Typical Procedures ............................................................................................... 1-21
1.3 Introduction of Iu UP Protocol .......................................................................................... 1-27
1.3.1 Functions............................................................................................................... 1-27
1.3.2 Operational Modes................................................................................................ 1-28
1.3.3 Transparent Mode (TrM) ....................................................................................... 1-29
1.3.4 Support Mode (SMpSDU: Support Mode for predefined SDU size) ..................... 1-30
1.3.5 Elementary Procedures......................................................................................... 1-34
Chapter 2 BSSAP........................................................................................................................... 2-1
2.1 Overview............................................................................................................................ 2-1
2.1.1 Definition and Functions of the A Interface............................................................. 2-1
2.1.2 BSSAP Implementation in MSOFTX3000............................................................... 2-1
2.2 Introduction of BSSAP Protocol......................................................................................... 2-3
2.2.1 BSSAP Messages................................................................................................... 2-3
2.2.3 BSSMAP Procedures.............................................................................................. 2-4
Chapter 3 MAP............................................................................................................................... 3-1
3.1 Overview............................................................................................................................ 3-1
3.1.1 Definition of the MAP Interfaces.............................................................................. 3-1
3.1.2 Functions of the MAP Interfaces............................................................................. 3-3
3.1.3 MAP Implementation in CSCN................................................................................ 3-4
3.2 Introduction of MAP Protocol ............................................................................................. 3-5
3.2.2 Operation Types...................................................................................................... 3-5
Chapter 4 H.248/MEGACO............................................................................................................ 4-1
4.1 Overview............................................................................................................................ 4-1
Table of Contents

ii
4.1.1 Definition and Functions of the Mc Interface........................................................... 4-1
4.1.2 H.248 Implementation in CSCN.............................................................................. 4-1
4.2 Introduction of H.248 Protocol ........................................................................................... 4-3
4.2.1 Overview ................................................................................................................. 4-3
Chapter 5 BICC.............................................................................................................................. 5-1
5.1 Overview............................................................................................................................ 5-1
5.1.1 Definition and Functions of the Nc Interface........................................................... 5-1
5.1.2 BICC Implementation in MSOFTX3000.................................................................. 5-1
5.2 Introduction of BICC Protocol ............................................................................................ 5-3
5.2.1 Basic Concepts ....................................................................................................... 5-3
5.2.2 Message Structure................................................................................................ 5-12
Chapter 6 BSSAP+ ........................................................................................................................ 6-1
6.1 Overview............................................................................................................................ 6-1
6.1.2 BSSAP+ Implementation in MSOFTX3000............................................................. 6-1
Chapter 7 CAP ............................................................................................................................... 7-1
7.1 Overview............................................................................................................................ 7-1
7.1.2 CAP Implementation in MSOFTX3000 ................................................................... 7-1
7.2 CAP Operations................................................................................................................. 7-3
7.2.1 Call Related Operations.......................................................................................... 7-3
7.2.2 SMS Related Operations ........................................................................................ 7-8
7.3 Basic Signaling Procedures............................................................................................... 7-9
Chapter 8 ISUP............................................................................................................................... 8-1
8.1 Overview............................................................................................................................ 8-1
8.1.1 ISUP Implementation in MSOFTX3000 .................................................................. 8-2
Table of Contents

iii
Chapter 9 Nb UP and IPBCP......................................................................................................... 9-1
9.1 Overview............................................................................................................................ 9-1
9.1.1 Brief Introduction to the Nb Interface ...................................................................... 9-1
9.1.2 Definition and Function of the Nb............................................................................ 9-1
9.1.3 Protocol Structure.................................................................................................... 9-2
9.2 Introduction to the Nb UP .................................................................................................. 9-4
9.2.1 Functions................................................................................................................. 9-5
9.2.2 Operational Modes.................................................................................................. 9-5
9.3 Introduction to the IPBCP.................................................................................................. 9-6
9.3.1 Functions................................................................................................................. 9-7
9.3.2 Primitive and Message Structure ............................................................................ 9-7

Chapter 1 RANAP and Iu UP

1-1
1.1 Overview
Radio Access Network Application Part (RANAP) is user-layer signaling of Signaling
System No.7. RANAP is the protocol used for control plane over the circuit domain
interface (that is, Iu-CS interface) between the UMTS Terrestrial Radio Access Network
(UTRAN) and the Core Network (CN). The lu UP protocol is used for user plane over
lu-CS interface, to bear and transmit the traffic.
1.1.1 Definition and Functions of Iu Interface
The Iu interface is specified at the boundary between UTRAN and CN. According to the
nature of provided services, the CN is divided into Circuit Switched (CS) domain,
Packet Switched (PS) domain and Broadcast (BC) domain. The CS domain provides
circuit services for users; the PS domain provides packet services; the BC domain
provides broadcast services. The Iu interface respectively towards these logically
independent CN domains is called Iu-CS, Iu-PS, Iu-BC. The Iu interface architecture is
shown in Figure 1-1.
Core Network (CN) UTRAN
Node B
Node B
Node B
Node B
RNC
Iu Interface
Iu-BC
Iu-CS
BC
Domain
CS
Domain
PS
Domain
Iu-PS
RNC

Figure 1-1 Iu interface architecture
The Iu interface between the Radio Network Controller (RNC) and the CN is defined as
follows:

1-2
There shall not be more than one Iu-CS interface between a RNC and the CS
domain resident CN;
There shall not be more than one Iu-PS interface between a RNC and the PS
domain resident CN;
There may be multiple Iu-BC interfaces between a RNC and the BC domain.
Main functions implemented by the Iu interface are described as follows:
Radio Access Bearer (RAB) management functions
Radio resource management functions
Rate adaptation functions
Iu link management functions
Iu user-plane management functions
Mobility management functions
Security management functions
Service and network access functions
Iu co-ordination functions (paging co-ordination and relocation co-ordination)
1.1.2 Protocol Structure for Iu-CS Interface
Figure 1-2 shows the protocol structure for Iu-CS interface described by the 3GPP
25.410.
Q.2150.1
Q.2630.1
RANAP
Iu UP Protocol
Layer
Transport
Network
Layer
Physical Layer
Transport
User
Network
Plane
Control Plane User Plane
Transport
User
Network
Plane
Transport Network
Control Plane
Radio
Network
Layer
ATM
SSCOP
AAL5
SSCOP
SSCF-NNI
AAL2 AAL5
MTP3b MTP3b
SCCP
SSCF-NNI

Figure 1-2 Iu-CS protocol structure
According to the vertical plane structure, the Iu-CS interface protocol includes:

1-3
Control plane: includes control plane signaling RANAP (TS25.413) and signaling
bearer (TS25.412).
User plane: includes user plane protocol Iu UP (TS25.415) and data bearer
(TS25.414).
Transport network control plane: includes data bearer control signaling ALCAP
(ITU-T Q.2630.1 and ITU-T Q.2630.2) and signaling bearer (TS25.414).
1.1.3 Protocol Implementation for Iu-CS Interface
MSOFTX3000 functions as a MSC Server in UMTS and is the control plane equipment
of the CN. So the Iu-CS interface in MSOFTX3000 is only embodied by the control
plane protocol, RANAP. The user plane protocol (Iu UP) is embodied on the interface
between the MGW (UMG8900) and the RNC. See Figure 1-3.
MSOFTX3000
UTRAN
RNC
Mc
UMG8900
Iu-CS
RANAP RANAP
RANAP Iu UP

Figure 1-3 protocol implementation for Iu-CS interface
1.2 Introduction of RANAP Protocol
1.2.1 Structure of the RANAP Protocol Stack
The structure of the RANAP protocol stack is shown in Figure 1-4. MSOFTX3000
supports two signaling bearer modes: ATM based broadband SS7 (SAAL-NNI, MTP3b,
SCCP) and IP based signaling transport systems (IP, SCTP, M3UA).

1-4
RNC
b) IP based
Iu-CS
RNC
a) ATM based
MSC Server
(SoftX3000)
Iu-CS
RANAP
SCCP
M3UA
SCTP
IP
RANAP
SCCP
MTP3B
STC
SAAL
AAL5
ATM
PL
RANAP
SCCP
MTP3B
STC
SAAL
AAL5
ATM
PL
MSC Server
(SoftX3000)
MAC
RANAP
SCCP
M3UA
SCTP
IP
MAC
RNC
b) IP based
Iu-CS
RNC
a) ATM based
MSC Server
(SoftX3000)
Iu-CS
RANAP
SCCP
M3UA
SCTP
IP
RANAP
SCCP
MTP3B
STC
SAAL
AAL5
ATM
PL
RANAP
SCCP
MTP3B
STC
SAAL
AAL5
ATM
PL
MSC Server
(SoftX3000)
MAC
RANAP
SCCP
M3UA
SCTP
IP
MAC

Figure 1-4 Structure of the RANAP protocol stack
From the point of view of layers, the RANAP protocol stack can be divided into two parts:
radio access network application protocol at the radio network layer, using RANAP
protocol (TS25.413), and signaling bearer, resident at the transport network layer.
1.2.2 Classification of RANAP Elementary Procedures
RANAP is responsible for signaling interaction of the Iu-CS interface between the CN
and the RNC. It provides a variety of functions above mentioned by combination of one
or more Elementary Procedures (EPs).
The following section describes EPs classified respectively by response type and
message transport mode.
I. Classified by Response Type
According to different response types, RANAP EPs are divided into Classes 1, 2 and 3.
Class 1: Elementary Procedures with response (success and/or failure). For Class
1 EPs, Successful means a signaling message explicitly indicates that the
elementary procedure successfully completed with the receipt of the response.
Unsuccessful means a signaling message explicitly indicates that the EP failed
or on time supervision expiry (that is, absence of expected response). A third
result is successful and unsuccessful. Successful and unsuccessful means one
signaling message reports both successful and unsuccessful outcome for the
different included requests. The response message used is the one defined for
successful outcome.
Class 2: Elementary Procedures without response. Class 2 EPs are considered
always successful.
Class 3: Elementary Procedures with possibility of multiple responses. Class 3
EPs have one or several response messages reporting both successful,

1-5
unsuccessful outcome of the requests and temporary status information about the
requests.
Messages relating to the three classes of RANAP EPs are shown in Table 1-1 to Table
1-3.
Table 1-1 Class 1 (with response)
Response message
Elementary
procedure
Initiating message
Successful outcome Unsuccessful outcome
Iu Release
IU RELEASE
COMMAND
IU RELEASE
COMPLETE

Relocation
Preparation
RELOCATION
REQUIRED
RELOCATION
COMMAND
RELOCATION
PREPARATION FAILURE
Relocation
Resource
Allocation
RELOCATION
REQUEST
RELOCATION
REQUEST
ACKNOWLEDGE
RELOCATION FAILURE
Relocation
Cancel
RELOCATION
CANCEL
RELOCATION
CANCEL
ACKNOWLEDGE

SRNS Context
Transfer
SRNS CONTEXT
REQUEST
SRNS CONTEXT
RESPONSE

Security Mode
Control
SECURITY MODE
COMMAND
SECURITY MODE
COMPLETE
SECURITY MODE REJECT
Data Volume
Report
DATA VOLUME
REPORT REQUEST
DATA VOLUME
REPORT

Reset RESET
RESET
ACKNOWLEDGE

Reset
Resource
RESET RESOURCE
RESET RESOURCE
ACKNOWLEDGE

Table 1-2 Class 2 (without response)
Elementary procedure message
RAB Release Request RAB RELEASE REQUEST
Iu Release Request IU RELEASE REQUEST
Relocation Detect RELOCATION DETECT
Relocation Complete RELOCATION COMPLETE
SRNS Data Forwarding Initiation SRNS DATA FORWARD COMMAND
SRNS Context Forwarding from Source RNC
to CN
FORWARD SRNS CONTEXT

1-6
Elementary procedure message
SRNS Context Forwarding to Target RNC
from CN
FORWARD SRNS CONTEXT
Paging PAGING
Common ID COMMON ID
CN Invoke Trace CN INVOKE TRACE
CN Deactivate Trace CN DEACTIVATE TRACE
Location Reporting Control LOCATION REPORTING CONTROL
Location Report LOCATION REPORT
Initial UE Message INITIAL UE MESSAGE
Direct Transfer DIRECT TRANSFER
Overload Control OVERLOAD
Error Indication ERROR INDICATION

Table 1-3 Class 3 (with possibility of multiple responses)
Elementary procedure Initiating message Response message
RAB Assignment
RAB ASSIGNMENT
REQUEST
RAB ASSIGNMENT RESPONSE x N
(N>=1)

II. Classified by Message Transport Mode
According to different message transport modes, RANAP EPs are classified into:
connection-oriented and connectionless. The former is supported by a UE specific
signaling connection for transport; the latter is supported by a common signaling
connection for transport.
All other procedures use connection-oriented service to transport except that Reset,
Reset Resource, Overload Control, and Paging use SCCP connectionless service and
Error Indication bases the actual conditions to make a determination between the
connectionless service and the connection-oriented service.
Connection-oriented messages are ones between a specific UE and the network, such
as UE location update procedure and call procedure. Connectionless messages are
ones pertaining to system maintenance and administration and affect part or all of UE
users.

1-7
Most of RANAP connectionless message may be up or down (except PAGING). Most
of connection-oriented messages are mono-directional (except ERROR INDICATION
and DIRECT TRANSFER).
1.2.3 Description of RANAP Elementary Procedures
I. RAB Assignment
RAB assignment is initiated by the CN. But the CN only determines a RAB ID value and
concerned RAB parameters. The RNC executes the request, allocates user plane
resources, and reports to the CN the outcome of the procedure in one or more
responses. The message flow is shown in Figure 1-5.
RNC CN
RAB Assignment Request
ERQ ( Q.2630.1 Message)
ECF ( Q.2630.1 Message)
RAB Assignment Response
**
*

Figure 1-5 RAB assignment message flow

Note:
Q.2630.1 message only appears on the Iu-CS interface. It does not appear on the Iu-PS interface.
There may be multiple responses.

The specific procedure is described as follows:
1) The CN sends a request (maybe for several RABs in one message), and starts the
TRABAssgt timer. Upon reception of the request message the RNC executes it,
and places temporarily unprocessed requests in the queue. In the first returned
RAB assignment response, the configuration of the RAB requested by the CN
must be contained.

1-8
2) If there are not RABs in the queue, the CN terminates TRABAssgt on reception of
the first RAB assignment response, and ends the RAB assignment procedure; if
there is a queue, the RNC starts the TQEUING timer, and returns the execution
results about RAB queuing to the CN with a RAB assignment response. (RAB
results may be returned one by one or several are returned at a time.)
3) If the RNC completes the execution of queued RABs before TQEUING expiry, it
stops timing of TQEUING, returns a RAB assignment response, and ends the
RAB assignment procedure; if the RNC does not complete the execution of RAB
assignment requests in the queue before TQEUING expiry, the RNC stops queue
execution, returns a RAB assignment response, and ends the RAB assignment
procedure.
4) If the CN receives execution results about all queued RABs before TRABAssgt
expiry, it stops timing of TRABAssgt, and ends the RAB assignment procedure; if
the CN does not receive execution results about all queued RABs before
TRABAssgt expiry, it ends the RAB assignment procedure, and regards RABs
without results returned as unsuccessful execution.
II. RAB Release Request
The RNC uses this procedure to request the CN to release concerned RAB resources.
The elementary procedure without response is connection-oriented. The message flow
is shown in Figure 1-6.
When a failure occurring to the corresponding user plane resource of RAB ID is found
at the RNC, the RNC initiates a RAB release request message to the CN in normal
cases.
CN
RAB
RELEASE REQUEST
RNC

Figure 1-6 RAB release request message flow
III. Iu Release Request
This procedure is used by the RNC to request the CN to release the Iu connection for a
particular UE. It is due to some UTRAN generated reason, for example, O&M
Intervention, User Inactivity, Radio Connection With UE Lost", etc. The Iu Release
Request procedure without response is connection-oriented. The message flow is

1-9
CN RNC
IU RELEASE REQUEST

Figure 1-7 Iu release request message flow
If a UE has two Iu connections, the message is sent the corresponding CN domain of
the Iu connection to be released.
IV. Iu Release
The purpose of the Iu Release procedure is to enable the CN to release the Iu
connection and all UTRAN resources related only to that Iu connection to be released.
The procedure with response is connection-oriented.
The procedure is initiated by the CN for at least the following reasons:
Completion of transaction between UE and CN.
Reception of Iu Release Request message by CN.
Completion of relocation of SRNS.
The message flow of the procedure is shown in Figure 1-8.
CN RNC
IU RELEASE COMMAND
IU RELEASE COMPLETE

Figure 1-8 Iu release message flow
V. Relocation of SRNS
This procedure is used to relocate the Serving RNS (SRNS) from one RNS to another.
This procedure can be divided into several stages: Relocation Preparation, Relocation
Resource Allocation, Relocation Detect and Relocation Complete. In addition,
Relocation Cancel is also included.
1) Relocation Preparation
The relocation message flow is shown in Figure 1-9 and Figure 1-10.

1-10
CN Source RNC
RELOCATION COMMAND
RELOCATION REQUIRED

Figure 1-9 Relocation Preparation procedure (successful operation)
CN Source RNC
RELOCATION PREPARATION
FAILURE
RELOCATION REQUIRED

Figure 1-10 Relocation Preparation procedure (unsuccessful operation)
Successful operation
The source RNC sends to the CN a RELOCATION REQUIRED message to request for
relocation, indicates the reason, and starts the TRELOCprep timer. After the CN
successfully processes the request, the Relocation Preparation procedure is
terminated in the CN by transmission of RELOCATION COMMAND message. If the
source RNC is ready meanwhile, the source RNC will trigger the execution of relocation
of SRNS.
Unsuccessful operation
If the CN or target RNC is not able to accept the relocation or a failure occurs during the
procedure, the CN sends a RELOCATION PREPARATION FAILURE message to the
source RNC. If the Iu connection is already established between the CN and the target
RNC, the CN sends a Iu release message to the target RNC with the cause relocation
cancel. The procedure is terminated. The preceding Iu connection continues to use.
If there is no response from the CN to the RELOCATION REQUIRED message before
the timer TRELOCprep expires in the source RNC, the source RNC initiates the
Relocation Cancel procedure.
2) Relocation Resource Allocation

1-11
This procedure is used to allocate resources from the target RNS for a relocation of
SRNS and co-ordinate Iu connection resources existing for the particular UE. The
procedure with response is connection-oriented. The message flow is shown in Figure
1-11 and Figure 1-12.
CN Target RNC
RELOCATION REQUEST
ACKNOWLEDGE
RELOCATION REQUEST

Figure 1-11 Relocation Resource Allocation procedure (successful operation)
CN Target RNC
RELOCATION FAILURE
RELOCATION REQUEST

Figure 1-12 Relocation Resource Allocation procedure (unsuccessful operation)
Successful operation: The CN initiates a relocation request to the target RNC. The
request contains a number of resource parameters required by the target RNC for
establishment. The timer TRELOCalloc starts. The target RNC detects the
usability of the resources requested by the CN, and then performs establishment
of the resources. When all necessary resources including user plane
configurations are successfully established, a RELOCATION REQUEST
ACKNOWLEDGE is returned. The procedure is terminated.
Unsuccessful operation: If the target RNC can not accept the relocation or a failure
occurs during the procedure, the target RNC returns a RELOCATION FALIURE
message to the CN. When the CN has received the message, the CN stops the
timer TRELOCalloc, and releases the resources pertaining to the target RNC.

1-12
3) Relocation Detect
This procedure is used by the target RNC to indicate to the CN the detection of
relocation execution. The procedure without response is connection-oriented. The
message flow is shown in Figure 1-13.
CN Target RNC
RELOCATION DETECT

Figure 1-13 Relocation Detect procedure
When relocation execution trigger is received, the target RNC sends a RELOCATION
DETECT message to the CN and starts the role of SRNC. Upon reception of the
RELOCATION DETECT message, the CN switches the user plane from the source
RNC to the target RNC.
4) Relocation Complete
This procedure is used by the target RNC to indicate to the CN the completion of
relocation of SRNS. The procedure without response is connection-oriented. The
message flow is shown in Figure 1-14.
CN Target RNC
RELOCATION COMPLETE

Figure 1-14 Relocation Complete procedure
When the new SRNC-ID and Serving RNC Radio Network Temporary Identity (S-RNTI)
are successfully exchanged with the UE by the radio protocols, the target RNC sends a
relocation complete message to the CN, and terminates the whole Relocation
procedure. Upon reception of the relocation complete message, the CN begins to
release the connection associated with the SRNC.
5) Relocation Cancel
The purpose of this procedure is to enable the source RNC to cancel an ongoing
relocation of SRNS. The procedure takes place after the Relocation Preparation
procedure. The procedure with response is connection-oriented.

1-13
This procedure is initiated due to either of the following reasons:
If the source RNC has not yet received a relocation request message when the
timer TRELOCprep expires, it starts the Relocation Cancel procedure to the CN.
The source RNC actively sends such message due to UE cause.
The source RNC terminates the Relocation procedure after a relocation cancel
message is sent; the CN receives the relocation cancel message and then terminates
the Relocation Preparation procedure. The message flow is shown in Figure 1-15.
CN Source RNC
RELOCATION CANCEL
ACKNOWLEDGE
RELOCATION CANCEL

Figure 1-15 Relocation Cancel procedure
VI. Paging
The purpose of this procedure is to enable the CN to send a paging message to a
particular UE. The procedure without response is connectionless.
When the UE is idle, paging is performed through a common paging channel; when the
UE has already had a Radio Resource Control (RRC) connection, paging is performed
through its dedicated RRC connection.
The message flow is shown in Figure 1-16.
CN RNC
PAGING

Figure 1-16 Paging procedure
VII. Common ID
This procedure is used, after a RRC connection is established for the UE, to create a
reference between a common identity of the UE (for example, IMSI) and the RRC
connection and store it in the RNC, so that subsequent paging messages can be

1-14
transported through the RRC connection. The procedure without response is
connection-oriented. The message flow is shown in Figure 1-17.
CN RNC
COMMON ID

Figure 1-17 Common ID procedure
After a connection has been established between the RNC and the CN, the CN shall
send the common ID of the UE to the RNC as soon as possible. When a call is already
set up between the UE and a domain of the CN (for example, PS domain) and another
domain (for example, CS domain) wants to page the UE, the RNC can use the
Common ID of the UE to look for the corresponding RRC connection of the PS domain.
(PS and CS domains always share one RRC connection to the same UE.) Then the
PAGING message is sent to the UE through the dedicated RRC connection channel.
If the RNC does not support this function, the RNC will send the PAGING message
through a common paging channel in the preceding conditions. In this way, the
PAGING message will not be found by the UE, and thus the paging operation will fail.
VIII. CN Invoke Trace
This procedure is used to inform the RNC to trace the actions of a particular UE and
report the record to a specified Operation and Maintenance Center (OMC). The
procedure without response is connection-oriented. The message flow is shown in
Figure 1-18.
CN RNC
CN INVOKE TRACE

Figure 1-18 CN Invoke Trace procedure
IX. Security Mode Control
This procedure is used by the CN to pass cipher and integrity mode information to the
UTRAN. The UTRAN uses these algorithms during the subsequent RAB connection

1-15
establishment, relocation, etc. procedures. This procedure with response is
connection-oriented. The message flow is shown in Figure 1-19 and Figure 1-20.
CN RNC
SECURITY MODE
COMMAND
SECURITY MODE
COMPLETE

Figure 1-19 Security Mode Control procedure (successful operation)
CN RNC
SECURITY MODE
COMMAND
SECURITY MODE
REJECT

Figure 1-20 Security Mode Control procedure (unsuccessful operation)
X. Location Reporting Control
This procedure is used by the CN to request the RNC to provide information on the
location of a given UE. The control parameter may be of direct report type, change
report type or stop report type. The procedure without response is connection-oriented.
The message flow is shown in Figure 1-21.
CN RNC
LOCATION REPORTING
CONTROL

Figure 1-21 Location Reporting Control procedure

1-16
XI. Location Report
This procedure is used by the RNC to report the UE's location information to the CN.
The report is controlled by the LOCATION REPORT CONTROL message. The
Figure 1-22.
CN RNC
LOCATION REPORT

Figure 1-22 Location Report procedure
XII. Initial UE Message
This procedure is used by the RNC to transparently transfer to the CN the radio
interface initial message (NAS-PDU) of the third layer from the UE when a Iu signaling
connection is established by the RNC. The procedure without response is
connection-oriented. The message flow is shown in Figure 1-23.
CN RNC
INITIAL UE MESSAGE

Figure 1-23 Initial UE Message procedure
The RNC does not analyze the contents of the initial message. What it does is to add
some information on it to generate an INITIAL UE message and then transfer it to the
CN.
XIII. Direct Transfer
This procedure is used to transparently carry UE-CN signaling messages by the
UTRAN over the Iu interface. The RNC does not perform any operations on them. The
UE-CN signaling messages are transported as a parameter in the DIRECT
TRANSFER message messages.
This procedure without response is connection-oriented. The message flow is shown in
Figure 1-24 and Figure 1-25. The procedure can be originated by either CN or UTRAN.

1-17
CN RNC
DIRECT TRANSFER

Figure 1-24 CN originated Direct Transfer procedure
CN RNC
DIRECT TRANSFER

Figure 1-25 UTRAN originated Direct Transfer procedure
XIV. Overload Control
This procedure is initiated by either the RNC or the CN in case that signaling overload
happens at its side. The other party performs overload control according to a certain
algorithm, such as restricting UE accessing or restricting to send paging or switching
request, etc. messages. The purpose to do so is to appropriately reduce the traffic
processed by the RNC or the CN, so as to ensure the normal operation of the system.
The RNC and the CN are equivalent in the aspect of the role during this control
procedure. That is, either can initiate this procedure.
This procedure has two operations: overload control at the CN side and overload
control at the UTRAN side. The procedure without response is connectionless. The
message flow is shown in Figure 1-26 and Figure 1-27.
CN RNC
OVERLOAD

Figure 1-26 Overload Control procedure at the CN side

1-18
CN RNC
OVERLOAD

Figure 1-27 Overload Control procedure at the UTRAN side
For flow control, at the CN Processor Overload is catered for, and at the UTRAN
Processor Overload and Overload in the Capability to Send Signaling Messages to
the UE are catered for.
XV. Reset
Reset is designed for all transactions on the Iu interface at the RNC or the CN. After
reset, all call connections (already established or being established) will be released.
Call messages from the UE will not be accepted during the reset protection time. The
message flow is shown in Figure 1-28 and Figure 1-29.
CN RNC
RESET
RESET ACKNOWLEDGE

Figure 1-28 Reset procedure initiated from the CN

1-19
CN RNC
RESET
RESET ACKNOWLEDGE

Figure 1-29 Reset procedure initiated from the UTRAN
The source end sends a RESET message and starts timer T(RafC) or T(RafR). Upon
reception of the RESET message, the opposite end releases affected RABs and then
returns a reset acknowledgement message.
XVI. Reset Resource
Reset Resource is designed for partial Iu connections at the RNC (or the CN). When
connection status abnormality is found by the RNC or the CN, the RNC or the CN
initiates the Reset Resource procedure. The message flow is shown in Figure 1-30 and
Figure 1-31.
CN RNC
RESET RESOURCE
RESET RESOURCE
ACKNOWLEDGE

Figure 1-30 Reset Resource procedure initiated from the CN

1-20
CN RNC
RESET RESOURCE
RESET RESOURCE
ACKNOWLEDGE

Figure 1-31 Reset Resource procedure initiated from the RNC
XVII. Error Indication
The Error Indication procedure is initiated by a node to report detected errors in one
incoming message, provided they cannot be reported by an appropriate failure
message.
If the error situation arises due to reception of a message utilizing dedicated signaling,
then the Error Indication procedure without response uses connection-oriented
signaling. Otherwise the procedure without response uses connectionless signaling.
The message flow is shown in Figure 1-32 and Figure 1-33.
CN RNC
ERROR INDICATION

Figure 1-32 Error Indication procedure originated by the CN
CN RNC
ERROR INDICATION

Figure 1-33 Error Indication procedure originated by the UTRAN
XVIII. CN Invoke Trace
This procedure is used to inform the RNC to trace the actions of a particular UE and
report the record to a specified Operation and Maintenance Center (OMC). The

1-21
Figure 1-18.
XIX. CN Deactivate Trace
This procedure is used to inform the RNC to stop tracing the actions of a particular UE.
The procedure without response is connection-oriented. The message flow is shown in
Figure 1-34.
CN RNC
CN DEACTIVATE
TRACE

Figure 1-34 CN Deactivate Trace procedure
1.2.4 Typical Procedures
On the basis of RANAP Elementary Procedures, this section describes the signaling of
several typical procedures on the Iu interface so that you can have an idea of
applications of the RANAP EPs.
The typical procedures to be described below are CS domain location update, mobile
calling, mobile called, relocation, relocation failure, etc.
I. Iu-CS Interface Location Update Procedure
Figure 1-35 illustrates a typical location update procedure. The location update
procedure is connection-oriented.

1-22
RNC CN
SCCP : CR
( Initial UE Message (location update request))
SCCP : CC
Security Mode Complete
Direct Transfer( location update accept)
Direct Transfer( TMSI reallcoate complete)
Iu Release Command
Iu Release Complete
SCCP : RLSD
SCCP : RLC
Direct Transfer( Auth. request)
Direct Transfer(Auth. response )
Security Mode Command
Data transfer phase
Connection establishment phase
Connection release phase

Figure 1-35 Iu interface location update procedure
Purposes of the location update procedure are:
1) Insert in the VLR the subscription information of the UE in the HLR: An example is
subscribed services (telecommunication services, supplementary services).
2) Location update is the premise for the UE to act as the calling party or the called
party. No matter the UE is the calling or called party, VLR must contain this users
data: whether a certain service (for example, SMS) is subscribed, whether a
supplementary service such as call forwarding is registered/activated, and so on.
3) When the UE is the called party, MSC Server/VLR preserves its LAI so as to send
paging messages. HLR preserves the UE resident MSC/VLR number so that
roaming number can be obtained
II. Iu-CS Interface Mobile Calling Procedure
Iu interface mobile calling procedure is shown in Figure 1-36.

1-23
RNC CN
Initial UE Message (cm service request)
SCCP : CC
RAB Assignment procedure
Direct Transfer( call proceeding )
Direct Transfer( alerting)
Direct Transfer ( disconnect: released by the called party)
Direct Transfer( connect ack )
Common ID
Authentication Encryption procedure
Direct Transfer ( setup )
Direct Transfer( connect )
In conversation
Direct Transfer ( release )
Direct Transfer ( release complete )
Iu Release/ SCCP Release

Figure 1-36 Iu-CS interface mobile calling procedure
UE calling procedure is basically same as MS calling procedure of GSM. The specific
procedure is described as follows:
1) The initial message for the UE to originate a call is contained in the NAS-PDU of
the INITIAL UE message.
2) After the Iu interface connection is established, the CN can initiate the Common ID
procedure for paging co-ordination.
3) The CN judges whether the UE is entitled to access. If the UE is entitled,
allowance is shown by triggering the Authentication/Encryption procedure
(consistent with the corresponding flow in the Location Update procedure) or
Direct Transfer (Cm service accept) is directly sent. Otherwise, the CN initiates the
Iu Release procedure.
4) The called number contained in the Direct Transfer (Setup) message is sent to the
CN. After number analysis, the CN determines the nature of the call: outgoing call
to PSTN or local office call, etc.
5) After the called number is successfully analyzed, the CN sends CALL
PROCEEDING and starts the RAB Assignment procedure (reference the
preceding diagram of RAB Assignment procedure).
6) After the called party hears ringing tone, the CN sends an ALERTING message to
the UE.
7) After the called party hooks off, the CN sends a CONNECT message to the UE.
8) Upon reception of the CONNECT message, the UE sends a CONNECT ACK
message. The call is connected.

1-24
9) If the call is terminated by the calling UE, the calling UE sends a DISCONNECT
message to the CN. If the called party hooks on first, the CN sends a
DISCONNECT message to the calling UE.
III. Iu-CS Interface Mobile Called Procedure
Iu interface mobile called procedure is shown in Figure 1-37.
RNC
CN
SCCP : CR
(Initial UE Message (paging response))
SCCP : CC
RAB Assignment procedure
Direct Transfer( call confirmed )
Direct Transfer( alerting)
Direct Transfer ( disconnect: released by the called party)
Direct Transfer( connect ack )
Common ID
Authentication Encryption procedure
Direct Transfer ( setup )
Direct Transfer( connect )
In conversation
Direct Transfer ( release )
Direct Transfer ( release complete )
Pagings

Figure 1-37 Iu-CS interface mobile called procedure
1) The CN analyzes whether or not the called party resident UE is within its scope. If
the UE is, the CN sends a connectionless PAGING message.
2) When a message indicating to page itself is found, the UE originates connection
setup with a PAGING RESPONSE message by using the RNC.
3) The CN can initiate the Common ID procedure to support RNC paging
co-ordination.
4) The CN sends a SETUP message containing the calling number (if the UE is
entitled to CLIP service).
5) Upon reception of the CALL CONFIRMED message from the UE, the CN starts
the RAB Assignment procedure (reference the preceding diagram of RAB
Assignment procedure).

1-25
6) After the called party hears ringing tone, the UE sends an ALERTING message to
the CN.
7) The called party hooks off, the UE sends a CONNECT message to the CN.
8) The CN returns a CONNECT ACK message. The call is connected.
9) The message flow about on-hook is the same as that of the mobile calling
procedure.
IV. Switching Procedure Between RNCs in the Same CN
Figure 1-38 illustrates the switching procedure between two RNCs in the same CN.
TRNC
Relocation Required
Relocation Command
Relocation Prep. Failure
Relocation Failure
Relocation Request
SCCP CC
Relocatin Req. Ack
Relocation Detect
Relocation Complete
SRNC CN
Connection Established
Relocation Cancel
Relocation Cancel Ack.
Relocation Command

Figure 1-38 Switching procedure between RNCs inside CN
As shown in Figure 1-38, solid lines represent normal switching procedures and dotted
lines represent abnormal procedures.
After a successful switch, the CN shall initiate the Iu Release procedure to the source
side. If the CN fails to initiate the Iu Release procedure to the RNC before the timer
expires, the source RNC shall actively initiate the Iu Release Request.

Note:
For the switching procedure between CNs, the message flow on the Iu interface is basically same. The
difference is E interface message flow between CNs (RANAP messages carried by the MAP protocol in
effect).


1-26
V. Resource Allocation Failure Procedure About Target RNC Relocation
Figure 1-39 illustrates the resource allocation failure procedure about relocating the
target RNC.
RNC2
Relocation Required
Relocation Prep. Failure
Relocation Failure
Relocation Request
SCCP CC
RNC1 CN
Call ongoing at the source side

Figure 1-39 Resource allocation failure procedure about target relocation
1) Once resource allocation for relocating the target RNC fails, the target RNC sends
a RELOCATION FAILURE message to the CN.
2) Upon reception of the message by the CN, the CN sends a RELOCATION PREP
FAILURE message to the source RNC.
3) The Iu connection for relocating the target RNC is released. The call continues to
be held at the source side.
VI. Relocation Cancel Procedure by Source Side Actively
Figure 1-40 illustrates the relocation cancel procedure by the source side actively

1-27
RNC2
Relocation Required
Relocation Command
Relocation Request
SCCP CC
Relocatin Req. Ack
RNC1 CN
Relocation Cancel
Relocation Cancel Ack.
Call ongoing at the source side

Figure 1-40 Relocation cancel procedure by source side actively
1) Relocation Cancel may take place during or after the Relocation Preparation
procedure. In other words, RELOCATION CANCEL message may be sent before
the RELOCATION COMMAND from the CN is received, or be sent by the RNC
after the CN has sent a RELOCATION COMMAND message.
2) After the source RNC has initiated the Relocation Required procedure, a
successive initiation of the Relocation Required procedure cannot be done if the
RELOCATION CANCEL or RELOCATION COMMAND message from the CN is
not received.
1.3 Introduction of Iu UP Protocol
1.3.1 Functions
Iu UP exists at lu access points of CN and UTRAN. As a radio network layer user-plane
protocol at lu interface, the lu UP protocol is used to transmit user data related to radio
access bearers (RAB). One lu UP protocol instance can and only can relate one RAB.
For termination users, if multiple RABs are set up simultaneously, multiple lu UP
protocol instances of the same number as RAB must be available.
When RAB needs to transport user data through the lu UP protocol, lu UP protocol
instances must be available at each lu interface access point. The lu UP protocol
instances must be set up, relocated and released together with RABs concerned. The
RAB functions completed by the peer protocol entities defined by the lu UP protocol
vary with lu UP protocol operational modes.
Iu UP logic location and data stream are shown in Figure 1-41.

1-28
Radio
Protoc-ols
Radio
Protoc-
ols
Iu UP
User Plane
Data
Bearers
Protocols
Iu UP
User Plane
Data
Bearers
Protocols
Transport
Layer
NAS Data
Streams
NAS Data
Streams
Non-Access Stratum
Access Stratum
UE UTRAN CN Iu Uu

Figure 1-41 Iu UP logic location and data stream
Iu UP operational mode is decided by RAB, other than the CN or service types, which
ensures the QoS required by RAB. Lu UP protocol data packet type is determined by lu
UP protocol operational mode, that is, different operational modes correspond to
different data packet structures.
In lu UP protocol support mode, when a call satisfies TrFO conditions, lu UP protocol
instances of MGW can be used or not used (in a stable calling state). Thus, the UP
instances in direct dialogue relationship with the RAN-side lu UP protocol can be
located in another RAN or in the nodes of CN not directly connected with RAN except
MGW.
1.3.2 Operational Modes
Iu UP defines two operational modes, which are activated based on RAB, rather than
CN domain or services (telecommunication). lu UP protocol operational mode specifies
whether to provide features or what features are provided to satisfy RAB QoS
requirements.
Iu UP operational modes are:
Transparent Mode: TrM
Support mode: SMpSDU (Support Mode for predefined SDU size)
Determination of the Iu UP protocol instance mode of operation is a CN decision taken
at RAB establishment based on the RAB characteristics. So the choice of a mode is
bound to the nature of the associated RAB and will not be changed unless the RAB
changes. It is indicated in the Radio Network layer control plane at RAB assignment

1-29
and relocation for each RAB. It is signaled to the Iu UP protocol layer at user plane
establishment.

Note:
In most cases, for the circuit domain-oriented lu interface user plane, support mode is adopted and lu user
plane protocol is used to implement some certain processing. Thus the lu user plane protocol (the lu UP
protocol) is usually regarded as an lu user protocol in the circuit domain.

1.3.3 Transparent Mode (TrM)
The transparent mode is intended for those RABs that do not require any particular
feature from the Iu UP protocol other than transfer of user data. The operation of the lu
UP protocol in transparent mode is illustrated in Figure 1-42.
Iu UP
Layer in
transparent Mode
TNL-SAP
Radio
Interface
Protocols
Iu UP
Layer in transparent
Mode
TNL-SAP
RNL-SAP
Non Access
Stratum
Access Stratum
UTRAN CN Iu Interface
TNL-SAP: Transport Network Layer-Service Access Point
RNL-SAP: Radio Network Layer-Service Access Point
CN: Core Network
UTRAN: UMTS Terresttrial Radio Access Network

Figure 1-42 The operation of Iu UP in transparent mode
In transparent mode, the lu UP instance does not exchange any lu UP protocol
information (lu UP frames) with its peer: no Iu UP frame is sent. Only are PDUs
exchanged through the Iu UP protocol layer, between upper layers and transport
network layer. The lu UP protocol layer in transparent mode is located in lu user plane
and used for transparent data transmission over lu interfaces. Between upper layers

1-30
and transport network layer, none access stratum (NAS) data are transmitted through
service access points (SAP).
In transparent mode, the lu UP protocol layer connects transport network layer and
upper layers. The lu UP protocol layer is an empty layer, through which NAS data
stream PUDs are transmitted between upper layers and transport layer.
In transparent mode, the lu UP protocol layer transmits lu UP PDUs at lu UP protocol
interfaces by making use of the services provided by the transport layer.
In transparent mode, the lu UP protocol layer is mainly to transmit user data.
In transparent mode, the lu UP protocol layer needs to make use of the services
provided by the lu UP protocol transport layer to transmit user data.
1.3.4 Support Mode (SMpSDU: Support Mode for predefined SDU size)
This mode is intended for those RABs that do require particular features from the Iu UP
protocol in addition to transfer of user data. In this mode, lu UP protocol frames are
transmitted by the peer lu UP protocol instances; while in transparent mode, no lu UP
protocol frames are generated. The functional model of the lu UP protocol layer in
support mode is shown in Figure 1-43.
Iu UP
Layer in
support
Mode
TNL-SAP
Radio
Interface
Protocols
Iu UP
Layer in support
Mode
TNL-SAP
RNL-SAP
Non Access
Stratum
Access Stratum
UTRAN CN Iu Interface
TNL-SAP: Transport Network Layer-Service Access Point
RNL-SAP: Radio Network Layer-Service Access Point
CN: Core Network
UTRAN: UMTS Terresttrial Radio Access Network
support
Mode
Function
support
Mode
Function
Iu UP
Frame

Figure 1-43 Iu UP operation in support mode
In predefined support mode, the corresponding RAB constrains the Iu UP protocol and
even the radio interface protocols in some particular way. For instance, certain RABs
can have variable predefined rates.

1-31
The operations at the lu UP protocol layer in support mode include:
Support the data streams that need frame handling in the UP
Transfer NAS data stream through SAP.
The interfaces of the lu UP protocol layer in support mode:
As part of the access stratum responsibility, the lu UP protocol layer supports NAS
data stream handling. Through SAP dedicated to information transmission, the lu
UP protocol provides these services for the UP upper layers.
Making use of the services provided by the transport layer, Iu UP supports Iu UP
PDU transmission through lu interfaces.
The support mode needs the following functions to support services:
Transfer of user data
initialization
rate control
time alignment
error events handling
frame quality classification
In support mode, the transport network layer provides the function of user data transfer
for the lu UP protocol layer. The functional model of the lu UP protocol layer in support
mode is shown in Figure 1-44.
Iu UP layer in
support mode
TNL-SAP
RNL-SAP
Iu Interface
TNL-SAP
Iu UP layer in
support mode
CN UTRAN
R
a
d
i
o

I
n
t
e
r
f
a
c
e
P
r
o
t
o
c
o
l
s
Non Access
Stratum
Access Stratum
Streams specific
NAS Data
functions
Frame Handler
function
dure
Control
func-
tions
Proce- Proce-
dure
Control
func-
tions
functions
NAS Data
Streams specific
Frame Handler
function

Figure 1-44 The functional model of the lu UP protocol layer in support mode

1-32
The lu UP protocol layer in support mode is made up of three sets of functions:
II. Frame Handler Function
This function is responsible for framing and de-framing different parts of an lu UP
protocol frame. This function takes different parts of an lu UP protocol frame and set the
control part field to proper values, including the handling of the frame number. It also
ensures that the frame control part is semantically correct. This function is responsible
for interworking with the transport layer and CRC check of the lu UP frame header. The
lu UP frames with header CRC check errors are dropped.
III. Procedure Control Functions
The procedures handled at the lu UP protocol layer are controlled by this set of
functions. The procedures include:
Rate control: This procedure controls over the lu UP the rate set that is allowed to
be sent. The function controlling this procedure interacts with the functions outside
the lu UP protocol layer.
Initialization: This procedure controls the exchange of initialization information
which is needed for operation in support mode. The initialization information can
contain RFCI collection to be used until termination of the connection or until a
new round of initialization.
Time alignment: This procedure controls the timing of the downlink data to the
RNC over lu. The function controlling this procedure interacts with the functions
outside of the lu UP protocol layer.
Error events handling: This procedure controls information exchanged over the lu
concerning fault monitor. The function controlling this procedure interacts with the
functions outside of the lu UP protocol layer.
IV. Special Functions of NAS Data Streams
The special functions of NAS data streams are responsible for "limited manipulation" of
the payload and the consistency check of the frame. If some frames are found lost
during frames receiving, the event will be reported to the procedure control function;
meanwhile for the CRC check and calculation of the Iu UP frame payload part. These
functions are also responsible for the frame quality classification handling.
The special functions of NAS data streams interact with the upper layers to exchange lu
data stream blocks of lu UP protocol frame payload. When necessary, these functions
also handle the padding and depadding of the Iu UP frame payloads.
The special functions of NAS data streams interact with the procedure control function
and provide access to the upper layers for the procedure control function.
Frame qualification classification function

1-33
In the lu UP protocol support mode, frame quality classifier is used to classify frame
qualification, which is based on two aspects: radio frame classification and the setting
of RAB attributes error SDU transmission. The RAB attribute error SDU
transmission tells if erroneous frames shall be sent or not.
FQC information handling
In SRNC on the sending side, the support mode function takes as input the radio frame
quality information and the frame. Based on this the FQC is set for the frame. If
necessary, a CRC is added and the frame is sent to CN. The configuration of FQC
domain is shown in Table 1-4:
Table 1-4 Configuration of FQC domain
INPUT ACTION
Delivery of erroneous SDU Radio Frame Classification Action taken in SRNC on the sending
side
Yes Bad Set FQC to 'bad radio'
No Bad Drop frame
Not Applicable Any Value Set FQC to good
Any value Good Set FQC to good

In the support mode, if CRC exits, the receiving side of CN will perform CRC check of
the frame payload, and then passes frames and frame qualify classification information
through RNL-SAP. The configuration of CRC is shown in Table 1-5:
Table 1-5 FQC configuration when CRC is available
INPUT ACTION
Delivery of erroneous
SDU
Payload CRC Check
result
Actions taken at CN on the receiving side
Yes Not OK Frame forwarded with FQC set to bad
No Not OK Drop frame, send Iu-UP-status primitive
indicating No data at the RNL-SAP
Not Applicable Any result Frame forwarded with FQC as set by UTRAN
Any value OK Frame forwarded with FQC as set by UTRAN

On the CN sending side, the support mode function adds CRC for frame payloads (if
needed), which then are transmitted together with FQC (in the case of transcoding,
FQC is normally set as good).

1-34
If CRC is available, in SRNC the support mode function will perform a CRC check.
Based on the FQC and the CRC check result, a decision is made whether to deliver the
frame or not. The actions corresponding to FQC setting and CRC check results are
shown in Table 1-6.
Table 1-6 Actions corresponding to FQC setting and CRC check results
INPUT ACTION
Delivery of
erroneous SDUs
FQC CRC check (if
payload CRC
present)
Actions taken at SRNC on the receiving
side
Yes Bad Any result Drop frame
No Bad Any result Drop frames
Yes Bad radio Any result Drop frame
No Bad radio Any result Drop frame
Yes Any value Not OK Drop frame
No Any value Not OK Drop frame
N/A Any value Any result Pass the frame to radio interface protocols
Any value Good OK Pass the frame to radio interface protocols

The case where SRNC receives a frame with the FQC set to "bad radio frame"
corresponds to a TrFO case. The frame is then trashed by the receiving RNC since
there is currently no means to pass the frame quality indicator down to the UE.
1.3.5 Elementary Procedures
In support mode, the elementary procedures of the lu UP protocol involve transfer of
user data, initialization, rate control, time alignment, error event process and frame
qualification classification.

Note:
The basic procedures described in this section are all in support mode of the lu UP protocol.


1-35
I. Transfer of User Data Procedure
The purpose of this procedure is to transfer lu user plane frames between the two lu
user plane protocol layers at the two ends of the lu interface. At present the user data
transferred by the lu UP protocol are mainly AMR speech service data.
As one lu user plane instance can only associate with one RAB, the user data being
transferred only relate to the associated RAB.
The message flow in transfer user data procedure is shown in Figure 1-45 and Figure
1-46.
CN/
RNC
RNC/
CN Transfer of User Data
(RFCI, payload)

Figure 1-45 Successful user data transfer
CN/
RNC
RNC/
CN
Transfer of User Data
(RFCI, payload)
1)
2)

1) Corrupted frame 2) Detection of Frame loss
RFCI: RAB sub Flow Combination Indicator
Figure 1-46 Unsuccessful user data transfer flow
The procedure is invoked by the Iu UP upper layers upon reception of the upper layer
PDU and associated control information: RFCI.
If necessary, NAS data stream function performs CRC check of the upper-layer PDU,
and then sends CRC check results together with RFCI information to the frame
handling function. The frame handling function then retrieves the frame number from its
internal memory, formats the frame header and the payload into the appropriate PDU
type and then transmits lu user frame PDU of to the lower layer of the lu interface.

1-36
When receiving a user data frame, the lu user-plane protocol layer will check the
consistency of the lu user-plane frame as below:
The frame handling function is responsible for checking the consistency of the
frame header. If correct, this function stores the frame number and passes the lu
user-plane payload and related CRC information (if CRC check is present) to the
NAS data stream function. And the RFCI received is transmitted to the procedure
control function.
The NAS data stream functions check the payload CRC (if CRC is available). If the
procedure control function indicates RFCI is correct and matches the lu user-plane
frame payload, the NAS data stream functions will send the RFCI and the payload
to the upper layers.
II. Initialization Procedure
Initialization procedure means that during data transfer, the lu user planes of RNC and
CN must establish the corresponding relationship between RFCI and RAB sub-flow
size, including user rate types the bearer path should support, intervals of speech data
frames sending, the protocol version used by RNC and CN, etc. This procedure is
mandatory for RABs using the support mode for predefined SDU size.
The message flow in the initialization procedure is shown in Figure 1-47. For R4, both
RNC side and CN side can originate this procedure.

*
Transfer Of User Data
CN/
RNC
INITIALISATION
((RFCI, SDU sizes[, IPTIs
2)
])m)
INITIALISATION ACK
* it can repeated n times
2)
optional
RNC/
CN

Figure 1-47 Initialization procedure
The procedure is described in detail as below:
RNC sends an initialization frame containing the user rate type, the interval for
speech data frames sending, the protocol version used at the two sides.
On receiving this frame, CN checks whether the information in the frame is correct.
If correct, CN will return a reply indicating correct initialization. When receiving the
reply, RNC will begin to transfer data.
If the information is wrong, CN will return a reply indicating wrong initialization.
Upon receiving this reply, RNC will send the initialization frame once again.

1-37
Initialization procedure occurs when speech channel is set up or switched over. CN
initiates this procedure to the RNC after switchover. Initialization procedure can also be
called lu UP protocol RFCI correction procedure.
III. Iu Rate Control Procedure
The lu rate control procedure is to control the rate of user data sending from CN to RNC,
that is, the working rate of AMR encoder. The purpose of this procedure is to notify the
peer lu UP protocol entity of the rate range allowed by the local lu UP protocol entity.
The message flow in this procedure is shown in Figure 1-48.

CN/
RNC
RNC/
CN
RATE CONTROL
(RFCI indicators)
RATE CONTROL ACK
(RFCI indicators)

Figure 1-48 lu rate control procedure
RNC/CN sends a rate control frame firstly. When receiving the frame, CN/RNC will
adjust the encoder working mode according to the rate information in the frame.
In normal cases when other signals are transmitted through the user data path, the
speech rate needs to be lowered. And when signals transmission is completed, the
speech rate needs to be increased. During this process, lu rate control procedure takes
effect.
Another typical case which lu rate control procedure is applied to is the handover
process. RNC may initiate immediate lu rate control procedure so that the RNCs at two
sides in the TrFO service can exchange information with each other as soon as
possible and services after handover can be correctly processed.
IV. Time Alignment Procedure
Time alignment procedure is to adjust the phase of user data frames sent from CN to
RNC. The message flow is shown in Figure 1-49.

1-38

CN
RNC
TIME ALIGNMENT
ACK
User data with bad timing
User data with adjusted timing

Figure 1-49 Time alignment procedure
RNC is responsible for this procedure. When RNC finds that the user data frames from
CN can not satisfy the system time requirements, it will send a time alignment frame to
request CN to adjust the time along with user data frames. If the time can be adjusted,
CN will return to RNC a reply frame indicating correct time alignment; otherwise, a reply
frame indicating error time alignment will be returned.
V. Handling of Error Event Procedure
This procedure is applied to handling of the abnormal transfer system condition
between RNC and CN, processing of lu user-plane error reports and error events and
maintenance of the system. The message flow is shown in Figure 1-50.
CN/
RNC
RNC/
CN
Error event
(Cause value,
Error distance)

Figure 1-50 Handling of error event procedure
When the protocols at the RNC side or CN side discover abnormal conditions, RNC or
CN will send error reports composed of error event frames to notify CN or RNC.

1-39
VI. Frame Quality Classification Procedure
This procedure, collaborated with the user data transfer procedure, is to exchange
frame qualify information at lu user-plane interfaces. The message flow is shown in
Figure 1-51.
CN/
RNC
RNC/
CN Transfer of User Data
(FQC, RFCI, payload)
Transfer of User Data
(FQC, RFCI, payload)

Figure 1-51 Frame quality classification procedure

Chapter 2 BSSAP

2-1
Chapter 2 BSSAP
2.1 Overview
Base Station Subsystem Application Part (BSSAP) is the application protocol used on
the A interface to the GSM network.
2.1.1 Definition and Functions of the A Interface
The A interface is defined as the communication interface between GSM Network
Subsystem (NSS) and Base Station Subsystem (BSS). In terms of system, it
interfaces a Mobile Service Switching Center (MSC) and a Base Station Controller
(BSC). Standard 2.048Mb/s digital transport links are used. Information carried
through this interface includes mobile station management, base station management,
mobility management, connection management, etc.
The BSSAP protocol used on the A interface describes two classes of messages,
namely BSSMAP messages and DTAP messages. BSSMAP messages are
responsible for service process control and are handled by the corresponding A
interface internal functional module. For DTAP messages, the A interface only
functions as a transport channel. At BSS side, DTAP messages are directly conveyed
to a radio channel; at NSS side, DTAP messages are carried to the corresponding
functional processing unit. The BSSAP protocol is 3GPP TS 08.08 compliant.
2.1.2 BSSAP Implementation in MSOFTX3000
MSOFTX3000 with UMG8900 Universal Media Gateway integrated inside can be
used as a MSC/VLR in GSM where the BSSAP protocol is utilized for communication
with a BSS. See Figure 2-1.
Chapter 2 BSSAP

2-2
MSOFTX3000
UMG8900
MSC/VLR
A
BSSAP
BSS
BSC
MSOFTX3000
Internal
interface
UMG8900
MSC/VLR
A
BSSAP
BSS
BSC

Figure 2-1 BSSAP protocol implementation in MSOFTX3000
2.1.3 Structure of the Protocol Stack
The structure of the A interface protocol stack is shown in Figure 2-2.
BSC
A
MSC Server
DTAP
SCCP
MTP3
MTP2
MTP1
BSSMAP
BSSAP
DTAP
SCCP
MTP3
MTP2
MTP1
BSSMAP
BSSAP
BSC
A
MSC Server
DTAP
SCCP
MTP3
MTP2
MTP1
BSSMAP
BSSAP
DTAP
SCCP
MTP3
MTP2
MTP1
BSSMAP
BSSAP

Figure 2-2 Structure of the A interface protocols
BSSAP user protocols include Direct Transfer Application Part (DTAP) and Base
Station Subsystem Management Application Part (BSSMAP). Both parts are borne
over the SCCP protocol. The underlying signaling transport protocol is TDM based
MTP.
Chapter 2 BSSAP

2-3
2.2 Introduction of BSSAP Protocol
2.2.1 BSSAP Messages
According to different message functions and handling modes, BSSAP messages are
classified into DTAP messages and BSSMAP messages.
I. DTAP Messages
DTAP messages are divided into Mobility Management (MM) messages and Call
Control (CC) messages. DTAP messages are not interpreted by the BSSAP protocol.
Instead, DTAP messages are conveyed transparently.
MM messages include those pertaining to authentication, CM service request, service
reconstruction, identification request, IMSI detach, location update, MM status, TMSI
reallocation, etc.
CC messages include those relating to alerting, call proceeding, connection, setup,
modification, release, disconnection, announcement, status query, starting DTMF, and
hold, retrieve, etc. involving supplementary services.
II. BSSMAP Messages
BSSMAP messages are divided into connectionless messages and
connection-oriented messages.
1) Connectionless messages
Connectionless messages include those pertaining to (group) blocking and
unblocking, handover, resource, reset, paging, etc.
Blocking and unblocking messages include block, block acknowledgement,
unblock and unblock acknowledgement messages. Group blocking and
unblocking messages include group block, group block acknowledgement, group
unblock and group unblock acknowledgement messages.
Handover messages include handover candidate enquiry and handover
candidate enquiry response messages.
Resource messages include resource request and resource indication
messages.
Resetting messages include reset and reset confirmed messages.
2) Connection-oriented messages
Connection-oriented messages include those pertaining to assignment, handover,
clear, authorization, cipher, etc.
Assignment messages include assignment request, assignment complete and
assignment failure messages.
Chapter 2 BSSAP

2-4
Handover messages include handover request, handover request confirmed,
handover command, handover complete and handover failure messages.
Clear messages include clear request, clear command and clear complete
messages.
Authentication messages include authentication request, authentication
response and authentication reject messages.
Cipher messages include cipher mode command and cipher mode command
completed messages.
2.2.2 Message Structure
BSSAP messages are encapsulated in the user data part of SCCP messages. The
message structure is shown in Figure 2-3.
MTP message SCCP message BSSAP message

Figure 2-3 BSSAP message structure
2.2.3 BSSMAP Procedures
BSSMAP protocol mainly implements the following functional procedures:
I. Assignment
The purpose of the Assignment procedure is to ensure that the correct dedicated
radio resource can be allocated or reallocated to a MS that requires it. However, the
initial random access by the MS and Immediate Assignment to a DCCH is handled
by the BSS without reference to the MSC.
II. Blocking and Unblocking
The Assignment procedure depends upon the MSC choosing the terrestrial resource
to be used. The MSC therefore needs to be informed of any terrestrial circuits that are
out of service at the BSS. This is performed by using a simple blocking/unblocking
procedure.
III. Resource Indication
The purpose of the Resource Indication procedure is to inform the MSC of the
following information:
the amount of radio resource that is spare at the BSS and available for traffic
carrying purposes;
Chapter 2 BSSAP

2-5
the total amount of the accessible radio resource (that is, available for service or
currently assigned).
This cannot easily be derived from the traffic that the MSC is carrying. The MSC may
take these pieces of information into account for the external handover decision.
IV. Reset
The purpose of the Reset procedure is to initialize the BSS or MSC in the event of a
failure. For example, in the event of a failure at the BSS which has resulted in the loss
of transaction reference information, a RESET message is sent to the MSC. This
message is used by the MSC to release affected calls and erase all affected
references, and to put all circuits to the idle state.
In case of a failure at a part of the MSC or BSS, the Clearing procedure can be used
to erase the affected parts.
V. Handover Required
Due to the following reasons, the BSS will send a HANDOVER REQUIRED message
to the MSC to implement handover for a MS with the assigned dedicated resource:
The BSS has detected a message in which handover required is indicated.
The MSC has initiates a Handover Candidate Enquiry procedure, and this MS is
currently awaiting the handover.
A cell change is required at call setup due to congestion, for example, directed
retry.
The HANDOVER REQUIRED message is retransmitted with a periodicity until:
A HANDOVER COMMAND message is received from the MSC, or
A RESET message is received, or
All communication is lost with the MS, and the transaction is abandoned, or
The transaction ends, for example, call clearing.
VI. Handover Resource Allocation
The Handover Resource Allocation procedure enables the MSC to request resources
from a BSS according to the handover requirements. The target BSS will reserve the
resource and awaits access of a MS on the reserved channel.
Chapter 2 BSSAP

2-6
VII. Handover Execution
Handover Execution is the process whereby an MSC instructs an MS to tune to a new
dedicated radio resource on a different cell. During handover execution, the dedicated
radio resources will not be released and the terrestrial resources will not be marked
as idle until the a CLEAR COMMAND message is received from the MSC or a reset
occurs.
VIII. Release of Radio Resource and Terrestrial Resource
After a transaction is completed, the MSC sends a CLEAR COMMAND to indicate to
the BSS to release the radio resources. Upon reception of the command, the BSS
initiates the Clearing procedure on the radio interface. Then, the BSS marks any
assigned terrestrial circuit as idle and returns a CLEAR COMPLETE message to the
MSC. On receipt of CLEAR COMPLETE, the MSC releases any assigned terrestrial
resources at the local end.
If a resource release is required because of a BSS generated reason, the BSS shall
generate a CLEAR REQUEST message to inform the MSC to initiate the Release
procedure, so as to release the terrestrial and radio resources associated with MSC
and BSS.
IX. Paging
PAGING messages for all MSs are sent through the BSSMAP as a connectionless
message. When the BSS receives a radio interface PAGING RESPONSE message,
a SCCP connection is set up towards the MSC. The PAGING RESPONSE message
is taken in a COMPLETE LAYER 3 message of BSSMAP and is carried to the MSC
through the signaling connection.
X. Flow Control
The flow control is adopted to prevent entities from entering unstable status due to
overload. The flow control on the A interface is implemented by controlling traffic at
the traffic source. 15-level flow control is provided. Flow control can be executed
according to user levels.
XI. Classmark Updating
The purpose of the Classmark Updating procedure is to inform the receiving entity
about classmark information received from the MS. In normal conditions, the BSS
receives the classmark information from the MS and then informs the MSC. Another
possibility is that the MSC sends to the new BSS the corresponding MS classmark
information through the A interface after the handover is completed.
Chapter 2 BSSAP

2-7
XII. Cipher Mode Control
The Cipher Mode Control procedure allows the MSC to pass cipher mode control
information to the BSS to select and load the user device and signaling encryption
device with the appropriate key.
XIII. Queuing Indication
The purpose of the Queuing Indication procedure is to inform the MSC about a delay
in the allocation of the necessary dedicated radio resources by the BSS. The
procedure is only relevant if the system is using a queuing procedure for traffic
channels in the BSS and for handover of traffic channels.
XIV. Load Indication
The purpose of the Load Indication procedure is to inform all adjacent BSSs about
the traffic of a cell so that a global control can be imposed on traffic handover in a
MSC. During some effective time segment, the traffic of the close cell shall be taken
into account for handover between adjacent BSSs.
Chapter 3 MAP

3-1
Chapter 3 MAP
3.1 Overview
3.1.1 Definition of the MAP Interfaces
Mobile Application Part (MAP) defines how information is exchanged between mobile
system communication network entities for the purpose of achieving Mobile Station
(MS) roaming function. Concerned network entities include Mobile Service Switching
Center Server (MSC Server), Visitor Location Register (VLR), Serving GPRS Support
Node (SGSN), Home Location Register (HLR), Short Message Center (SMC) and
Gateway Mobile Location Center (GMLC). In the UMTS network, C, D, E, G, Lg or L
interface can be used to convey MAP messages, thus all of them are called MAP
interface.
I. C Interface
The C interface is the interface between a MSC Server and a HLR. On this interface,
the MSC Server uses the MAP protocol of SS7 to carry signaling. The MSC Server
implements the following functions:
In a Mobile Terminated Call (MTC), the MSC/GMSC Server gets the routing
information from the HLR through the C interface. The HLR provisions through
the C interface to the MSC/GMSC Server the routing information and subscriber
management information (including subscriber status, subscriber location, and
subscription information.).
Short message service (mobile terminated short message getting routing
information process).
For CAMEL applications, this interface is used to get routing information,
subscriber status, and subscription information when a mobile subscriber
terminates the call.

Note:
MSOFTX3000 and HLR9820 support MAP Phase1, MAP Phase2 and MAP Phase3, and allows network
carriers to select specifications for different phases according to the functional requirements.

Chapter 3 MAP

3-2
II. D Interface
The D interface is the interface between a VLR and a HLR. This interface is used to
exchange mobile station location information and subscriber management information
between the HLR and the VLR. On this interface, the VLR uses the MAP protocol of
SS7 to carry signaling, and supports the following functions:
Getting authentication information
Location updating
Provisioning mobile terminated roaming number
Supplementary services
VLR restoration
Subscriber data management function
For the purpose of ensuring that a mobile subscriber can establish and accept calls in
the whole serving area, data exchange between the VLR and the HLR is required.
For instance, the VLR has to notify the HLR of information about the current location
of the subscriber; the HLR has to send to the VLR all service data pertaining to the
subscriber. If the subscriber resident VLR area is already changed, the HLR also has
to delete the location information and service data pertaining to the mobile subscriber
in the previous roaming VLR. In addition, modification requests (for example,
supplementary service operations) concerning used services by the subscriber and
modifications in subscriber data by the carrier shall be exchanged through the D
interface.
III. E Interface
The MAP interface between two MSC Servers and the MAP interface between a MSC
Server and a SMC are defined as the E interfaces. Signaling interworking is achieved
by the MAP protocol of SS7. The MAP protocol mainly implements the following
functions:
Handover
Short message service
MAP controls handover between two MSC Servers in adjacent areas. When a mobile
station in a call is moving from an area controlled by a MSC Server to the area
controlled by another MSC Server, the handover operation must be started and
implemented between the MSC Servers for the purpose of not breaking the
communication.
IV. G Interface
The G interface is resident between two VLRs. Signaling interworking is achieved by
the MAP protocol of SS7. The function realized through this interface is:
Chapter 3 MAP

3-3
When a mobile subscriber roams to a new VLR controlled area, the current VLR gets
IMSI and authentication set information from the previous VLR (if the authentication
set is still in use).
V. Lg Interface
The Lg interface is located between a MSC Server and a GMLC. The interface is
used to support Location Services (LCS) functions. Signaling interworking is achieved
by the MAP protocol of SS7. The functions realized through this interface include:
The GMLC initiates a location request message of the target subscriber to the
MSC Server currently in service.
The MSC Server returns to the GMLC the outcome of the location request.
The MSC Server reports to the GMLC the location information of the target
subscriber.

Note:
Both MSC Server and VLR are integrated in MSOFTX3000 entity. Accordingly, the B interface becomes
an internal interface, the C and D interfaces can use the same physical connection, and the E and G
interfaces can use the same physical connection.

VI. L Interface
The L interface is the MAP interface between a SSP and a SCP. The interface is used
for supplementary service invocation reports.
3.1.2 Functions of the MAP Interfaces
In CSCN, the MAP message handling module is strictly 3GPP TS 29.002 V3.9.0
(2001-06) specification compliant. The module provisions all basic functions defined
in 3GPP TS 29.002, including:
Version negotiation function;
Mobility management, supporting the management on the mobility of both 2G
and 3G subscribers, and supporting to notify the Service Control Point (SCP)
function of mobility events;
Subscription data management, including management on ordinary service
subscription data, LCS and CAMEL subscription data;
Error recovery, including data restoration and HLR restart announcement;
Security management, including authentication, encryption and consistency
check, and TMSI reallocation;
Chapter 3 MAP

3-4
Call handling, including access of calling & called subscribers, obtaining routing
information and providing roaming number;
Handover control, including intra-office handover inside the UMTS system, and
intra-office handover between UMTS and GSM systems;
Supplementary services, including call related and call independent
supplementary services, and notifying the SCP function of supplementary
service events;
Short message, including mobile originated and mobile terminated short
messages, and short message intelligent trigger function;
Location service, including mobile originated and mobile terminated location,
emergency call location and operation and maintenance location.
3.1.3 MAP Implementation in CSCN
Implementation of MAP interfaces in CSCN is illustrated in Figure 3-1.
E/G
MSC Server
MSC Server/VLR
(MSOFTX3000)
HLR
SCP
GMLC
SMC
C/D
L
Lg
E
MAP
E/G
MSC Server
MSC Server/VLR
(MSOFTX3000)
HLR
SCP
GMLC
SMC
C/D
L
Lg
E
MAP

Figure 3-1 MAP protocol implementation in CSCN
MSOFTX3000 and HLR9820 provide two ways to transfer the MAP protocol: TDM
based and IP based. The TDM based way is to make use of the services provided by
the MTP for information transfer; the IP based way is to make use of the services
provided by the SIGTRAN protocol for transmission. The protocol stack is shown in
Figure 3-2
C, D, E, G, Lg, and L MAP interfaces all follow this protocol stack structure.
Chapter 3 MAP

3-5
MAP
SCCP
MTP3
MTP2
MTP1
(a) TDM based (b) IP based
TCAP
SCCP
SCTP
IP
MAC
M3UA
TCAP
MAP
SCCP
MTP3
MTP2
MTP1
TCAP
MAP
TCAP
SCCP
SCTP
IP
MAC
M3UA
MAP
C/D/E/
G/Lg/L
C/D/E/
G/Lg/L
MAP
SCCP
MTP3
MTP2
MTP1
TCAP
SCCP
SCTP
IP
MAC
M3UA
TCAP
MAP
SCCP
MTP3
MTP2
MTP1
TCAP
MAP
TCAP
SCCP
SCTP
IP
MAC
M3UA
MAP
C/D/E/
G/Lg/L
C/D/E/
G/Lg/L

Figure 3-2 Position of MAP interface in the protocol stack
3.2 Introduction of MAP Protocol
In the Signaling System No.7, MAP messages are transported as TCAP message
component part. Codes of MAP messages use the ASN.1 format. The position in a
link message is shown in Figure 3-3.
MTP
Message
SCCP
Message
TCAP
Message
MAP
Message
MTP
Message
SCCP
Message
TCAP
Message
MAP
Message

Figure 3-3 Position of MAP in a link message
There is a one-to-one relationship between the types of MAP messages and the
operation codes in TCAP component. In the message transfer process, allocation of
an Invoke ID is required by each initiated operation. The Invoke ID is uniquely used to
identify an operation in the MAP dialog process. By distinguishing the operation code,
a component can be "translated" to a corresponding MAP message. Message
translation between MAP and TCAP is made by MAP PM.
3.2.2 Operation Types
In CSCN, MAP supports the operations defined in 3GPP TS 29.002, as shown in
Table 3-1.
Chapter 3 MAP

3-6
Table 3-1 Operations supported by MAP in MSOFTX3000
Operati
on
code
Operation name Purpose
0x02 UpdateLocation
Used by VLR to initiate the location update procedure to
HLR in case of inter-VLR location update or subscriber data
unconfirmed by HLR.
0x03 CancelLocation
Used by HLR to delete the subscriber data of the previous
VLR in location update, or independent location deletion
caused by subscriber data modification, or deletion of
subscriber location information by operator.
0x04 ProvideRoamingNumber
Used by HLR to get the roaming number from VMSC
Server, so that GMSC Server can address the call to the
present location of the called subscriber to set up the call.
0x07 insertSubscriberData
Used by HLR to insert in VLR the subscription data during
location update, and independently insert subscriber data
during subscriber data modifications.
0x08 deleteSubscriberData
Used by HLR to independently delete the subscription data
in VLR when the operator deletes subscriber data.
0x09 sendParameters
Phase1 operation used to get the identity & authentication
set of the subscriber from the previous VLR, to get
authentication set from HLR and for Phase1 data restoration
request & inserting subscriber data.
0x0A registerSS
Used for the registration of call forwarding supplementary
services.
0x0B eraseSS
Used for the deletion of call forwarding supplementary
services.
0x0C activeSS
Used for the activation of call forwarding, call barring and
CW supplementary services.
0x0D deactiveSS
Used for the deactivation of call forwarding, call barring and
CW supplementary services.
0x0E interrogateSS
Used for the interrogation of line identification, call
forwarding, call barring and CW supplementary services.
0x0F
authenticationFailureRep
ort
Used to report to HLR an authentication failure in the event
of an authentication failure.
0x11 registerPassword
Used to modify the password for barring supplementary
service operations.
0x12 getPassword
Used to activate/deactivate barring supplementary services
and to get the user password when modifying the barring
password.
0x13
processUnstructureSS-Da
ta
Used for Phase1 mobile originating unstructured
supplementary service.
Chapter 3 MAP

3-7
Operati
on
code
0x16 sendRoutingInformation
Used by GMSC Server to get the subscriber location
information from HLR, including roaming number and
forwarded-to number, when the subscriber is called.
0x1C performHandover Used for the Phase1 handover request.
0x1D sendEndSignal Used for handover termination.
0x1E
PerformSubsequentHand
ov-er
Used for the Phase1 subsequent handover request.
0x21 processAccessSignalling
Used by MSC Server b to transparently transmit access
information to MSC Server a.
0x22 ForwardAccessSignalling
Used by MSC Server a to transparently transmit access
information to MSC Server b.
0x25 reset Used to inform VLR that HLR is already reset.
0x26 forwardcheckssindication
Used by HLR to inform about the possible incorrectness of
user supplementary service data after restart.
0x2E forwardSM
Used for mobile originating and mobile terminating short
messages.
0x2F reportSM-DeliveryStatus Used for the report in case of short message issue failure.
0x30 noteSubscriberPresent
Phase1 operation used for the announcement about short
message subscriber location updates or memory availability.
0x38 sendAuthenticationInfo
Used by VLR to get the authentication information from
HLR.
0x39 restoreData
Used by VLR to get the subscription data from HLR when
the called HLR requests VLR for the roaming number but
VLR does not contain the subscriber data.
0x3A sendIMSI To get the subscriber IMSI through MSISDN.
0x3B
processUnstructuredSS-R
request
Used for the mobile originating unstructured supplementary
service processing.
0x3C unstructuredSS-Rrequest
Used for the network originating unstructured
supplementary service processing.
0x3D unstructuredSS-Notify
Used for the network originating unstructured
supplementary service announcement.
0x42 readyForSM
Used for the announcement of short message subscriber
location update or memory availability.
0x43 purgeMS
Used by VLR to report to the HLR about its subscriber
deletion operation.
0x44 prepareHandover Used for the non-Phase1 handover request.
0x45
PrepareSubsequentHand
ov-er
Used for the non-Phase1 subsequent handover request.
Chapter 3 MAP

3-8
Operati
on
code
0x46 provideSubscriberInfo
Used by HLR to get the subscriber location information and
status information data from VLR.
0x48 SsInvocationNotification
Used to report to SCP the supplementary service
invocation event when CD, ECT, MPTY
supplementary services are invoked.
0x53
ProvideSubscriberLocatio
n
Used for mobile terminating location request.
GMLC initiates the location request to MSC
Server, and MSC Server responds to GMLC with
the location outcome.
0x55 sendRoutingInfoForLCS
Used to request HLR for routing information
when GMLC initiates the mobile terminating
location request.
0x56 SubscriberLocationReport
Used for emergency call or mobile originating
location request, and MSC Server reports to
GMLC the location outcome information.
0x59 NoteMMEvent
Used to report the event to SCP when normal
location update, IMSI attach, IMSI detach, and
combined location update are done at the
subscriber.

3.3 Signaling Procedures
The location updating procedure and the routing information procedure are the most
basic procedures supported by MAP for inter-network roaming of mobile subscribers.
Other procedures include supplementary service handling, short message, handover
handling, authentication, and so on. In the following section, MAP signaling
procedures are illustrated by two typical examples.
I. Location Updating Procedure
Upon reception of the location updating request message, the VLR judges the
location area. If the updating is not in the same VLR location area, a location updating
request is sent to the HLR. When the HLR returns an acknowledgement message to
the VLR, the HLR number is attached. The location updating procedure may involve
the procedures of getting subscriber identity from the Previous VLR (PVLR), getting
authentication information from HLR, location deletion procedure, and inserting
subscriber data procedure.
1) If the MSC Server/VLR receives a location updating request initiated by the
subscriber using TMSI, and the previous location area information contained in
the location updating request message indicates a location area of an adjacent
Chapter 3 MAP

3-9
VLR, then the VLR initiates the procedures of getting subscriber IMSI and
authentication information from the PVLR.
2) The MSC Server/VLR receives the location updating request from the subscriber.
If authentication made on data configurations is required but there is not an
available authentication set, the MSC Server/VLR will initiate the request for
getting authentication information to the HLR.
3) After the HLR receives the location updating request from the MSC Server/VLR,
the HLR finds that the subscriber roaming-to MSC/VLR number is changed. In
this case, the HLR will initiate the location deletion procedure to the PVLR to
remove the subscriber information in the PVLR.
4) The HLR sends subscriber data to the VLR.
The procedures of getting subscriber identity and authentication information from
PVLR, getting authentication information from HLR, location deletion in PVLR,
inserting subscriber data and D-interface location updating are all relatively
independent. They co-ordinate each other to complete the location updating
procedure of the subscriber to HLR. D-interface location updating and inserting
subscriber data procedures are necessary, while the other three procedures are
triggered only when conditions are met.
The location updating procedure is illustrated in Figure 3-4.
MSC Server
/VLR
A_LU_REQUEST
UTRAN UE HLR
PVLR
MAP_SEND_IDENTIFICATION
ack
MAP_UPDATE_LOCATION
MAP_CANCEL_LOCATION
MAP_CANCEL_LOCATION
ack
MAP_INSERT_SUBSCRIBER_DATA
MAP_INSERT_SUBSCRIBER_DATA ack
MAP_UPDATE_LOCATION ack
A_LU_CONFIRM

Figure 3-4 Location updating procedure
Chapter 3 MAP

3-10
II. Send Routing Information (SRI) Procedure
The SRI procedure requires the co-ordination of the roaming number assignment.
When the HLR receives the request for SRI from the GMSC Server, the forwarded-to
number or absent subscriber message is returned if the subscriber is in the inactive
status; otherwise the request for roaming number is initiated to the subscriber
roaming-to VLR, and a corresponding response is sent to the GMSC Server
according to the returned outcome from the VLR.
The SRI procedure is illustrated in Figure 3-5.
GMSC
Server
MAP_SEND_ROUTING_
INFORMATION
Network
VLR HLR
MAP_PROVIDE_SUBSCRIBER_
INFORMATION
MAP_PROVIDE_SUBSCRIBER_
INFORMATION ack
MAP_SEND_ROUTING_
INFORMATION ack
MAP_PROVIDE_ROAMING_
NUMBER
MAP_PROVIDE_ROAMING_
NUMBER ack
MAP_SEND_ROUTING_
INFORMATION
MAP_SEND_ROUTING_
INFORMATION ack
IAM

Figure 3-5 Send routing information (SRI) procedure
Chapter 4 H.248/MEGACO

4-1
4.1 Overview
H.248/MEGACO has been jointly developed within the ITU-T and the IETF. It is named
H.248 by the ITU-T and MEGACO by the IETF. Hereinafter, both are called H.248 in
this manual.
H.248 is a media gateway control protocol. In a decomposed gateway model, the
H.248 protocol is used for the communication between a media gateway controller
(MGC) and a media gateway (MG), implementing the function of the MGC controlling
MGs. In UMTS, the H.248 protocol is applied on the Mc interface.
4.1.1 Definition and Functions of the Mc Interface
I. Definition of the Mc Interface
The Mc interface is the standard interface between the MSC Server (GMSC Server)
and the MGW. It is H.248 protocol compliant. Aiming at special requirements of 3GPP,
H.248 extended Transaction and Package are defined. The Mc interface is an
additional interface for 3GPP R4. The physical interface mode may be ATM or IP.
Protocol messages through the Mc interface may be encoded in a binary format or in a
text format. The underlying transmission mechanism provides protocol bearer for it by
using MTP3b (ATM based signaling transfer) or SCTP (IP based signaling transfer).
II. Functions Provided by the Mc Interface
The Mc interface provides the capabilities of the static and dynamic resources for the
MSC Server (GMSC Server) controlling the various transmission modes (IP/ATM/TDM)
in the MGW in the call processing procedure, such as terminal property, terminal
connection switching relationship, MGW borne media streams. The Mc interface also
provides the call independent MGW status maintenance and management capability.
4.1.2 H.248 Implementation in CSCN
The H.248 protocol is utilized on the interface between MSOFTX3000 and UMG8900,
namely Mc interface defined in UMTS. See Figure 4-1.

4-2
Nc
MSC Server
(MSOFTX3000)
Mc Mc
MWG
(UMG8900)
MWG
(UMG8900)
H.248 H.248
GMSC Server
(MSOFTX3000)
Nc
MSC Server
(MSOFTX3000)
Mc Mc
MWG
(UMG8900)
MWG
(UMG8900)
H.248 H.248
GMSC Server
(MSOFTX3000)

Figure 4-1 H.248 protocol implementation in CSCN
As shown in Figure 4-2, the H.248 protocol is applied to the Mc interface. Protocol
transmission may be based on IP (figure a) or based on ATM (figure b). IP based
transmission is typically used due to the current networking architecture.
H.248
SCTP
IP
MAC
L1
(G)MSC Server
Mc
MGW
a) IP based
Mc
MGW
b) ATM based
(G)MSC Server
H.248
H.248
SCTP
IP
MAC
L1
STC
SAAL
AAL5
MTP3B
ATM
PL
H.248
STC
SAAL
AAL5
MTP3B
ATM
PL
H.248
SCTP
IP
MAC
L1
(G)MSC Server
Mc
MGW
a) IP based
Mc
MGW
b) ATM based
(G)MSC Server
H.248
H.248
SCTP
IP
MAC
L1
STC
SAAL
AAL5
MTP3B
ATM
PL
H.248
STC
SAAL
AAL5
MTP3B
ATM
PL

Figure 4-2 Structure of H.248 protocol

4-3
4.2 Introduction of H.248 Protocol
4.2.1 Overview
I. Basic Concepts
Media Gateway (MG): The media gateway converts media provided in one type of
network to the format required in another type of network. For example, a MG
could terminate bearer channels from a switched circuit network (for example,,
PCM) and media streams from a packet network (for example,, media streams in
an IP network). This gateway may be capable of processing audio, video and data
alone, and will be capable of full duplex media translations. The MG may also play
some audio/video signals and perform a number of interactive voice response
(IVR) functions, or may perform media conferencing.
Media Gateway Controller (MGC): Controls the parts of the call state that pertain
to connection control for media channels in a MG.
Multipoint Control Unit: An entity that controls the setup and coordination of a
multi-user conference that typically includes processing of audio, video and data.
Stream: Bidirectional media or control flow received/sent by a media gateway as
part of a call or conference.
II. Connection Model
The connection model for the protocol describes the logical entities, or objects, within
the Media Gateway that can be controlled by the Media Gateway Controller. The main
abstractions used in the connection model are Terminations and Contexts. Figure 4-3
illustrates the connection model:
Termination
SCN Bearer Channel
Termination
SCN Bearer Channel
Termination
RTP Stream
Context
Context
Context
Media Gateway
Null Context
*
Termination
SCN Bearer Channel
Termination
SCN Bearer Channel
Termination
RTP Stream
*
Termination
RTP Stream
*
Context

Figure 4-3 Example of H.248/MEGACO connection model

4-4
In the connection model defined by the H.248/MEGACO, two entities, namely Context
and Termination, are included. A Context shall contain one or more Terminations;
otherwise, the Context will be deleted. A Termination shall exist in only one Context at a
single time point.
1) Context
A Context is an association between a number of Terminations. The Context describes
the topology and the media mixing/switching parameters if more than two Terminations
are involved in the association.
There is a special Context called the null Context. It contains Terminations that
Terminations that are not associated to any other Termination. Terminations in the null
Context can have their parameters examined or modified, and may have events
detected on them.
The maximum number of Terminations in a Context is a MG property.
The attributes of Contexts are:
ContextID: Context identifier, which is 32-bit and uniquely identifies a Context
within the scope of the MG.
Some special contextIDs are coded as shown in Table 4-1:
Table 4-1 Codes of special Contexts
Context Binary code Text code
NULL Context 0 -
CHOOSE Context 0xFFFFFFFE $
ALL Context 0xFFFFFFFF *

Topology: The topology of a Context describes the flow of media between the
Terminations within a Context. In contrast, the mode of a Termination describes
the flow of the media at the ingress/egress of the media gateway.
Priority: The priority is used for a Context in order to provide the MG with
information about a certain precedence handling for a Context. The value range is
0~15. The less the value is, the higher the priority is.
Emergency indicator: An indicator for an emergency call is also provided to allow a
preference handling in the MG.
2) Termination
A Termination is a logical entity on a MG that sources and/or sinks media and/or control
streams. A Termination is described by a number of characterizing properties, which
are grouped in a set of descriptors that are included in commands. Terminations have
unique identifies (TerminationIDs), assigned by the MG at the time of their creation.

4-5
Usually Terminations are grouped into two classes: semi-permanent Terminations and
ephemeral Terminations. Terminations representing physical entities have a
semi-permanent existence. For example, a Termination representing a TDM channel
might exist for as long as it is provisioned in the gateway. Only if the configuration
information is deleted, the corresponding Termination disappears. Ephemeral
Terminations represent ephemeral information flows, such as RTP flows, would usually
exist only for the duration of their use. Ephemeral Terminations are created by means
of an Add command. They are destroyed by means of a Subtract command. In contrast,
when a physical Termination is added to or subtracted from a Context, it is taken from or
to the null Context, respectively.
Termination dynamics: The protocol can be used to create new Terminations and
to modify the property values of existing Terminations.
TerminationIDs: Terminations are referenced by a TerminationID, which is an
arbitrary schema by the MG. A wildcarding mechanism using two types of
wildcards can be used with TerminationsIDs. The two wildcards are ALL and
CHOOSE.
Packages: Different types of gateways may implement Terminations that have
widely differing characteristics. In order to achieve MG/MGC interoperability,
optional properties of the Termination are grouped into Packages, and a
Termination realizes a set of such Packages.
Termination properties and descriptors: Terminations have properties. The
properties have unique PropertyID.
ROOT Termination: The ROOT Termination is typically used to refer to the entire
gateway. Packages may be defined on ROOT. Root thus may have properties,
events, signals, statistics and parameters. The ROOT Termination may appear in
a Modify, Notify, AuditValue, AuditCapability and ServiceChange commands. Any
other use of the ROOT TerminationID is an error.
Commands: The protocol provides commands for manipulating the logical entities
of the connection model, Contexts and Terminations. Most commands are for the
specific use of the Media Gateway Controller as command initiator in controlling
Media Gateways as command responders. The exceptions are the Notify and
ServiceChange commands: Notify is sent from Media Gateway to Media Gateway
Controller, and ServiceChange may be sent by either entity. For the meanings of
the commands, please reference the following section about command
explanation.
Descriptors: The parameters to a command are termed Descriptors. A Descriptor
consists of a name and a list of items. Descriptors may be returned in the response
as output from a command. In any such return of descriptor contents, an empty
descriptor is represented by its name unaccompanied by any list.

4-6
A message is an information unit sent by the H.248 protocol. A message may be
encoded in a binary format or in a text format.
In the case of binary codes, specifications defined in ITU-T X.680 (ASN.1) are
used for description, and BER rules defined in X.690 for encoding;
In the case of text format, RFC 2234 ABNF specifications are followed.
MGCs should support both encoding formats. MGs may support one of or both formats.
Any H.248 message shares the same structure as shown in Figure 4-4.
Megaco/H.248 message
Trans Hdr
Req or
Reply
Req or
Reply
Req or
Reply
Transaction Transaction Transaction
....
Header
Command
Ctx
Properties
Ctx Hdr Command
....
Trans Hdr
Action Action
....
....
Descriptor
Descriptor

Figure 4-4 H.248 message structure
A message contains multiple transactions that have nothing to do with each other and
can be handled separately; a transaction is composed of several actions and actions
correspond to Contexts; an action constitutes a series of commands restricted by a
Context. In this way, H.248 message mechanism is shown in Figure 4-5.

4-7
H.248 message
Transaction1
ContextID1
Command1
Des-1 Des-n
Commandn
ContextIDn
TransactionIDn
H.248 message
Transaction1
ContextID1
Command1
Des-1 Des-n
Commandn
ContextIDn
TransactionIDn

Figure 4-5 Message mechanism
I. Message
Information units transmitted or accepted by the H.248 protocol are called messages. A
message begins with the Header followed by several transactions.
The message Header contains the Message Identifier (MID) and the Version Number:
The MID identifies the message sender, and may be set to a provisioned name
(for example, domain address/domain name/device name). Domain name is a
suggested default.
The Version Number identifies the version of the protocol the message conforms
to. Versions consist of one or two digits, beginning with version 1 for the present
version of the protocol.
The transactions in a message are treated independently. There is no order implied.
II. Transaction
Commands between the Media Gateway Controller and the Media Gateway are
grouped into Transactions, each of which is identified by a TransactionID. Transactions
consist of one or more Actions. An Action consists of a series of Commands that are
limited to operating within a single Context.
A Transaction begins with a Transaction Header (TransHdr), in which TransactionID is
contained. TransactionID is assigned by the sender of the Transaction, and it is unique
within the scope of the sender.
TransHdr is followed by the Actions of the Transaction. The Actions must be executed
in order. At the first failing command in an Action, processing of the remaining
commands in that Transaction stops except Optional Command. Transactions

4-8
guarantee ordered commands processing, which is one significant function to
introduce Transactions.
Commands may be marked as Optional which can override this behavior. If a
command marked as Optional results in an error, subsequent commands in the
Transaction will be executed.
Transactions include requests and responses, and responses are divided into two
types: TransactionReply and TransactionPending.
TransactionRequest
Each TransactionRequest requests to activate one Transaction. One Transaction
contains one or more Actions and each Action includes one or more commands related
to one single Context.
The structure of TransactionRequest is as follows:
TransactionRequest(TransactionId {
ContextID {Command ... Command},
. . .
ContextID {Command ... Command } })

TransactionReply
TransactionReply is a response of the Transaction receiver to the TransactionRequest,
indicating that the receiver completes the executing of the TransactionRequest
command. Every transaction should have its Reply. The following cases indicate the
completion of the executing of a TransactionRequest:
1) All the commands in the TransactionRequest are successfully executed;
2) A non-optional command in the TransactionRequest fails to be executed.
The structure of TransactionReply is as follows:
TransactionReply(TransactionID {
ContextID { Response ...Response },
. . .
ContextID { Response ...Response } })

TransactionPending
The receiver invokes the TransactionPending. A TransactionPending indicates that the
Transaction is actively being processed, but has not been completed. It is used to
prevent the sender from assuming the TransactionRequest was lost where the
transaction will take some time to complete.
The structure of TransactionPending is as follows:

4-9
TransactionPending (TransactionID { } )

Transactions are presented as TransactionRequests. Corresponding response to a
TransactionRequest is received in a single reply, possibly preceded by a number of
TransactionPending messages.
The H.248 protocol supports the transactions as shown in Table 4-2:
Table 4-2 H.248 transactions
Transaction Description
MGW Communication
Up
Message reported by MGW after resumption of MGC-MGW
communication.
MGW Out Of Service
Reported to MGC when MGW becomes faulty, to indicate MGW to get out
of service.
MGW Restoration Restoration message reported by MGW after its recovery from fault.
MGW Register
This function actively sends the Register message to the MGC to request
for registration when the whole system is powered up. Only after
successful registration of MGW can the MGC use the resources on the
MGW.
MGW Re-Register
In some cases, such as MGC handover, MGC may request the MGW to
register again.
(G)MSC Server Ordered
Re-Register
(G)MSC SERVER requests the MGW to register again, and the MGW
initiates the transaction after it receives the command.
(G)MSC Server
Restoration
After recovery of (G)MSC SERVER from fault, (G)MSC SERVER sends
this message to the MGW.
Termination Out Of
Service
After a Termination fails, the MGW sends this message to the MGC so that
the MGC will no longer use this resource.
Termination Restoration
When the Termination recovers from failure, the MGW sends
this message to notify the MGC to update the resource
status.
Audit Value
To audit the current values of the various attributes requesting for
Termination resources.
Audit Capability
To audit the capability set of the various attributes requesting for
Termination resources.
MGW Capability
Change
In case of change of MGW due to fault or OMC configuration, the MGW
uses this transaction to notify the MGC, so that the MGC will update the
capability status of the MGW.
(G)MSC Server Out Of
Service
To notify MGW when (G)MSC SERVER becomes faulty.
Change Through
Connection
To change the MODE attribute of Termination. This operation can be used
to control the directions of media flows, including forward, backward,
bi-directional, isolated.
Change Flow Direction
To control the direction of the media flow between Terminations by
modifying the topology parameter between Terminations.

4-10
Isolate Bearer
Termination
To isolate one Termination from its media flow relation with other
Terminations, so that it has no media flow relation with any Termination.
Join Bearer Termination To add a Termination in an existing CONTEXT.
Establish Bearer
To establish bearer between MGWs. This operation includes applying for a
Termination resource and establishing the bearer to the destination MGW.
Prepare Bearer
To apply for Termination resource from MGW. This is an operation prior to
bearer. It may result in the generation of a new CONTEXT.
Activate Interworking
Function
To activate the IWF on an MGW.
Release Bearer
To release bearer between MGWs. This operation does not release the
Termination resource.
Release Termination To release Termination resource.
Bearer Released
Bearer release completion event reported by MGW. This event is
requested by the MGC.
Bearer Established
Bearer establishment completion event reported by MGW. This event is
requested by the MGC.
Send Tone
Send-tone operation. During a call, the MGC can request the Termination
to send a certain tone to a certain direction, such as ring-back tone, busy
tone, and so on.
Play Announcement To play announcement in intelligent or supplementary services, and so on.
Send DTMF To send DTMF tone.
Detect DTMF To request MGW to detect DTMF tones.
Report DTMF MGW reports to the MGC about the completion of DTMF tone detection.
Announcement
Completed
Announcement playing completion message reported by MGW.
Activate Voice
Processing Function
To activate the voice processing function, including EC, Reserve Circuit.
Tunnel Information Up
MGW reports IPBCP frame to MGC, and the MGC sends it to the peer
MGW by means of tunnel.
Tunnel Information
Down
MGC sends the IPBCP message from another MGC to MGW.
Tone Completed Tone playing completion event reported by MGW.
Stop Announcement MGC requests MGW to stop sending ANNOUNCEMENT.
Stop Tone MGC requests MGW to stop sending Tone.
Stop DTMF MGC requests MGW to stop sending DTMF tone.
Stop DTMF Detection MGC requests MGW to stop DTMF detection.
Confirm Char MGC requests MGW to confirm the reserved resources.

4-11
Modify Char MGC modifies resources previously reserved on MGW.
Reserve Char MGC reserves resources on MGW.
Bearer Modified Bearer modification completion event.
Bearer Modification
Failed
Bearer modification failure event.
TFO Activation MGC activates the TFO function of MGW.
Optimal Codec and
Distant List Notify
MGW reports Codec List of Codec negotiation during TFO.
Codec Modify MGW reports Codec modification result.
Distant Codec List MGW reports remote Codec negotiation result.
Command Rejected
When MGW detects an illegal or inexecutable command from the MGC, it
returns Command Rejected.
Modify Bearer
Characteristics
MGC requests to modify bearer resource.

III. Action
Actions are related to Contexts. An action consists of a series of commands that are
limited to operate within one Context. Actions are identified by a ContextID. In an action,
commands should be processed in order.
An action begins with the Context header (CtxHdr) in which ContextID is contained for
identifying the Context this action corresponds to. ContextID is assigned by the MG and
is unique within the scope of the MG. The MGC shall use the ContextID in all
subsequent transactions relating that Context.
CtxHdr is followed by several commands, and these commands are related to the
Context identified by the ContextID.
IV. Command (CMD)
Commands are the major contents in an H.248 message. They control the Context and
Termination attributes including to specify the event reported by the Termination what
signals and actions can be imposed on the Termination, as well as specifying the
topology structure of the Context. A command is composed of the command header
(CMDHdr) and command parameters. In H.248 protocol, command parameters are
grouped into Descriptors.
H.248 protocol defines eight commands, all of which are sent to MG by MGC
except the command Notify, which is sent to MGC by MG. The command

4-12
ServiceChange can be sent by either the MG or the MGC. The meanings of
H.248 commands are as follows:
Table 4-3 H.248 commands
Command
Sending
direction
Meaning
Add MGC?MG
The Add command adds a Termination to a Context. The Add
command on the first Termination in a Context is used to create a
Context.
Modify MGC?MG
The Modify command modifies the properties, events and signals of
a Termination.
Subtract MGC?MG
The Subtract command disconnects a Termination from its Context
and returns statistics on the Terminations participation in the
Context. The Subtract command on the last Termination in a
Context deletes the Context.
Move MGC?MG
The Move command atomically moves a Termination to another
Context.
AuditValue MGC?MG
The AuditValue command returns the current state of properties,
events, signals and statistics of Terminations.
AuditCapabi
lities
MGC?MG
The AuditCapabilities command returns all the possible values for
Termination properties, events and signals allowed by the media
gateway.
Notify MG?MGC
The Notify command allows the MG to inform the MGC of the
occurrence of events in the MG.
ServiceCha
nge
MGC?MG
The ServiceChange command allows the MG to notify the MGC that
a Termination or group of Terminations is about to be taken out of
service or has just been returned to service. ServiceChange is also
used by the MG to announce its availability to an MGC (registration),
and to notify the MGC of impending or completed restart of the MG.
The MGC may announce a handover to the MG by sending it a
ServiceChange command.

V. Descriptor
The parameters to a command are termed Descriptors. A descriptor consists of a name
and a list of items. Some items may have values. Many commands share common
descriptors. In general, the text format of descriptors is as follows:
DescriptorName=<someID>
{ parm = value, parm = value ...... }

H.248 protocol defines 18 types of descriptors, as shown in Table 4-4.

4-13
Table 4-4 Descriptors
Descriptor Name Description
Modem Identifies modem type and properties.
Mux
Describes multiplex type for multimedia Terminations (for example, H.221,
H.223, H.225.0) and Terminations forming the input mux.
Media A list of media stream specifications.
TerminationState
Properties of a Termination (which can be defined in packages) that are not
stream specific.
Stream A list of remote/local/localcontrol descriptors for a single stream.
Local
Contains properties that specify the media flows that the MG receives from the
remote entity.
Remote
Contains properties that specify the media flows that the MG sends to the
remote entity.
Localcontrol Contains properties that are of interest between the MGC and the MG.
Events A list of events that the MG is requested to detect and report.
EventBuffer
A list of events, with their parameters if any, that the MG is requested to detect
and buffer when EventBufferControl equals LockStep.
Signals
Describes signals and/or actions to be applied (for example, ringback tone) to
the Terminations.
Audit Specifies what information is to be audited.
ServiceChange In ServiceChange, what, why service change occurred, and so on.
DigitMap
A dialing plan resident in the MG used for detecting and reporting digit events
received on a Termination.
Statistics In Subtract and Audit, Report of Statistics kept on a Termination.
Packages A AuditValue, returns a list of packages realized by Termination.
ObservedEvents In Notify or AuditValue, report of events observed.
Topology
Specifies flow directions between Terminations in a Context, and applies to a
Context instead of a Termination.

The following part uses an example to illustrate a typical implementation of the H.248
protocol. The diagrams of the call procedure abstractly display the interaction between
a media gateway and the media gateway controller instead of taking issues like time
graduation into account.
The example is about a call set up between two residential gateways. User A and User
B are respectively connected to two residential gateways RGW1 and RGW2, and the

4-14
gateways are under the control of the same media gateway controller. The example
only describes a successful call, and it is assumed that the gateways have registered
on the media gateway controller.
The procedure is divided into two processes, namely call setup process and call
backout process.
I. Call Setup Process
H.248 call setup process is shown in Figure 4-6.

4-15
RGW
1
MGC
RGW
2
USER
A
USER
B
Modify Resp Modify Resp
UserA
offhook
Nodify Resp
Modify SG:dialtone
ED:al/on,dd/ce{Dmap1}
DM:Dmap1 = 2XXX
Notify offhook
Dial Tone
Modify Resp
UserA dials
digits
Nodify Resp
Notify digits
Add TermA SD:ringbacktone
Add $, Local SDP Info -underspecified
RingBack
Tone
Add Resp TermA
Add Resp EphA Local SDP (Specified)
Add TermB SD:Ring ED:offhook
Add $ Local(Underspecified)
Remote SDP (Specified)
UserB Phone
Ringing
Add Resp TermB
Add Resp EphB Local SDP
(Specified)
UserB Goes
Offhook
Nodify Resp
Notify offhook
Modify TermA SendRecv
Modify EphA Remote(Specified) SendRecv
Modify Resp
Modify TermB SendRecv
Modify EphB SendRecv
Modify Resp
RTP MEDIA
Modify to check offhook
Modify to check offhook

Figure 4-6 Call setup process

4-16
1) MGC sends a Modify message to both gateways to detect the offhook event on the
terminations.
2) It is assumed that User A hooks off first. After RGW1 detects the event, it sends to
MGC a Notify message in which the corresponding event information and
detected timestamp are contained. MGC returns a response message.
3) MGC sends a Modify command to RGW1, indicating to RGW1 to send dial tone to
User A. RGW sends dial tone to the user and meanwhile returns a response
message.
4) User A hears the dial tone and begins to dial.
5) MGC receives the Notify message from RGW1 and begins to analyze the digits. It
is assumed that the called party is connected to RGW2 which is managed by the
same MGC. MGC creates a new context for RGW1 and adds a physical
termination TermA in it. If User B is idle, ringback tone is sent to User A. At the
same time, an ephemeral termination is created and then added in the preceding
context. The connection domain IP address and the media domain port number of
the ephemeral termination are not specified. RGW1 creates a context whose ID is
1. The physical termination TermA is added in the context. Meanwhile, an
ephemeral termination EphA is created and its IP address and port number are
assigned. Then, RGW1 returns a corresponding response in which the IP address
and the port number used are indicated.
6) MGC sends a similar transaction to RGW2. RGW2 creates a context whose ID is 2,
then it adds the physical termination TermB in the context; meanwhile, RGW2
creates an ephemeral termination EphB and returns a response message.
7) User B hooks off. RGW2 uses a Notify command requesting to report this event to
MGC. MGC also returns a Notify response.
8) MGC sends to RGW1 a message to stop sending ringback tone to User A, and
sets the remote SDP information of EphA. The mode of both terminations is
modified to SendRecv (previously both created as RecvOnly mode). RGW1
returns a response message indicating the success of the operation.
9) MGC sends a transaction to RGW2, indicating to stop ringing tone on TermB. After
the completion of the processing, RGW2 returns a response.
10) The users can have a conversation. Once the call is terminated by either party, the
other party will hear busy tone.
II. Call Backout Process
Call backout process is shown in Figure 4-7.

4-17
RGW
1
MGC
RGW
2
USER
A
USER
B
UserA Goes
OnHook
Modify TermB SD:BusyTone
UserB Goes
Onhook
Nodify Resp
Notify OnHook
BusyTone To
UserB
Modify Resp
Subtract TermA
Subtract EphA
Subtract Resp TermA
Subtract Resp EphA Statistics
Nodify Resp
Notify OnHook
Subtract TermB
Subtract EphB
Subtract Resp TermB
Subtract Resp EphB Statistics

Figure 4-7 Call backout process
1) It is assumed that the calling party User A will terminate the call. RGW1 sends a
Notify message to MGC to report this event. MGC returns a response message of
the Notify command.
2) MGC generates a Modify command, indicating to RGW2 to play busy tone to User
B. The mode of both terminations is set to RecvOnly. RGW2 returns a response
indicating the success of the operation.
3) MGC directs RGW1 to remove both terminations from the context 1 and return the
statistics information of the ephemeral termination as the response.
4) User B hears busy tone and then hooks on. RGW2 reports a Notify message to
MGC. MGC returns a corresponding response message.

4-18
5) The gateway sends a Subtract command to delete TermB and EphB from the
context 2. RGW2 also deletes the terminations from the context 2 and then returns
a response in which the statistics information of the ephemeral termination is
contained. Here, a call procedure ends. The terminations return to the initial status
and await a new call.

Chapter 5 BICC

5-1
Chapter 5 BICC
5.1 Overview
The Bearer Independent Call Control (BICC) protocol is one of the application layer
control protocols. It is used to establish, modify and terminate calls and can bear
comprehensive PLMN/PSTN/ISDN services.
BICC evolves from the ISUP protocol and has it developed. It is characterized by the
separation between the call control level and the bearer control level, thus the Call
Service Function (CSF) is independent of the Bearer Control Function (BCF).
In UMTS, BICC is applied to the call control interface between two MSC Servers.
5.1.1 Definition and Functions of the Nc Interface
I. Definition of the Nc Interface
Nc is an additional interface in UMTS R4. It is also named Nc reference point in 3GPP
protocols. It is the standard interface between two MSC Servers (GMSC Servers),
where the BICC or ISUP protocol recommended by the ITU-T is used.
II. Functions of the Nc Interface
The Nc interface provides the UMTS CS domain service with the inter-office call control
capability which is independent of user-level bearer technology and control-level
signaling transport technology used, thus achieving the interworking between
networks.
5.1.2 BICC Implementation in MSOFTX3000
When MSOFTX3000 acts as a MSC Server (or GMSC Server), the BICC protocol is
used for interworking between MSOFTX3000 and other MSC Server, as shown in
Figure 5-1.
Chapter 5 BICC

5-2
Nc
MSC Server
(MSOFTX3000)
Mc Mc
MWG MWG
BICC
GMSC Server
(MSOFTX3000)
Nb
Nc
MSC Server
(MSOFTX3000)
Mc Mc
MWG MWG
BICC
GMSC Server
(MSOFTX3000)
Nb

Figure 5-1 BICC protocol implementation in MSOFTX3000
The BICC protocol is defined to use any transport networks for signaling transport,
such as IP, ATM, TDM networks. According to implementation requirements,
MSOFTX3000 can use four transport modes: TDM based MTP3, IP based M3UA or
SCTP, and ATM based MTP3b. See Figure 5-2.
BICC
SCTP
IP
MAC
L1
(G)MSC Server
Nc
MSC Server
c) SCTP/IP based
Nc
MSC Server
d) ATM based
(G)MSC Server
BICC
BICC
SCTP
IP
MAC
L1
STC
SAAL
AAL5
MTP3B
ATM
PL
BICC
STC
SAAL
AAL5
MTP3B
ATM
PL
BICC
MTP3
MTP2
MTP1
(G)MSC Server
Nc
MSC Server
a) TDM based
(G)MSC Server
Nc
MSC Server
b) M3UA based
BICC
L1
BICC
M3UA
IP
MAC
L1
BICC
MTP3
MTP2
MTP1
SCTP
M3UA
IP
MAC
SCTP
BICC
SCTP
IP
MAC
L1
(G)MSC Server
Nc
MSC Server
c) SCTP/IP based
Nc
MSC Server
d) ATM based
(G)MSC Server
BICC
BICC
SCTP
IP
MAC
L1
STC
SAAL
AAL5
MTP3B
ATM
PL
BICC
STC
SAAL
AAL5
MTP3B
ATM
PL
BICC
MTP3
MTP2
MTP1
BICC
MTP3
MTP2
MTP1
(G)MSC Server
Nc
MSC Server
a) TDM based
(G)MSC Server
Nc
MSC Server
b) M3UA based
BICC
L1
BICC
M3UA
IP
MAC
L1
BICC
MTP3
MTP2
MTP1
BICC
MTP3
MTP2
MTP1
SCTP
M3UA
IP
MAC
SCTP

Figure 5-2 BICC protocol stack
Chapter 5 BICC

5-3
5.2 Introduction of BICC Protocol
BICC signaling develops on the basis of ISUP signaling, and is basically similar to the
ISUP protocol in the aspect of supporting basic call procedures and supplementary
service features. The additional Application Transport Mechanism (APM) in BICC
makes it possible to exchange bearer related information between the call control
nodes at the ends of the Nc interface. Such information includes bearer address,
connection reference, bearer characteristics, bearer setup mode and supported Codec
list, and so on. BICC can also provide an optional tunnel transport function on the Nc
interface for the bearer control signaling between MGWs.
The BICC protocol utilizes the idea of separation between call signaling function and
bearer signaling function, defines a new call control signaling protocol used in a
backbone network, thus can control a variety of networks including SS7, ATM and IP
networks. The call control protocol is based on N-ISUP signaling. It continues to use
related message in ISUP and utilizes APM to convey BICC specific bearer control
information. Therefore, it can bear comprehensive PSTN/ISDN services. The
separation between call and bearer makes the interworking between services provided
by networks of different bearer types simple. What is required is to implement
interworking on bearer level. It is unnecessary to make any modifications on services.
5.2.1 Basic Concepts
I. Terminology
The BICC protocol defines some new terminologies. A brief introduction is shown in
Table 5-1.
Table 5-1 Basic concepts of BICC protocol
Abbrevi
ation
Full name Description
BNC Backbone Network Connection
Represents the edge to edge transport connection
within the backbone network, consisting of one or more
Backbone Network Connection Links (BNCL). The
Backbone Network Connection represents a segment
of the end to end Network Bearer Connection (NBC).
BNCL
Backbone Network Connection
Link
Represents the transport facility between two adjacent
backbone network entities containing a bearer control
function.
Chapter 5 BICC

5-4
Abbrevi
ation
BCF Bearer Control Function
Note that five types of BCFs are defined as follows:
Bearer Control Joint Function (BCF-J): The Bearer
Control Joint Function (BCF-J) provides the control of
the bearer switching function, the communication
capability with two associated call service functions
(CSF), and the signaling capability necessary to
establish and release the backbone network
connection.
Bearer Control Gateway Function (BCF-G): The
Bearer Control Gateway Function (BCF-G) provides
the control of the bearer switching function, the
communication capability with its associated call
service function (CSF-G), and the signaling capability
necessary to establish and release of the backbone
network connection.
Bearer Control Nodal Function (BCF-N): The Bearer
Control Nodal Function (BCF-N) provides the control of
the bearer switching function, the communication
capability with its associated call service function
(CSF-N), and the signaling capability necessary to
establish and release of the backbone network
connection to its peer (BCF-N).
Bearer Control Relay Function (BCF-R): The Bearer
Control Relay Function (BCF-R) provides the control of
the bearer switching function and relays the bearer
control signaling requests to next BCF in order to
complete the edge to edge backbone network
connection.
Bearer Control Transit Function (BCF-T): The Bearer
Control Transit Function (BCF-T) provides the control
of the bearer switching function, the communication
capability with its associated call service function
(CSF-T), and the signaling capability necessary to
establish and release of the backbone network
connection.
BCS Bearer Control Segment
Represents the signaling relationship between two
adjacent Bearer Control Functional entities (BCF).
BIWF Bearer Inter-Working Function
A functional entity which provides bearer control
functions (BCF) and media mapping/switching
functions within the scope of a Serving Node
(ISN/TSN/GSN). A Bear Inter-Working Function
includes one BCF (BCF-N/BCF-T/BCF-G)
and one or more MCF and MMSF, and is
functionally equivalent to a Media Gateway
that incorporates bearer control.
BIWN Bearer Inter-Working Node
A physical unit incorporating functionality similar to a
BIWF.
Chapter 5 BICC

5-5
Abbrevi
ation
CCA Call Control Association
Defines the peer to peer signaling association between
Call, and Call & Bearer state machines located in
different physical entities.
CMN Call Mediation Node
A functional entity that provides CSF-C functions
without an associated BCF entity.
CSF Call Service Function
Four types of CSF are defined:
Call Service Nodal Function (CSF-N): The Call Service
Nodal Function (CSF-N) provides the service control
nodal actions associated with the narrowband service
by interworking with narrowband and BICC signaling,
signaling to its peer (CSF-N) the characteristics of the
call, and invoking the Bearer Control Nodal Functions
(BCF-N) necessary to transport the narrowband bearer
service across the backbone network.
Call Service Transit Function (CSF-T): The Call
Service Transit Function (CSF-T) provides the service
transit actions necessary to establish and maintain a
backbone network call, and its associated bearer by
relaying signaling between CSF-N peers and invoking
the Bearer Control Transit Functions (BCF-T)
necessary to transport the narrowband bearer service
across the backbone network.
Call Service Gateway Function (CSF-G): The Call
Service Gateway Function (CSF-G) provides the
service gateway actions necessary to establish and
maintain a backbone network call and its associated
bearer by relaying signaling between CSF-N peers and
invoking the Bearer Control Gateway Functions
(BCF-G) necessary to transport the narrowband bearer
service between backbone networks.
Call Service Co-ordination Function (CSF-C): The Call
Service Co-ordination Function (CSF-C) provides the
call co-ordination and mediation actions necessary to
establish and maintain a backbone network call by
relaying signaling between CSF-N peers. The CSF-C
has no association with any BCF.
GSN Gateway Serving Node
A functional entity which provides gateway functionality
between two network domains. This functional entity
contains one or more call service gateway functions
(CSF-G), and one or more bearer interworking
functions (BIWF). GSNs interact with other GSNs in
other backbone network domains, and other ISNs and
TSNs within its own backbone network domain. The
network signaling flows for a GSN are equivalent as
those for a TSN.
Chapter 5 BICC

5-6
Abbrevi
ation
ISN Interface Serving Node
A functional entity which provides the interface with
non-BICC networks and terminal equipment. This
functional entity contains one or more call service
nodal functions (CSF-N), and one or more bearer
inter-working functions (BIWF) which interact with the
non-BICC networks and terminal equipment and its
peers within the BICC network.
MCF Media Control Function
A functional entity that interacts with the BCF to provide
the control of the bearer and MMSF. The precise
functionality is outside the scope of BICC.
MMSF
Media Mapping/Switching
Function
An entity providing the function of controlled
interconnection of two bearers and optionally the
conversion of the bearer from one technology and
adaptation/encoding technique to another.
SN Serving Node A functional entity referring to ISN, GSN or TSN nodes.
NBC Network Bearer Connection
Used to transport user selected bearer
services between two or more TEs.
STL Signaling Transport Layer
Any suite of protocol layers currently specified to
provide Transport and/or Network Layer services to the
BICC. Their functions, protocol and service primitives
are outside the scope of this specification.
STC Signaling Transport Converter
A protocol layer between the STL and BICC. This layer
enables the BICC protocol to be independent of the
STL being used.
SWN Switching Node
A functional entity which provides the switching
functions within the backbone core network. This
functional entity contains a bearer control state
machine (BCF-R). SWNs interact with other SWNs and
BIWFs.
SCN Switched Circuit Network
A generic term for any network that uses circuit
switching technology, that is, ISDN, PSTN, PLMN.
TE Terminal Equipment
Represents the customers access equipment used to
request and terminate network associated connectivity
services.
TSN Transit Serving Node
A functional entity which provides transit functionality
between ISNs and GSNs. This functional entity
contains one or more call service transit functions
(CSF-T), and one or more bearer interworking
functions (BIWF). TSNs interact with other TSNs,
GSNs and ISNs within their own backbone network
domain.

Chapter 5 BICC

5-7
II. Separation between Call and Bearer
BICC is characterized by separation of call control and bearer control layers. The
separation enables the BICC specification to concentrate on handling of Call Service
Functions instead of taking specific bearer control into account, as shown in Figure 5-3.
Such layered and independent architecture is fully consistent with strcuturization and
componentization design idea of a packet network.
Call Service Function
(CSF)
Bearer Control Function
(BCF)
Serving Node (SN)
Call Control Signaling
(BICC protocol)
Call Control Signaling
(BICC protocol)
Bearer Control Signaling Bearer Control
Signaling
Bearer
Main scope
of the BICC
specification

Figure 5-3 Diagram of separation of call and bearer of BICC
As shown in Figure 5-4, the three-layer architecture of BICC is very clear: BICC
signaling is used between CSFs; bearer control signaling (for example, Q.AAL2) is
used between BCFs; transport of media streams (bearer streams) has nothing to do
with BICC.
ISUP CC
BAT
ASE
APM
ASE
BICC
ASE
BCF
Interface Serving Node (ISN)
CC
BAT
ASE
APM
ASE
BICC
ASE
BCF
Transit Serving Node (TSN)
BAT
ASE
APM
ASE
BICC
ASE
BCF
BICC
signaling
Bearer
control
signaling
Bear Bear Bear
Bearer
streams

APM: APplication transport Mechanism ASE: Application Service Element
BAT: Bearer Association Transport CC: Call Control
Figure 5-4 Network model of BICC
III. Protocol Model
Figure 5-5 shows the generic protocol model defined by the BICC protocol.
Chapter 5 BICC

5-8
BICC procedures
call control
protocol
generic interface
transport specific
interface
Signaling
Transport
Converter
bearer specific
interface
bearer control
protocol
Mapping
Function
Bearer
Control
Signaling
Transport
Layers
generic interface

Figure 5-5 Generic protocol model of BICC
The protocol model of BICC regards process of the BICC protocol itself as a black box.
It has two interface to the BICC core network:
Signaling transport interface: This interface is used to package BICC messages in
signaling transport layer messages for interaction between BICC entities.
Bearer control interface: This interface is used for control and query of bearers.
BICC protocol model implies this idea: In order to make BICC thoroughly independent
of any other parts of its interfaces (signaling transport or bearer), BICC uses a
converter for interface unification at the signaling transport interface point and the
bearer control interface point.
From the point of view of BICC process, it provides only one set of abstracted operation
primitives externally. Then, by a converting/mapping component, primitive conversion
with the specific part (signaling transport or bearer) is achieved:
At the signaling transport interface point, Signaling Transport Converter (STC) is
used to convert signaling transport primitives of BICC with specific Signaling
Transport Layers (STLs), such as with MTP3, MTP3B, SCTP, M3UA.
At the bearer control interface point, the Bearer Mapping Layer is used to convert
abstracted bearer control primitives of BICC with specific bearer control primitives,
such as with AAL1, AAL2, B-ISUP, IP, SS7-Bearer.
IV. Signaling Capability Sets and Service Sets Supported by BICC
BICC protocol defines a call control signaling protocol used in a backbone network,
including SS7, ATM and IP networks. It can bear comprehensive PSTN/ISDN services.
Basic call signaling capability sets supported by BICC are shown in Table 5-2. Generic
signaling procedures, supplementary services and additional functions/services
supported by BICC are shown in Figure 5-4.
Chapter 5 BICC

5-9
Table 5-2 Signaling capability sets of a BICC basic call
Function/Service National International
Speech/3.1 kHz audio
64k bit/s unrestricted
Multirate connection types (Note 1)
N x 64k bit/s connection types
En bloc address signaling
Overlap address signaling
Transit network selection -
Continuity indication
Forward transfer -
Simple segmentation
Tones and announcements
Access delivery information
Transportation of User teleservice
information

Suspend and resume
Signaling procedures for connection
type allowing fallback capability

Propagation delay determination
procedure

Simplified echo control signaling
procedures

Automatic repeat attempt
Blocking and unblocking
CIC group query CIC -
Dual seizure
Reset
Receipt of unreasonable signaling
information

Compatibility procedure (BICC and
BAT APM user application)

ISDN User Part signaling congestion
control
Note 2 Note 2
Automatic congestion control
Chapter 5 BICC

5-10
Interaction with INAP
Unequipped CIC -
ISDN User Part availability control Note 3 Note 3
MTP pause and resume Note 2 Note 2
Overlength messages
Temporary Alternative Routing (TAR)
Hop counter procedure
Collect call request procedure
Hard-to-Reach
Calling geodetic location procedure
Carrier selection indication -
Inter-nodal traffic group identification
Codec negotiation and modification
procedures

Joint BIWF support
Global Call Reference procedure
Out of band transport of DTMF tones
and information

Note:
" indicates supported by ITU-T; - indicates not supported by ITU-T.
Multi rate connection types include 2X64, 384, 1536, and 1920kbit/s.
If BICC uses MTP3B to transport signaling, these functions are provided by STC. Reference Q.2150.1.
If BICC uses MTP3B to transport signaling, these processes are provided by STC. Reference
Q.2150.1.

Table 5-3 Generic signaling procedures, supplementary services and additional functions/services of
BICC
Generic signaling procedures
Generic number transfer
Generic digit transfer -
Chapter 5 BICC

5-11
Generic notification procedure
Service activation
Remote Operations Service Element
(ROSE) capability
-
Network specific facilities -
Pre-release information transport
Application Transport Mechanism
(APM)

Redirection -
Pivot routeing
Bearer redirection
Supplementary services
Direct-Dialling-In (DDI)
Multiple Subscriber Number (MSN)
Calling Line Identification Presentation
(CLIP)

Calling Line Identification Restriction
(CLIR)

Connected Line Identification
Presentation (COLP)

Connected Line Identification
Restriction (COLR)

Malicious Call Identification (MCID)
Sub-addressing (SUB)
Call Forwarding Busy (CFB)
Call Forwarding No Reply (CFNRy)
Call Forwarding Unconditional (CFU)
Call Deflection (CD)
Explicit Call Transfer (ECT)
Call Waiting (CW)
Call HOLD (HOLD)
Completion of Calls to Busy Subscriber
(CCBS)

Completion of Calls on No Reply
(CCNR)

Chapter 5 BICC

5-12
Terminal Portability (TP)
Conference calling (CONF)
Three-Party Service (3PTY)
Closed User Group (CUG)
Multi-Level Precedence and
Preemption (MLPP) (Note 1)

Global Virtual Network Service (GVNS)
International telecommunication charge
card (ITCC)

Reverse charging (REV) -
User-to-User Signaling (UUS)
Additional functions/services
Support of VPN applications with PSS1
Information Flows

Support of GAT protocol
Support of Number Portability (NP) -

Note:
" indicates supported by ITU-T; - indicates not supported by ITU-T.
Only information about transit MLPP is supported.

Message format for BICC is basically same as that for ISUP except that the routing
label is absent and Call Identification Code is replaced by Call Instance Code.
See Figure 5-6.
Chapter 5 BICC

5-13
Transmission sequence
Octet
Mandatory fixed part
8 7 6 5 4 3 2 1
Call Instance Code
Message type code
Mandatory fixed parameter A
Parameter name = X
Parameter Z
End of optional parameters
Pointer to parameter M
Pointer to start of optional part
Length indicator of parameter M
Parameter M
Mandatory variable part
Optional part
Length indicator of parameter P
Parameter X
Length indicator of parameter Z

Transmission sequence
Mandatory fixed parameter A
Pointer to parameter P
Parameter P
Length indicator of parameter X
Parameter name = Z

Figure 5-6 Format for BICC messages
I. Call Instance Code (CIC)
Call Instance Code (CIC) is a logic number associated with the inter-office calling
relation. It is used to identify which call instance this message corresponds to. From the
point of view of function, it is similar to Circuit Identification Code used in ISUP
messages except that it does not identify circuits and it is extended. The Call Instance
Code is extended to 32 bits (Circuit Identification Code has 12 bits), and thus the
number of inter-office call instances is up to 4,294,967,296 (2
32
) theoretically.
Chapter 5 BICC

5-14
II. Message Type
The BICC message type code consists of a one-octet field and is mandatory for all
messages. The message type code uniquely defines the function and format of each
BICC message, as shown in Table 5-4. Code points marked as ISUP only in this table
are reserved in BICC.
Table 5-4 BICC message type codes
Message type Code Description
Address complete 0000 0110
Answer 0000 1001
Application transport 0100 0001
Blocking 0001 0011 ISUP only
Blocking acknowledgement 0001 0101 ISUP only
Call progress 0010 1100
Circuit/CIC group blocking 0001 1000
Circuit/CIC group blocking acknowledgement 0001 1010
Circuit/CIC group query (national use) 0010 1010
Circuit/CIC group query response (national
use)
0010 1011
Circuit/CIC group reset 0001 0111
Circuit/CIC group reset acknowledgement 0010 1001
Circuit/CIC group unblocking 0001 1001
Circuit/CIC group unblocking
acknowledgement
0001 1011
Charge information (national use) 0011 0001
Confusion 0010 1111
Connect 0000 0111
Continuity 0000 0101
Continuity check request 0001 0001 ISUP only
Facility 0011 0011
Facility accepted 0010 0000
Chapter 5 BICC

5-15
Facility reject 0010 0001
Facility request 0001 1111
Forward transfer 0000 1000
Identification request 0011 0110
Identification response 0011 0111
Information (national use) 0000 0100
Information request (national use) 0000 0011
Initial address 0000 0001
Loop back acknowledgement (national use) 0010 0100 ISUP only
Loop prevention 0100 0000
Network resource management 0011 0010
Overload (national use) 0011 0000 ISUP only
Pass-along (national use) 0010 1000 ISUP only
Pre-release information 0100 0010
Release 0000 1100
Release complete 0001 0000
Reset circuit/CIC 0001 0010
Resume 0000 1110
Segmentation 0011 1000
Subsequent address 0000 0010
Subsequent Directory Number (national use) 0100 0011
Suspend 0000 1101
Unblocking 0001 0100 ISUP only
Unblocking acknowledgement 0001 0110 ISUP only
Unequipped CIC (national use) 0010 1110
User Part available 0011 0101 ISUP only
User Part test 0011 0100 ISUP only
User-to-user information 0010 1101
Chapter 5 BICC

5-16
Reserved
0000 1010
0000 1011
0000 1111
0010 0010
0010 0011
0010 0101
0010 0110
used in 1984 version
(Red Book) ISUP
Reserved
0001 1101
0001 1100
0001 1110
0010 0111
used in 1988 version
(Blue Book) ISUP
Reserved
0011 1001
to
0011 1101
used in B-ISUP
Reserved for future extension 1000 0000

III. Parameter Parts
BICC message parameter parts include mandatory fixed part, mandatory variable part
and optional part. Each message type has unique parameters.
Call procedures of the BICC protocol mainly include successful call setup procedures,
additional call setup procedures, mid-call procedures, normal release procedures, and
so on.
I. Successful Call Setup Procedures
Bearer setup types lead to different call setup procedures. The main procedure types
are:
Normal modes of each call corresponding to one bearer setup procedure: BNC
forward establishment, without notification; BNC forward establishment,
notification; BNC backward establishment.
Tunnelling modes of each call corresponding to one bearer setup procedure:
per-call bearer setup using tunnelling fast forward; per-call bearer setup using
tunnelling delayed forward; per-call bearer setup using tunnelling backward.
Modes of re-using idle bearer: use of idle BNC, established in the forward direction;
use of idle BNC, established in the backward direction.
In the case of using IP bearer, the current procedure for tunnelling forward setup mode
is shown in Figure 5-7:
Chapter 5 BICC

5-17
CSF-N
BCF-N BCF-R
ISN-A
BCF-R
CSF-T
TSN
SWN-1 SWN-2
IAM (Action = Connect Forward) , (BNC characteristics)
IAM
ACM
ACM
ANM
ANM
BCF-R BCF-R
CSF-N
BCF-N
ISN-B
SWN-1 SWN-2
IAM (COT on previous), (Action = Connect Forward) ,
(BNC characteristics)
ACM
ANM
BBB
COT
APM (Action = Connect Forward, plus notification)
APM (Action = Connect Forward plus notification)
BICC BICC
BCF-N
(z) (y)
AAA
ISUP ISUP
ACM
ANM
APM (Tunnel data)
(x)
APM (Action = Connected)
APM (Tunnel data)
APM (Tunnel data)
APM (Tunnel data)

Figure 5-7 Delayed forward bearer setup, with notification
II. Additional Call Setup Procedures
To support applications of bearer control independence, BICC supports codec
negotiation and codec modification procedures, as shown in Figure 5-8.
Chapter 5 BICC

5-18
CSF-N
BCF-N BCF-R
ISN-A
BCF-R
CSF-T
TSN
SWN-1 SWN-2
IAM (Action = Connect Forward) , (BNC
characteristics), ( Codec list)
Bearer Set-up req. (BNC-ID=y1), (BIWF- Addr=y)
Bearer-Set-up req
Bearer-Setup-Connect
IAM
ACM
ACM ANM
ANM
Bearer-Set-up req
BCF-R BCF-R
CSF-N
BCF-N
ISN-B
SWN-1 SWN-2
IAM (COT on previous), (Action = Connect Forward) ,
(BNC characteristics), (Codec list)
Bearer Set-up req. (BNC-ID= z1), (BIWF- Addr= z)
Bearer-Set-up req
ACM
ANM
Bearer-Set-up req
BBB COT
APM (Action = Connect Forward, plus notification
+ Selected codec), (BNC-ID=y1), (BIWF Addr=y)
(Selected codec), (Available codec list)
APM (Action = Connect Forward plus notification
+ Selected codec), (BNC-ID= z1), (BIWF Addr= z),
(Selected codec), (Available codec list)
BICC BICC
BCF-N
(z) (y)
AAA
ISUP ISUP
ACM
ANM
(x)

Figure 5-8 Forward setup, with codec negotiation
III. Mid-Call Procedures
To support applications of bearer control independence, BICC supports mid-call codec
negotiation and codec modification, as shown in Figure 5-9.
Chapter 5 BICC

5-19
CSF-N
BCF-N BCF-R
SN-A
BCF-R
CSF-T
TSN
SWN-1 SWN-2
BCF-R BCF-R
CSF-N
BCF-N
SN-B
SWN-1 SWN-2
BICC
APM (Action =Suc ces sful codec modific ation )
BICC
(x) (z)
BCF-N
(y)
APM (Action = Modify to selected codec information), (Selected codec and/or Codec list)
APM (Action = Successful codec modification)
APM (Action = Modify to selected codec information), (Selected codec and/or Codec list)
APM (Action = Successful codec modification)
Bearer Modify
Bearer Modify
Bearer Modify
Bearer Modify Ack
Bearer Modify Ack
Bearer Modify Ack
Bearer Modify
Bearer Modify Bearer Modify
Bearer Modify Ack
Bearer Modify Ack
Bearer Modify Ack
Bearer Modify
Bearer Modify
Bearer Modify
Bearer Modify Ack
Bearer Modify Ack
Bearer Modify Ack
Bearer Modify
Bearer Modify Bearer Modify
Bearer Modify Ack
Bearer Modify Ack
Bearer Modify Ack
Optionally sent to modify
codec profile and/or allocate
additional bandwidth.
Optionally sent to modify
codec profile and/or allocate
additional bandwidth.
Optionally sent to
reduce bandwidth
when no longer
required.
Optionally sent to
reduce bandwidth
when no longer
required.
APM (Action = Mid-call codec negotiation), (Supported codec list)
APM (Action = Mid-call codec negotiation), (Supported codec list)

Figure 5-9 Mid-call codec negotiation containing w
IV. Normal Release Procedures
According to different bearer setup types, there are the following release procedures:
forward call and bearer release, forward bearer setup; forward call and bearer release,
backward bearer setup; forward call release, bearers not released. See Figure 5-10.
Chapter 5 BICC

5-20
CSF-N
ISN-A
CSF-T
TSN
SWN-1 SWN-2
CSF-N
ISN-B
SWN-1 SWN-2
BICC BICC
REL
REL
REL
REL
BCF-N
RLC
RLC
RLC
RLC
Bearer release req.
Bearer release req.
Bearer release req.
Bearer release Ack.
Bearer release Ack.
Bearer release Ack.
BCF-N BCF-R BCF-R
BCF-R BCF-R
BCF-N
Bearer release req.
Bearer release req.
Bearer release req.
Bearer release Ack.
Bearer release Ack.
Bearer release Ack.
ISUP
ISUP

Figure 5-10 Forward call and bearer release, forward bearer setup mode

Chapter 6 BSSAP+

6-1
Chapter 6 BSSAP+
6.1 Overview
6.1.1 Definition and Functions of the Interface
The Gs interface is the interface between a SGSN and a MSC Server/VLR, where a
number of signaling procedures defined by the BSSAP+ protocol implement message
interaction functions between them.
The Gs interface is optional to UMTS. Through the Gs interface, some functions
respectively pertaining to a Packet Switched (PS) domain and a Circuit Switched (CS)
domain are combined, thus effectively saving radio resources. The SGSN stores
ISDN numbers of the VLR; the VLR stores ISDN numbers of the SGSN. At the SGSN,
creation of a relationship table of Routing Area Identities (RAIs) and VLRs is required.
To set up an association, the corresponding VLR is found by the SGSN according to
the RAI.
Interaction functions of the Gs interface include:
Non-GPRS location update
Explicit IMSI detach from GPRS service
Explicit IMSI detach from non-GPRS service
Implicit IMSI detach from non-GPRS service
Non-GPRS service paging
Non-GPRS service alerting
MS information request
MM information request
SGSN reset
VLR reset
HLR reset
BSSAP+ compliant specifications are 3GPP TS 29.018 and 3GPP TS 29.016.
6.1.2 BSSAP+ Implementation in MSOFTX3000
Implementation of BSSAP+ in MSOFTX3000 is illustrated in Figure 6-1.
Chapter 6 BSSAP+

6-2
MSOFTX3000
Gs
BSSAP+
SGSN
MSOFTX3000
Gs
BSSAP+
SGSN

Figure 6-1 BSSAP+ protocol implementation in MSOFTX3000
The Gs interface is based on MTP link or IP link physically, as shown in Figure 6-2.
The SGSN as a signaling point interconnects with the MSC/VLR across the SS7
network. BSSAP+ uses basic connectionless services (Class 0) of SCCP. According
to service requirements in the aspect of BSSAP+, SCCP and MTP functions have
been appropriately tailored (reference 3GPP TS 29.016 for more information).
BSSAP+
SCCP
MTP3
MTP2
MTP1
MSC Server
(MSOFTX3000)
SGSN
SCCP
MTP3
MTP2
MTP1
SCTP
IP
MAC
MSC Server
(MSOFTX3000)
SGSN
M3UA
SCTP
IP
MAC
M3UA
BSSAP+ BSSAP+
SCCP
BSSAP+
SCCP
Gs Gs
BSSAP+
SCCP
MTP3
MTP2
MTP1
MSC Server
(MSOFTX3000)
SGSN
SCCP
MTP3
MTP2
MTP1
SCTP
IP
MAC
MSC Server
(MSOFTX3000)
SGSN
M3UA
SCTP
IP
MAC
M3UA
BSSAP+ BSSAP+
SCCP
BSSAP+
SCCP
Gs Gs

Figure 6-2 Structure of the BSSAP+ Protocol Stack
MTP message SCCP message BSSAP+ message

Figure 6-3 Position of BSSAP+ in a link message
Chapter 6 BSSAP+

6-3
BSSAP+ signaling format is simple. All follow the message type + message unit
format. The message unit uses a simple Tag Length Value (TLV) format. BSSAP+
messages are relatively short and they are not more than 100 bytes.
BSSAP+ is a subsystem of SCCP. The subsystem number is not invariably defined by
the protocol at present. It can be specified by the carrier.
I. Non-GPRS Location Update
The non-GPRS location update procedure is initiated in the following conditions:
1) A GPRS attach and an IMSI attach are initiated at the same time.
2) Location change in the MS results in LAI change of the resident cell, or routing
area update occurs between SGSNs.
3) Only GPRS attached MS initiates an IMSI attach.
4) Only IMSI attached MS initiates a GPRS attach.
The location update type in the conditions 1) and 3) is IMSI attach. The location
update type in the conditions 2) and 4) is normal location update.
The non-GPRS location update procedure causes location update at the MSC/VLR
side, and results in creation of the association between the SGSN and the MSC/VLR.
In addition, the TMSI reallocation function is also equipped. According to MAP data
configurations, the MSC/VLR determines whether or not to allocate a new TMSI to
the user. A combined location update takes advantage of saving radio interface
resources.
II. Explicit IMSI Detach from GPRS Service
If IMSI detach from GPRS service happens at the SGSN side, the MS in the non
Gs-NULL state shall inform the MSC/VLR that the association should be cancelled.
The MS in the non Gs-NULL state initiates an explicit IMSI detach from GPRS service
in the following conditions:
1) The MS initiates IMSI detach from GPRS service.
2) A failure of routing area update at the SGSN side results in deletion of user data
done by the SGSN.
3) The HLR initiates to delete the user data.
4) The user data is deleted manually at the SGSN.
The IMSI detach from GPRS service type in the condition 1) is MS initiated IMSI
detach from GPRS service.
The IMSI detach from GPRS service type in the conditions 2) and 3) is GPRS
services not allowed.
Chapter 6 BSSAP+

6-4
The IMSI detach from GPRS service type in the condition 4) is SGSN initiated IMSI
detach from GPRS service.
III. Explicit IMSI Detach from non-GPRS Service
If an IMSI detach or a combined GPRS/IMSI detach is received at the SGSN, the MS
in the non Gs-NULL state shall inform the MSC/VLR. Then the MSC/VLR detaches
the users IMSI from service and cancels the association.
The MS in the non Gs-NULL state initiates an explicit IMSI detach from non-GPRS
service in the following conditions:
1) The MS initiates IMSI detach.
2) The MS initiates GPRS/IMSI detach.
The IMSI detach type in the condition 1) is explicit MS initiated IMSI detach from
non-GPRS service.
The IMSI detach type in the condition 2) is combined explicit MS initiated IMSI
detach from GPRS and non-GPRS services.
For the conditions 1) and 2), the MSC/VLR cancels the users location. However at
the SGSN side, only the association is cancelled for the condition 1) and the location
is cancelled for the condition 2).
IV. Implicit IMSI Detach from Non-GPRS Service
If the MS Reachable timer at the SGSN side expires, the MS in the non Gs-NULL
state shall inform the MSC/VLR to initiate an implicit IMSI detach. The MSC/VLR
detaches the user's IMSI service. The concerned IMSI detach type is implicit IMSI
detach from GPRS and non-GPRS services.
V. Non-GPRS Service Paging
A MS in the non Gs-NULL state, or in the Gs-NULL state but with the "confirmed by
radio contact flag set to FALSE, acts as the called party at the MSC/VLR side. The
circuit paging messages are sent to the SGSN through the Gs interface, and then the
messages are delivered to the MS through the Gb/Iu interface. The SGSN may be in
one of the following conditions:
1) The user is acknowledged, and the SGSN-Reset flag is FALSE:
The user is in the non Gs-NULL state, and the SGSN delivers paging messages
through the Gb/Iu interface;
The user is in the Gs-NULL state, and the SGSN sends a paging reject message
to the MSC/VLR with the cause as association cancellation;
The users PPF flag is FALSE, and the SGSN returns a paging unreachable
message to the MSC/VLR.
Chapter 6 BSSAP+

6-5
2) The user is acknowledged, and the SGSN-Reset flag is TRUE:
If the paging request message contains the LAI message unit, the SGSN sends
the paging at the LAI;
If the paging request message does not contain the LAI message unit, the SGSN
sends the paging at all the Ra belonging to both the SGSN and the VLR.
3) The user is unacknowledged, and the SGSN-Reset flag is FALSE:
The SGSN returns a paging reject to the MSC/VLR with the cause as IMSI
unknown.
4) The user is unacknowledged, and the SGSN-Reset flag is TRUE:
Same as the handling described for the condition 2).
In addition, some cells in a particular Location Area (LA) may not support GPRS
service. The SGSN shall group such cells into one to more null RAs. If the SGSN
expects to send a CS paging at a certain LA, the SGSN has to send the paging at all
null RAs of the concerned LA simultaneously.
VI. Non-GPRS Service Alerting
If the MSC/VLR has detected that the MS lost radio interface communication and
then regards the MS unreachable, the MSC/VLR shall initiate the non-GPRS service
alerting procedure to the SGSN. Upon reception of the non-GPRS service alerting
message, the SGSN sets the users NGAF flag. Later, if the SGSN finds the MS
becomes reachable, the SGSN shall send a message to the MSC/VLR to inform the
MSC/VLR about that.
VII. MS Information Request
If a MS is in the non Gs-NULL state, the MSC/VLR can initiate the MS information
request procedure to the associated SGSN, requesting the SGSN to provide the
users identity information and location information. If the SGSN fails to provision the
identity information, the SGSN shall initiate the identification request to the MS.
Upon reception of the request for provisioning location information from the MSC/VLR,
the SGSN does differently in case of a 2G user and 3G user:
1) In case of a 2G user, the SGSN returns the MS resident Cell Global Identification
(CGI) and the time record that the network has radio contact with the user lately.
2) In case of a 3G user, the SGSN returns the MS resident Serving Area
Identification (SAI) and the time record that the network has radio contact with
the user lately. If the user has Iu interface connection, the MS location
information saved in the SGSN may be incorrect (for example, handover may
take place at the user but the users location information in the SGSN may not
be updated immediately), the SGSN shall initiate the location reporting request
to the MS.
Chapter 6 BSSAP+

6-6
VIII. MM Information Request
If a MS is in the non Gs-NULL state, the MSC/VLR can initiate the MM information
request procedure to the associated SGSN. The SGSN sends the MM information
through the Gb/Iu interface and the GPRS broadcast channel. And when the user is
enjoying GPRS service, the message can be sent through the service channel. If the
user is unknown at the SGSN, the message is discarded by the SGSN.
IX. SGSN Reset
After the OMC initiates the SGSN reset procedure at the background, the SGSN
notifies all associated MSC/VLRs that the confirmed by radio contact flag of the MS
saved in the VLR should be set to FALSE, and the association should be cancelled.
In addition, the SGSN-Reset flag should be set to TRUE. The SGSN-Reset flag
should be monitored by a timer, and the timers duration should be greater than the
duration of the MS Reachable timer. After the SGSN-Reset flag monitoring timer
expires, the SGSN-Reset flag is set to FALSE. SGSN reset will affect CS paging.
X. VLR Reset
After the VLR is reset, the VLR informs the SGSN to set the VLR-Reliable flag of all
users associated with the VLR to FALSE and to cancel the association. If the
VLR-Reliable flag of a MS is FALSE, the SGSN receives from the user the combined
Ra/La update (no matter La is changed) or the periodic Ra update. The SGSN shall
initiate the location update request to the MSC/VLR.
XI. HLR Reset
After the HLR reset, the location information confirmed in HLR flag of the MS at the
VLR side is FALSE. The location information of the MS in the HLR should be restored.
The SGSN performs the NGAF flag set.

Chapter 7 CAP

7-1
Chapter 7 CAP
7.1 Overview
CAMEL Application Part (CAP) has evolved from the Intelligent Network Application
Protocol (INAP) of the wired Intelligent Network (IN). CAP enables signaling
interworking between GSM Service Switching Function (gsmSSF), GSM Specialized
Resource Function (gsmSRF) and GSM Service Control Function (gsmSCF) of radio
IN functional entities, for the purpose of supporting CAMEL services.
CAP protocol is one of the parts of the Signaling System No. 7. CAP is the user part
of the Transaction Capabilities Application Part (TCAP) in the SS7. CAP uses
structured/unstructured dialog capabilities provided by the TCAP protocol, and
realizes signaling interaction between functional entities.
CAP interface used in the UMTS is shown in Figure 7-1.
MSC Server
gsmSSF
MSC Server
gsmSSF
gsmSCF
VLR
gsmSRF
MAP
CAP
CAP
CAP
MSC Server
gsmSSF
MSC Server
gsmSSF
gsmSCF
VLR
gsmSRF
MAP
CAP
CAP
CAP

Figure 7-1 CAP interface supported in the UMTS network
7.1.2 CAP Implementation in MSOFTX3000
MSOFTX3000 functions as a MSC Server or GMSC Server in the UMTS R4
networking model. Service Switching Point (SSP) functional entity is built in
MSOFTX3000. The CAP protocol is used on the interface between MSOFTX3000
and a Service Control Point (SCP), as shown in Figure 7-2.
Chapter 7 CAP

7-2
CAP
MSC Server/SSP
(MSOFTX3000)
SCP
CAP
CAP
MSC Server/SSP
(MSOFTX3000)
SCP
CAP

Figure 7-2 CAP protocol implementation in MSOFTX3000
MSOFTX3000 provides two ways to transfer the CAP protocol: TDM based and IP
based. The TDM based way is to make use of the services provided by the MTP for
information transfer; the IP based way is to make use of the services provided by the
SIGTRAN protocol for transmission. The protocol stack is shown in Figure 7-3
CAP
SCCP
MTP3
MTP2
MTP1
(G)MSC Server/SSP
(MSOFTX3000)
TCAP
SCCP
SCTP
IP
MAC
(G)MSC Server/SSP
(MSOFTX3000)
M3UA
TCAP
CAP
SCCP
MTP3
MTP2
MTP1
TCAP
CAP
TCAP
SCCP
SCTP
IP
MAC
M3UA
CAP
CAP CAP
SCP SCP
CAP
SCCP
MTP3
MTP2
MTP1
(G)MSC Server/SSP
(MSOFTX3000)
TCAP
SCCP
SCTP
IP
MAC
(G)MSC Server/SSP
(MSOFTX3000)
M3UA
TCAP
CAP
SCCP
MTP3
MTP2
MTP1
TCAP
CAP
TCAP
SCCP
SCTP
IP
MAC
M3UA
CAP
CAP CAP
SCP SCP

Figure 7-3 Structure of the CAP protocol stack
The structure of a CAP message is shown in Figure 7-4.
MTP
Message
SCCP
Message
TCAP
Message
CAP
Message
MTP
Message
SCCP
Message
TCAP
Message
CAP
Message

Figure 7-4 Position of CAP in a link message
In SS7, CAP messages are conveyed as the component part of TCAP messages.
CAP messages are coded in the Abstract Syntax Notation One (ASN.1) format. There
Chapter 7 CAP

7-3
is a one-to-one relationship between CAP message types and operation codes in the
TCAP component. When a message is transferred, an Invoke ID shall be allocated to
each initiated operation. The Invoke ID is mainly used to identify a particular operation
in a certain direction of the CAP dialog. By distinguishing the operation code, a
component can be translated to the corresponding CAP message. Message
translation between CAP and TCAP is implemented by the Functional Entity Access
Manager (FEAM).
7.2 CAP Operations
Interaction between functional entities across the mobile intelligent network depends
on a variety of operations defined by the CAP protocol. The CAP protocol defines
different operation sets in specific phases. MSOFTX3000 supports CAMEL Phase 3.
In this phase, the CAP protocol defines 32 CAP operations. 24 operations are call
related and others are Short Message Service (SMS) related. The functions of each
operation are briefly described as follows.
7.2.1 Call Related Operations
I. Initial DP
This operation is sent by the gsmSSF to the gsmSCF. After detection of a Detection
Point (DP) in the Basic Call State Module (BCSM), triggering of an intelligent call
procedure is required. The gsmSSF initiates the Initial DP. The "Initial DP" operation
contains various information needed by the gsmSCF, such as the calling number,
called number, calling subscriber location information, called subscriber location
information, subscriber status, etc.
II. RequestReportBCSMEvent
This operation is sent by the gsmSCF to the gsmSSF. According to the service
requirements, the gsmSCF can use the RequestReportBCSMEvent to request the
gsmSSF for a call related BCSM event. Upon reception of this operation, the gsmSSF
records the necessary call related BCSM event to be reported. When the BCSM
event is detected, a notification is sent to the gsmSCF by an "EventReportBCSM.
III. EventReportBCSM
This operation is sent by the gsmSSF to the gsmSCF. The gsmSSF has recorded the
reported event required in the RequestReportBCSMEvent message sent by the
gsmSCF. If the event is detected, a notification is sent to the gsmSCF by using an
EventReportBCSM. The gsmSCF will perform further handling according to the
event type.
Chapter 7 CAP

7-4
IV. CallInformationRequest
This operation is sent by the gsmSCF to the gsmSSF. After collection of call related
information is required in service operations and management, the gsmSCF can send
to the gsmSSF a CallInformationRequest message to collect the following call
related information:
Call Attempt Elapsed Time
Call Stop Time
Call Connected Elapsed Time
Release Cause
The information will be reported by the gsmSSF to the gsmSCF in the
CallInformationReport format when the call is released or the collection is
completed.
V. CallInformationReport
This operation is sent by the gsmSSF to the gsmSCF. When the gsmSSF receives
the CallInformationRequest from the gsmSCF, the gsmSSF sends the required
information in the CallInformationReport format to the gsmSCF at call release or
collection completion, so that the gsmSCF can collect the call related information.
If a gsmSSF is requested by the gsmSCF to report a call information event, the
gsmSSF contains the suspended call information report. If the gsmSSF reports the
call information event, the call information report suspension will be released.
VI. ApplyCharging
This operation is sent by the gsmSCF to the gsmSSF, and is used to control the
duration of the call. The ApplyCharging operation contains the maximum call
duration, the charging tariff change duration and other control parameter used in the
call. The actual call duration will be sent in an ApplyChargingReport by the gsmSSF
to indicate to the gsmSCF when the call reaches the maximum duration or the call is
released by either subscriber.
VII. ApplyChargingReport
This operation is sent by the gsmSSF to the gsmSCF. When the actual call duration
reaches the maximum duration specified in the corresponding ApplyCharging
operation or the call is released by either subscriber, the gsmSSF sends this
operation to inform the gsmSCF about the actual duration and other related
information of the call.
Chapter 7 CAP

7-5
VIII. SendChargingInformation
This operation is sent by the gsmSCF to the gsmSSF. This operation is used to send
e-parameters from the gsmSCF to the gsmSSF. SendChargingInformation contains
the Charge Advice Information (CAI) of the Advice of Charge (AoC). This CAI can be
used to replace the MSC generated CAI and inhibit any further generation of CAI.
IX. FurnishChargingInformation
requirements, the gsmSCF sends to the gsmSSF a FurnishChargingInformation
message to control output of the charging information at the gsmSSF.
X. Continue
This operation is sent by the gsmSCF to the gsmSSF. The gsmSCF makes use of the
Continue operation to instruct the gsmSSF to proceed with the suspended call
processing.
XI. Connect
requirements, the gsmSCF makes use of the Connect operation to modify some
parameters of the call, such as the called address, calling line identification
presentation, etc., so that the call can go on as per the service requirements.
XII. ReleaseCall
requirements, the gsmSCF initiates, at any time of the call, the ReleaseCall
operation to request the gsmSSF to release the corresponding call.
XIII. ConnectToResource
This operation is sent by the gsmSCF to the gsmSSF. When subscriber interaction is
required, the gsmSCF originates the ConnectToResource operation to instruct the
gsmSSF to connection the current call to the gsmSRF, preparing for the subsequent
subscriber interaction process.
XIV. PlayAnnouncement
This operation is sent by the gsmSCF to the assisting gsmSSF/gsmSRF. This
operation is used in the user interaction process of intelligent call proceeding. Via this
operation, the gsmSCF indicates to the gsmSRF to play an announcement to the user.
Chapter 7 CAP

7-6
The gsmSSF plays a role of signaling trunk during this process. Upon reception of the
operation, the gsmSSF will deliver it to the concerned gsmSRF.
XV. PromptAndCollectInformation
This operation is sent by the gsmSCF to the assisting gsmSSF/gsmSRF. This
operation is used in user interaction process of intelligent call proceeding. Via this
operation, the gsmSCF instructs the gsmSRF to play an announcement to the user, in
order to require the user to input relative information (e.g. account information and
user password). After collecting the information input by the user, the gsmSRF sends
it to the gsmSCF in the format of PromptAndCollectInformation. The gsmSSF
functions as the signaling trunk in the process. Upon reception of the operation, the
gsmSSF will deliver it to the controlled gsmSRF.
XVI. DisconnectForwardConnection
This operation is sent by the gsmSCF to the gsmSSF/gsmSRF. After user interaction
process is completed, the gsmSCF uses this operation to request the
gsmSSF/gsmSRF to clear the connection of the specialized resources for the call.
XVII. SpecializeResourceReport
This operation is sent by the gsmSRF to the gsmSCF. The gsmSRF uses this
operation to indicate to the gsmSCF that the corresponding PlayAnnouncement
operation has been completed.
XVIII. EstablishTemporaryConnection
This operation is sent by the gsmSCF to the initiating gsmSSF. Due to the
requirement by the service or management, the gsmSCF expects to utilize an assist
procedure in user interaction. In this case, the gsmSCF actively sends the
EstablishTemporaryConnection operation to the initiating gsmSSF, requesting the
initiating gsmSSF to create a temporary connection with the assisting
gsmSSF/gsmSRF. Upon receipt of the operation, the initiating gsmSSF will initiate an
assist request to the corresponding network entity according to the address of the
assisting gsmSSF/gsmSRF contained in the operation, so as to enable the
appropriate assist procedure.
XIX. AssistRequestInstruction
This operation is sent by the assisting gsmSSF/gsmSRF to the gsmSCF. Upon
reception of the assist request from the initiating gsmSSF, the assisting
gsmSSF/gsmSRF sends this operation to the gsmSCF to start an assist procedure
and makes use of the assisting SSP or independent IP to achieve user interaction.
Chapter 7 CAP

7-7
XX. CallGap
This operation is sent by the gsmSCF to the gsmSSF. A gsmSSF may provision to the
gsmSCF a large volume of message traffic in a relatively short time. If the growing of
the traffic exceeds the allowable range, congestion may happen at the gsmSCF. This
will prolong the message responding time and increase the call failure rate. Therefore,
the gsmSCF can activate a CallGap operation at detecting the congestion,
requesting the gsmSSF to slow down the sending of service requests to it.
XXI. ResetTimer
This operation is sent by the gsmSCF to the gsmSSF. This operation is used by the
gsmSCF to refresh the status timer of the gsmSSF during the service proceeding, in
order to avoid status timeout at the gsmSSF.
XXII. Cancel
This operation is sent by the gsmSCF to the gsmSSF/gsmSRF, for the purpose of
canceling a previously sent PlayAnnouncement operation or
PromptAndCollectInformation operation. The gsmSSF/gsmSRF uses an error
indication Canceled to notify the gsmSCF of the successful cancellation of the
corresponding operation.
The Cancel operation can also be used to cancel all suspended
ApplyChargingReport or CallInformationReport operation, and all configured EDP
events.
XXIII. ActivityTest
This operation is originated by the gsmSCF to test the normality of the control
relationship of the gsmSCF on the gsmSSF/gsmSRF. Upon reception of the
ActivityTest operation indication, the gsmSSF/gsmSRF will return the ActivityTest"
outcome if the control relationship is normal; otherwise, the gsmSSF/gsmSRF will not
perform any handling on it. If an ActivityTest response is not received at the
gsmSCF, it indicates that the control relationship between the gsmSCF and the
gsmSSF/gsmSRF has failed in some way. Appropriate actions can be taken as per
the service requirements.
XXIV. ContinueWithArgument
This operation is sent by the gsmSCF to the gsmSSF. The gsmSCF uses the
ContinueWithArgument operation to instruct the gsmSSF to proceed with the
suspended call handling. Moreover, this operation also provides additional services
for the user (calling or called party).
Chapter 7 CAP

7-8
7.2.2 SMS Related Operations
I. InitialDPSMS
This operation is sent by the gsmSSF to the gsmSCF. When the gsmSSF determines
that triggering of a mobile initial SMS procedure is required, the gsmSSF originates
the corresponding procedure by sending the InitialDPSMS operation and requests
the gsmSCF to complete the mobile initial SMS procedure.
II. RequestReportSMSEvent
This operation is sent by the gsmSCF to the gsmSSF. The gsmSCF sends the
RequestReportSMSEvent operation to the gsmSSF, requesting the gsmSSF to
monitor the SMS related event (a success or failure in submitting the short message
to the SMSC). At detecting the SMS event, the gsmSSF notifies the gsmSCF of that
via an EventReportSMS operation.
III. EventReportSMS
This operation is sent by the gsmSSF to the gsmSCF. The gsmSSF has recorded the
reported event required in the RequestReportSMSEvent operation sent by the
gsmSCF. If the event is detected, a notification is sent to the gsmSCF by using an
EventReportSMS. The gsmSSF will perform further handling according to the event
type.
IV. ContinueSMS
This operation is sent by the gsmSCF to the gsmSSF. The gsmSCF uses the
ContinueSMS operation to instruct the gsmSSF to proceed with the suspended
short message handling.
V. FurnishChargingInformationSMS
This operation is sent by the gsmSCF to the gsmSSF, for the purpose of controlling
the output of charging information at the gsmSSF. The gsmSCF sends charge related
information to a logical short message record. The first
FurnishChargingInformationSMS operation leads to the generation of a logical short
message record. Receipt of subsequent FurnishChargingInformationSMS
operations shall overwrite or add the contents of the logical short message record.
VI. ReleaseSMS
requirements, the gsmSCF uses the ReleaseSMS operation to request the gsmSSF
Chapter 7 CAP

7-9
to release the mobile initial SMS. This operation can be sent only when the controlling
relationship exists between the gsmSCF and the gsmSSF.
VII. ResetTimerSMS
This operation is sent by the gsmSCF to the gsmSSF. This operation is used by the
gsmSCF to refresh the status timer of the gsmSSF during the short message
proceeding, in order to avoid status timeout at the gsmSSF.
VIII. ConnectSMS
requirements, the gsmSCF can make use of the ConnectSMS operation to request
the gsmSSF to execute certain SMS handling: routing the short message to a
specified target address or affecting other SMS establishment information, etc.
7.3 Basic Signaling Procedures
MSOFTX3000 supports two ways to trigger an intelligent service: subscription
information trigger and number segment trigger. Both trigger signaling procedures are
illustrated in examples in the following part.
I. Procedure 1
Figure 7-5 depicts the call flow for a mobile prepaid subscriber in the MSCa/VLR/SSP
covering scope making a call to a PSTN subscriber, where the O-CSI triggers the
intelligent service.
Chapter 7 CAP

7-10
MSCa/VLR/SSP SCPa PSTN
O-CSI trigger
IDP
Charging the
calling party
RRBE
AC
Continue
IAI
ACM
ANC
.
.
.
ACR
ERB
RC
CAP messages
TUP messages

Figure 7-5 Flow of prepaid subscriber calling PSTN subscriber (O-CSI trigger)
1) The MSCa/VLR/SSP receives the call. According to the calling partys
subscription information, the service is triggered in Originating CAMEL
Subscription Information (O-CSI) manner. The MSCa/VLR/SSP resident toll area
code is directly put in the Location Number parameter of the IDP message. Then
the MSCa/VLR/SSP sends the IDP message to the SCPa.
2) After the SCPa receives the IDP message, the SCPa analyzes the calling partys
account before anything else is done. If the account is a valid one, determination
of the calling tariff rate is done according to the toll area code of the calling party
visitor location (Location Number parameter contained in the IDP message), and
the called toll area code. In addition to the determination, the balance in the
account is converted into conversation duration, and RRBE, AC and Continue
are sent to the MSCa/VLR/SSP.
3) The MSCa/VLR/SSP performs the connection according to the called number in
the TUP message.
4) At the end of the conversation, either party hooks on. The MSCa/VLR/SSP
reports the charging report and the onhook event.
II. Procedure 2
Figure 7-6 depicts the call flow for a mobile prepaid subscriber out of the
MSCa/VLR/SSP covering scope making a call to a PSTN subscriber, where the
calling party resident MSC/VLR accesses the MSCa/VLR/SSP in OVERLAY mode
Chapter 7 CAP

7-11
and the MSCa/VLR/SSP analyzes the calling number and triggers the intelligent
service based on the number segment.
MSCa/VLR/SSP SCPa PSTN
Number segment
trigger
IDP
Charging the
calling party
RRBE
AC
Continue
IAI
ACM
ANC
.
.
.
ACR
ERB
RC
CAP messages
TUP messages
IAI

Figure 7-6 Flow of prepaid subscriber calling PSTN subscriber (number segment trigger)
1) Upon receipt of the forwarded call, the MSCa/VLR/SSP analyzes the calling
number. If the calling party is a prepaid subscriber, the prefix at the front of the
called number is converted into the toll area code representing the actual
location of the calling party, and is put in the Location Number parameter of the
IDP message. The MSCa/VLR/SSP looks up the corresponding SCP address
based on the calling number segment, and then sends the IDP message to the
SCPa.
2) After the SCPa receives the IDP message, the SCPa analyzes the calling partys
account before anything else is done. If the account is a valid one, the tariff rate
is determined according to the actual location (Location Number) of the calling
party and the called toll area code. The balance in the account is converted into
the conversation duration. RRBE, AC and Continue messages are sent to the
MSCa/VLR/SSP.
3) The MSCa/VLR/SSP performs the connection according to the called number in
the TUP message.
4) At the end of the conversation, either party hooks on. The MSCa/VLR/SSP
reports the charging report and the onhook event.

Chapter 8 ISUP

8-1
Chapter 8 ISUP
8.1 Overview
The Integrated Services Digital Network User Part (ISDN User Part, that is, ISUP) is
one of the User Parts of the Common Channel Signaling System No. 7, which defines
the signaling messages, functions and procedures required to control voice and
non-voice services (for example, circuit switched data communication). The ISUP can
not only implement the functions of the Telephone User Part (TUP) and the Data User
Part (DUP), but also achieve the ISDN services on a wide basis, thus having a
spacious application scope.
The ISUP protocol supports basic bearer services, that is, establishing, monitoring and
releasing 64kbit/s circuits between user terminals, and providing lower-layer
information transfer capability for the users.
In addition to basic bearer services, the ISUP also supports the following
supplementary services:
Calling line identification presentation and identification restriction (CLIP and
CLIR)
Connected line identification presentation and identification restriction (COLP and
COLR)
Call diversion services (call forwarding unconditional, call forwarding busy, call
forwarding no reply, call forwarding on mobile subscriber not reachable)
Call hold (HOLD)
Call waiting (CW)
User-to-user signaling (UUS)
Three-party service (3PTY)
The ISUP also supports the function of multi destination signaling point.
The Signaling Connection Control Part (SCCP) provides the support for ISUP
end-to-end signaling services.
Chapter 8 ISUP

8-2
8.1.1 ISUP Implementation in MSOFTX3000
When MSOFTX3000 functions as the GMSC Server, interconnection with exchange
equipment in the PSTN and other PLMNs is made possible by the ISUP interface. The
ISUP is implemented in MSOFTX3000 as shown in Figure 8-1.
BICC
GMSC Server
(MSOFTX3000)
MSC Server
(MSOFTX3000)
PSTN
PLMN
ISUP
MGW MGW
H.248 H.248
ISUP
BICC
GMSC Server
(MSOFTX3000)
MSC Server
(MSOFTX3000)
PSTN
PLMN
ISUP
MGW MGW
H.248 H.248
ISUP

Figure 8-1 Implementation of the ISUP in MSOFTX3000
When MSOFTX3000 functions as the GMSC Server, there are two approaches to
interwork with the PSTN/PLMN:
MSOFTX3000 has a built-in Signaling Gateway (SG) function, thus providing the
TDM interface for interworking with PSTN/PLMN signaling equipments (exchange,
STP, and so on) where ISUP is used as the inter-office signaling and MTP is used
to carry the signaling.
MSOFTX3000 provides the IP interface, being transferred by an independent SG,
to interworking with PSTN/PLMN signaling equipments where ISUP is used as the
inter-office signaling and SIGTRAN is used to carry the signaling.
MSOFTX3000 provides two ways to transfer the ISUP protocol: TDM based and IP
based. The TDM based way is to make use of the services provided by the MTP for
information transfer; the IP based way is to make use of the services provided by the
SIGTRAN protocol for transmission. The protocol stack is shown in Figure 8-2
Chapter 8 ISUP

8-3
ISUP
SCCP
MTP3
MTP2
MTP1
GMSC Server
(SoftX3000)
PSTN/PLMN
ISUP
SCCP
MTP3
MTP2
MTP1
ISUP
SCCP
SCTP
IP
MAC
GMSC Server
(SoftX3000)
PSTN/PLMN
M3UA
ISUP
SCCP
SCTP
IP
MAC
M3UA
ISUP
SCCP
MTP3
MTP2
MTP1
GMSC Server
(SoftX3000)
PSTN/PLMN
ISUP
SCCP
MTP3
MTP2
MTP1
ISUP
SCCP
SCTP
IP
MAC
GMSC Server
(SoftX3000)
PSTN/PLMN
M3UA
ISUP
SCCP
SCTP
IP
MAC
M3UA

Figure 8-2 ISUP protocol stack
Primitives are used for communication of ISUP messages with the lower transport layer.
The primitives used between MTP (or M3UA) and ISUP include the transfer primitive,
the resume primitive, the pause primitive and the status primitive.
The MTP-TRANSFER primitive is used to carry the signaling messages of the
ISDN User Part. ISDN User Part signaling messages are capsulated in the
MTP-TRANSFER primitive for transmission and reception.
The MTP-PAUSE primitive is sent by the Message Transfer Part to indicate its
inability to transfer messages to the destination specified as a parameter.
The MTP-RESUME primitive is sent by the Message Transfer Part to indicate its
ability to resume unrestricted transfer of messages to the destination specified as
a parameter.
The MTP-STATUS primitive is sent by the Message Transfer Part to indicate that
the signaling route to a specific destination is congested or the ISDN User Part at
the destination is unavailable. Unavailability causes can be unequipped,
inaccessible, or unknown.
ISDN User Part messages are conveyed on a signal link by means of message signal
unit (MSU) where the messages are capsulated in the service information field (SIF).
An ISUP message consists of six parts, namely routing label, circuit identification code,
message type code, the mandatory fixed part, the mandatory variable part, and the
optional part, as shown in Figure 8-3.
Please reference Chapter MTP in Transport Protocols part of this manual for the
description of routing label and circuit identification code. Others are covered in this
chapter.
Chapter 8 ISUP

8-4
Signaling message
OPC DPC ISUP message CIC SLC
F
MSU
Message type
Mandatory parameter A with fixed length
Mandatory parameter F with fixed length
Point to parameter M
Point to parameter P
Point to start bit of optional parameter
Length of parameter M
Parameter M
Length of parameter P
Parameter P
Code of parameter X
Length of parameter X
Parameter X
Code of parameter Z
Length of parameter Z
Parameter Z
End tag of variable parameter
Mandatory parameter with fixed length

Mandatory parameter with variable length
Optional parameter
Signaling message
OPC DPC CIC SLC
F

Figure 8-3 Structure of an ISUP message
I. Message Type Code
The message type code consists of a one-octet field and is mandatory for all messages.
The message type code uniquely defines the function and format of each ISDN user
part message (see Table 8-1).
Table 8-1 ISUP message code
Code
Abbreviati
on
Meaning
00000001 IAM
Initial address message: A message sent in the forward direction to
initiate seizure of an outgoing circuit and to transmit number and other
information relating to the routing and handling of a call.
00000010 SAM
Subsequent address message: A message that may be sent in
the forward direction following an initial address message, to convey
additional called party number information.
00000011 INR
Information request message: A message sent by an exchange to
request information in association with a call.
Chapter 8 ISUP

8-5
Code
Abbreviati
on
Meaning
00000100 INF
Information message: A message sent to convey information in
association with a call, which may have been requested in an
information request message.
00000101 COT
Continuity message: A message sent indicating whether or not
there is continuity on the preceding circuit(s) as well as of the selected
circuit to the following exchange, including verification of the
communication path across the exchange with the specified degree of
reliability.
00000110 ACM
Address complete message: A message indicating that all the address
signals required for routing the call to the called party have been
received.
00000111 CON
Connect message: A message indicating that all the address signals
required for routing the call to the called party have been received and
that the call has been answered.
00001000 FOT
Forward transfer: A message sent in the forward direction on
semi-automatic calls when the outgoing international exchange operator
wants the help of an operator at the incoming international exchange.
The message will normally serve to bring an assistance operator into the
circuit if the call is automatically set up at the exchange. When the call is
completed by an operator at the incoming international exchange, the
message should preferably cause this operator to be recalled.
00001001 ANM
Answer message: A message indicating that the call has been
answered. In semi-automatic working, this message has a supervisory
function. In automatic working, this message is used in conjunction with
charging information.
00001100 REL
Release message: A message sent in either direction to indicate that the
circuit is being released due to the cause supplied and is ready to be put
into the idle state on receipt of the release complete message. Where
the call is to be redirected the message will also carry the redirection
number.
00001110 RES
Resume message: A message sent in either direction indicating that the
calling or called party, after having been suspended, is reconnected.
00010000 RLC
Release complete message: A message sent in either direction in
response to the receipt of a release message, or if appropriate to a reset
circuit message, when the circuit concerned has been brought into the
idle condition.
00010001 CCR
Continuity check request message: A message sent by an exchange for
a circuit on which a continuity check is to be performed, to the exchange
at the other end of the circuit, requesting continuity checking equipment
to be attached.
00010010 RSC
Reset circuit message: A message sent to release a circuit, due to
memory broken or other causes.
Chapter 8 ISUP

8-6
Code
Abbreviati
on
Meaning
0010011 BLO
Blocking: A message sent only for maintenance purposes to the
exchange at the other end of a circuit, to cause an engaged condition of
that circuit for subsequent calls outgoing from that exchange. When a
circuit is used in the dual-circuit mode of operation, an exchange
receiving the blocking message must be capable of accepting incoming
calls on the concerned circuit unless it has also sent a blocking
message. Under certain conditions, a blocking message is also a proper
response to a reset circuit message.
00010101 BLA
Blocking acknowledgement: A message sent in response to a blocking
message, indicating that the circuit has been blocked.
00010111 GRS
Circuit group reset: A message sent to release an identified group of
circuits.
00011000 CGB
Circuit group blocking message: A message sent to the exchange at the
other end, indicating the specified circuit group has been blocked.
00011001 CGU
Circuit group unblocking: A message sent to the exchange at the other
end of an identified group of circuits to cause cancellation in that group of
circuits of an engaged condition activated earlier by a blocking or circuit
group blocking message.
00011010 CGBA
Circuit group blocking acknowledgement: A message sent in response
to a circuit group blocking message to indicate that the requested group
of circuits has been blocked.
00011011 CGUA
Circuit group unblocking acknowledgement: A message sent in
response to a circuit group unblocking message to indicate that the
requested group of circuits has been unblocked.
00011111 FAR
Facility request: A message sent from an exchange to another exchange
to request activation of a facility.
00100000 FAA
Facility accepted: A message sent in response to a facility request
message indicating that the requested facility has been activated.
00100001 FRJ
Facility rejected: A message sent in response to a facility request
message to indicate that the facility request has been rejected.
00100100 LPA
Loop-back acknowledgement message: A message sent in the
backward direction in response to a continuity check request message
indicating that a loop (or transceiver in the case of a 2-wire circuit) has
been connected.
00101000 PAM Pass-along message
00101001 GRA
Circuit group reset acknowledgement: A message sent in response to a
circuit group reset message and indicating that the requested group of
circuits has been reset. The message also indicates the maintenance
blocking state of each circuit.
00101010 CQM
Circuit group query message: A message sent on a routine or demand
basis to request the far-end exchange to give the states of all circuits in a
particular range.
Chapter 8 ISUP

8-7
Code
Abbreviati
on
Meaning
00101011 CQR
Circuit group query response: A message sent in response to a circuit
group query message to indicate the states of all circuits in a particular
range.
00101100 CPG
Call progress: A message, sent in either direction during the set-up or
active phase of the call, indicating that an event, which is of significance,
and should be relayed to the originating or terminating access, has
occurred.
00101111 CFN
Confusion message: A message sent in response to any message
(other than a confusion message) if the exchange does not recognize
the message or detects a part of the message as being unrecognized.
00110000 OLM
Overload message: A message sent in the backward direction, on
non-priority calls in response to an IAM, to invoke temporary trunk
blocking of the circuit concerned when the exchange generating the
message is subject to load control.
00110001 CRG
Charging information: Information sent in either direction for accounting
and/or call charging purposes.
00110010 NRM
Network resource management message: A message sent in order to
modify network resources associated with a certain call. The message is
sent along an established path in any direction in any phase of the call.
00110011 FAC
Facility: A message sent in either direction at any phase of the call to
request an action at another exchange. The message is also used to
carry the results, error or rejection of a previously requested action.
00110110 IDR Identification request
00110111 IDS Identification response
00111000 SGM
Segmentation message: A message sent in either direction to convey an
additional segment of an overlength message.
00011101
00011100
00011110
00100111
Reserved

Each kind of message is composed of message type code and several parameters.
Each parameter has a name that is coded by a single octet. The length of a parameter
may be fixed or variable, and each parameter can have a one-octet length indicator.
II. Mandatory Fixed Part
Those parameters that are mandatory and of fixed length for a particular message type
are contained in the mandatory fixed part. The position, length and order of the
Chapter 8 ISUP

8-8
parameters is uniquely defined by the message type; thus, the names of the
parameters and the length indicators are not included in the message.
III. Mandatory Variable Part
Mandatory parameters of variable length are included in the mandatory variable part.
Pointers are used to indicate the beginning of each parameter. Each pointer is encoded
as a single octet. The name of each parameter and the order in which the pointers are
sent is implicit in the message type. The number of parameters and the number of
pointers is uniquely defined by the message type.
A pointer is also included to indicate the beginning of the optional part. If the message
type indicates that no optional part is allowed, then this pointer will not be present. If the
message type indicates that an optional part is possible but there is no optional part
included in this particular message, then a pointer field containing all zeros is used.
All the pointers are sent consecutively at the beginning of the mandatory variable part.
Each parameter contains the parameter length indicator and the contents of the
parameters.
IV. Optional Part
The optional part consists of parameters that may or may not occur in any particular
message type. Both fixed length and variable length parameters may be included.
Optional parameters may be transmitted in any order. Each optional parameter will
include the parameter name (one octet) and the length indicator (one octet) followed by
the parameter contents.
End of optional parameters octet: If optional parameters are present and after all
optional parameters have been sent, an "end of optional parameters" octet containing
all zeros will be transmitted.
I. Basic Call Signaling Procedure
A mobile subscriber makes a call to an idle PSTN subscriber. The call is implemented
successfully. The inter-office ISUP signaling procedure between the GMSC Server
(functioned by MSOFTX3000) and the PSTN end office LS is made as shown in Figure
8-4.
Chapter 8 ISUP

8-9
GMSC Server LS
IAM
ACM
ANM
Conversation
REL
RLC
REL
RLC
Calling party
hangs up first
Called party
hangs up first
GMSC Server LS
IAM
ACM
ANM
Conversation
REL
RLC
REL
RLC
Calling party
hangs up first
Called party
hangs up first

Figure 8-4 Basic call process by means of ISUP
1) Call setup process
The GMSC Server sends an IAM message to the PSTN end office LS. The LS notifies
the called party on receipt of the IAM message, and ringing is performed on the called
party in the case of idle state. The LS sends an ACM message in the backward
direction. After the called party answers, the LS sends an ANM message in the
backward direction, and the call is successfully set up.
2) Call release process
If the calling party hangs up first, the GMSC Server sends a REL message in the
forward direction. On receipt of the REL message, the LS sends back a RLC message
to release the trunk and meanwhile notifies the called party of the end of the call.
If the called party hangs up first, the LS sends a REL message in the backward
direction. After receiving the REL message, the GMSC Server sends back a RLC
message to release the trunk.
II. Call Failure Signaling Procedure
A mobile subscriber makes a call to an idle PSTN subscriber. The call is not successful
as the called party is busy. The inter-office ISUP signaling procedure between the
GMSC Server (functioned by MSOFTX3000) and the PSTN end office LS is made as
Chapter 8 ISUP

8-10
GMSC Server LS
IAM
REL
RLC
Called party is busy
GMSC Server LS
IAM
REL
RLC
Called party is busy

Figure 8-5 Unsuccessful call process by means of ISUP
1) The GMSC Server sends an IAM message to the PSTN end office LS to set up the
call.
2) The LS finds that the called party is busy and then directly sends a REL message
to release the call where the release cause is carried.
3) The GMSC Server sends back a RLC message to complete the release.

Chapter 9 Nb UP and IPBCP

9-1
9.1 Overview
9.1.1 Brief Introduction to the Nb Interface
As the interface between MGW devices in the CS domain of the UMTS network, the Nb
interface provides service connection channels between different MGWs, such as
between the end office MGW and the gateway office MGW.
The Nb interface provides the transmission and bearer function for voice service traffic,
and IPBCP is used for the control of voice service traffic transmission in the CN. IPBCP
accomplishes negotiation about the Nb interface bearer features of different MGWs,
and the negotiation interaction messages are transmitted through the tunnel provided
by the Mc interface and Nc interface.
In the architecture where call control is independent from bearer, the Nb interface is
divided into two parts as user plane and control plane based on the difference between
service traffic and control traffic. The user plane transfers service traffic based on Nb
UP; whereas the control plane accomplishes bearer feature negotiation based on Nb
CP. Different bearer modes require different protocols. In the case of IP bearer, the
control plane selects IPBCP for bearer control; and the user plane uses UDP/IP to fulfill
the function of speech service traffic bearer.
9.1.2 Definition and Function of the Nb
As a newly defined interface, the Nb interface is used to connect the service bearer
devices in the CN. The Nb interface has the following functions:
Providing the service traffic bearer function for the CN
Accomplishing being independent from the lower-layer transmission mode based
on Nb UP, and accomplishing bearers of IP/ATM mode.
Providing transparent transmission channels for TDM bearer signaling.
The adaptation protocol used in the Nb interface user plane is to transfer data between
MGWs. Nb UP is originated by an MGW and acknowledged by the neighbor MGW. The
Nb UP frame is the same as the lu UP frame, that is, one PDU type is effective for the
both.
The Nb interface position and the data adaptation protocols are shown in Figure 9-1.

9-2

MGW MGW
Nb Iu
T
r
a
n
s
p
o
r
t

L
a
y
e
r

SRNC
Radio
Protocols
Iu UP Iu UP
Nb
UP
Nb
UP

Figure 9-1 The Nb interface position and the adaptation protocols structure
The definition and operation of Nb UP are the same as that of IuUP, and they both
support the two operational modes: pre-defined support mode and transparent
transmission mode. The only difference between the two protocols is that they are
applied to different interfaces. The most distinctive point of Nb UP is to shield
differences of lower layers, so as to bear the service traffic based on different modes.
9.1.3 Protocol Structure
The lower layer over the Nb interface has two transmission modes, which are based on
IP and ATM respectively. Different transmission modes call for different user-plane
protocols and control-plane adaptation protocols. Next will introduce the protocol stack
structures related to specific transmission modes.
I. IP Bearer Mode
In the WCDMA R4 network, the complete IP network is recommended for the CN
devices. 3GPP defines the protocol stack structure over the Nb interface when IP
transmission mode is selected. And over the Nb interface, the protocols of the user
plane are different from the adaptation protocols used by the control plane.
Based on IP transmission mode, the user plane adopts such a protocol structure as
RTP/UDP/IP. And the IP layer supports IPv4 and IPv6. The structure of the user-plane
protocol stack is shown in Figure 9-2.

9-3
RTP/RTCP
(RFC1889/RFC1990)
UDP
(RFC768)
IPv4(RFC791) or IPv6
(RFC2460)
Nb UP
DATA

Figure 9-2 The protocol stack structure of the IP bearer user plane
One MGW device can have several IP addresses, and IP address + UDP port number
is used to identify a bearer resource. In the structure figure above, RTP is optional.
UDP shall assign two successive port numbers to RTP and RTCP. And RTP shall use
the port with an even port number, and RTCP shall use the port identified by that even
number+1.
In the case of IP transmission, the control plane uses IPBCP (IP Bear Control Protocol).
The bearer feature negotiation is accomplished through the tunnel provided by the Mc
interface and the Nc interface. For details, please see related introduction to IPBCP.
II. ATM Bearer Mode
The structure of the user-plane protocol stack based on ATM transmission is illustrated
in Figure 9-3.
AAL2 SAR
SSCS(I.366.1)
AAL2(I.363.2)
ATM
Nb UP
DATA

Figure 9-3 The structure of the user-plane protocol stack based on ATM bearer
As the above figure shown, the protocol stack structure here is the same as that of the
lu interface user plane based on ATM bearer.
The ATM AAL2 link requires virtual circuit transmission. The types of virtual circuits can
be PVC and SPVC and SVC. The Nb interface in ATM transmission mode must support

9-4
PVC, whereas SPVC and SVC are optional. The virtual circuit is released by the
initiator.

Note:
At present, the UMG8900 device only supports PVC, other than SPVC and SVC.

AAL-2 SAR SSCS is able to provide elementary data packets for segmentation and
assembly, and it also supports transmission error check, reliable and sequenced
packets transfer and flow control.
The AAL2 sub-layer can transmit such applications as being low-speed, sensitive to
delay and with variable packet length.
The protocol stack structure of the control plane in ATM transmission mode is
illustrated in Figure 9-4.
MTP-3b
SAAL
AAL5
STC(Q.2150.1)
Q.AAL2(Q.2630.1/
Q.2630.2)
ATM

Figure 9-4 The protocol stack structure of the control plane in ATM transmission mode
The figure shows that in ATM transmission mode, the protocol stack structure of the Nb
interface control plane is the same as that of the lu interface control plane at the
transport layer. For details, please refer to related protocol introduction in the appendix
and the lu interface protocol structure introduction in this manual.
9.2 Introduction to the Nb UP
When the MGW device is applied to the CN, the interface defined for the bearer
devices between end offices, between an end office and a gateway office is Nb
interface. When the call-independent bearer architecture is adopted, user data are
transmitted based on Nb UP, and control data are transmitted based on Nb CP.

9-5
Within the UMG8900 device, if the Nb interface selects ATM bearer mode, the MASU
will be responsible for Nb UP processing and protocol supporting function. If the Nb
interface selects IP bearer mode, the MRPU and MTCA/MTCB will be responsible for
Nb UP processing and protocol stack supporting function.
9.2.1 Functions
Nb UP is mainly used for user plane adaptation at Nb interfaces of CS domain of
WCDMA CN and service data transmission between MGWs of CN. Nb UP provides
lower layer-independent features. Nb UP is the same as the lu UP protocol in terms of
location in the network and functions expect the application environments.
Nb UP, located between the core network layer (CNL) and the transport network layer
(TNL), provides data transmission services for CNL. Nb UP is independent from the
transmission mechanism of the lower layer.
Either IP or ATM can be selected as the transmission protocol at Nb interfaces, which
corresponds to a different transmission control protocol from the other.
9.2.2 Operational Modes
Like the lu UP protocol, Nb UP also has two operational modes: support mode for
predefined SDU size (SMpSDU) and transparent mode (TrM).
I. Transparent Mode (TrM)
InTrM, Nb UP transmits the frames of the upper layer and the lower layer transparently,
rather than exchange any information with the opposite-end Nb UP. The function of this
mode is confined to user data transmission, and any in-band negotiation process
related to bearer set up is not allowed.
II. Support Mode for Predefined SDU Size (SMpSDU)
This mode is applied to the condition that the Nb UP layer needs to process data
frames through this layer. PDUs frames used for transmitting AMR speech adopt this
mode. In support mode, Nb UP has the following functions:
Transfer of user data
Initialization
Rate control
Time alignment
Handling of error events
Frame quality classification
As Nb UP has the same functions as the lu UP protocol, for its functions, please see the
previous part of the lu UP protocol introduction.

9-6
The basic procedures of Nb UP are transfer of user data procedure, initialization
procedure, rate control procedure, time alignment procedure, handling of error events
procedure and frame quality classification procedure.
The procedures are almost the same as those of the lu UP protocol. The only difference
is that for Nb UP, the two interworking entities are located on different MGWs in CN,
other than between RNC and MGW. So the basic procedures of Nb UP are not
described here and for more information please refer to related part about lu UP
protocol procedures.
9.3 Introduction to the IPBCP
IPBCP (IP Bear Control Protocol) is engaged in bearer attributes negotiation before the
RTP bearer is set up for bearing Nb UP data at Nb interfaces. This negotiation is
accomplished after a round of successful interaction between request messages and
reply messages. IPBCP meets related requirements defined by the ITU-T Q.1970
recommendation.
Within UMG8900, the processing of IPBCP protocol stack is performed by configuring
MRPU. IPBCP implements bearer control transmission and tunnel functions at Mc
interfaces by means of the extended functions of H.248 protocol stack provided by
MPPB.
IPBCP bearer and negotiation processes are completed through Mc interfaces and Nc
interfaces. The logic structure is shown in Figure 9-5:
MGW MGW
MSC-Server MSC-Server
Nc
Mc
Nb
Mc
TS 29.232
BICC: Q.765.5
Tunnel: Q.1990
IPBCP: Q.1970

Figure 9-5 IPBCP bearer logic structure
Nb interface control-plane protocols are defined by the TS 29.232 of 3GPP standard. In
IP bearer mode, the connection between two MGWs for service bearer property
negotiation is set up through the path provided by Mc interfaces and the tunnel

9-7
provided by Nb interfaces, which meet the requirements on Mc interfaces and Nb
interfaces defined by the 3GPP standard respectively.
9.3.1 Functions
IPBCP is mainly engaged in information exchange and negotiation during BICC call
establishment, concerning media stream characteristics, port number, IP address, and
so on. IPBCP uses the codec type defined by SDP to encode this information. IPBCP
assumes a reliable, sequenced, point-to-point signalling transport service between two
nodes.
9.3.2 Primitive and Message Structure
IPBCP contains the following four types of primitive messages:
Request Message: the messages sent from Bear inter-working Function (BIWF) of
MGW to the remote end to request initialized IP bearer set up or modification.
Accepted Message: the messages returned when the BIWF of the remote MGW
receives and processes the request messages correctly.
Confused Message: the messages returned when the BIWF of the remote MGW
can not identify the request messages received.
Rejected Message: the messages returned when the BIWF of the remote MGW
correctly receives the request messages but refuses to process them due to some
reason.
The SDP domains (Session Description Protocol) included in an IPBCP primitive
message are described as below.
1) Session and time description domain
Protocol version (v)
Origin (o): source MGW
Session name (s)
Connection data (c)
Session attribute (a): used to identify IPBCP version and message type.
Time (t)
2) Media description domain
Media Announcement 1 (m)
Media attributes (a): supporting RTP dynamic payload type, DTMF and additional
attributes of other speech and signals.

Note:
The partial and sub domains listed above are added as SDP requires, but independent of application
environment. The above domains must be present and be used as RFC 2327 defines.

9-8
Other SDP domains may also exist in an IPBCP message, but they are not useful for IPBCP application.
So they are discarded as not being accepted.

IPBCP basic procedures involve IP bearer set up, IP bearer changing, IP bearer
release, compatibility process and exceptional events process.
I. IP Bearer Setup
1) Successful process
The interworking in IP bearer set-up process is shown in Figure 9-6.
I-BIWF R-BIWF
Request
Accepted
T1
Check the
info Received

Figure 9-6 Successful IP bearer set up
The process is described as follows.
When receiving an IP bearer set up request from the control entity, the initialing bearer
Inter-working function (I-BIWF) will send a request to the receiving BIWF (R-BIWF) and
meanwhile start a timer (T1)
The request message sent to R-BIWF should contains media announcement, the
interface address for transmitting media streams with R-BIWF of the connect data
domain and some optional information in the media attribute domain.
When receiving accept message returned by R-BIWF, I-BIWF will stop T1, and analyze
the accept message. If the following conditions are satisfied, the IP bearer is
successfully set up.
Except the port sub domain, the media announcement domain returned is
consistent with that in the request message.
Except time capability, tone capability and signal capability, the media attribute
domain is identical with that in the request message.
If the time capability, tone capability and signal capability are included in the
accept message, they can be accepted by I-BIWF.
2) Abnormal process

9-9
The IP bearer set up fails if R-BIWF can not correctly identify the request message from
I-BWF or the accept message returned by R-IWF is wrong.
In terms of I-BIWF at the sending side, the following abnormal cases may appear.
REJECTED message is received.
ACCEPTED message has errors.
If so, I-BIWF will stop T1, release the resources assigned for IP bearer and notify to set
up bearer control entities.
In terms of R-BIW at the receiving side, the following abnormal cases may appear.
The contents of REQUES received are wrong.
The designated media announcement is not supported.
R-BIWF should return the REJECTED message.
II. IP Bearer Changing
After IP bearer is set up, it can be changed by the control entities of I-BIWF and R-BIWF.
However, only fmt list in the media announcement parameter and the media attributes
used by IP bearer can be changed.
1) Successful process
The successful IP bearer changing process is shown in Figure 9-7.
I-BIWF R-BIWF
Request
Accepted
T2
Check the
info Received

Figure 9-7 IP bearer changing
Both I-BIWF and R-BIWF can originate IP bearer changing. The process will be
described later with I-BIWF being the initiating side as example. The IP bearer
changing process originated by R-BIWF is the same as that by I-BIWF, except that
messages involved are in the reverse flow.
I-BIWF sends a REQUEST message to request to modify IP bearer. Such parameters
are included in the message as media announcement and media attribute. After the
REQUEST message is sent, I-BIWF starts a timer (T2).
Upon receiving the REQUEST message, R-BIWF will check the message. If no
abnormality is found, the ACCEPTED message will be returned containing such
parameters as media announcement and media attribute. Except the port number, the

9-10
contents of media announcement in the ACCEPTED message should be consistent
with those in the REQUEST message. And except time, other options of media attribute
should be identical with those in the REQUEST message. The ACCEPTED message
sent by the receiving side means that the IP bearer modification is completed at the
receiving side.
After receiving the ACCEPTED message, I-BIWF stops T2 and checks the message
according to the following rules.
For the Media announcement, except the port number, other information should
be consistent with that in the REQUEST message I-BIWF sends.
Except time capability, tone capability and signal capability, other media attributes
should be consistent with the media attributes in the REQEUST message.
If time capability, tone capability and signal capability are included in the
ACCEPTED message, they must be accepted by R-BIWF.
If all those rules are met, I-BIWF will acknowledge the ACCEPTED message, and the
IP bearer modification is completed at the initiating side. After that, the upper-layer
control part is notified about the information that the IP bearer has been changed.
2) IP bearer changing fails
The following abnormal cases may happen to the initiating side.
The REJECTED message is received.
The ACCEPTED message is wrong.
If so, the initiating side will stop T2 and demand to modify the bearer control entity.
The following abnormal cases may happen to the receiving side.
The REQUEST message is wrong.
The designated Media announcement is not supported.
The receiving end should return the REJECTED message.
III. IP Bearer Release
IP bearer release concerns no IPBCP message interworiking. IPBCP is applied to
BICC environment, and IP bearer release is triggered by CSF.
IV. Capability Interworking
This process is to negotiate the IP BCP version of the two interwroking sides. The
process is shown in Figure 9-8.

9-11
I-BIWF R-BIWF
Request[I-Version ......]
Confused[T-Version ......]
Request[T-Version ......]

Figure 9-8 Capability interworking process
The REQUEST message includes the version number parameter I-Version. When the
receiving side receives the REQUEST message, it will check the version number. If t
I-Version is supported, the receiving side will use this version number in all the
messages sent to the remote side later. If it is not supported, the receiving side will
return the CONFUSE message which contains the version number T-Version it
supports.
When receiving the CONFUSED message, the initiating side will check the version
number T-version contained in the message. If T-version is supported, the initiating side
will resend REQUEST, using T-Version. If it is not supported, the initiating side will
report to the control entity.

HUAWEI


Signaling Procedures
Table of Contents

i
Table of Contents
Chapter 1 MGW Registration Procedures................................................................................... 1-1
1.1 MGW Registration Procedure............................................................................................ 1-1
1.2 MGW Deregistration Procedure......................................................................................... 1-1
Chapter 2 Mobility Management .................................................................................................. 2-1
2.1 Overview............................................................................................................................ 2-1
2.2 Location Management ....................................................................................................... 2-1
2.2.1 Basic Procedures .................................................................................................... 2-2
2.2.2 Major Procedures.................................................................................................... 2-5
2.3 Handover ......................................................................................................................... 2-12
2.3.1 Overview ............................................................................................................... 2-12
2.3.2 Classification ......................................................................................................... 2-12
2.3.3 Intra-UMTS Handover ........................................................................................... 2-14
2.3.4 Inter-System Handover ......................................................................................... 2-22
2.4 Roaming Restriction ........................................................................................................ 2-30
Chapter 3 Security Management.................................................................................................. 3-1
3.1 Overview............................................................................................................................ 3-1
3.2 Authentication .................................................................................................................... 3-1
3.2.1 GSM Authentication ................................................................................................ 3-1
3.2.2 UMTS Authentication .............................................................................................. 3-4
3.2.3 Dual-Mode MS Authentication ................................................................................ 3-7
3.3 Encryption.......................................................................................................................... 3-9
3.4 Integrity Protection........................................................................................................... 3-10
3.5 TMSI Reallocation............................................................................................................ 3-11
Chapter 4 Call Procedures ........................................................................................................... 4-1
4.1 Mobile Subscriber Calling Mobile Subscriber .................................................................... 4-1
4.1.1 Call Model ............................................................................................................... 4-1
4.1.3 Calling Procedures (Early Assignment Procedures)............................................... 4-4
4.1.4 Called Procedures (Early Assignment Procedures)................................................ 4-5
4.1.5 Disconnection Procedures ...................................................................................... 4-6
4.2 Mobile Subscriber Calling PSTN Subscriber ..................................................................... 4-6
4.2.1 Call Model ............................................................................................................... 4-6
4.2.3 Call Procedures....................................................................................................... 4-9
4.3 PSTN Subscriber Calling Mobile Subscriber ................................................................... 4-11
4.4 Pre-paging ....................................................................................................................... 4-12
Table of Contents

ii
4.5 Call Forwarding Services................................................................................................. 4-13
4.5.1 CFU....................................................................................................................... 4-14
4.5.2 CFB....................................................................................................................... 4-15
4.5.3 CFNRy................................................................................................................... 4-19
4.5.4 CFNRc................................................................................................................... 4-22
Chapter 5 SMS Procedures .......................................................................................................... 5-1
5.1 Overview............................................................................................................................ 5-1
5.2 Mobile Originated SMS...................................................................................................... 5-1
5.3 Mobile Terminated SMS.................................................................................................... 5-2
5.4 SMS Alerting Procedures .................................................................................................. 5-3
Chapter 6 IN Service Handling Procedures................................................................................ 6-1
6.1 Pre-paid Service Handling Procedures ............................................................................. 6-1
6.1.1 Mobile Pre-paid Subscriber Calling Ordinary WCDMA Subscriber ........................ 6-1
6.1.2 PSTN or Ordinary WCDMA Subscriber Calling Pre-paid Subscriber ..................... 6-2
6.1.3 Pre-Paid Subscriber Calling Pre-paid Subscriber ................................................... 6-3
6.1.4 Pre-paid Subscriber Calling Ordinary WCDMA Subscriber with CFU to Pre-paid
Subscriber ........................................................................................................................ 6-5
6.1.5 Recharge Procedure............................................................................................... 6-6
6.2 Mobile Originated SMS Handling Procedure..................................................................... 6-7
6.3 Mobility Management Event Notification Handling Procedure .......................................... 6-8
Chapter 7 Location Service Procedures..................................................................................... 7-1
7.1 Overview............................................................................................................................ 7-1
7.2 General LCS Architecture.................................................................................................. 7-1
7.3 General Network Location Procedures.............................................................................. 7-3
7.3.1 Mobile Terminated Location Request ..................................................................... 7-3
7.3.2 Mobile Originated Location Request ....................................................................... 7-5
7.3.3 Network Induced Location Request ........................................................................ 7-7

Chapter 1 MGW Registration Procedures

1-1
1.1 MGW Registration Procedure
When a media gateway (MGW) is in service for the first time or restarted, it must be
registered with the corresponding MSC Server. After successful registration, the
MGW can report its currently available physical terminals immediately, or the MSC
Server can obtain the information of the available physical terminals on the MGW
using the audit command.
See Figure 1-1 for the MGW registration procedure.
MGW MSC Server
ServiceChange
ServiceChange_Reply
MGW MSC Server
ServiceChange
ServiceChange_Reply

Figure 1-1 MGW registration procedure
1) When an MGW is in service for the first time or restarted, it sends the
ServiceChange message to the MSC Server to which it belongs to request
registration. This message contains such descriptors as Method (Restart", for
example), ServiceChangeAddress (address message) and Reason. This
message corresponds to the ROOT terminal (that is, the whole MGW).
2) The MSC Server authenticates the MGW and returns the ServiceChange_Reply
message (containing ServiceChangeAddress) to accept registration. If the MSC
Server rejects the registration due to inconsistent version or MGW out of control,
it sends the message ServiceChange_Reply (containing Reason) to the MGW.
1.2 MGW Deregistration Procedure
Before an MGW exits, it must be deregistered with the corresponding MSC Server.
After successful deregistration, the MGW is out of service. To activate it, register it
again.
The MGW deregistration procedure uses the same messages as MGW registration
procedure, but uses different descriptors, as shown in Figure 1-1.
1) When an MGW exits, it sends the ServiceChange message to the MSC Server
to which it belongs to request deregistration. This message contains such
descriptors as Method (Forced", for example) and Reason (for example, 905

1-2
"Termination taken out of service"). This message corresponds to the ROOT
terminal (that is, the whole MGW).
2) The MSC Server returns the ServiceChange_Reply message to accept
deregistration.
Chapter 2 Mobility Management

2-1
2.1 Overview
To support the mobility of Mobile Stations/User Equipments (MS/UE), the network
shall provide related management functions (mobility management).
The Mobility Management (MM) aims to locate the MS/UE and keep the connection
between MS/UE and the network in the desirable status.
The action that MS/UE changes its connection with the current cell/network is known
as roaming.
The MM involves location management and handover management, depending on
the current status of the roaming MS/UE.
2.2 Location Management
It is very important to locate an MS/UE when it is in the idle status. Since knowing the
current location of the MS/UE is the precondition that the network can set up the
connection with it quickly when it is called.
To realize location management, network will keep tracing MS/UE's current location
and store the location information. The location information is stored in HLR, VLR and
MS/UE (in SIM/USIM card). The location management procedure is used to ensure
the consistency of the location information in these three entities.
Among the three entities, HLR serves to store the MS/UE subscription data and
location information (that is, the MSC/VLR No.). VLR serves to store the subscriber
related information, including the MS/UE subscription data, location information and
subscriber status information downloaded from HLR. MSC processes the MS/UE
location registration procedure and exchanges data with VLR. The MS/UE stores the
information of the Location Area (LA) where it stays.
The location management protocol is observed between HLR and MSC/VLR, and
between MSC/VLR and MS/UE. The Mobile Application Part (MAP) of SS7 is adopted
between HLR and MSC/VLR, while Radio Interface Layer 3 protocol of MM (RIL3-MM)
is adopted between MSC/VLR and the MS/UE.
The MM includes some basic procedures, such as:
Authentication;

2-2
Acquiring International Mobile Subscriber Identity (IMSI) from Previous VLR
(PVLR);
Acquiring authentication set from HLR;
Location cancellation;
Inserting subscriber data;
Implicit IMSI detach;
Purging MS/UE.
By combining some basic procedures mentioned above according to the triggering
conditions, the major MM procedure, location update, can be realized.

Note:
The following section describes the location update procedures of the Global System for Mobile
communications (GSM), which are similar to that of the Universal Mobile Telecommunication System
(UMTS).

2.2.1 Basic Procedures
The location management includes some basic procedures, such as:
Authentication;
Acquiring IMSI from PVLR;
Location cancellation;
Inserting subscriber data;
Implicit IMSI detach;
Explicit IMSI detach;
Purging MS.
I. Authentication
On receipt of the location update request from MS, if authentication is needed but
there is no available authentication set, MSC/VLR will request for the authentication
set from HLR, and initiate the authentication procedure.
The authentication procedure is shown in Figure 2-1.

2-3
HLR
D
SEND AUTHENTICATE
SEND AUTHENTICATE ACK
Authentication procedure
MSC/
VLR
MS

Figure 2-1 Authentication procedure

Note:
For detailed description of the authentication procedure, see Section 3.1 Authentication in this manual.

II. Acquiring IMSI from PVLR
If the subscriber requests location update with Temporary Mobile Subscriber Identifier
(TMSI), the MSC/VLR finds that the TMSI is unknown, and the MS has never
registered in current VLR, the VLR will get the PVLR address according to the old
TMSI and Location Area Identity (LAI), and initiates the procedure to acquire IMSI
and authentication set from PVLR.
Figure 2-2 shows the procedure of acquiring IMSI from PVLR.
VLR PVLR
G
SEND IDENTIFICATION
SEND IDENTIFICATION ACK

Figure 2-2 Acquiring IMSI
III. Location Cancellation
On receipt of the location update request from MSC/VLR, if the HLR finds that the
subscriber has moved to an area controlled by a different MSC/VLR, it will initiate
location cancellation procedure to remove the subscriber information from PVLR.
The location cancellation procedure is shown in Figure 2-3.

2-4
HLR PVLR
D
CANCEL LOCATION
CANCEL LOCATION ACK

Figure 2-3 Location cancellation procedure
IV. HLR Inserting Subscriber Data to VLR
After receiving the location update request from MSC/VLR, if the HLR finds that the
subscriber roamed-to MSC/VLR number is changed, it will initiate the location
cancellation procedure to delete the subscriber information in PVLR. Afterwards, HLR
provides the needed subscriber information to the new VLR.
Figure 2-4 shows the procedure of inserting the subscriber data to VLR by HLR.
HLR VLR
INSERT SUBSCRIBER DATA
INSERT SUBSCRIBER DATA ACK
D

Figure 2-4 HLR inserts the subscriber data to VLR
V. Purging MS
The procedure is initiated by VLR to delete the subscriber data from the database.
This procedure is induced when the MS stays inactive within a long time (can be set,
usually 24 hours), or when the system administrator deletes the subscriber record.
The procedure is shown in Figure 2-5.
VLR HLR
D
MAP_PURGE_MS
MAP_PURGE_MS_ack

Figure 2-5 Purging MS

2-5
VI. Implicit IMSI Detach
Once the implicit IMSI detach timer times out, VLR will set the subscriber status
automatically to "detached". The implicit IMSI detach timer records the period within
which the MS is not active (no location update or calling). When the recorded time
reaches the preset "detach" value, VLR will set the subscriber status to "detached".
Whether VLR will initiate the implicit IMSI detach is also related to the periodic
location update time, which is set in Base Station Controller/Radio Network Controller
(BSC/RNC). If the implicit detach time is set longer than the periodic location update
time, and the subscriber has initiated the periodic location update within the set time,
the implicit detach will not be triggered. In this case, the IMSI detach will be triggered
only when the subscriber moves into a no-signal area and does not make the periodic
location update within the implicit detach time.
VII. Explicit IMSI Detach
The MS will initiate the IMSI detach procedure when it is being powered off. VLR will
then mark the IMSI as detached to indicate that the MS is inactive.
Figure 2-6 shows the explicit detach procedure.
MS
BSS
VLR MSC
A
B
Um
1.IMSIdetach
2.Detack IMSI
3. Purging command (to
release resources)
4. Purging completed
L3 message
MS
BSS
VLR MSC
A
B
Um
1.IMSIdetach
2.Detack IMSI
release resources)
L3 message

Figure 2-6 Explicit IMSI detach procedure
1) MS sends the "IMSI Detach" message which requires no response, and
abandons the radio connection.
2) VLR receives the message and set the MS status to "IMSI detached".
3) MSC releases the related resources and the IMSI detach is completed.
2.2.2 Major Procedures
The major procedure of location management is the location update. There are
different kinds of location updates, including normal location update, periodic location
update, IMSI attach and combined Routing Area/Location Area (RA/LA) update.

2-6
I. Normal Location Update
If an MS receives, when being powered on or is moving, a Location Area Identity (LAI)
different from the one stored in itself, the MS will send the location update request to
the network to update the LAI.
According to whether or not the new LAI shares the same MSC/VLR with the old LAI
and whether or not IMSI is involved, the location update is classified into the following
three kinds:
The location update within the same MSC/VLR area (only VLR is involved)
MS BSS MSC VLR
LOCATION_UPDATING_REQUEST
MAP_UPDATE_LOCATION_AREA
MAP_AUTHENTICATE
MAP_AUTHENTICATE ack
MAP_SET_CIPHERING_MODE
MAP_UPDATE_LOCATION_AREA
ack
LOCATION_UPDATING_ACCEPT
MAP_FORW._NEW_TMSI ack
A B

Figure 2-7 Location update within the same MSC/VLR area (only VLR is involved)
1) MS sends to MSC the "Location updating request" message, which includes the
TMSI/IMSI and LAI of the MS and indicates that it is a normal location update.
2) MSC sends the "Update location area" message to VLR.
3) VLR initiates the authentication and encryption procedures. These procedures
are optional.
4) VLR updates the LA information of the MS, stores the new LAI and sends to
MSC the "Update location area ack" message.
5) MSC sends to the MS the "Location updating accept" message, which contains
the TMSI.
6) MSC releases the channel resources and the location update is completed.

Note:
The italicized operations are optional.

The inter MSC/VLR location update (the subscriber data cannot be obtained
from PVLR)

2-7
The MS moves from LAI-1 in MSC-A to LAI-2 in MSC-B. The MS will use the IMSI to
initiate the location update if it enters a new VLR, registers for the first time, or the
related network data are lost.
MS BSS MSC-B HLR
A D
LOCATION_UPDATING
_REQUEST
MAP_UPDATE_
LOCATION_AREA
MAP_UPDATE_LOCATION
MAP_CANCEL_
LOCATION
LOCATION_UPDATING
_ACCEPT
VLR-B
PVLR
B
D G
MAP_CANCEL_
LOCATION ack
MAP_UPDATE_
LOCATION_AREA ack
MAP_INSERT_SUBSCR._DATA ackc

Figure 2-8 Inter MSC/VLR location update (IMSI updating)
1) MS moves to the LA (LAI-2) in MSC-B, monitors the new LA information on the
Broadcast Control Channel (BCCH), and finds that it is different from the LA
(LAI-1) information in the SIM card.
2) MS sends to MSC-B the "Location updating request" message, which includes
the IMSI.
3) VLR-B sends the message "Update location" on D interface.
4) HLR sends to PVLR the "Cancel location" message. After receiving this
message, PVLR deletes all the information of this MS and sends to HLR the
"Cancel location ack" message.
5) HLR inserts the subscriber data in VLR-B, which registers the subscription
information related to this MS, including IMSI and LAI.
6) HLR sends back to MSC-B the "Update location ack" message, which includes
the HLR No.
7) MSC-B sends to MS the "Location updating accept" message to inform it to
modify the LAI in SIM card.
8) SIM card sends the location update acknowledgement.
Location update results:

2-8
1) The LAI in SIM card is changed to LAI-2.
2) The current location information of this MS is registered in HLR, including
MSC-B/VLR-B No.
3) The subscriber data, location information and status information are stored in
VLR-B.
4) The data of this subscriber in PVLR is deleted completely.
Inter MSC/VLR location update (VLR, HLR and TMSI are involved)
The MS moves from LAI-1 in MSC-A to LAI-2 in MSC-B (IMSI can be used to obtain
subscriber data from PVLR).

MS BSS MSC HLR
A D
LOCATION_UPDATING
_REQUEST
MAP_UPDATE_
LOCATION_AREA
ack
MAP_UPDATE_LOCATION
MAP_CANCEL_
LOCATION
LOCATION_UPDATING
_ACCEPT
VLR
PVLR
B
D G
MAP_CANCEL_
LOCATION ack
MAP_UPDATE_
LOCATION_AREA ack
MAP_INSERT_SUBSCR._DATA ack

Figure 2-9 Inter MSC/VLR location update (TMSI updating)
1) When the MS enters a new LA (VLR-B), it conducts location update with the
TMSI assigned by the PVLR. In this case, VLR-B must get the IMSI of the MS
from the PVLR in order to get the HLR address of this MS. Therefore, VLR-B,
PVLR and HLR will be involved in this location update.
2) VLR-B must get the IMSI from the PVLR. Except from that, this procedure is the
same as the one described above.
II. Periodic Location Update
When the MS suddenly enters a no-signal area, or is suddenly powered down, the
MS will detach from the network before it can send the "RIL3-MM IMSI detach"
message. In this case, it is impossible for VLR to mark the IMSI as detached. If this
MS is called, the circuit resources and radio resources will be wasted.

2-9
The solution to this problem is the periodic location update. The MS is required to
update its location periodically (for example, once every 30 minutes) regardless of
whether or not it has entered a new LA. The VLR will set the IMSI as detached if the
MS does not update its location when the time is due. The period can be manually set
from 6 minutes to 24 hours, or as infinite (no periodic location update).
In MSOFTX3000, the IMSI detach time is set in VLR. When the detach time is due,
the MS will be regarded as having been shut down, and VLR will mark it as detached.
The time for the periodic location update is set in BSC/RNC. The IMSI detach time set
in VLR and the periodic location update time set in BSC/RNC are determined based
on the network planning.
The setting of the period for periodic location update should also take into
consideration the elements such as network quality, signaling link occupancy, and so
on. If the period is too short, much of the signaling link resources and radio resources
will be occupied by periodic location update. The overall connected ratio will therefore
be affected. If the period is too long, the radio resources and circuits may also be
wasted. Therefore, the period of the periodic location update is the balanced result of
Quality of Service (QoS) and network resource.
Through the periodic location update, the waste of circuit/radio resources due to the
data inconsistency after the active/standby switchover of the HLR/VLR database can
also be avoided.
The procedure of periodic location update is the same as that of the normal location
update.
III. IMSI Attach
The Mobile Terminated Call (MTC) will be impossible when the MS is powered down.
However, the circuit between the calling party and the destination MSC will still be set
up and the called MS will be paged if the MS is not marked as detached. The
circuit/radio resources are wasted without making any profit for the operator.
The IMSI attach/detach procedure is designed to solve the problem. In VLR, there is
an attach/detach flag for IMSI. When the MS is available, the flag is set as "IMSI
attached". Otherwise, it is set as "IMSI detached".
When the MS is powered down normally, the MS will send the "RIL3-MM IMSI
detach" message to MSC, which will mark the MS as "IMSI detached".
When the MS enters the active status again, and if it is in a new LA, the normal
location update procedure will be performed. If it is still in the old LA, the IMSI attach
procedure as shown in Figure 2-10 will be initiated (this procedure is only applicable
to the situation that the MS was marked as "IMSI detached").

2-10
UE
RNS
VLR MSC
RANAP
Iu
MAP
B
Uu
L3 1.Location update request
(IMSI attach)
4. Location update
accept (access
acknowledgment)
2. Access IMSI
(attach IMSI)
3.IMSI access conf irm
LAIn-LAlo (which means no
location update.
Otherwise, update location message
will be sent.
release resources)
UE
RNS
VLR MSC
RANAP
Iu
MAP
B
Uu
L3 1.Location update request
(IMSI attach)
4. Location update
accept (access
acknowledgment)
2. Access IMSI
(attach IMSI)
3.IMSI access conf irm
LAIn-LAlo (which means no
location update.
Otherwise, update location message
will be sent.
release resources)

Figure 2-10 IMSI attach procedure
1) MS/UE sends the "Location updating request" message, which indicates that the
location update type is the IMSI attach.
2) The following procedures are the same as the location update within the same
MSC/VLR area
IV. Combined RA/LA Update
1) Related concepts
LA: An area in which the MS/UE may roam without updating the location registers in
GSM/WCDMA network. A LA consists of one or more cells. RA: In GPRS network,
every LA is divided into several RAs. Each RA consists of several cells.
GPRS attach: A procedure that GPRS subscribers attach to the GPRS network and
the subscriber information is stored in Serving GPRS Support Node (SGSN).
Combined RA/LA location update with IMSI attach: The GPRS subscribers transmit
the subscriber information through the Gs interface (between SGSN and MSC) to
MSC/VLR through the GPRS network equipment during the combined RA/LA location
update, so as to realize the attach to the GSM network.
LA Update followed by RA update: The GPRS subscribers transmit the LA update
information through Gs interface to MSC/VLR through SGSN during the combined
RA/LA location update, so as to complete the LA update procedure.
2) Procedures
If the network is configured with Gs interface, and the MS supports both Circuit
Switched (CS) and Packet Switched (PC) services.
The combined RA/LA update procedure will be performed in the following cases:
The MS enters a new RA;
The GRPS attached MS initiates the IMSI attach;
The MS initiates GPRS attach and IMSI attach concurrently.
The SGSN-VLR connection will be set up. Each will keep the Integrated Services
Digital Network (ISDN) number of the other. In SGSN, a mapping table between

2-11
Routing Area Identity (RAI) and VLR should be created, so that SGSN can find the
corresponding VLR when correlation is needed. The combined RA/LA update fulfills
the RA and LA updates by using only one radio interface. It saves much radio
interface resource.
The normal procedure in combined RA/LA update is shown in Figure 2-11. The dotted
lines represent optional procedures.
1.Routing Area Update Request
2.Location Update Request
3. Update Location
4.Insert Subscriber Data
5.Insert Subscriber Data Ack
6.Update Location Ack
7.Location Update Accept
8.Routing Area Update Accept
9.Routeing Area Update Complete
10.TMSI Reallocation Complete
MSC/VLR SGSN MS HLR

Figure 2-11 Normal procedure of combined RA/LA update
1) The MS sends the RA update request to SGSN to initiate the combined RA/LA
update.
2) SGSN gets the location update type from the received message. If the location
update type is the "Combined RA/LA location update with IMSI attach", or the
"LA update followed by RA update", SGSN will get the VLR No. from the
RAI-VLR mapping table and send the location update request to VLR. SGSN
performs the RA update procedure at the same time.
3) VLR determines whether or not to send the location update request to HLR
based on the location update type (contained in the message it receives) and the
MS information stored in itself. If yes, VLR sends the location update request to
HLR. VLR stores or updates the SGSN No. at the same time.
4) Procedures 3, 4, 5 and 6 are the same as those in the none-GPRS location
update. See the inter MSC/VLR location update procedure.
5) VLR returns the "Location update accept" message to SGSN after the location
update is completed. If the TMSI needs to be re-allocated, VLR will send the
allocated TMSI to SGSN in the "Location update accept" message.

2-12
6) On receipt of the "Location update accept" message, if the RA update is also
successful, SGSN will send to the MS the "RA update accept" message.
7) The MS returns to SGSN the "RA update complete" message after receiving the
"RA update accept" message.
8) If the TMSI is re-allocated by the VLR during the combined RA/LA update,
SGSN will return to VLR the "TMSI reallocation complete" message.
2.3 Handover
2.3.1 Overview
During the service access or an ongoing session, the MS/UE may move from one cell
to another. In such case, the change of the serving cell becomes a very important
function of mobile communication system. The handover function is therefore
provided, which determines directly the spectrum utilization and QoS.
The basic parameters in the handover operation include the handover decision (when
to perform handover) and Service Area Identity (SAI) selection. To ensure that the
current conversation will not be interrupted, the handover is conducted when the
MS/UE moves out of the current cell. To ensure reliable service quality, the handover
is conducted when the MS/UE changes serving cell to avoid strong interference in the
current cell, or when the "preferred cell" is congested.
Different handover decision methods are adopted for different handover purposes. A
handover for the purpose of no conversation interruption is determined on the basis
of uplink/downlink transmission quality (such as transmission Bit Error Rate,
attenuation and edge transmission delay). To get such values, MS/UE and the Base
Transceiver Station (BTS)/NodeB will regularly measure the uplink/downlink
transmission quality and receiving level. The MS/UE will send the recorded result to
the BTS/NodeB twice a second. In the handover due to cell congestion, the decision
is made on the basis of the current load of each BTS, which is available at only MSC
and RNC. In this kind of handover, a certain number of MS/UEs (unspecified) will be
handed over to the neighbor cell with relatively less traffic. Therefore, such handover
is determined also based on other decision methods and corresponding
measurement results.
2.3.2 Classification
There are many handover causes. According to the mobile communication system
that the MS/UE accesses after the handover, the handover has the following kinds:
1) Intra-system handover: Intra-UMTS handover, that is, the handover between
Radio Network Systems (RNS) within an UMTS. Intra-GSM handover is referred
to as the handover between Base Station Subsystems (BSS) within a GSM.

2-13
2) Inter-system handover: The handover when a UMTS subscriber moves between
3G and 2G networks. To be specific, this kind of handover includes the
UMTS-GSM handover and the GSM-UMTS handover. The precondition for the
inter-system handover is that the UMTS RNC ID and the GSM cell ID are
mutually recognizable in the two systems. At the same time, the two systems
shall support the conversion of the service quality parameters between them
(that is, the conversion between 2G channel type and 3G QoS). The terminal's
support (such as dual-mode MS/UE) is also needed.
In terms of the equipment that may be involved in the handover, there are the
following kinds of handovers:
1) Intra-RNS handover: This procedure does no involve the CN, and is transparent
to the upper-level CN. The handover between RNCs requires the support of lur
interface.
2) Intra-MSC handover: The handover between RNCs/BSCs (including RNC-RNC,
BSC-BSC and RNC-BSC) within an MSC. This kind of handover needs the
support of MSC.
3) Inter-MSC handover: The handover between RNCs/BSCs that belong to different
MSCs. This kind of handover involves two or three MSCs. This kind of handover
can be sub-divided into three kinds:
Basic handover: The MS/UE is handed over from a controlling MSC (MSC-A) to
another MSC (MSC-B).
Subsequent handover back to MSC-A: The MS/UE is handed back from MSC-B
to MSC-A after the basic handover.
Subsequent handover to third-party MSC: The MS/UE is handed over from
MSC-B to a third MSC (MSC-B') after the basic handover.
Whatever the handover type is, the principles behind are the same, as shown in
Figure 2-12.

2-14
Original network Handover point New network
Handover request
Establish new path
Path established
Assign and activate
new channel
Instruct MS/UE to start handover
Handover command
UE requests to access
UE accesses new path
Release original path

Figure 2-12 Handover principles
The handover point may differ in different handover types. In intra-RNS handover, the
handover point is a RNC. In intra-MSC handover, the handover point is MSC. In
inter-MSC handover, there are two handover points: MSC-A and MSC-B.
2.3.3 Intra-UMTS Handover
As mentioned above, the intra-UMTS handover is the handover between RNSs within
the UMTS (from one 3G service area to another 3G service area).
According to the position of the target 3G SAI, the intra-UMTS handover is divided
into intra-MSC handover and inter-MSC handover. The later can be sub-divided into
basic handover, subsequent handover back to MSC-A and subsequent handover to
third-party MSC.
I. Intra-MSC Handover
In most cases, the UMTS UE moves from one 3G service area to another during a
session. If the Serving RNC (SRNC) of this UE finds that more reliable service is
available in the new service area, it will decide to initiate the handover and change
the SRNC of this UE.
Figure 2-13 shows the intra-MSC handover procedure.

2-15
UE UE
RNS-A
3G_MSC-A RNS-B
Iu-Relocation-Required
Iu-Relocation-Request
Iu-Relocation-Request-Ack
Iu-Relocation-Command
RRC-HO-Command
Iu-Relocation-Detect
RRC-HO-Complete
Iu-Relocation-Complete
Iu- Release-Command
Iu- Release-Complete
Detection of UE in
target RNS

Figure 2-13 Intra-MSC handover procedure
1) The access network RNS-A of the UE makes the decision to initiate the
handover procedure. It sends to MSC (MSC-A) the handover request
(Iu-Relocation-Required). Included in the handover request is the address
information of the expected access network RNS-B, termed as Target RNS
(TRNS).
2) On receipt of the request, MSC-A checks in the corresponding table. If the TRNS
is found to be its subordinate RNS, MSC-A will generate the corresponding
handover request message (Iu-Relocation-Request) and send it to RNS-B.
3) On receipt of the message from MSC, RNS-B assigns the necessary resource
for the UE to access according to the corresponding requirement (included in the
cells of the message), and performs QoS configuration. The related resources
will be assigned at the same time at the MSC-A.
4) After assigning the related resources, RNS-B sends to MSC-A the
"Iu-Relocation-Request-Ack" message, indicating that the resources assignment
is completed and the RNS is ready for the UE to access.
5) On receipt of the acknowledgement from RNS-B, MSC-A sends the
"Iu-Relocation-Command" message to RNS-A. RNS-A in turn sends it in the
message "RRC-HO-Command" to the UE, asking it to access the new service
area.
6) RNS-B sends to MSC-A the message "Iu-Relocation-Detect" when it detects that
the UE is accessing. After the UE access, RNS-B sends to MSC-A the message
"Iu-Relocation-Complete", indicating that it is able to provide service for the UE.
7) After receiving the handover complete message from RNS-B, MSC-A sends the
message "Iu-Release-Command" to RNS-A, asking it to release the related
resources. After releasing the resource, RNS-A returns the message
"Iu-Release-Complete" to MSC-A, ending the handover procedure.


2-16
Note:
The RNS-B after the handover becomes the SRNS of that UE. If handover occurs again, the RNS-B will
play the role of RNS-A then.

II. Inter-MSC Handover
Basic handover
When an UE in an ongoing session moves to another 3G service area of a different
MSC, the handover will involve two MSCs. The new cell provides radio resources for
the UE, just as what happens in the intra-MSC handover. However, in the inter-MSC
handover, an inter-MSC circuit must be set up between the two MSCs for the call.
Figure 2-14 shows the basic inter-MSC handover procedure.
RNS-A
3G_MSC-A
3G_MSC-B
MAP-Prep-Handover req.
MAP-Allocate-Handover-Number req.
IU-RELOC-REQUEST
IU-RELOC-REQUIRED
RNS-B
VLR-B
IU-RELOC-REQUEST-ACK
MAP-Send-Handover-Report req.
MAP-Prep-Handover resp.
IAM MAP-Send-Handover-Report resp. (1)
ACM
IU-RELOC-COMMAND
IU-RELOC-DETECT
IU-RELOC-COMPLETE
MAP-Process-Access-Sig req.
MAP-Send-End-Signal req. IU-REL-CMD/COM
ANSWER
RELEASE
End of call
MAP-Send-End-Signal resp.
NOTE 1: Can be sent at any time after the reception of IAM

Figure 2-14 Inter-MSC handover procedure
1) The access network RNS-A of the UE makes the decision to initiate the
handover procedure. It sends to its MSC (MSC-A) the handover request
information of the expected access network RNS-B, termed as Target RNS
(TRNS).
is found to be connected to another MSC (MSC-B), MSC-A will pack the
handover request into a certain cell, put the cell into the corresponding MAP
message (MAP-Prepare-Handover req), and send it to MSC-B through MAP
signaling.
3) On receipt of the MAP-Prepare-Handover Req, MSC-B generates the
corresponding message "Iu-Relocation-Request" and sends it to the TRNS.

2-17
4) Upon the reception of the handover request, RNS-B assigns the corresponding
resources for the UE. MSC-B also assigns the related resources at the same
time. After assigning the resources, RNS-B sends to MSC-B the message
"Iu-Relocation-Request-Ack". During or after assigning the resources, MSC-B
will also send to its VLR (VLR-B) the message "MAP-Allocate-Handover-Number
req.", asking for the handover number. VLR-B will send the assigned handover
number to MSC-B in the message "MAP-Send-Handover-Report req.".
5) After receiving the acknowledgement from RNS-B and the handover number,
MSC-B sends to MSC-A the message "MAP-Prep-Handover-resp", indicating
that it is ready for the handover. Included in this message is the handover
number, with which MSC-A can find the route to MSC-B.
6) MSC-A then sends to MSC-B the "Initial Address Message (IAM)" to request for
the corresponding trunk circuit. After occupying the trunk circuit, MSC-B returns
to MSC-A the "Address Complete Message (ACM)". The occupation of the trunk
circuit is then completed.
7) After the setup of the circuit, MSC-A generates the message
"Iu-Reloc-Command" according to the information extracted from the message
"MAP-Prep-Handover-resp", and sends it to RNS-A, asking the UE to start the
handover.
8) The UE then starts to access RNS-B. Upon the detection of UE access, RNS-B
sends to MSC-B the message "Iu-Reloc-Detect". MSC-B packs the message into
the MAP signaling "MAP-Process-Access-Sig req" and sends to MSC-A. MSC-B
then starts waiting for the handover complete message. On receipt of the
corresponding MAP signaling, MSC-A also starts waiting for the handover
complete message.
9) After the UE accesses RNS-B, RNS-B sends the handover complete message to
MSC-B, which will pack the message into the MAP signaling
"MAP-Send-End-Signal req" and send it to MSC-A. The MSC-B then starts some
post-handover operations, such as sending the message "Answer" to the
inter-MSC circuit.
10) After receiving the message from MSC-B, MSC-A concludes that the handover is
completed. It starts releasing the resources occupied by that UE at RNS-A by
sending to the RNS-A the message "IU-REL-CMD". RNS-A returns the message
"IU-REL-COMP" to MSC-A after the releasing. The inter-MSC circuit will be
maintained until the session is over. Then, MSC-A will release the circuit, use the
MAP signaling "MAP-Send-End-Signal resp" to notify MSC-B of the release, and
stop the exchange of MAP signaling with MSC-B.


2-18
Note:
Anytime after receiving the IAM message from MSC-A, MSC-B can use the MAP signaling
"MAP-Send-Handover-Report resp" to notify VLR-B to release the handover number, so that it can be
reused next time.

Subsequent handover
In this handover, the UE is handed over to another cell (in a different MSC) after the
basic handover. The other MSC could be either of the following:
1) The MSC-A in the basic handover.
2) A new neighbor MSC other than the MSC-A. It is termed here as MSC-BP or
MSC-B'.
The first kind of handover is known as the subsequent handover back to MSC-A. The
later is known as the subsequent handover to third-party MSC.
Subsequent handover back to MSC-A
As mentioned above, in this handover, the UE is handed over from MSC-B to MSC-A
after the basic handover.
Figure 2-15 shows the procedure of the subsequent handover back to MSC-A.
RNS-B
3G_MSC-A 3G_MSC-B
MAP-Prep-Sub-Handover req.
Iu-RELOCATION-
REQUIRED
RNS-A
VLR-B
Iu-RELOCATION-
COMMAND
MAP-Prep-Sub-Handover resp.
Iu-RELOCATION-
REQUEST-ACK
Iu-RELOCATION-
DETECT
Iu-RELOCATION-
COMPLETE
Iu-RELEASE-
CMD/COM
Iu-RELOCATION-
REQUEST
Release

Figure 2-15 Procedure of subsequent handover back to MSC-A

Note:
RNS-A refers the SRNS of the UE, while RNS-B is the target RNS of the handover.


2-19
1) After the basic handover, the SRNS of the UE (RNS-A) makes the decision to
initiate the handover again. It sends to MSC-B the handover request
"Iu-Relocation-Required". Included in the request is the address information of
the expected access network RNS-B (TRNS).
2) On receipt of the request, MSC-B checks in the corresponding table. If the TRNS
is found to be connected to another MSC, MSC-B will generate the
corresponding MAP message "MAP-Prepare-Handover req", and send it to
MSC-A through MAP signaling.
3) On receipt of the handover request, the MSC-A finds that the TRNS is under its
own control. MSC-A then generates and sends the handover request
"Iu-Relocation-Request" to RNS-B.
4) On receipt of the message from MSC, RNS-B assigns the necessary resources
for the UE to access according to the requirement (included in the cells of the
message), and performs QoS configuration. The related resources will be
assigned at the same time at the MSC-A. After assigning the resources, RNS-B
sends to MSC-A the message "Iu-Relocation-Request-Ack".
5) The MSC-A then generates and sends the MAP message
"MAP-Prep-Sub-Handover resp" to MSC-B through the MAP signaling, indicating
that it is ready for the subsequent handover.
6) MSC-B then sends to RNS-A the handover command "Iu-Relocation-Command",
asking the UE to start handover.
7) The UE then starts to access RNS-B. Upon the detection of the access, RNS-B
sends to MSC-A the message "Iu-Relocation-Detect". After the access is
completed, RNS-B sends to MSC-A the message "Iu-Relocation-Complete",
indicating that the access is complete.
8) MSC-A sends to MSC-B the message "MAP-Send-End-Signal resp", indicating
that the subsequent handover is completed. The MAP signaling exchange
between the two is then stopped. Afterward, MSC-A will release the trunk circuit
set up with MSC-B during the basic handover.
9) After receiving the "MAP-Send-End-Signal resp", MSC-B concludes that the
handover is completed. It asks RNS-A to release the resources occupied by that
UE.

Note:

Subsequent handover to third-party MSC
In this handover, the UE is handed over from MSC-B to MSC-B' after the basic
handover.

2-20
Figure 2-16 shows the procedure of the subsequent handover to third-party MSC.
Iu-RELOCATION-
REQUIRED
VLR-B
Iu-RELOCATION-CMD
MAP-Prep-Sub-Handover req.
Iu-RELOCATION-
DETECT
Iu-RELOCATION-
COMPLETE
RNS-B
3G_MSC-B' VLR-B'
MAP-Prepare-Handover req.
MAP-Prepare-Handover resp.
MAP-Allocate-Handover-Number req.
MAP-Send-Handover-Report req.
IAM
MAP-Send-Handover-Rep. resp. (1)
MAP-Prep-Sub-Ho resp.
MAP-Process-Access-Signalling req.
MAP-Send-End-Signal req.
ACM
Answer
Release
Release
(end of call)
3G_MSC-A 3G_MSC-B
RNS-B'
Iu-RELOCATION-
REQUEST
Iu-RELOCATION-
REQUEST-ACK
Iu-RELEASE-CMD/COM

Figure 2-16 Procedure of subsequent handover to third-party MSC
1) After the basic handover, the SRNS of the UE (RNS-A) makes the decision to
initiate the handover again. It sends to MSC-B the handover request
"Iu-Relocation-Required". Included in the request is the address information of
the expected access network RNS-B' (TRNS).
2) On receipt of the request, MSC-B checks in the corresponding table. If the TRNS
is found to be connected to another MSC, MSC-B will generate the
corresponding MAP message "MAP-Prep-Sub-Handover req.", and send it to
MSC-A through MAP signaling.
3) On receipt of the handover request, the MSC-A finds that the TRNS is in another
MSC (MSC-B'). MSC-A then generates the message "MAP-Prep-Handover req"
and sends it to MSC-B' through the MAP signaling.

2-21
4) On receipt of the message, MSC-B' generates the message
"Iu-Relocation-Request" and sends it to the TRNS.
5) Upon the reception of the handover request, RNS-B' assigns the corresponding
resources for the UE. MSC-B' also assigns the related resources at the same
time. After assigning the resources, RNS-B' sends to MSC-B' the message
"IU-Relocation-Request-Ack". During or after assigning the resources, MSC-B'
will also send to its VLR (VLR-B') the message
"MAP-Allocate-Handover-Number req", asking for the handover number. VLR-B'
will send the assigned handover number to MSC-B' in the message
"MAP-Send-Handover-Report req".
6) After receiving the acknowledgement (from RNS-B') and the handover number,
MSC-B' sends to MSC-A the message "MAP-Prep-Handover-resp", indicating
number, with which MSC-A can find the route to MSC-B'.
7) MSC-A then sends to MSC-B' the Initial Address Message (IAM) to request for
the corresponding trunk circuit. After occupying the trunk circuit, MSC-B' returns
to MSC-A the Address Complete Message (ACM). MSC-A then generates the
message "MAP-Prep-Sub-Handover resp" and sends it to MSC-B through the
MAP signaling, indicating that it is ready for the subsequent handover.
8) MSB-B then sends to RNS-A the handover command "Iu-Relocation-Command",
asking the UE to start handover.
9) The UE starts to access RNS-B'. Upon the detection of the access, RNS-B'
sends to MSC-B' the message "Iu-Relocation-Detect". MSC-B' sends the
message to MSC-A in the signaling "MAP-Process-Access-Signal req" and waits
for the handover complete message. After the UE accesses RNS-B', RNS-B'
sends the handover complete message "Iu-Relocation-Complete" to MSC-B',
which will send the message to MSC-A in the MAP signaling
"MAP-Send-End-Signal req". The MSC-B' then starts some post-handover
operations, such as sending the message "Answer" to the inter-MSC circuit.
10) On receipt of the "MAP-Send-End-Signal req", MSC-A sends to MSC-B the
message "MAP-Send-End-Signal resp", notifying that the handover has
succeeded, and the resources occupied by that UE can be released. MSC-A
also stops the exchange of MAP signaling with MSC-B, and releases the trunk
circuit set up with MSC-B during the basic handover. MSC-B initiates the Iu
release procedure to release the related resources.
The inter-MSC circuit will be maintained until the session is over. Then, MSC-A will
release the circuit, use the MAP signaling "MAP-Send-End-Signal resp" to notify
MSC-B' to release the related radio resources, and stop the exchange of MAP
signaling with MSC-B'.


2-22
Note:
The MSC-B' after the handover plays the role of MSC-B during the basic inter-MSC handover. If
handover occurs again, the target MSC will play the role of MSC-B' then.

2.3.4 Inter-System Handover
The inter-system handover is the handover of MS/UE from UMTS to GSM, or from
GSM to UMTS. To support the inter-system handover, the GSM system should be
able to recognize the RNC ID of UMTS, and UMTS should be able to recognize the
cell ID of GSM. At the same time, the systems should support the conversion of
service quality parameters (2G channel type and 3G QoS) between them.
In terms of the system, the inter-system handover is divided into two types: The
handover from UMTS to GSM and the handover from GSM to UMTS.
However, there will be many more types if the handover modes are considered:
Intra-MSC handover from UMTS to GSM
Intra-MSC handover from GSM to UMTS
Inter-MSC handover from UMTS to GSM
Inter-MSC handover from GSM to UMTS
Subsequent handover back to MSC-A UMTS cell after UMTS-GSM handover
Subsequent handover back to MSC-A GSM cell after GSM-UMTS handover
Subsequent handover to MSC-B' UMTS cell after UMTS-GSM handover
Subsequent handover to MSC-B' GSM cell after GSM-UMTS handover
There are two key factors in inter-system handover:
First, The RNS of UMTS should be able to recognize the GSM cells, and the BSS of
GSM should be able to recognize the UMTS cells. In addition, the MSC should
support both UMTS and GSM cells, and be capable of generating messages that
meet UMTS and GSM protocols respectively.
Second, The MSC should support the conversion of UMTS and GSM service quality
parameters. To be more specific, the MSC should be able to convert and map
between the GSM Channel Type and the UMTS QoS, so that subscribers can obtain
services of the same quality after the handover.
The inter-system handover involves primarily the MSC adaptation for UMTS and
GSM access networks. Therefore, four basic inter-system handover procedures are
described below. Other procedures are the combination and extension of these four
basic procedures.

2-23
I. Intra-MSC Handover from UMTS to GSM
Figure 2-17 shows the procedure of intra-MSC handover from UMTS to GSM.
UE MS
RNS-A 3G_MSC-A BSS-B
Iu-Relocation-Required
A-Handover-Request
A-Handover-Request-Ack
Iu-Relocation-Command
RRC-HO-Command
RI-HO-Access
A-Handover-Detect
RI-HO-Complete
A-Handover-Complete
Iu-Release-Command
Iu-Release-Complete

Figure 2-17 Procedure of intra-MSC handover from UMTS to GSM
1) The access network RNS-A of the MS/UE makes the decision to initiate the
information of the expected access network BSS-B, usually the Cell Global ID
(CGI) of the target cell.
2) On receipt of the request, MSC-A checks in the corresponding table. If the target
cell is found to be in the BSS under its own control, MSC-A will generate the
corresponding GSM handover request message "A-Handover-Request" and
send it to BSS-B. While structuring this message, MSC performs the protocol
interworking between UMTS and GSM systems.
3) On receipt of the message from MSC, BSS-B assigns the necessary resources
for the MS/UE to access according to the corresponding requirement (included in
the cells of the message), and performs channel selection to ensure the service
quality.
4) After assigning the related resources, BSS-B sends to MSC-A the
"A-Handover-Request-Ack" message, indicating that the resources assignment
is completed and the BSS is ready for the MS/UE to access.
5) On receipt of the acknowledgement, MSC-A generates the UMTS handover
command "Iu-Relocation-Command" and sends the message to RNS-A. RNS-A
in turn sends it in the message "RRC-HO-Command" to the MS/UE, asking it to
access the new service area. In this process, some information (recognizable to
RNS-A) used to instruct the MS/UE to conduct radio access will be carried in the
GSM message "A-Handover-Request-Ack". Such information is transparent to
MSC. MSC just needs to put the information into UMTS handover message and
sends it to RNS-A.

2-24
6) BSS-B sends to MSC-A the message "A-Handover-Detect" when it detects that
the MS/UE is accessing. After the access, which will be reported by the MS/UE,
BSS-B sends to MSC-A the message "A-Handover-Complete", indicating that it
is able to provide service for the MS/UE.
message "Iu-Release-Command" to RNS-A, asking it to release the related
resources. After releasing the resource, RNS-A returns the message
"Iu-Release-Complete" to MSC-A, ending the handover procedure.

Note:
The BSS-B after the handover becomes the Serving BSS (SBSS) of that MS. If handover occurs again,
the BSS-B will play the role of BSS-A then.

II. Intra-MSC Handover from GSM to UMTS
Figure 2-18 shows the procedure of intra-MSC handover from GSM to UMTS.
UE
BSS-A 3G_MSC-A
RNS-B
A-Handover-Required
Iu-Relocation-Request
Iu-Relocation-Request-Ack
A-Handover-Command
RI-HO-Command
Iu-Relocation-Detect
RRC-HO-Complete
Iu-Relocation-Complete
A-Clear-Command
A-Clear-Complete
MS

Figure 2-18 Procedure of intra-MSC handover from GSM to UMTS
1) The access network BSS-A of the MS/UE makes the decision to initiate the
(A-Handover-Required). Included in the handover request is the address
information of the expected access network RNS-B, usually the ID of the target
RNC.
cell is found to be in the RNS under its own control, MSC-A will generate the
corresponding UMTS handover request message "Iu-Relocation-Request" and
send it to RNS-B. While structuring this message, MSC performs the protocol
interworking between UMTS and GSM systems.

2-25
3) On receipt of the message from MSC, RNS-B assigns the necessary resources
for the MS/UE to access according to the requirement (included in the cells of
the message), and performs QoS configuration.
4) After assigning the related resources, RNS-B sends to MSC-A the
"Iu-Relocation-Request-Ack" message, indicating that the resources assignment
is completed and the RNS is ready for the MS/UE to access.
5) On receipt of the UMTS acknowledgement, MSC-A generates the GSM
handover command "A-Handover-Command" and sends the message to BSS-A.
BSS-A in turn sends it in the message "RI-HO-Command" to the MS/UE, asking
it to access the new service area. In this process, some information
(recognizable to BSS-A) used to instruct the MS/UE to conduct radio access will
be carried in the UMTS message "Iu-Relocation-Request-Ack". Such information
is transparent to MSC. MSC just needs to put the information into GSM
handover message and sends it to BSS-A.
6) RNS-B sends to MSC-A the message "Iu-Relocation-Detect" when it detects that
the MS/UE is accessing. After the access, RNS-B sends to MSC-A the message
"Iu-Relocation-Complete", indicating that it is able to provide service for the
MS/UE.
message "A-Clear-Command" to BSS-A, asking it to release the related
resources. After releasing the resources, BSS-A returns the message
"A-Clear-Command" to MSC-A, ending the handover procedure.

Note:
The RNS-B after the handover becomes the SRNS of that MS/UE. If handover occurs again, it will play
the role of RNS-A then.

III. Inter-MSC Handover from UMTS to GSM
Figure 2-19 shows the procedure of inter-MSC handover from UMTS to GSM.

2-26
3G_MSC-A MSC-B
MAP-Prep-Handover req. MAP-Allocate-Handover-Number req.
A-HO-REQUEST
Iu-RELOCATION-
REQUIRED
BSS-B/MS/UE
VLR-B
A-HO-REQUEST-ACK
MAP-Send-Handover-Report req. MAP-Prep-Handover resp.
IAM
MAP-Send-Handover-Report resp. (1)
ACM
Iu-RELOCATION-
COMMAND
A-HO-DETECT
A-HO-COMPLETE
MAP-Send-End-Signal req. Iu-RELEASE-
CMD/COM
ANSWER
RELEASE
End of call
UE/MS/RNS-A

Figure 2-19 Procedure of inter-MSC handover from UMTS to GSM
1) The access network RNS-A of the MS/UE makes the decision to initiate the
"Iu-Relocation-Required". Included in the handover request is the address
information of the expected access network BSS-B, usually the CGI of the target
cell.
BSS is found to be connected to another MSC (MSC-B), MSC-A will pack the
handover request into a cell, put the cell into the corresponding MAP message
"MAP-Prepare-Handover req", and send it to MSC-B through the MAP signaling.
In this procedure, MSC-A will map the UMTS message into GSM message while
packing the handover request, so as to make the message become recognizable
to GSM system.
3) On receipt of the message, MSC-B generates the message
"A-Handover-Request" and sends it to the target BSS.
4) BSS then assigns the corresponding resources for the MS/UE. MSC-B also
assigns the related resources at the same time. After assigning the resources,
BSS sends to MSC-B the message "A-Handover-Request-Ack". During or after
assigning the resources, MSC-B will also send to its VLR (VLR-B) the message
"MAP-Allocate-Handover-Number req", asking for the handover number. VLR-B
will then send the assigned handover number to MSC-B in the message
"MAP-Send-Handover-Report req".
5) After receiving the acknowledgement (from RNS-B) and the handover number,
number, with which MSC-A can find the route to MSC-B. Besides, the message

2-27
"A-Handover-Request-Ack" is packed into this message in the Packet Data Unit
(PDU) format.
6) MSC-A then sends to MSC-B the IAM to request for the corresponding trunk
circuit. After occupying the trunk circuit, MSC-B returns to MSC-A the ACM. The
occupation of the trunk circuit is then completed.
7) After the setup of inter-MSC circuit, MSC-A generates the message
"Iu-Reloc-Command" according to the information extracted from the message
"MAP-Prep-Handover-resp" and sends it to RNS-A, asking the MS/UE to start
the handover. This procedure also requires the protocol interworking between
UMTS and GSM systems.
8) The MS/UE then starts to access the BSS. Upon the detection of the access,
BSS sends to MSC-B the message "A-Handover-Detect". MSC-B packs the
message into the MAP signaling "MAP-Process-Access-Sig req" and sends it to
MSC-A. MSC-B then waits for the handover complete message. On receipt of
the corresponding MAP signaling, MSC-A also waits for the handover complete
message.
9) After the MS/UE accesses BSS, BSS sends the handover complete message to
MSC-B, which will pack the message into the MAP signaling
"MAP-Send-End-Signal req" and send it to MSC-A. The MSC-B then starts some
post-handover operations, such as sending the message "Answer" to the
inter-MSC circuit.
complete. It starts releasing the resources occupied by that MS/UE at RNS-A by
sending to the RNS-A the message "IU-REL-CMD". RNS-A returns the message
"IU-REL-COMP" to MSC-A after the releasing. The inter-MSC circuit will be
maintained until the session is over. Then, MSC-A will release the circuit, use the
MAP signaling "MAP-Send-End-Signal resp" to notify MSC-B of the release, and
stop the exchange of MAP signaling with MSC-B.

Note:
1) Anytime after receiving the IAM message from MSC-A, MSC-B can use the MAP signaling
reused next time.
2) The BSS after the handover becomes the SBSS of that MS/UE. If handover occurs again, the BSS
will play the role of BSS-A.

IV. Inter-MSC Handover from GSM to UMTS
Figure 2-20 shows the procedure of inter-MSC handover from GSM to UMTS.

2-28
UE/MS/BSS-A
MSC-A
3G_MSC-B
MAP-Prep-Handover req. MAP-Allocate-Handover-Number req.
Iu-RELOCATION-REQUEST
A-HO-REQUIRED
RNS-B/UE/MS
VLR-B
Iu-RELOCATION-REQUEST-ACK
MAP-Send-Handover-Report req. MAP-Prep-Handover resp.
IAM
MAP-Send-Handover-Report resp. (1)
ACM
A-HO-COMMAND
Iu-RELOCATION-DETECT
Iu-RELOCATION-COMPLETE
MAP-Send-End-Signal req. A-CLR-CMD/COM
ANSWER
RELEASE
End of call

Figure 2-20 Procedure of inter-MSC handover from GSM to UMTS
1) The access network BSS-A of the MS/UE makes the decision to initiate the
(A-Handover-Required). Included in the handover request is the address
information of the expected access network RNS-B, usually the ID of the target
RNC.
(RNS-B) is found to be connected to another MSC (MSC-B), MSC-A will pack
the handover request into a certain cell, put the cell into the corresponding MAP
message "MAP-Prepare-Handover req", and send it to MSC-B through the MAP
signaling.
3) On receipt of the message, MSC-B extracts the GSM message
"A-Handover-Request". Based on this message, MSC generates the
corresponding UMTS handover request "Iu-Relocation-Request" and sends it to
the RNS-B. In this procedure, MSC-B will map the GSM message into the UMTS
message.
4) Upon the reception of the handover request, RNS-B assigns the corresponding
resources for the MS/UE. MSC-B also assigns the related resources at the same
time. After assigning the resources, RNS-B sends to MSC-B the message
"Iu-Relocation-Request-Ack". During or after assigning the resources, MSC-B
will also send to its VLR (VLR-B) the message "MAP-Allocate-Handover-Number
req", asking for the handover number. VLR-B will then send the assigned
handover number to MSC-B in the message "MAP-Send-Handover-Report req".
5) After receiving the acknowledgement (from RNS-B) and the handover number,

2-29
number, with which MSC-A can find the route to MSC-B. Besides, MSC-B will
put the message "A-Handover-Request-Ack" (packed in the PDU format) into
this message.
6) MSC-A then sends to MSC-B the IAM to request for the corresponding trunk
circuit. After occupying the trunk circuit, MSC-B returns to MSC-A the ACM. The
occupation of the trunk circuit is then completed.
7) After the setup of inter-MSC circuit, MSC-A generates the message
"A-Handover-Command" according to the GSM message
"A-Handover-Request-Ack" extracted from the message
"MAP-Prep-Handover-resp". MSC-A sends the message to BSS-A, asking the
MS/UE to start the handover.
8) The MS/UE then starts to access RNS-B. Upon the detection of the access,
RNS-B sends to MSC-B the message "Iu-Relocation-Detect". MSC-B converts
the message into the corresponding GSM message "A-Handover-Detect", packs
the message into the MAP signaling "MAP-Process-Access-Sig req" and sends it
to MSC-A. MSC-B then waits for the handover complete message. On receipt of
the corresponding MAP signaling, MSC-A will also waits for the handover
complete message.
9) After the MS/UE accesses RNS-B, RNS-B sends the handover complete
message to MSC-B. MSC-B converts the message into the corresponding GSM
message "A-Handover_Complete", packs the message into the MAP signaling
"MAP-Send-End-Signal req" and sends it to MSC-A. The MSC-B then starts
some post-handover operations, such as sending the message "Answer" to the
inter-MSC circuit.
completed. It starts releasing the resources occupied by that MS/UE at BSS-A
by sending to the BSS-A the message "A-CLR-CMD". BSS-A returns the
message "A-CLR-COMP" to MSC-A after the releasing. The inter-MSC circuit
will be maintained until the session is over. Then, MSC-A will release the circuit,
use the MAP signaling "MAP-Send-End-Signal resp" to notify MSC-B of the
release, and stop the exchange of MAP signaling with MSC-B.

Note:
1). Anytime after receiving the IAM message from MSC-A, MSC-B can use the MAP signaling
reused next time.
2). The RNS-B after the handover becomes the SRNS of that MS/UE. If handover occurs again, the
RNS-B will play the role of RNS-A then.


2-30
2.4 Roaming Restriction
MSOFTX3000 supports Zone Code based roaming restriction, LA-based roaming
restriction and VLR list based roaming restriction.
Zone Code based roaming restriction
Zone Code is a kind of subscription data in HLR, which can be used to restrict the
roaming area of the subscriber. MSC can define the LA contained in each Zone Code.
In this way, the areas in which mobile subscriber are allowed to roam can be set
flexibly.
LA-based roaming restriction
MSC can provide roaming restriction function based on LA without the cooperation of
HLR. For this type of roaming restriction, subscriber group and location group No.
(one location group No. may correspond to one or more LAs) should be defined first.
Then the correspondence between the subscriber group and location group No.
should be defined, so that the area in which roaming is forbidden for this subscriber
group can be established.
VLR list based roaming restriction
VLR list is a kind of subscription data in HLR, which defines the VLR areas in which
roaming is allowed. MSC enables this roaming restriction with the cooperation of
HLR.
Chapter 3 Security Management

3-1
3.1 Overview
The security management of MSOFTX3000 at MSC side includes authentication,
encryption, integrity protection, and TMSI reallocation.
3.2 Authentication
MSOFTX3000 authentication function includes GSM authentication and UMTS
authentication.
3.2.1 GSM Authentication
I. Definition
The GSM authentication function is to define whether a user has rights to access
Public Land Mobile Network (PLMN). It is done by comparing authentication response
of MS and the set of three Authentication Vectors (AV) provided by Authentication
Center (AuC). Through authentication, the network operator can prevent illegal
subscriber (using duplicated International Mobile Subscriber Identity (IMSI) and
Individual Subscriber Authentication Key (Ki)) from using any form of service.
II. Authentication Parameters
Messages stored in
Subscriber Identity Module (SIM)
Solidified data: IMSI, Ki, A3 (authentication algorithm), and A8 (ciphering algorithm).
These data will not be changed.
Temporary network data: Temporary Mobile Subscriber Identity (TMSI), Location Area
Identity (LAI), Ciphering Key (Kc), Ciphering Key Sequence Number (CKSN), and
prohibited PLMN.
Service-related data
AuC
RANDom number (RAND) generator
Ki
Ciphering algorithms, which should be consistent with those applied in SIM.

3-2
III. Principle
The basic function of AuC is to generate the AV trio: RAND, Signed Response to
RAND (SRES), and Kc. Among which
RAND is generated by RAND generator.
SRES is resulted from RAND and Ki in A3 algorithm.
Kc is resulted from RAND and Ki in A8 algorithm.
After generated, the AV trio is stored in HLR. When authentication is required,
MSC/VLR of the MS service region will load at least one AV trio from HLR.
Refer to Figure 3-1 for the principle of authentication.
Card manufacture center
IMSI, KI
A3, A8 (A5)
SIM card
IMSI, KI
A3, A8 (A5)
A3
SRES KI (IMSI) + RAND
KI (IMSI) + RAND
A8
KC
M + KC
A5
KC (M)
(MS/BSS)
KC (M) + KC M
A5
(MS/BSS)
KI (M)
KI (N)
IMS (m)
IMS (n)
RAND
generator
A8 A3
KI (IMSI)
IMSI buffer
RAND
RAND
RAND
RAND
KC
1
2
5
KC
KC
KC
SRES
SRES
SRES
SRES
Tem-
porary
data
AUC

HLR/AUC
HLR
Authentication
request
RAND
KC
SRES
RAND
A8 A3
SRES
Verify if matching
CKSN
KC
BSS
KI (IMSI)
VLR SIM
RAND 16byte
KI 16byte
kc 8byte
SERS 4byte
CKSN The last three bits of 1 byte

Figure 3-1 GSM authentication principle
IV. Authentication Procedure
It is up to the network operators to decide whether to implement authentication.
Generally, authentication is implemented upon every call connection establishment,
location update, supplementary service activation without call connection, and Short
Message Switching (SMS). Figure 3-2 shows GSM authentication procedure.

3-3
MS BSS MSC VLR HLR/AC
Um
BSSAP
A
MAP
B
MAP
D
related service request
call establishment/location update
/supplementary service (SMS)
MAP message
(service request)
(CKSN, IMSI/TMSI)
AV retrieval request
(IMSI)
authentication request
(CKSN, R)
respond with "SERS"
after a consistency check
(authentication successful
(authorized user)/
authentication unsuccessful
(unauthorized user))
request accepted/
request rejected
such as "service accepted",
"location update accepted",
or "authentication rejected"
return "accepted" message
return several AVs
(IMSI, KC, S, R)
authentication request authentication request
authentication response authentication response
authentication response

Figure 3-2 GSM authentication procedure
1) MS indicates the stored CKSN in the first COMPLETE LAYER3 INFO (call
establishment/location update/supplementary service (SMS)).
2) When MSC receives COMPLETE LAYER3 INFO message, it decides whether
authentication is needed based on data configuration. If authentication is not
needed, the procedure is skipped. Otherwise, check if CKSN is consistent with
the value stored in MS in the access process. If not consistent, MSC sends
PROCESS ACCESS REQUEST to VLR to initiate an authentication procedure;
otherwise, the procedure is skipped
3) VLR check if there is an AV trio, (or reuse of the AV trio is permitted). If no AV is
found, VLR will retrieve one from HLR. HLR receives the AV retrieval request, it
requests AuC (usually integrated in HLR) to generate five AVs. Then, HLR
returns the five AVs to VLR in AUTHENTICATION RESPONSE message. If there
is still any AV trio in VLR, HLR will not participate in the procedure, and VLR will
initiate AUTHENTICATION REQUEST to MS directly.
4) VLR sends AUTHENTICATION REQUEST message to invoke authentication
procedure. The request includes a RAND and a CKSN.
5) Upon receiving the request message, MS generates an SRES resulting from Ki
and the RAND in A3 authentication algorithm, and a Kc resulting from Ki and the
RAND in A8 ciphering algorithm. MS sends SRES and Kc back to VLR in
AUTHENTICATION RESPONSE message.
6) When generating authentication vector set at network side, the same algorithm is
adopted. An SRES is generated resulting from Ki and RAND in A3 algorithm.
Then VLR compares the value of two SRESs. If they are the same, authentication

3-4
succeeds, allowing MS to access the network. If they are different, authentication
fails, MS access to the network is denied.
3.2.2 UMTS Authentication
I. Definition
In addition to the network authenticating user function in GSM authentication, UMTS
authentication includes user authenticating network function and integrity protection
function. Furthermore, UMTS authentication increase the length of ciphering key,
applying a more robust ciphering algorithm and integrity algorithm.
The UMTS authentication vector set is a Quintet: RAND, XRES, Ciphering Key (CK),
Integrity Key (IK), and AuthenTication TokeN (AUTN). These five elements comprises
the UMTS authentication vector.
UMTS AV quintet:
RAND
RAND is a random number provided to UE. UE then uses it to generated
authentication response RES or RES+RES_EXT, and security keys as IK and CK. The
length of RAND is 16 octets.
AUTN
AUTN is used by UE to authenticate the network. It is 16 octets in length.
XRES
XRES refers to expected UE authentication response. By comparing XRES and RES
(or RES+RES_EXT) generated by UE, the network can decide if authentication
succeeds. It is 4-16 octets in length.
CK
CK refers to UMTS ciphering key. It is 16 octets in length.
IK
IK is UMTS integrity protection key, which is 16 octets in length.
Other parameters related to UMTS authentication:
AUTS
AUTS is to provide necessary information to invoke re-authentication procedure.
When MS returns authentication failure, and failure cause is synchronization failure,
this parameter is added. It is 14 octets in length.
SQN
SeQuence Number (SQN) is needed to calculate MAC and AUTN value. Timer SQN
MS
and SQN
HE
are stored in USIM and Home Environment (HE). The timers are used for
network authentication. SQN
MS
is an independent timer to every user, as it indicates
the maximum values that USIM receives.

3-5
AMF
Authentication and key Management Field (AMF) is indicates and generates the
algorithm and ciphering key for a certain AV. It indicates the maximum differential
value between SQN
MS
and SQN. If SQN-SQN
MS
<AMF, and SQN>SQN
MS
, SQN is
valid. USIM restricts CK with a validity period. The period can be adjusted in AMF.
AK
AK encrypts SQN in AUTN. It is obtained from RAND and K (CK constantly shared
between AuC and HE). Alternatively, set AK=0.
MAC
Message Authentication Code (MAC) is obtained from the calculation of SQN, RAND,
AMF and K. The received end shall re-calculate MAC to compare with the received
one, judging if MAC failed.
II. Principle
When user accesses the network, if authentication is required, VLR/SGSN will select
an unused AV quintet, and initiate authentication request to UE. The request message
includes RAND, AUTN and CKSN of selected authentication vector. USIM checks if
AUTN is accepted. If not, then authentication fails; otherwise, work out RES, CK and
IK, and return RES to VLR/SGSN. VLR/SGSN compares the RES returned from UE
with XRES in authentication vector set. IF they are the same, authentication succeeds;
otherwise, authentication fails. On successful authentication, the CK and IK that UE
calculated and stored in USIM, and the CK and IK that VLR/SGSN stored in
authentication vector set can be used for subsequent encryption procedures. If
authentication fails, UE will delete the stored CK and IK.
III. Authentication Procedure
Figure 3-3 shows UMTS authentication procedure.

3-6
UE RNS MSC/SGSN VLR
HLR/Auc
Uu
RANAP
Iu
MAP
B
MAP
D
related service request
(call establishment/location update/
supplementary service (SMS))
(CKSN, ATUN, RAND)
(return "accepted" message such as "service accepted",
"location update accepted" or "authentication rejected"
return several AVs
(RAND, AUTN,
CK, IK, XRES)
(RES (RES+RES_EXT) or authentication failure)
authentication success
authentication failure report
subsequent processing
(such as getting IMSI, another authentication)
MAP message
(service request)
AV retrieval request
(CKSN, IMSI/TMSI)
authentication response
respond with "XERS" after
a consistency check if RES
or RES+RES_EXT is returned

Figure 3-3 UMTS authentication procedure
UMTS authentication procedure is initiated and controlled by the network, yet UE can
deny network authentication challenge.
1) UE indicates the stored CKSN in the first COMPLETE LAYER3 INFO (call
establishment/location update/supplementary service (SMS))
2) MSC/SGSN receives COMPLETE LAYER3 INFO message, checks if CKSN
value (that UE used in previous implementation) is the valued stored in UE. If so,
authentication procedure is skipped; otherwise, MSC/SGSB will send request to
VLR for authentication parameters.
3) If there is no quintet available in VLR, VLR will initiate a request to HLR/AuC for
authentication vector set. HLR receives the authentication set retrieval request, it
requests AuC (usually integrated in HLR) to generate five sets of authentication
vectors. Then, HLR returns the five sets to VLR in AUTHENTICATION
RESPONSE. If there is still any authentication vector quintet in VLR, HLR will not
participate in the procedure, and VLR will initiate AUTHENTICATION REQUEST
to MS directly.
4) MSC/SGSN sends UE an AUTHENTICATION REQUEST to invoke
authentication procedure. The request includes an RAND, an AUTN and a CKSN.
5) UE responses with an AUTHENTICATION RESPONSE message:
UE check AUTN. If the MAC is the same as the calculated one, UE will then
check if the range of SQN, which is calculated based on AUTN, is correct. If SQN
is correct, UE will make out RES (or RES+RES_EXT) based on RAND, and send
it to VLR in AUTHENTICATION RESPONSE message.
In UMTS authentication challenge, the newly generated CK and IK should
overwrite the original ones, and should be stored in USIM with CKSN.

3-7
6) The network receives AUTHENTICATION RESPONSE:
On receiving RES, the network compares RES (or RES+RES_EXT) with XRES.
If they are identical, the user is legal; otherwise, the user is illegal.
In case of authentication failure, if UE uses TMSI, the network can initiate
identification procedure; if UE uses IMSI, or the network decides not to initiate
identification procedure, it shall send AUTHENTICATION REJECT message to
UE.
7) UE authentication rejects with AUTHENTICATION FAILURE message:
UE check AUTN. If MAC failure occurs, which means the MAC of AUTN differs
from the calculated MAC, UE will send authentication failure message to end the
procedure. MSC shall initiate the authentication failure reporting procedure to
HLR, and identification procedure as well as authentication procedure. If
identification procedure is again initiated, the network will confirm the
corresponding relationship between the received IMSI and the send TMSI. If
relationship is incorrect, retrieve AV quintet again and initiate the authentication
procedure. In the second authentication request, if it is MAC failure again, the MS
will regard the present service area as a prohibited one until the system
information is updated.
If no MAC failure occurs, MS will check if the range of SQN, which is calculated
based on AUTN, is correct. If SQN exceeds the range, MS will send
synchronization failure message to end the procedure. The message contains
rejection cause parameter Synch failure and re-synchronization flag parameter
AUTS, the latter of which is calculated based on AUTN and RAND. The network
shall re-synchronize with the parameter AUTS. MSC/VLR shall delete all unused
AVs, retrieve AV from HLR, and re-initiate an authentication procedure.
3.2.3 Dual-Mode MS Authentication
I. Definition
A dual-mode MS refers to the mobile phone that can be used in two different mobile
communication systems. The basic architecture is that under the control of central
control unit, it adopts the same man-machine interface, and the same antenna, but
two separate systems. When the MS is powered on, the central control unit detects
between the two systems, and selects a path. It can select either mobile
communication system as specific environment or operation requires. Here, the
dual-mode MS is compatible with GSM (2G) and UMTS (3G). R99+ME is a dual-mode
MS that can access BSS as well as UTRAN.
Related concepts
Authentication and key agreement (AKA) of UMTS refers to the authentication
and encryption procedures of sending authentication vector quintet. AKA of GSM
refers to the authentication and encryption procedures of sending authentication
vector trio.

3-8
R98-: Refers to the network node or ME designed on R97 or R98.
R99+: Refers to the network node or ME designed on R99 or later.
UMTS users includes: R99+ME with USIM and R98-ME with USIM.
GSM users includes: R99+ME with SIM and R98-ME with SIM.
II. Authentication Procedure
When the dual-mode MS opens an account, it can only be UMTS or GSM. The GSM
user requires authentication vector trio in GSM authentication; while UMTS user
requires the quintet in UMTS authentication. When the dual-mode MS roams between
GSM and UMTS network, it will apply authentication vector trio or quintet depending
on the network it situates in. In addition, it also requires conversion between trio and
quintet.
Opening an account of UMTS user
Figure 3-4 illustrates the AKA of UMTS user.
Release 99+ VLR/SGSN Release 98-
VLR/SGSN
Release 99+
HLR/AuC
USIM
RAND
AUTN
RES
CK
IK
CK, IK
Kc
UTRAN
R99+ ME
RAND
AUTN
RES
[Kc]
CK, IK
Kc
GSM BSS
CK, IK--> Kc
RES--> SRES
CK, IK--> Kc
R98- ME
CK, IK--> Kc
CK, IK--> Kc
RES--> SRES
RAND
SRES
[Kc]
Kc
RAND
SRES
[Kc]
Kc
R99+ ME
or
R98- ME *
CK, IK--> Kc
RES-->SRES
Quintets Triplets
CK, IK--> Kc
RES -->SRES
UMTS security context GSM security context
CK, IK--> Kc

Figure 3-4 Opening an account of UMTS user
When R99+UE UMTS user with USIM accesses UTRAN, AKA of UMTS is adopted
When R99+UE UMTS user with USIM accesses GSM BSS, and VLR is R99+, AKA of
UMTS is adopted Kc is calculated based on IK and CK.

3-9
When R99+UE UMTS user with USIM accesses GSM BSS, and VLR is R98-, AKA of
GSM is adopted. Kc of ME is calculated based on IK and CK. R98- mode VLR/SGSN
uses stored Kc and RES.
Opening an account of GSM user
Figure 3-5 illustrates the AKA of GSM user.
GSM security context
Release 99+
VLR/SGSN
Release 98-
VLR/SGSN
Release 98- or Release 99+
HLR/AuC
SIM
RAND
SRES
CK
IK
Kc
UTRAN
R99+ UE
RAND
SRES
[Kc]
Kc
GSM BSS
Kc --> CK, IK
R98- UE
Kc --> CK, IK
RAND
SRES
[Kc]
Kc
RAND
SRES
[Kc]
Kc
R99+ UE
or
R98- UE
Triplets Triplets

Figure 3-5 Opening an account of GSM user
When R99+UE GSM user with SIM accesses UTRAN, AKA of GSM is adopted. IK and
CK used in access network and MS is calculated based on Kc of GSM.
When R99+UE GSM user with SIM accesses GSM BSS, and VLR/SGSN is R99+,
AKA of GSM is adopted.
When R99+UE GSM user with SIM accesses GSM BSS, and VLR/SGSN is R98-,
AKA of GSM is adopted.
3.3 Encryption
The purpose of encryption is to ensure transmission security of user data in the air. All
encryption and decryption implementations are done in the air.
GSM encryption: The encryption and decryption of user information is an exclusive
or operation on 114-bit wireless pulse code and 114-bit encryption serial code. It
applies A5 encryption algorithm. The algorithm calculates based on Kc of the MS and
the frame number of the pulse string. Kc is calculated based on RAND (in
authentication request message), and Ki in A8 algorithm.

3-10
UMTS encryption: To initiate encryption in the network, include the encryption
algorithm and CK in the encryption command; RNC and UE negotiate an algorithm
and initiate the encryption procedure. Then, UE uses CK, which is calculated based on
RAND, for encryption and decryption; NODEB uses CK sent by MSC/VLR for the
same purpose.
The network sends encryption messages to wireless access network. In this
procedure, the core network and wireless access network negotiate an encryption
algorithm for MS, which is further applied in subsequent service transfer. When the MS
switches between GSM and UMTS, the algorithm will still be applied, and related
parameters will be sent to switched destination RNC. The encryption procedure is
UE/UTRAN CN
SECURITY MODE COMPLETE
or SECURITY MODE REJECT
SECURITY MODE COMMAND

Figure 3-6 Encryption and integrity protection procedure
3.4 Integrity Protection
The purpose of integrity protection is to ensure that no illegal modification is done on
signaling after it is sent, by verifying the validity of signaling data. The source of
signaling data is the sending party.
To initiate encryption in the network, include the integrity protection algorithm and IK in
the encryption command; RNC and UE negotiate an algorithm and initiate the integrity
protection procedure. Then, UE uses IK, which is calculated based on RAND, for
integrity protection processing; NODEB uses IK sent by MSC/VLR for the same
purpose.
Figure 3-6 illustrates the integrity protection procedure.
1) CN initiates SECURITY MODE COMMAND message, which invokes security
mode control procedure, and provides to UTRAN the available encryption
algorithm (if any) and integrity protection algorithm.
2) After receiving SECURITY MODE COMMAND message, UTRAN will select an
appropriate algorithm based on UR/UTRAN capabilities, trigger relevant wireless
interface procedures, and initiate encryption devices (if compatible) and integrity
protection.
3) When UTRAN wireless interface procedure successfully is completed, UTRAN
returns a SECURITY MODE COMPLETE message, containing the selected
integrity protection algorithm and encryption algorithm. The signaling data always
applies the latest received messages for encryption and integrity protection.

3-11
4) If UE or UTRAN does not support the specified algorithm for encryption or
integrity, it returns a SECURITY MODE REJECT message, and the reason value
is required encryption/integrity algorithm not supported. If the wireless interface
security control procedure fails, it returns a SECURITY MODE REJECT message,
and the reason value is wireless interface control procedure failure. When
encryption or integrity protection is activated, CN requires another algorithm,
which is not supported by UE or UTRAN, it returns a SECURITY MODE REJECT
message, and reason value is changed encryption algorithm and/or integrity
algorithm not supported.
3.5 TMSI Reallocation
TMSI refers to Temporary Mobile Subscriber Identifier, which is managed by
MSC/VLR. The purpose of TMSI reallocation is to ensure IMSI security when using
TMSI through wireless interface, preventing any unauthorized trace of user activities
through IMSI.
When a mobile subscriber comes to a certain MSC/VLR control area, MSC/VLR will
allocate a TMSI, which uniquely identifies the subscriber, according to specific TMSI
allocation principle. Then, the network identifies the subscriber by TMSI instead of
IMSI. All signaling data interaction will be based on TMSI, thus achieving the purpose
of security.
TMSI reallocation can be implemented in user location update, call establishment, and
in supplementary service application. When a new TMSI is allocated, the previous one
will be deleted.
The TMSI reallocation procedure implemented in location update is done together with
location update accept process. See Figure 3-7 for details.
MSC/VLR
Loc Update Accept (with TMSI)
MS/UE
TMSC Realloc complete

Figure 3-7 TMSI reallocation in location update
1) MSC/VLR invokes TMSI reallocation procedure. It generates a new TMSI, stores
the corresponding relationship between TMSI and IMSI, and send the new TMSI
and LAI to MS.
2) Upon receiving the newly-allocated TMSI, MS automatically delete the old one,
save the new one, and returns a response message to MSC/VLR. MSC/VLR
receives the response message, and deletes the original corresponding
relationship of TMSI and IMSI.

Chapter 4 Call Procedures

4-1
4.1 Mobile Subscriber Calling Mobile Subscriber
4.1.1 Call Model
The following procedures are based on calls between two local office users. See
Figure 4-1 for the networking.
UE-T
MGW
RNC-O RNC-T
UE-O
MSC
SERVER
/VLR

Figure 4-1 Call model (mobile subscriber calling mobile subscriber)
4.1.2 Diagram of Call Procedures
The procedures for a mobile subscriber calling another mobile subscriber are shown
in Figure 4-2.

Note:
MSC Server and VLR are combined, so interface B is an internal one and the messages at interface B
are internal messages.


4-2
UE-O MSC Server/VLR
RNS-O
HLR
CM_Service_Req(Initial UE)
MAP_SEND_AUTHENTICATION_INFO
MAP_SEND_AUTHENTICATION_INFO_ACK
AUTHENTICATION REQUEST
AUTHENTICATION RESPONSE
CM_SERVERICE_ACCEPT
SETUP
CALL PROCEEDING
SECURITY MODE COMMAND(OPTION)
SECURITY MODE COMPLETE(OPTION)
COMMON ID
MGW
BEARER ESTABLISHMENT
RAB ASSIGNMENT REQUEST
RADIO BEARER SETUP
RADIO BEARER SETUP COMPLETE
RAB ASSIGNMENT RESPONSE
PREP BEARER
PREP BEARER
Security
management
procedure
(optional)
User plane
bearer
establishment
procedure at
caller side


4-3
HLR MSC Server/VLR MGW UE-T RNS-T
MAP_SEND_ROUTING_INFORMATION
MAP_PROVIDE_ROAMING_NUMBER
MAP_PROVIDE_ROAMING_NUMBER_ACK
MAP_SEND_ROUTING_INFORMATION_ACK
PAGIN
G
PAGING RESPONSE
VLR
SETUP
CALL CONFIRMED
COMMON ID
Security
management
procedure
(optional)
RADIO BEARER SETUP
RADIO BEARER SETUP
COMPLETE
PREP BEARER
PREP BEARER
Procedure of
getting
roaming
number
User plane
bearer
establishment
procedure at
callee side


4-4
UE-O VMSC/GMSC RNS-O MGW
UE-T
CONNECT
CONNECT ACK
DISCONNECT
RELEASE
RELEASE COMPLETE
IU_RELEASE_COMMAND
IU_RELEASE_COMPLETE
SENDTONE
SENDTONE
STOP TONE
STOP TONE
CONNECT
BEARER RELEASE
DISCONNECT
RELEASE
RELEASE COMPLETE
RELEASE_TERM
RELEASE_TERM
IU_RELEASE_COMMAND
IU_RELEASE_COMPLETE
BEARER RELEASE
RELEASE_TERM
RELEASE_TERM
RNC-T
During the call
Caller release
procedure
Callee release
procedure
ALERTING

Figure 4-2 Procedures for mobile subscriber calling mobile subscriber
4.1.3 Calling Procedures (Early Assignment Procedures)
1) UE sends the CM SERVICE REQUEST message to the network. This message
contains such parameters as mobile identifications including temporary mobile
subscriber identifier (TMSI), international mobile subscriber identity (IMSI), and

4-5
international mobile equipment identity (IMEI), classmark2, ciphering key
sequence number (CKSN), and connection management (CM) service type
(including mobile originating call setup, emergency call setup, short message
service, supplementary services, and location service).
2) The network may initiate authentication and ciphering procedures, during which
initiation of the procedure of getting authentication set from HLR/AUC may be
required. If no security management procedures (that is, authentication,
ciphering, TMSI reallocation, or getting identifier) happen, ignore this step and
skip to step 3.
3) Upon receipt of the service acceptance message or ciphering complete message,
UE sends the SETUP message to the network. After receiving the SETUP
message, the core network (CN) returns the CALL PROCEEDING message to
the calling party.
4) The calling side starts the establishment of user plane bearer: MSC Server
sends the Prepare Bearer Req message to MGW. MGW allocates ATM
resources dynamically, and returns the Prepare Bearer Rsp message containing
TerminationId (T1). Then MSC Server invokes the RAB assignment procedure to
RNS-O. RNS-O establishes the ATM bearer resources at the access side
together with MGW through the BEARER ESTABLISHMENT procedure. This
procedure is parallel to that of step 5.
5) MSC Server queries the route information to HLR. HLR obtains the roaming
number from VLR. MSC Server triggers VLR to initiate the paging procedure
after getting the incoming call data from VLR.

Note:
1) The difference between early assignment and late assignment is the time when a Traffic Channel
(TCH) is allocated. For the called party, early assignment refers to assignment performed before
off-hook while late assignment refers to assignment performed after off-hook. For the calling party,
assignment is performed before ALERTING message in an early assignment procedure while
assignment is performed after ALERTING message in a late assignment procedure.
2) Early assignment shortens call connection delay and increases call completion rate. Late assignment
avoids TCH resources from being occupied during alerting and thus improves the utilization ratio of TCH
resources.

4.1.4 Called Procedures (Early Assignment Procedures)
1) The network receives the PAGING RESPONSE message from the called party.
If authentication is not performed, skip to Step 3.

4-6
2) CN initiates authentication, ciphering, and TMSI reallocation procedures during
which initiation of getting authentication set information from HLR/AUC is
required.
3) CN sends the SETUP message to the called UE.
4) Upon receipt of the CALL CONFIRMED message from the called UE, CN
initiates the procedure of establishing user plane bearer. This procedure is
similar to the procedure of establishing ATM bearer at the calling side.
5) The transport control plane and the user plane are established during the
assignment procedure, that is, Q.AAL2 establishment and IUUP initialization.
After RAN receives the ESTABLISH CONFIRM message pertaining to the user
plane, it originates the RAB ASSIGNMENT RESPONSE message.
6) Then CN awaits alerting from the called UE and sends the ALERTING message
to the calling party and the SEND TONE message to MGW for playing the ring
back tone.
7) CN awaits off-hook at the called UE, that is, the CONNECT message. CN sends
the CONNECT message to the calling party.
8) After receiving the CONNECT message, the calling party sends the STOP
TONE message to MGW for stopping the ring back tone and the CONNECT
ACK message to the network. The network forwards the CONNECT ACK
message to the called party.
9) The calling and called UEs enter the conversation status.
4.1.5 Disconnection Procedures
1) During the conversation, if the calling party releases the call, the calling UE
sends the DISCONNECT message to the network and the network notifies the
called party of the disconnection message.
2) The called party sends the RELEASE message to the network to release the
resources on the current transaction. The network sends the RELEASE
message to the calling party to release the resources on the current transaction.
Upon receipt of the RELEASE message, the calling party responds with the
RELEASE COMPLETE message.
3) The network actively sends the IU RELEASE COMMAND message to start the
release of the signaling plane.
4) The network sends to MGW the RELEASE TERMINATION message to release
the user plane resources.
4.2 Mobile Subscriber Calling PSTN Subscriber
4.2.1 Call Model
The following procedures are based on calls originated by a mobile subscriber to a
PSTN subscriber. See Figure 4-3 for the networking.

4-7
PSTN USER
MGW
RNC-O
UE-O
MSC
SERVER
/VLR
PSTN

Figure 4-3 Call model
4.2.2 Diagram of Call Procedures
The procedures for a mobile subscriber calling a PSTN subscriber are shown in
Figure 4-4.

4-8
UE-O MSC Server/VLR
RNS-O
HLR
CM_Service_Req(Initial UE)
MAP_SEND_AUTHENTICATION_INFO
MAP_SEND_AUTHENTICATION_INFO_ACK
CM_SERVERICE_ACCEPT
SETUP
CALL PROCEEDING
SECURITY MODE COMMAND(OPTION)
SECURITY MODE COMPLETE(OPTION)
COMMON ID
MGW
RADIO BEARER SETUP
PREP BEARER
PREP BEARER
Security
management
procedure
(optional)
User plane
bearer
establishment
procedure at
caller side
RESERVE CIRCUIT
RESERVE CIRCUIT


4-9
UE-O (G)MSC Server RNS-O PSTN MGW
IAI
ACM
ALERTING
SEND TONE
SEND TONE
ANC
CONNECT
STOP TONE
STOP TONE
CONNECT ACK
CLF
IU_RELEASE_COMMAND
IU_RELEASE_COMPLETE
BEARER RELEASE
DISCONNECT
RELEASE
RELEASE COMPLETE
RELEASE_TERM
RELEASE_TERM
RLG
Release
procedure
RELEASE_TERM
RELEASE_TERM
a

Figure 4-4 Procedures for mobile subscriber calling PSTN subscriber
4.2.3 Call Procedures
1) UE sends the CM SERVICE REQUEST message to the network. The CM
SERVICE REQUEST message contains such parameters as TMSI, IMSI, IMEI,
classmark2, CKSN, and CM service type (including mobile originating call setup,
emergency call setup, short message service, supplementary services, and
location service).
2) The network may initiate authentication and ciphering procedures, during which
initiation of the procedure of getting authentication set from HLR/AUC may be
required. If there is no security management procedure (that is, authentication,
ciphering, TMSI reallocation, and getting identifier), ignore this step and skip to
step 3.
3) Upon receipt of the service acceptance message or ciphering complete message,
UE sends the SETUP message to the network. After receiving the SETUP
message, CN returns the CALL PROCEEDING message to the calling party.

4-10
4) The calling side starts the establishment of user plane bearer: MSC Server
sends the Prepare Bearer Req message to MGW. MGW allocates ATM
TerminationId (T1). Then MSC Server invokes the RAB assignment procedure to
RNS-O. RNS-O establishes the ATM bearer resources at the access side
together with MGW through the BEARER ESTABLISHMENT procedure.
5) GMSC Server sends an initial address message with information (IAI) to PSTN.
6) After receiving the IAI, PSTN returns an address complete message (ACM).
After receiving the ACM, GMSC Server sends the SEND TONE message to
MGW for playing the ring back tone.
7) After the called party picks up the phone, the called UE sends an answer signal,
charge (ANC) to the network. GMSC Server sends the STOP TONE message to
MGW for stopping the ring back tone. After the calling party picks up the phone,
both parties talk with each other.
8) After the conversation, if the calling party hooks on first, the calling UE sends a
DISCONNECT message to GMSC Server. Then GMSC Server sends a clear
forward signal (CLF) message to notify PSTN to clear the connection. After
clearing the connection, PSTN returns a release guard signal (RLG) to GMSC
Server.
9) GMSC Server sends a RELEASE message to the calling party to release the
transaction resources. A RELEASE COMPLETE message is the response to the
RELEASE message.
10) The network sends to MGW the RELEASE TERMINATION message to release
the user plane resources.

4-11
4.3 PSTN Subscriber Calling Mobile Subscriber
UE(caller) VMSC Server RNS MGW
HLR PSTN
GMSC Server
ALERTING
CONNECT
CONNECT ACKNOWLEDGE
RLG
IU RELEASE COMPLETE
IAI(TUP)
MAP_SEND_ROUTING_INFORMATION
MAP_PROVIDE_ROAMING_NUMBER
MAP_PROVIDE_ROAMING_NUMBER_ACK
MAP_SEND_ROUTING_INFORMATION ACK
IAI(TUP)
PAGING
PAGE RESPONSE
TMSI REALLOCATION COMMAND
CALL CONFIRMED
SETUP
RADIO BEARER SETUP
ACM
ANC
CONNECT ACKNOWLEDGE
DISCONNECT
RELEASE
RELEASE COMPLETE
IU RELEASE COMMAND
CLF
PREPARE BEARER
PREPARE BEARER
BEAR ESTABLISHMENT
RESERVE CIRCUIT
RESERVE CIRCUIT
CALL
BEARER RELEASE
RELEASE_TERM
RELEASE_TERM
RELEASE_TERM
RELEASE_TERM
TMSI REALLOCATION COMPLETE

Figure 4-5 Procedures for PSTN subscriber calling mobile subscriber
1) PSTN sends an IAI to GMSC Server.

4-12
2) GMSC Server gets routing information from HLR. After getting the mobile station
roaming number (MSRN) of the called party, GMSC Server sends the IAI to
MSC Server. MSC Server then notifies VLR of the incoming call.
3) VLR fetches data about the incoming call and initiates a paging procedure. After
the network receives a paging response from the called UE, skip to Step 5 if
authentication, ciphering, or TMSI reallocation procedures do not happen.
4) The network initiates authentication, ciphering, and TMSI reallocation
procedures, during which initiation of getting authentication set information from
HLR/AUC may be required.
5) The network sends a SETUP message to the called UE.
6) Upon receipt of the CALL CONFIRMED message from the called UE, MSC
Server initiates a procedure of establishing user plane bearer: MSC Server
sends the Prepare Bearer REQ message to MGW. MGW allocates ATM
TerminationId. Then MSC Server invokes the RAB assignment procedure to
RNS. RNS establishes the ATM bearer resources at the access side together
with MGW through the BEARER ESTABLISHMENT procedure.
7) The transport control plane and the user plane are established during the
assignment procedure. After RAN receives an ESTABLISH CONFIRM message
regarding the user plane, it sends a RAB assignment response message.
8) At the same time, MSC Server establishes the calling user plane bearer. The
called UE hooks off. MSC Server receives an ALERTING message and then
sends an ACM to the calling party.
9) The network awaits off-hook of the called party, that is, the CONNECT message,
and sends a CONNECT message to the calling party. The calling party returns a
CONNECT ACK. The network sends a CONNECT ACK to the called party. Then
the calling and called parties enter the conversation status.
10) During the conversation, if the called party hooks on, the called UE sends a
DISCONNECT message to the network and the network notifies the calling party
of the disconnection message. After releasing the call, the calling UE sends a
RLG to the network. The network sends a RELEASE message to the called
party for the purpose of releasing the transaction resources. The network
actively sends an IU RELEASE COMMAND to release the signaling plane
resources and a RELEASE TERMINATION message to MGW to release the
user plane resources.
4.4 Pre-paging
Pre-paging is a network function. Before GMSC Server originates to VMSC Server a
call setup request, VMSC Server initiates a paging procedure to the called UE when
HLR asks VMSC Server for the roaming number. Then VMSC Server sends the
roaming number to HLR. In this way, a radio connection between VMSC Server and

4-13
UE has been established when VMSC Server receives the call setup request from
GMSC Server.
A pre-paging procedure initiated during getting the roaming number makes it possible
to know whether or not the called party can be paged before a roaming number is
allocated. These actions make contributions to saving network resources as they
avoid such a possible case that the called party cannot be connected when GMSC
Server accesses VMSC Server according to the roaming number. In addition, data
restoration happens (if needed) before pre-paging, for the purpose of increasing the
efficiency of incoming calls.
The pre-paging procedure is shown in Figure 4-6.
GMSC Server
HLR
paging
SRI(Prepage)
PAN(Prepage)
SRI_ACK
PAN_ACK
Paging
VMSC Server

Figure 4-6 Pre-paging procedure
1) It is assumed that GMSC Server supports pre-paging. GMSC Server originates a
send_routing_information (SRI) message to HLR. The SRI message contains a
Prepage flag field. After receiving the SRI message, HLR finds that the Prepage
flag is carried in the message. Then HLR performs bit set on the Prepage flag in
the provide_roaming_number (PRN) message according to the judgment
whether or not the entity itself supports pre-paging.
2) VMSC Server receives the PRN message. If the message contains the Prepage
flag, VMSC Server initiates a paging procedure. Upon receipt of the paging
response from UE, VMSC Server returns a PRN response message to HLR.
4.5 Call Forwarding Services
Call forwarding services make it possible to forward an incoming call to another
subscriber. After subscription, subscribers have to activate them before using them.
Call forwarding services are divided into the following classes:
CFU: Call forwarding unconditional
CFB: Call forwarding on mobile subscriber busy
CFNRy: Call forwarding on no reply
CFNRc: Call forwarding on mobile subscriber not reachable

4-14

Note:
The following call forwarding procedures are activated before MGW makes the selection. After the calls
are forwarded to different offices according to the actual situations, the user plane bearer is established.
Refer to sections 6.2.2 and 6.2.4 for the procedures for establishing user plane bearer for details.

4.5.1 CFU
After a subscriber activates CFU, the corresponding information is registered in HLR.
The forwarding procedure is as follows:
GMSC Server sends an INFO REQUEST to HLR to ask for routing information. If
HLR finds that the subscriber has registered the CFU service, it sends to GMSC
Server an INFO ACK message containing the forwarded-to number. GMSC Server
connects the call according to the forwarded-to number. If there is an information
element notification to calling party in the INFO ACK message, a Notification
message will be sent to the calling party. The call can be forwarded to a PSTN
subscriber or a mobile subscriber.
I. Forwarded to a PSTN Subscriber
MSa/TEa
GMSC
Server
HLRb
MSC
Server b
PSTN
Set-up
Info request
Info ack
Set-up
Notification
OR1:N
Set-up
OR1:Y
OR2:Y

OR1: Forwarding requested
OR2: Notification to calling subscriber required
Figure 4-7 CFU to PSTN
As shown in Figure 4-7, the related message will be routed to MSC Server b if
forwarding is not required.
If the call is set to be forwarded to a PSTN subscriber, GMSC Server will forward the
concerned message to PSTN.

4-15
II. Forwarded to a Mobile Subscriber
MSa/TEa
GMSC
Server
HLRb
MSC
Server b
HLRc
Set-up
Info request
Info ack
Set-up
Notification
OR1:N
Set-up
OR1:Y
OR2:Y
MSC
Server c
Information request
Information acknowledge

Figure 4-8 CFU to a mobile subscriber
As shown in Figure 4-8, if the call is set to be forwarded to a mobile subscriber,
GMSC Server sends an INFORMATION REQUEST message to HLRc where the
forwarded-to mobile subscriber is resident, for the purpose of asking for routing
information. HLRc returns the routing information to GMSC Server through an
INFORMATION ACKNOWLEDGE message. After receiving the routing information,
GMSC Server sends a SETUP message to MSC Server c that will be responsible for
continuing to page the called mobile subscriber.
4.5.2 CFB
CFB happens when the called party is busy or rejects the incoming call. When CFB is
activated, the forwarding party can still make calls.
It is divided into Network Determined User Busy (NDUB) and User Determined User
Busy (UDUB).
Forwarded to a PSTN subscriber: NDUB

4-16
MSa/TEa HLRb VLRb MSb
Set-up
Info-req
Info-ack
Set-up
OR1:N
Release
OR1:Y
LEc
MSC
Server b
Info request
Page MS
Busy Subscriber
Impossible Call Completion
Connect to following address
Set-up
Notification
Notification
OR3:Y
OR2:Y
Release
GMSC
Server

NDUB: Network Determined User Busy
OR1: Call to be forwarded
OR2: Notification to forwarding subscriber required
OR3: Notification to calling subscriber required
Figure 4-9 CFB to PSTN (NDUB)
The procedure is as follows:
1) After access, MSa originates a SETUP message to GMSC Server to start the
call setup procedure.
2) GMSC Server initiates the procedure of getting routing information to the MSb
(called party) resident HLRb with an INFO-REQ message. Upon receipt of the
routing information, HLRb returns an INFO-ACK message.
3) According to the routing information returned by HLRb, GMSC Server sends a
SET-UP message to MSb resident VMSC Server, that is, MSC Server b.
4) After receiving the SET-UP message, MSC Server b sends an INFO REQUEST
message to VLRb to ask for user data pertaining to the incoming call, and then
awaits a response from VLRb. VLRb sends a PAGE MS message to MSC
Server b. MSC Server b returns a response to VLRb, and the response carries a
user error information element indicating that the failure cause is subscriber
busy. Data about the subsequent forwarding is contained in the response
returned by VLRb to MSC Server b.
5) If the CFB service is not available, the call fails; otherwise, skip to Step 6.
6) Based on the forwarding data, MSC Server b directly sends a SET-UP message
to PSTN.
Forwarded to a PSTN subscriber: UDUB

4-17
MSa/TEa
GMSC
Server
HLRb VLRb MSb
Set-up
Info-req
Info-ack
Set-up
OR1:N
Release
OR1:Y
LEc
MSC
Serverb
Info request
Page MS
Busy Subscriber
Set-up
Notification
OR2:Y
Release
Set-up
UDUB

Figure 4-10 CFB to PSTN (UDUB)
The procedure is as follows:
4) After receiving the SET-UP message, MSC Server b sends an INFO REQUEST
message to VLRb to ask for user data, and then awaits a response from VLRb.
VLRb sends a PAGE MS message to MSC Server b. MSC Server b sends a
SET-UP message to MSb to start the call setup procedure. After hearing the
ringing tone, the called party rejects the call. MSC Server b returns a response to
VLRb, and the response carries a user error information element indicating that
the failure cause is subscriber busy. Data about the subsequent forwarding is
contained in the response returned by VLRb to MSC Server b.
5) If the CFB service is not available, the call fails; otherwise, skip to Step 6.
6) Based on the forwarding data, MSC Server b directly sends a SET-UP message
to PSTN.

4-18
MSa/TEa
GMSC
Serfer
HLRb VLRb MSb
Set-up
Info-req
Info-ack
Set-up
OR1:N
Release
OR1:Y
HLRc
MSC
Server b
Info request
Page MS
Busy Subscriber
Information Req
Set-up
Notification
OR2:Y
Release
MSC
Server c
Information Ack
OR3:Y
Notification

OR2: Notification to forwarding subscriber required
Figure 4-11 CFB to a mobile subscriber (NDUB)
The procedure of call forwarding to a mobile subscriber is similar to that of call
forwarding to a PSTN subscriber on network determined busy. The only exception is
as follows: MSC Server b has to fetch routing information from the MSc resident
HLRc according to the forwarded-to number (INFORMATION REQ, INFORMATION
ACK). After getting the routing information, MSC Server b sends a SET-UP message
to MSC Server c to start the call setup procedure.
MSa/TEa
GMSC
Server
HLRb VLRb MSb
Set-up
Info-req
Info-ack
Set-up
OR1:N
Release
OR1:Y
HLRc
MSC
Server b
Info request
Page MS
Busy Subscriber
Information Req
Set-up
Notification
OR2:Y
Release
MSC
Server c
Information Ack
Set-up
UDUB

Figure 4-12 CFB to a mobile subscriber (UDUB)

4-19
The procedure of call forwarding to a mobile subscriber on user determined user busy
has the almost same activities as that of call forwarding to a PSTN subscriber on user
determined busy except that the call connection continues at MSC Server b in the
former procedure. The continuing process has been described in the procedure of call
forwarding to a mobile subscriber on network determined busy.
4.5.3 CFNRy
After a subscriber subscribes and activates this service, all calls relating to basic
services and all calls relating to certain particular services made to the subscriber will
be forwarded if no reply is received.
MSa/TEa
GMSC
Server
HLRb VLRb MSb
Set-up
Info-req
Info-ack
Set-up
OR1:N
Release
OR1:Y
LEc
MSC
Server b
Info request
Set-up
Notification
OR2:Y
Release
Set-up
Call conf
Info ack
Start timer
Info-req
Time expires
Notification
OR3:Y

Figure 4-13 CFNR to a PSTN subscriber
MSC Server b obtains the user data of the incoming call from VLRb. After VLRb
responds with the INFO ACK message, MSC Server b invokes a paging and call

4-20
setup procedure to MSb. MSb responds to the paging request. At the same time,
MSC Server b starts a timer of no response duration.
4) If the called party does not answer the call, MSC Server b initiates the release
procedure after the timer times out. At the same time, MSC Server b notifies
VLRb of the release with the INFO REQ message.
5) VLRb judges whether the call needs to be forwarded. If there is no forwarding
data, the call is released. If there is, VLRb sends the forwarding data to MSC
Server b. MSC Server b continues the call connection to the forwarded-to
subscriber.

4-21
MSa/TEa
GMSC
Server
HLRb VLRb MSb
Set-up
Info-req
Info-ack
Set-up
OR1:N
Release
OR1:Y
HLRc
MSC
Server b
Info request
Info ack
Info Req
Information Req
Set-up
Notification
OR2:Y
Release
MSC
Server c
Information Ack
OR3:Y
Notification
Set-up
Call Conf

Figure 4-14 CFNR to a mobile subscriber
If the call is set to be forwarded to a mobile subscriber, the procedure is as follows:
MSC Server b obtains the user data of the incoming call from VLRb. After VLRb
responds with the INFO ACK message, MSC Server b invokes a paging and call
setup procedure to MSb. MSb responds to the paging request. At the same time,
MSC Server b starts a timer of no response duration.
4) If the called party does not answer the call, MSC Server b initiates the release
procedure after the timer times out. At the same time, MSC Server b notifies
VLRb of the release with the INFO REQ message.
5) VLRb judges whether the call needs to be forwarded. If there is no forwarding
data, the call is released. If there is, VLRb sends the forwarding data to MSC
Server b. MSC Server b continues the call connection to the forwarded-to
subscriber: first, it obtains routing information from the forwarded-to subscriber
resident HLRc; next, it continues to connect the call.

4-22
4.5.4 CFNRc
CFNRc may be triggered on one of the following conditions: no paging response, MS
power-off, assignment failure.
The following part describes the procedure of call forwarding on no paging response.
MSa/TEa
GMSC
Server
HLRb VLRb MSb
Set-up
Info-req
Info-ack
Set-up
OR1:N
Release
OR1:Y
LEc
MSC
Server b
Info request
Set-up
Notification
OR2:Y
Release
Paging
Page MS
Absent Subscriber
Provide Roam No
Roam No
No response

Figure 4-15 CFNRc to a PSTN subscriber (no paging response)
1) MSa sends a SET-UP message to GMSC Server. GMSC Server requests HLRb
to provide routing information. HLRb asks VLRb for roaming number.
2) GMSC Server sends a SETUP message to MSC Server b. MSC Server b
requests VLRb for user data of the incoming call, which triggers VLRb to initiate
a paging procedure. However, a paging response is not received. MSC Server b
returns a PAGE RESPONSE with the cause value absent subscriber.
3) At this time, VLRb makes a judgment whether or not forwarding happens. If call
forwarding does not happen, the call ends. Otherwise, VLRb continues to
connect the call according to the forwarding data.

4-23
MSa/TEa
GMSC
Server
HLRb VLRb MSb
Set-up
Info-req
Info-ack
Set-up
OR1:N
Release
OR1:Y
HLRc
MSC
Server b
Info request
Page MS
Absent Subscriber
Info req
Set-up
Notification
OR2:Y
Release
MSC
Server c
Info ack
Paging
Provide Roam No
Roam No
No response

Figure 4-16 CFNRc to a mobile subscriber (no paging response)
1) MSa sends a SET-UP message to GMSC Server. GMSC Server requests HLRb
to provide routing information. HLRb asks VLRb for roaming number.
2) GMSC Server sends a SETUP message to MSC Server b. MSC Server b
requests VLRb for user data of the incoming call, which triggers VLRb to initiate
a paging procedure. However, a paging response is not received. MSC Server b
returns a PAGE RESPONSE with the cause value absent subscriber.
3) At this time, VLRb makes a judgment whether or not forwarding happens. If call
forwarding does not happen, the call ends. Otherwise, VLRb continues to
connect the call according to the forwarding data.
Chapter 5 SMS Procedures

5-1
5.1 Overview
Short Message Service is one of basic telecommunication services. SMS enables the
mobile network system to provide users with a communication method different from
voice transport. A short message makes use of signaling channels of the mobile
network to transfer text information of a limited length. There are two types of SMSs,
namely peer-to-peer SMS and cell broadcast SMS.
A short message is sent from an entity to a specified called party through Short
Message Mobile Originated (SMMO) and Short Message Mobile Terminated (SMMT)
services. This is peer-to-peer SMS. The length of a single short message is 140 bytes
after coding. 160 English characters can be carried.
Cell broadcast SMS is like this: a short message is sent through BSC to all SMS
subscribers in a specified area. After coding, each page can accommodate 82 bytes
and the maximum number of pages is 15. Only peer-to-peer SMS is described in the
following section.
5.2 Mobile Originated SMS
Mobile originated SMS means that a short message is originated by MS and is sent
to the short message center (SMC). The procedure of mobile originated SMS is
MS VMSC VLR SMC
1.Short Message(RP_ DATA)
2.MAP_SEND_INFO_FOR_MO_SMS
3.MAP_SEND_INFO_FOR_MO_SMS_ACK
4.MAP_MO_FORWARD_SHORT_MESSAGE(RP_DATA)
5.MAP_MO_FORWARD_SHORT_MESSAGE_ACK(RP_ACK)
6.Short Message
Acknowledgement(RP_ACK)
7.ShortMessage
Error(RP_ERROR)

Figure 5-1 Mobile originated short message transfer procedure

5-2
1) After a subscriber triggers to send a short message, MS sends it to MSC through
the A interface (GSM) or the Iu interface (UMTS).
2) Upon receipt of the SMS request from the A interface or the Iu interface, MSC
initiates to VLR a request for mobile originated SMS user data detection
according to the MSISDN of the short message originated MS.
3) VLR checks the subscription information and detects whether or not the local
office supports SMS. The detection results are sent to MSC.
4) MSC analyzes the detection results. If the local office does not support SMMO or
operator determined barring (ODB) is active, MSC directly returns a rejection
(RP_ERROR) to MS. Otherwise, the SMC address is got from the mobile
originated short message, and the short message is forwarded to the proper
SMC.
5) After receiving the request for forwarding mobile originated short message, SMC
checks the validity of the data. If it is valid, SMC returns a forwarding response to
MSC.
6) MSC receives the response from SMC and sends the outcome to MS.
5.3 Mobile Terminated SMS
Mobile terminated SMS means that SMC delivers a short message to the destination
subscriber. The procedure of mobile terminated SMS is shown in Figure 5-2.
MS
VMSC VLR HLR SMC
1.MAP_SEND_ROUTING_INFO_FOR_SM
2.MAP_SEND_ROUTING_INFO_FOR_SM_ACK
3.MAP_MT_FORWARD_SHORT_MESSAGE(RP_DATA)
4.MAP_SEND_INFO_FOR_MT_SMS
5.MAP_PAGE/MAP_SEARCH_FOR_MOBILE_SUBSCRIBER
6.Page
7.Page response
8.MAP_PROCESS_ACCESS_REQUEST_ACK/
MAP_SEARCH_FOR_MOBILE_SUBSCRIBER_ACK
9.MAP_SEND_INFO_FOR_MT_SMS_ACK
10.Short Message(RP_DATA))
11.Short Message
Acknowledgement(RP_ACK)
12.MAP_MT_FORWARD_SHORT_MESSAGE_ACK(RP_ACK))

Figure 5-2 Mobile terminated short message transfer procedure
1) After receiving the mobile originated short message, SMC gets the called number
from it. SMC makes use of the called number and initiates to HLR a procedure for
getting routing information.
2) Upon receipt of the routing information request, HLR retrieves information about
the subscriber in the database. A failure cause is returned to SMC if one of the
following conditions is encountered: the subscriber is absent, roaming is not allowed,

5-3
ODB is active, terminated SMS is not supported, the Mobile station Not Reachable
Flag (MNRF) is set, MCEF is set, or the subscriber has been removed from the
roaming destination MSC/VLR. Otherwise, HLR returns to SMC the VMSC number
where the called party is resident. (Note: In the case that information about location of
the called MSC is valid but bit set is performed on MNRF, a failure response is
returned to SMC if the subscribers short message has a low priority; otherwise, the
routing information is returned.)
3) SMC delivers to VMSC a request for forwarding the short message according to
the received VMSC number.
4) Upon receipt of the forwarding request from SMC, VMSC initiates to VLR a request
for detecting SMMT user data.
5) VLR queries the existing subscription data and mobility management status. It may
be found that SMMT is not supported, MS is powered off, MNRF is set, roaming is not
allowed. If the subscriber can not be paged due to one of those reasons, MSC sends
a failure response to SMC gateway. Otherwise, initiation of a paging procedure to MS
starts in a specific location area in case of a known MS location area, or initiation of a
paging procedure starts in the whole MSC serving area in case of an unknown MS
location area.
6) MSC originates a PAGE message to MS.
7) MS returns a PAGE RESPONSE to MSC.
8) 9) 10) Upon receipt of the PAGE RESPONSE from MS, MSC initiates an access
procedure if it is required. After the access is completed, the short message is
delivered to MS through the A interface (2G) or the Iu interface (3G).
11) 12) After receiving the delivery outcome relating to the short message from MS,
MSC notifies SMC of the outcome. If several short messages are to be delivered (that
is, RP-MMS flag bit is contained in the short message forwarding request from SMC),
the connection is held and the procedures mentioned in 3) 10) 11) and 12) are
repeated. Otherwise, all connections will be released.
5.4 SMS Alerting Procedures
I. Procedure of Alerting SMC due to Mobile Station Reachable
In the mobile terminated SMS procedure, if the short message fails to be delivered as
there is no page response, the subscriber does not reply, or due to other reasons,
SMC initiates to HLR a short message status report so that HLR can get information
about MSISDN of the called party and address of originated SMC. HLR stores the
information in the data record of the called party (named Message Waiting Data). Bit
set is performed on MNRF contained in HLR. In addition, SMC temporarily stores the
failed short message. When MS is found in the network again, MSC initiates to HLR a
notification that it is ready for the short message. The notification cause is mobile

5-4
station reachable. Figure 5-3 shows the procedure of alerting SMC due to mobile
station reachable.
MS MSC VLR HLR SMC
1.CM Service Request/Page response/Location Updating
2.MAP_PROCESS_ACCESS_REQUEST / MAP_UPDATE_LOCATION_AREA
3.MAP_READY_FOR_SM (Mobile Present) / MAP_UPDATE_LOCATION
4.MAP_READY_FOR_SM_ACK
5.MAP_ALERT_SERVICE_CENTRE
6.MAP_ALERT_SERVICE_CENTRE_AC

Figure 5-3 Procedure of alerting SMC due to mobile station reachable
1) MS accesses the network again as a call is made or answered, or its location is
updated.
2) MSC may initiate an access procedure to VLR if a service is connected to MS or
a page response is originated by MS. MSC may initiate a user data detection
procedure when MS location is updated.
3) VLR checks the user data. When bit set performed on MNRF of the subscriber is
found, the flag bit is cleared. In addition, VLR initiates to HLR a notification that it
is ready for the short message. The notification cause is mobile station
reachable. If it is a location update procedure, VLR sends a location update
request to HLR.
4) If HLR receives the notification that VLR is ready for the short message, HLR
performs detection on dynamic data of the subscriber. If bit set performed on
MNRF is found, the bit is cleared, HLR originates an AlertSC notification to SMC,
and HLR returns a notification response to VLR. If what HLR receives is a
location update request and bit set performed on MNRF in the dynamic data of
the subscriber is found, the flag bit is cleared, HLR originates an AlertSC
notification to SMC, and then the location update procedure goes on normally.
5) Upon receipt of the AlertSC notification from HLR, SMC returns a response.
Then SMC makes another attempt to deliver the short message in suitable
situations.
II. Procedure of Alerting SMC due to MS Memory Capacity Available
If a mobile terminated short message fails to be delivered as MS memory capacity is
unavailable, SMC initiates to HLR a short message status report so as to notify HLR
of information about MSISDN of the called party and address of originated SMC. HLR

5-5
stores the information in the data record of the called party (named Message Waiting
Data). Bit set is performed on MCEF contained in HLR. In addition, SMC temporarily
stores the failed short message. If MS memory capacity becomes available again
since a short message is deleted, MS sends a memory capacity available message
to MSC. Upon receipt of the message, MSC originates to HLR a notification that it is
ready for the short message. The notification cause is memory capacity available.
Figure 5-4 shows the procedure of alerting SMC due to memory capacity available.
MS MSC HLR
SMC
1.SM memory capacity available
2. MAP_READY_FOR_SM
3. MAP_READY_FOR_SM_ACK
4.SM memory capacity available
5. MAP_ALERT_SERVICE_CENTRE
6. MAP_ALERT_SERVICE_CENTRE_ACK

Figure 5-4 Procedure of alerting SMC due to MS memory capacity available
1) MS sends a memory capacity available message to MSC through the A
interface (2G) or the Iu interface (3G).
2) MSC notifies HLR that it is ready for the short message. The notification cause is
memory capacity available.
3) After receiving the message, HLR checks the dynamic data of the subscriber. If
bit set performed on MCEF is found, the bit is cleared. HLR sends an AlertSC
notification to MSC and returns to VLR a notification response. MSC receives the
response and returns a response message to MS.
4) Upon receipt of the AlertSC notification from HLR, SMC returns a response.
Then SMC makes another attempt to deliver the short message in suitable
situations.
Chapter 6 IN Service Handling Procedures

6-1
6.1 Pre-paid Service Handling Procedures
6.1.1 Mobile Pre-paid Subscriber Calling Ordinary WCDMA Subscriber
It is assumed that the pre-paid subscriber is resident in the serving area of
MSCa/VLR/SSP. O-CSI is used to trigger a service. The call procedure is shown in
Figure 6-1.
MSCa /VLR/SSP SCPa
IDP
RRBE
Apply Charging
Continue
CAP signaling
MAP signaling
O_CSI trigger
Charging the calling party
MSCb /VLR
IA M (MSRN)
ACM
ANC
ERB(DP9)
ACR
ISUP signaling

HLRb
SRI
PRN
PRN_ ack
SRI_ Ack (MSRN)
Release Call
FCI

Figure 6-1 Procedure of prepaid subscriber calling ordinary WCDMA subscriber (O-CSI trigger)
1) MSCa/VLR/SSP receives the call. According to the calling partys subscription
information, the service is triggered in O-CSI manner. MSCa/VLR/SSP resident
toll area code is put in the Location Number parameter of the IDP message.
Then MSCa/VLR/SSP sends the IDP message to the SCPa.
2) After SCPa receives the IDP message, SCPa analyzes the calling partys
account before anything else is done. If the account is valid, skip to Step 3).
3) SCPa determines the calling tariff rate based on the calling partys location and
the called number. SCPa calculates the balance of the account into conversation
duration, and also sends RRBE, AC, FCI and CONTINUE to MSCa/VLR/SSP.

6-2
4) Upon receipt of CONTINUE message, MSCa/VLR/SSP sends an SRI message
to the called HLRb. MSCa/VLR/SSP gets the MSRN of the called party and
performs call connection.
5) After a conversation, either party hooks on. MSCa/VLR/SSP reports the charging
report and the on-hook event.
6.1.2 PSTN or Ordinary WCDMA Subscriber Calling Pre-paid Subscriber
It is assumed that a PSTN or ordinary WCDMA subscriber makes a call to a pre-paid
subscriber. T-CSI is used to trigger a service. The call procedure is shown in Figure
6-2.
SCPb
IDP
RRBE
Apply Charging

HLRb
Send Routing Info
CAP signaling
MAP signaling
ERB(DP17)
ApplyChargingReport
...
Connect
SRI_ Ack MSRN
Send Routing Info
SRI_ack (O-CSI+T-CSI)
T_CSI trigger
MSCb /VLR
Charging the called party
IA M(MSRN)
ACM
ANC
ISUP signaling
PRN
PRN_ ack
MSC/VLRSSP
Release Call

Figure 6-2 PSTN or ordinary WCDMA subscriber calling pre-paid subscriber
1) After receiving the call originated by a PSTN or WCDMA subscriber,
MSCa/VLR/SSP finds that the calling party is not a pre-paid subscriber. Then an
SRI message is sent to the called HLRb. If the called party is a pre-paid
subscriber, the subscription information (O_CSI+T_CSI) is returned.
2) MSCa/VLR/SSP gets the SCPb address from the T_CSI data, and sends an IDP
message to SCPb. As GMSC to PSTN or originating MSC to GSM has the SSP
function, the toll area code of the location where GMSC/SSP or originating

6-3
MSC/SSP is resident is placed in the Location Number parameter of the IDP
message.
3) After receiving the IDP message, SCPb analyzes the called partys account
before anything else is done. If the account is valid, SCPb determines the tariff
rate according to the home location of the called party and the actual location of
the called party (reference Location Information parameter). SCPb calculates the
account balance to conversation duration, and sends RRBE, AC and CONNECT
to MSCa/VLR/SSP.
4) Upon receipt of CONNECT message, MSCa/VLR/SSP sends an SRI message
again to HLRb. This SRI message disables T-CSI. MSRN of the called party is
obtained.
5) MSCa/VLR/SSP performs connection according to the MRSN of the called party.
6) After the conversation, either party hooks on. MSCa/VLR/SSP reports the
charging report and the on-hook event.
6.1.3 Pre-Paid Subscriber Calling Pre-paid Subscriber
It is assumed that the calling pre-paid subscriber is resident in the serving area of
Figure 6-3.

6-4
IDP
RRBE
Apply Charging
Send Routing Info
CAP signaling
MAP signaling
ERB (DP9)
ApplyChargingReport
Connect
SRI_ ack(MSRN)
Send Routing Info
SRI_ ack (O-CSI+T-CSI)
HLRb MSCa/VLR/SSP SCPa
IDP
Apply Charging
Continue
MSCb/VLR
O_CSI trigger
Charging the calling party
IAM (MSRN)

ACM

ANC
ISUP signaling
SCPb
ERB (DP17)
ApplyChargingReport
RC
RC
RRBE
Charging the called party
PRN
PRN_ ack
FCI
T_CSI trigger

Figure 6-3 Pre-paid subscriber calling pre-paid subscriber
1) MSCa/VLR/SSP receives the call. According to the calling partys subscription
information, the service is triggered in O-CSI manner. MSCa/VLR/SSP resident
toll area code is put in the Location Number parameter of the IDP message.
Then MSCa/VLR/SSP sends the IDP message to SCPa.
2) SCPa determines the calling tariff rate based on the calling partys location and
the called number. SCPa calculates the balance of the account into conversation
duration, and sends RRBE, AC, FCI and CONTINUE to MSCa/VLR/SSP.
3) Upon receipt of the CONTINUE message, MSCa/VLR/SSP sends an SRI
message to the called HLR. If the called party is a pre-paid subscriber,
MSCa/VLR/SSP returns O_CSI+T_CSI information and called location
information (VLR-number).

6-5
4) MSCa/VLR/SSP sends to SCPb an IDP message where MSCa/VLR/SSP
resident toll area code is put in the Location Number field and the called location
information (Vlr-number) is put in the Location Information field.
5) After receiving the IDP message, SCPb analyzes the called partys account
before anything else is done. If the account is valid, SCPb determines the called
tariff rate according to the location information of the called party contained in the
IDP message. SCPb calculates the account balance to conversation duration,
and sends RRBE, AC, FCI and CONNECT to MSCa/VLR/SSP.
6) MSCa/VLR/SSP sends an SRI message again to HLRb. This SRI message
disables T-CSI. MSRN of the called party is obtained.
7) MSCa/VLR/SSP performs connection according to the MRSN of the called party.
8) After the conversation, either party hooks on. MSCa/VLR/SSP reports the
charging report and the on-hook event to SCPa and SCPb respectively.
6.1.4 Pre-paid Subscriber Calling Ordinary WCDMA Subscriber with CFU to
Pre-paid Subscriber
It is assumed that the calling pre-paid subscriber is resident in the serving area of
Figure 6-4.

6-6
MSCa /VLR/SSP SCPa
IDP
RRBE
Apply Charging
Continue
Charging A
MSCc /VLR
IAM (MSRN)
ACM
ANC
ERB(DP9)
ACR

HLRb
PRN
PRN_ ack
SRI
SRI_ ack(FTN)

HLRc
SRI_ ack(MSRN)
SRI
Output CFU bill for B
SRI
SRI_ Ack
(O-CSI+T-CSI)
SCPc
Charging C
IDP
ERB(DP17)
ACR
RRBE
Apply Charging
Connect
RC
RC
FCI
O-CSI trigger

Figure 6-4 Pre-paid subscriber calling ordinary WCDMA subscriber with CFU to pre-paid subscriber
6.1.5 Recharge Procedure
Recharge procedure is associated with IP typically, as shown in Figure 6-5.

6-7
MSCa/VLR/SSP SCPa
IDP
O-CSI trigger
RRBE
CTR
P&C
P&C Result
P&C Result
P&C
P&C
P&C Result
Select a language
Select a procedure
Input the card number
PA
SRR
Please wait a moment
PA
SRR
P&C
ERB(o-Abandon)
Usage life
Options for other procedures
User on-hook
PA
SRR
Prompt of a successful recharge
Money

Figure 6-5 Recharge procedure
6.2 Mobile Originated SMS Handling Procedure
In some mobile originated SMS associated procedures, MSC/VLR/SSP can report
SMS events to GsmSCF, and GsmSCF can modify SMS parameters and influence
the sending of the short messages.
A typical SMS CAMEL procedure is shown in Figure 6-6.

6-8
MSC/VLR/SSP SCP SMSC
IDP SMS
RRSE
Continue SMS
ERS
FCI SMS
SMS-CSI trigger
MAP MO FORWARD SHORT MESSAGE
MAP MO FORWARD SHORT MESSAGE ACK
Continue SMS
CAP messages
MAP messages

Figure 6-6 Mobile originated SMS handling procedure
1) MSC/VLR/SSP receives the mobile originated short message. According to the
subscription information, SMS-CSI is used to trigger a service. MSC/VLR/SSP
sends an IDP SMS message to SCP.
2) After receiving the IDP SMS message, SCP analyzes the calling partys account
before anything else is done. If the account is valid, RRSE and CONTINUESMS
are sent to MSCa/VLR/SSP.
3) MSCa/VLR/SSP sends the short message to SMSC.
4) Upon receipt of the outcome of sending SMS, MSCa/VLR/SSP reports the
outcome to SCPa.
6.3 Mobility Management Event Notification Handling
Procedure
After having successfully completed a mobility management event from a subscriber,
the VLR initiates a mobility event notification procedure to the GsmSCF according to
the subscription information. Mobility events that can be reported at present include
intra-VLR location update (not including periodic location update), inter-VLR location
update, MS powered off, network determined IMSI detach, and IMSI attach.
The mobility management event notification procedure is shown in Figure 6-7.

6-9
VLR gsmSCF
MAP NOTE MM EVENT
MAP NOTE MM EVENT ACK
M-CSI trigger

Figure 6-7 Mobility management event notification handling procedure
Chapter 7 Location Service Procedures

7-1
7.1 Overview
LoCation Service (LCS) specifies for operators, subscribers and third party service
providers all the necessary network elements and entities, their functionalities,
interfaces, as well as communication messages, so as to implement the positioning
functionality in a cellular network. The LCS is able to position a Mobile Station (MS) to a
cell degree. The LCS covers a wide range of applications, including public security
services as emergency calls and alarms, location-based billing and tracing, and
location-based information services as navigation, city-touring, and located
broadcasting.
7.2 General LCS Architecture
In 3GPP networking architecture, LCS is a system relatively independent to the core
network. MSOFTX3000 implements LCS function based on 2001 June version of 3GPP.
Below is the architecture of LCS in 3GPP
UE
Node B
(LMU
Type B)
HLR
Gateway
MLC
External
LCS client
Le
Lg
Lg
Lh
Gateway
MLC
Other PLMN
LMU
Type A
Uu
Iu Iub
gsmSCF
Lc
CBC
Note 1)
IuBC
3G-
SGSN
3G-
MSC/VLR
RNC
Node B
(LMU
Type B)
Iur
Iub
SRNC
(SMLC
functio-
nality)

Figure 7-1 Architecture of LCS in 3GPP
The LCS Client, which invokes a LCS request, is divided into external LCS Client and
internal LCS client. The LCS Server contains RNC, MSC/VLR, HLR, and SGSN. RNC
accomplishes location measurement and calculation. MSC/VLR, HLR and SGSN fulfill
addressing of UE, sending and receiving of location messages, and subscriber data
storage management. GMLC provides interface between LCS Client and LCS Server.
I. Related Entities
LCS Client

7-2
The LCS Client consists of external LCS Client and internal LCS Client. An external
LCS Client is an application server providing location-based services. It connects with
GMLC through Le interface. An internal LCS Client can be included in CN equipment
(as MSC or gsmSCF), or operation & maintenance (O&M) equipment which can be a
separate one or the O&M equipment of MSC. LCS Client invokes a location request,
and implements location-based services with the results.
As functions differ, LCS Client can be divided into four types:
1) The Commercial LCS Clients (or Value Added Service LCS Client), which support
value-added services, can be subscriber specific or non-subscriber specific.
2) The Internal LCS Clients support, or enhance with LCS, certain O&M related tasks,
supplementary services, IN related services and GSM bearer services and
teleservices.
3) The Emergency LCS Clients assists subscribers who place emergency calls.
4) The Lawful Intercept LCS Client uses the location information to support various
legally required or sanctioned services
LCS Server
The LCS Server is a group of software and/or hardware entities offering LCS
capabilities, including MSC, SGSN and RNC. It is a group of entities implementing
location function coordinately rather than a specific entity. The LCS Server accepts
LCS requests, services requests, and sends back responses to the received requests.
Gateway Mobile Location Center (GMLC)
GMLC is a gateway connecting with external LCS Client. It receives location requests
from Le interface, then starts addressing HLR and sends location request to VMSC.
GMLC can also send the location results to related LCS Client, and convert the result
into local coordinates.
MSC/VLR
MSC/VLR implements codec, version negotiation, and signaling processing of location
messages; and provides interface functions as signaling tracing and O&M. It is required
to accomplish the processing and control of location procedures, protecting subscriber
private information, and providing billing according to processing results.
HLR
It stores LCS subscription data, and provides MSC number to located subscriber.
Target UE
Target UE, which is also named MS hereinafter, refers to the located mobile phone. The
present position or the previously-located position of the mobile phone need to be
provided according to location requests. Usually, the target UE is the located object, but
for Mobile Originated Location Request (MO-LR), the target UE sends location
requests.

7-3
7.3 General Network Location Procedures
LCS procedures include Mobile Terminated Location Request (MT-LR) procedure,
Mobile Originated Location Request (MO-LR) procedure, and Network Induced
Location Request (NI-LR) procedure.
7.3.1 Mobile Terminated Location Request
Figure 7-2 shows MT-LR procedure.
10. RANAPLocation Report
UE HLR GMLC SRNC Client VMSC
8. RANAPLocation Reporting Control
5. MSPaging, Authentication, Ciphering
12. LCSServiceResponse
2. MAPSend Routing Info for LCS
1. LCSService Request
3. MAPSend Routing Info for LCSack.
4. MAPProvide Subscriber Location
9. Messages for individual positioning methods
11. MAP Provide Subscriber Location ack.
[6. LCSLocation Notification Invoke]
[7. LCS Location Notification Return Result]

Figure 7-2 MT-LR procedure
On receiving the location request from an external client, GMLC verifies LCS
Client identifier and subscription data of the requested LCS, and obtains MSISDN
or IMSI, LCS QoS data of target UE. For call-related location requests, GMLC
shall obtain and verify called number of LCS client. To process location requests
to multiple UEs, repeat step 2) till step 12).

7-4
2) If GMLC knows VMSC and IMSI of a certain MSISDN, skip to step 4). Otherwise,
GMLC sends to HLR a MAP_SEND_ROUTING_INFO _FOR_LCS message of
IMSI or MSISDN with target UE.
3) HLR verifies the caller address of GMLC, which has been authorized and can
request UE location information, and returns VMSC address and IMSI or MSISDN
(MSISDN is not included in step 2).
4) GMLC sends MAP_PROVIDE_SUBSCRIBER_LOCATION message to related
VMSC. The message included requested location information type, IMSI, LCS
QoS of UE, and indication of whether LCS Client has override capability. For
call-related location request, the message also includes called number of LCS
Client. For value-added LCS Client, client name can be included. For non-call
related location request, LCS Client identifier is included. For other cases, client
name or identifier is optional.
5) If GMLC locates in another PLMN or another nation, VMSC will verify whether
invoking a location request from that PLMN or nation is permitted. If not, it will
return related error messages. If so, VMSC verifies LCS prohibition restriction of
UE subscription file stored in VLR. If LCS is prohibited, there is no need to inform
UE, and LCS Client does not have override capability, VMSC returns an error
message. If UE is in idle mode, the core network will invoke paging, authentication
and ciphering procedures. If target UE supports UE-based or UE-assisted location
method, UE will provides its location method in controlled early classmark sending
to SRNC and MSC.
6) If the location request comes from a value-added LCS Client, and UE subscription
file indicates that UE requires notification (with private verification), and UE
supports notification of LCS, then VMSC sends an LCS Location Notification
Invoke message to target UE, indicating location request type , LCS Client
identifier, and whether private verification is required.
7) Target UE informs subscriber that a location request comes. If private verification
is authorized, target UE inquires that whether location request shall be permitted
in case of no response, and waits for subscriber for decision. Then, UE returns the
LCS Location Notification Return Result message to VMSC, which could also be
returned between Step 6) and Step 11). If no message is returned within specified
time, VMSC thinks no response, and shall return an error message to GMLC when
private verification is required, and indicates whether the reason is subscriber not
allowing location or no response.
8) VMSC sends RANAP Location Report Control message to SRNC, which includes
location request type, UE location capability, and QoS of request.
9) SRNC determines and implements the location method.
10) When obtaining QoS-satisfied location results, SRNC returns the results in
RANAP Location Report message to VMSC. If no location result is obtained, the
cause of failure shall be included in RANAP Location Report message.

7-5
11) If no private verification procedure is implemented, VMSC will return location
information and estimated time to GMLC. If the private verification procedure is
implemented, and the LCS Location Notification Return Result message that MSC
receives indicates that location is permitted, only location message is returned. If
location is not permitted, or response times out, and UE subscription file specifies
that location is prohibited in case of no response, then VMSC shall return an error
response message to GMLC. If private verification is implemented, and location is
permitted, but SRNC does not obtain location message, and request type of LCS
Client is current location or last known location, and VMSC has the last known
location, return the location to GMLC. If UE was in idle state, VLR shall release the
MM connection with UE. VMSC can record charging information.
12) GMLC returns estimated UE location to LCS client that initiates the request.
GMCL can implement coordinate conversion, and record account information of
LCS client and the network.

Note:
Steps 1) to Step 8) cover location preparation, Step 9) is location measurement setup process, and Steps
10) to 12) are location calculation and release processes.

7.3.2 Mobile Originated Location Request
Figure 7-3 shows MO-LR procedure.

7-6
UE SRNC MSC
5. RANAP L ocation Reporting Control
11. LCS MO-LRReturn Result
[ 4. Location Services Invoke]
3. Authentication, Ciphering or CMService Accept
7. RANAP Location Report.
or transfer of location assistance data
12. Release CM, MM, RRCconnections
1 . CMService Request
GMLC LCS Client
8. MAP Subscriber Location Report
9. MAPSubscriber Location Report ack.
10. Location Information
2. CM Service Request

Figure 7-3 MO-LR procedure
1) UE sends LCS MO-LR message to SRNC.
2) SRNC forwards LCS MO-LR message to MSC.
3) MSC authenticates, ciphers and accesses the LCS request of UE.
4) When the access process completes, UE invokes MO-LR indication.
5) If UE requests its own location or sends UE location to LCS client, the message
includes LCS request and QoS information; if UE is required to send UE location
to LCS client, the message shall include LCS client identifier or GMLC address.
When GMLC address is not included, VMSC can be configured as local GMLC.
Check if the GMLC allows connection from LCS client. If not, reject the location
request. If it is UE-assisted location data or ciphering key, the message shall
include assist data or ciphering key type, and in which method will these data be
applied. VMSC checks in UE subscription file if UE can request its location, or can
send its location to other LCS client or request location assist data and ciphering
key. If UE sends location request, and call set up completes, VMSC can reject the
request for some certain types of non-voice calls.

7-7
6) For LCS procedures of other location results, they are the same as described in
MT-LR procedure.
7) SRNC reports location results to VMSC.
8) VMSC reports location results to GMLC.
9) GMLC responses whether the correct location information is received.
10) GMLC returns the results to UE-requested LCS client.
11) Finally, MSC returns location request response (including location results)
12) Release Connection Management (CM), Mobility Management (MM), or Radio
Resource Control (RRC) connection.
7.3.3 Network Induced Location Request
Figure 7-4 shows NI-LR procedure.
9. Location Information
10. Emergency Call Release
12. MAP Subscriber Location Report ack
UE HLR GMLC SRNC
LCS Client
VMSC
4. RANAP Location Reporting Control
6. RANAP Location Report
2. RANAP (CMService Request)
3. Emergency Call Origination
1. CMService Request
8. MAP Subscriber Location Report ack

Figure 7-4 NI-LR procedure
1) In idle state, UE invokes RRC connection request to start an emergency call.
2) SRNC transfers the CM service request through Iu interface. UE can be identified
by TMSI, IMSI, or IMEI.

7-8
3) Start emergency call procedure.
4) Based on network operator requirement, LCS request procedure shall be invoked
on emergency call origination. Invoke the LCS request control procedure to SRNC.
VMSC, SRNC and UE continue with the emergency call procedure.
5) For LCS procedures of other location results, they are the same as described in
MT-LR procedure.
6) SRNC reports location results to VMSC.
7) VMSC reports location results to GMLC.
8) GMLC responses whether the correct location information is received.
9) GMLC returns the results to UE-requested default LCS client.
10) Emergency service releases.
11) For emergency service in North America, MSC will send another Location Report
to GMLC.
12) GMLC conforms, releases the emergency call and stores related information.

HUAWEI


Signaling Analysis
Table of Contents

i
Table of Contents
Chapter 1 Analysis of Location Update Signaling..................................................................... 1-1
1.1 Overview of Location Update Signaling............................................................................. 1-1
1.2 IMSI Attach ........................................................................................................................ 1-1
1.2.1 IMSI Attach Procedure............................................................................................ 1-1
1.2.2 Interface Tracing Example of IMSI Attach .............................................................. 1-2
1.2.3 Key Messages of IMSI Attach................................................................................. 1-3
1.3 IMSI Detach ..................................................................................................................... 1-15
1.3.1 IMSI Detach Procedure......................................................................................... 1-15
1.3.2 Interface Tracing Example of IMSI Detach ........................................................... 1-16
1.3.3 Key Messages of IMSI Detach.............................................................................. 1-16
1.4 Normal Updating.............................................................................................................. 1-19
1.4.1 Normal Updating Procedure.................................................................................. 1-19
1.4.2 Interface Tracing Example of Normal Updating.................................................... 1-19
1.4.4 Normal Updating Failure Procedure...................................................................... 1-30
1.4.5 Interface Tracing Example of Normal Updating Failure........................................ 1-30
Chapter 2 Analysis of Relocation Signaling............................................................................... 2-1
2.1 Overview of Relocation Signaling...................................................................................... 2-1
2.1.1 Relocation Procedure.............................................................................................. 2-1
2.1.2 Interface Tracing Example of Relocation................................................................ 2-1
2.1.3 Key Messages of Relocation................................................................................... 2-2
2.1.4 Relocation Failure Messages.................................................................................. 2-6
2.1.5 Interface Tracing Example of Relocation Failure.................................................... 2-7
2.1.6 Key Messages of Relocation Failure ...................................................................... 2-7
Chapter 3 Analysis of Call Signaling........................................................................................... 3-1
3.1 Intra-Office Calls ................................................................................................................ 3-1
3.1.1 Intra-Office Call Procedure...................................................................................... 3-1
3.1.2 Interface Tracing Example of Intra-Office Call ........................................................ 3-2
3.1.3 Key Messages of Intra-Office Call........................................................................... 3-2
3.1.4 Call Failure Procedure .......................................................................................... 3-21
3.1.5 Call Failure Messages Traced .............................................................................. 3-22
Chapter 4 Analysis of Iu Interface Protocol................................................................................ 4-1
4.1 Overview............................................................................................................................ 4-1
4.2 Q.AAL2 Protocol Application ............................................................................................. 4-1
4.2.1 The process of Normal Establishment .................................................................... 4-2
Signaling Analysis
Table of Contents

ii
4.2.2 Establishment Failure.............................................................................................. 4-2
4.2.3 Normal Release....................................................................................................... 4-4
4.2.4 Example of Q.AAL2 Trace ...................................................................................... 4-5
4.2.5 Examples of Important Messages of Q.AAL2......................................................... 4-5
4.3 Iu UP Application ............................................................................................................... 4-9
4.3.2 Major Functions of Iu UP......................................................................................... 4-9
4.3.3 Example of lu UP Trace in Voice Call ................................................................... 4-10
4.4 Basic Signaling Procedure at Iu Interface ....................................................................... 4-11
4.4.2 Voice Call Establishment and Release................................................................. 4-11
4.4.3 VP Call Establishment and Release ..................................................................... 4-12
4.4.4 Examples of Iu UP Important Messages............................................................... 4-12
4.5 Case Analysis of Iu Interface Fault .................................................................................. 4-14
4.5.1 Overview ............................................................................................................... 4-14
4.5.2 Unsuccessful Q.AAL2 Signaling Establishment.................................................... 4-15
4.5.3 Unsuccessful Iu UP Initialization........................................................................... 4-17

Signaling Analysis
Chapter 1 Analysis of Location Update Signaling

1-1
1.1 Overview of Location Update Signaling
Huawei universal mobile telecommunications system (UMTS) core network
equipment provides signaling tracing (including subscriber tracing and interface
tracing) and analysis tool that facilitates system debugging and troubleshooting.This
chapter introduces some common signaling procedures and examples.
1.2 IMSI Attach
1.2.1 IMSI Attach Procedure
When a user equipment (UE) is powered on, it initiates international mobile
subscriber identity (IMSI) attach.If the UE is in the same location area after power-on,
the Iu_CS interface protocol is as shown in Figure 1-1.
Signaling Analysis

1-2

Figure 1-1 Power-on location update procedure
1.2.2 Interface Tracing Example of IMSI Attach
You can set a user interface for tracing the messages generated during power-on of
an UE, as shown in Figure 1-2.

Figure 1-2 Power-on messages
Signaling Analysis

1-3
1.2.3 Key Messages of IMSI Attach
I. RN_MM_LOCATION_UPDATION_REQUEST
This message is sent by the mobile station to the network either to request update of
its location file (normal updating or periodic updating) or to request IMSI attach. See
Figure 1-3 for details

Figure 1-3 RN_MM_LOCATION_UPDATION_REQUEST message
Note the following information in this message:
Skip Indicator: Bits 5 to 8 of the first octet of every Mobility Management message
and general packet radio service (GPRS) Mobility Management message contain the
skip indicator.A message received with skip indicator different from 0000 shall be
ignored. A message received with skip indicator encoded as 0000 shall not be
ignored (unless it is ignored for other reasons).A protocol entity sending a Mobility
Management message or a GPRS Mobility Management message shall encode the
skip indicator as 0000.
Mm msg type: The purpose of this information element is to indicate whether a
normal updating, a periodic updating, or an IMSI attach is wanted. It may also indicate
that a follow-on request has been received from the mobile station CM layer. The
Location Updating Type information element is coded as shown in
figure 10.5.79/3GPP TS 24.008 and table 10.5.93/3GPP TS 24.008. The first and
second bits of this information element indicate the location update type. 00 stands
Signaling Analysis

1-4
for normal location updating; 01 stands for periodic updating; 10 stands for IMSI
attach; 11 stands for a reserved bit.
8 7 6 5 4 3 2 1
Location updating
Type IEI
FOR 0
spare
LUT octet 1

Figure 10.5.79/3GPP TS 24.008 Location Updating Type information element
Table 10.5.93/3GPP TS 24.008: Location Updating Type information element
LUT (octet 1)
Bits
2 1
0 0 Normal location updating
0 1 Periodic updating
1 0 IMSI attach
1 1 Reserved

FOR (octet 1)
The Follow-On Request bit (FOR) is coded as follows:
Bits
4
0 No follow-on request pending
1 Follow-on request pending

Ciphering key sequence num: In a global system for mobile communications (GSM)
authentication challenge, the purpose of this information element is to make it
possible for the network to identify the ciphering key Kc which is stored in the mobile
station without invoking the authentication procedure.In a UMTS authentication
challenge, the purpose of this information element is to make it possible for the
network to identify the ciphering key CK and the integrity key IK which are stored in
the mobile station without invoking the authentication procedure.
Location area identity: The purpose of this information element is to provide an
unambiguous identification of location areas within the area covered by the GSM
system.
Mobile identity: The purpose of this information element is to provide either the
international mobile subscriber identity (MSISDN), international mobile subscriber
identity (IMSI), temporary mobile subscriber identity (TMSI), or international mobile
equipment identity together with the software version number (IMEISV).
II. RN_MM_AUTHENTICATION_REQUEST
This message is sent by the network to the mobile station to initiate authentication of
the mobile station identity. See Figure 1-4 for the detailed information of this
message.
Signaling Analysis

1-5

Figure 1-4 RN_MM_AUTHENTICATION_REQUEST message
Spare half octet: This element is filled with spare bits set to zero and is placed in bits
5 to 8 of the octet unless otherwise specified.
Authentication parameter RAND (UMTS challenge or GSM challenge): The purpose
of this information element is to provide the mobile station with a non-predictable
number to be used to calculate the authentication response signature SRES and the
ciphering key Kc (for a GSM authentication challenge), or the response RES and both
the ciphering key CK and the integrity key IK (for a UMTS authentication challenge).
III. RN_MM_AUTHENTICATION_RESPONSE
This message is sent by the mobile station to the network to deliver a calculated
response to the network. See Figure 1-5 for the detailed information of this message.
Signaling Analysis

1-6

Figure 1-5 RN_MM_AUTHENTICATION_RESPONSE message
Authentication response: The purpose of this information element is to provide the
network with the authentication response calculated in the subscriber identity module
(SIM).
IV. RN_MM_IDENTITY_REQUEST
This message is sent by the network to the mobile station to request a mobile station
to submit the specified identity to the network. See Figure 1-6 for the detailed
information of this message.
Signaling Analysis

1-7

Figure 1-6 RN_MM_IDENTITY_REQUEST message
Identity type: The purpose of this information element is to specify which identity is
requested.The least significant three bits of this element indicate the identify type: 001
stands for IMSI; 010 stands for IMEI; 011 stands for IMEISV; 100 stands for TMSI.
Type of identity (octet 1)
Bits
3 2 1
0 0 1 IMSI
0 1 0 IMEI
0 1 1 IMEISV
1 0 0 TMSI

All other values are reserved.

V. RN_MM_IDENTITY_RESPONSE
This message is sent by the mobile station to the network in response to an
IDENTITY REQUEST message providing the requested identity. See Figure 1-7 for
the detailed information of this message.
Signaling Analysis

1-8

Figure 1-7 RN_MM_IDENTITY_RESPONSE message
VI. SECURITY_MODE_COMMAND
This message is sent by the core network to trigger the integrity and ciphering
functions over the radio interface. See Figure 1-8 for the detailed information of this
message.
Signaling Analysis

1-9

Figure 1-8 SECURITY_MODE_COMMAND message
Integrity Protection Information: This element contains the integrity protection
information (key and permitted algorithms).
Encryption Information: This element contains the user data encryption information
(key and permitted algorithms) used to control any encryption equipment at the radio
network controller (RNC).
Key Status: This information element tells if the keys included in the SECURITY
MODE COMMAND message are new or if they have been used previously.
VII. SECURITY_MODE_COMPLETE
This message is sent by the RNC as a successful response to SECURITY MODE
COMMAND message. See Figure 1-9 for the detailed information of this message.
Signaling Analysis

1-10

Figure 1-9 SECURITY_MODE_COMPLETE message
Chosen Integrity Protection Algorithm: This element indicates the integrity protection
algorithm being used by the RNC.
Chosen Encryption Algorithm: This element indicates the encryption algorithm being
used by the RNC.
VIII. COMMON_ID
This message is sent by the core network to inform the RNC about the permanent
non-access stratum (NAS) UE identity for a user. See Figure 1-10 for the detailed
Signaling Analysis

1-11

Figure 1-10 COMMON_ID message
Permanent NAS UE Identity: This element is used to identify the UE commonly in
UMTS terrestrial radio access network (UTRAN) and in core network.The RNC uses
it to find other existing signaling connections of this same UE. Initially this is of the
type of IMSI.
IX. RN_MM_LOCATION_UPDATING_ACCEPT
This message is sent by the network to the mobile station to indicate that updating or
IMSI attach in the network has been completed. See Figure 1-11 for the detailed
Signaling Analysis

1-12

Figure 1-11 RN_MM_LOCATION_UPDATING_ACCEPT message
Mm msg type: This information element indicates the message type.
system.
X. RN_MM_TMSI_REALLOCATION_COMPLETE
This message is sent by the mobile station to the network to indicate that reallocation
or deletion of a TMSI has taken place. See Figure 1-12 for the detailed information of
this message.
Signaling Analysis

1-13

Figure 1-12 RN_MM_TMSI_REALLOCATION_COMPLETE message
and GPRS Mobility Management message contains the skip indicator. A message
received with skip indicator different from 0000 shall be ignored. A message received
with skip indicator encoded as 0000 shall not be ignored (unless it is ignored for other
reasons). A protocol entity sending a Mobility Management message or a GPRS
Mobility Management message shall encode the skip indicator as 0000.
XI. IU_RELEASE_COMMAND
This message is sent by the core network to order the RNC to release all resources
related to the Iu connection. See Figure 1-13 for the detailed information of this
message.
Signaling Analysis

1-14

Figure 1-13 IU_RELEASE_COMMAND message
Cause: The purpose of this information element is to indicate the reason for a
particular event for the Radio Access Network Application Part (RANAP) protocol.
XII. IU_RELEASE_COMPLETE
This message is sent by the RNC as response to the IU RELEASE COMMAND
message. See Figure 1-14 for the detailed information of this message.
Signaling Analysis

1-15

Figure 1-14 IU_RELEASE_COMPLETE message
1.3 IMSI Detach
1.3.1 IMSI Detach Procedure
When a UE is powered off, it initiates IMSI detach. See Figure 1-15 for the Iu-CS
interface protocol.

Figure 1-15 IMSI detach procedure
Signaling Analysis

1-16
1.3.2 Interface Tracing Example of IMSI Detach

Figure 1-16 Power-off messages
1.3.3 Key Messages of IMSI Detach
I. RN_MM_IMSI_DETACH_INDICATION
This message is sent by the mobile station to the network to indicate the mobile
station is deactivated or the SIM is detached from the mobile station. See Figure 1-17
for the detailed information of this message.

Figure 1-17 RN_MM_IMSI_DETACH_INDICATION message
IMSI Detach Indication message type: This information element indicates the type of
the IMSI detach indication message.
Signaling Analysis

1-17
II. IU_RELEASE_COMMAND
This message is sent by the core network to order the RNC to release all resources
related to the Iu connection. See Figure 1-18 for the detailed information of this
message.

Figure 1-18 IU_RELEASE_COMMAND message
Cause: The purpose of this information element is to indicate the reason for a
particular event for the RANAP protocol.
III. IU_RELEASE_COMPLETE
This message is sent by the RNC as response to the IU RELEASE COMMAND
Signaling Analysis

1-18

Figure 1-19 IU_RELEASE_COMPLETE message
Signaling Analysis

1-19
1.4 Normal Updating
1.4.1 Normal Updating Procedure

Figure 1-20 Normal updating procedure
1.4.2 Interface Tracing Example of Normal Updating

Figure 1-21 Main tracing messages of normal updating
Signaling Analysis

1-20
1.4.3 Main Tracing Messages of Normal Updating
I. RN_MM_LOCATION_UPDATION_REQUEST
This message is sent by the mobile station to the network either to request update of
its location file (normal updating or periodic updating) or to request IMSI attach. See
Figure 1-22 for details

Figure 1-22 RN_MM_LOCATION_UPDATION_REQUEST message
and general packet radio service (GPRS) Mobility Management message contain the
skip indicator.A message received with skip indicator different from 0000 shall be
ignored. A message received with skip indicator encoded as 0000 shall not be
ignored (unless it is ignored for other reasons).A protocol entity sending a Mobility
Management message or a GPRS Mobility Management message shall encode the
skip indicator as 0000.
Mm msg type: The purpose of this information element is to indicate whether a
normal updating, a periodic updating, or an IMSI attach is wanted. It may also indicate
that a follow-on request has been received from the mobile station CM layer. As
shown below, the first and second bits of this information element indicate the location
update type. 00 stands for normal location updating; 01 stands for periodic updating;
10 stands for IMSI attach; 11 stands for a reserved bit.
Signaling Analysis

1-21
Ciphering key sequence num: In a GSM authentication challenge, the purpose of this
information element is to make it possible for the network to identify the ciphering key
Kc which is stored in the mobile station without invoking the authentication
procedure.In a UMTS authentication challenge, the purpose of this information
element is to make it possible for the network to identify the ciphering key CK and the
consistency ciphering key IK which are stored in the mobile station without invoking
the authentication procedure.
system.
II. COMMON_ID
The purpose of the Common ID procedure is to inform the RNC about the permanent
NAS UE Identity of a user. See Figure 1-23 for the detailed information of this
message.

Figure 1-23 Common ID message
Signaling Analysis

1-22
III. MAP_OPEN_REQ
This message is used for establishing a Mobile Application Part (MAP) dialogue
between two MAP service-users. See Figure 1-24 for the detailed information of this
message.

Figure 1-24 MAP_OPEN_REQ message
Application context name: This parameter identifies the type of the application context
being established. If the dialogue is accepted, the received application context name
shall be echoed.In case of refusal of dialogue, this parameter shall indicate the
highest version supported.
Destination address: A valid Signaling Connection Control Part (SCCP) address
identifying the destination peer entity.
IV. MAP_UPDATE_LOCATION_REQ
This message is used by the visited location register (VLR) for updating the location
information stored in the home location register (HLR). See Figure 1-25 for the
detailed information of this message.
Signaling Analysis

1-23

Figure 1-25 MAP_UPDATE_LOCATION_REQ message
imsi: IMSI number.
Msc Number: mobile switching center (MSC) number.
Vlr Number: VLR number.
V. MAP_DELIMITER_REQ
This message is used to explicitly request the transfer of the MAP protocol data units
to the peer entities. See Figure 1-26 for the detailed information of this message.
Signaling Analysis

1-24

Figure 1-26 MAP_DELIMITER_REQ message
VI. MAP_OPEN_CNF
This message is used for establishing a Mobile Application Part (MAP) dialogue
between two MAP service-users. See Figure 1-27 for the detailed information of this
message.
Signaling Analysis

1-25

Figure 1-27 MAP_OPEN_CNF message
Result: This parameter indicates whether the peer entity accepts the dialog.
VII. MAP_INSERT_SUBSCRIBER_DATA_IND
This message is used by an HLR to update a VLR with certain subscriber data when
subscriber data changes. See Figure 1-28 for the detailed information of this
message.
Signaling Analysis

1-26

Figure 1-28 MAP_INSERT_SUBSCRIBER_DATA_IND message
VIII. MAP_INSERT_SUBSCRIBER_DATA_RSP
This message is sent by the VLR as response to the
MAP_INSERT_SUBSCRIBER_DATA_IND message. See Figure 1-29 for the detailed
Signaling Analysis

1-27

Figure 1-29 MAP_INSERT_SUBSCRIBER_DATA_RSP message
IX. MAP_UPDATE_LOCATION_CNF
This message is sent by the HLR to confirm the location update requrest intiated by
the VLR. See Figure 1-30 for the detailed information of this message.
Signaling Analysis

1-28

Figure 1-30 MAP_UPDATE_LOCATION_CNF message
X. RN_MM_LOCATION_UPDATING_ACCEPT
IMSI attach in the network has been completed. See Figure 1-31 for the detailed
Signaling Analysis

1-29

Figure 1-31 RN_MM_LOCATION_UPDATING_ACCEPT message
system.
Signaling Analysis

1-30
1.4.4 Normal Updating Failure Procedure

Figure 1-32 Normal updating failure procedure
1.4.5 Interface Tracing Example of Normal Updating Failure

Figure 1-33 Main tracing messages of normal updating failure
1.4.6 Main Tracing Messages of Normal Updating
I. RN_MM_LOCATION_UPDATION_REJECT
IMSI attach has failed. See Figure 1-34 for the detailed information of this message.
Signaling Analysis

1-31

Figure 1-34 RN_MM_LOCATION_UPDATION_REJECT message
Reject cause: This parameter indicates the cause for rejecting the location update
request.

Signaling Analysis
Chapter 2 Analysis of Relocation Signaling

2-1
2.1 Overview of Relocation Signaling
2.1.1 Relocation Procedure

Figure 2-1 Relocation procedure
2.1.2 Interface Tracing Example of Relocation

Figure 2-2 Main relocation messages
Signaling Analysis

2-2
2.1.3 Key Messages of Relocation
I. RELOCATION_REQUIRED
This message is sent by the source RNC to inform the core network that a relocation
is to be performed. See Figure 2-3 for the detailed information of this message.

Figure 2-3 RELOCATION_REQUIRED message
Cause: This information element indicates the cause for sending this message.
sourceRNC ID: This information element indicates the identifier of the source RNC.
targetRNC ID: This information element indicates the identifier of the target RNC.
II. RELOCATION_REQUEST
This message is sent by the core network to request the target RNC to allocate
necessary resources for a relocation. See Figure 2-4 for the detailed information of
this message.
Signaling Analysis

2-3

Figure 2-4 RELOCATION_REQUEST message
III. RELOCATION_REQUEST_ACKNOWLEDGE
This message is sent by the target RNC to inform the core network about the result of
the resource allocation for the requested relocation. See Figure 2-5 for the detailed
Signaling Analysis

2-4

Figure 2-5 RELOCATION_REQUEST_ACKNOWLEDGE message
IV. RELOCATION_COMMAND
This message is sent by the core network to the source RNC to inform that resources
for the relocation are allocated in target RNC. See Figure 2-6 for the detailed

Figure 2-6 RELOCATION_COMMAND message
Signaling Analysis

2-5
V. RELOCATION_DETECT
This message is sent by the target RNC to inform the core network that the relocation
execution trigger has been received. See Figure 2-7 for the detailed information of
this message.

Figure 2-7 RELOCATION_DETECT message
VI. RELOCATION_COMPLETE
This message is sent by the target RNC to inform the core network that the relocation
is completed. See Figure 2-8 for the detailed information of this message.
Signaling Analysis

2-6

Figure 2-8 RELOCATION_COMPLETE message
2.1.4 Relocation Failure Messages
The following is a relocation failure procedure:

Figure 2-9 Relocation failure procedure
Signaling Analysis

2-7
2.1.5 Interface Tracing Example of Relocation Failure

Figure 2-10 Relocation failure messages Traced
2.1.6 Key Messages of Relocation Failure
I. RELOCATION_CANCEL
This message is sent by the source RNC to the core network to cancel an ongoing
relocation.

Figure 2-11 RELOCATION_CANCEL message
user connect id: This information element indicates the direction of a connection.
Signaling Analysis

2-8
II. RELOCATION_CANCEL_ACKNOWLEDGE
This message is sent by the core network to inform the source RNC that the
relocation has been cancelled.

Figure 2-12 RELOCATION_CANCEL_ACKNOWLEDGE message
Signaling Analysis
Chapter 3 Analysis of Call Signaling

3-1
3.1 Intra-Office Calls
3.1.1 Intra-Office Call Procedure
The following procedure introduces the messages traced at the caller side.

Figure 3-1 Intra-office call procedure (at the caller side)
Signaling Analysis

3-2
3.1.2 Interface Tracing Example of Intra-Office Call

Figure 3-2 Intra-office call messages (at the caller side)
3.1.3 Key Messages of Intra-Office Call
I. RN_MM_CM_SERVICE_REQUEST
This message is sent by the mobile station to the network to request a service for the
connection management sub-layer entities, for example, circuit switched connection
establishment, supplementary services activation, short message transfer, and
location services. See Figure 3-3 for the detailed information of this message.

Signaling Analysis

3-3

Figure 3-3 RN_MM_CM_SERVICE_REQUEST message
mm msg type: This information element indicates the type of the connection
management (CM) service request message.
CM service type: This information element indicates the type of the CM service.
II. RN_CC_SETUP
This message is sent by the network to the mobile station to initiate a mobile
terminated call establishment. See Figure 3-4 for the detailed information of this
message.
Signaling Analysis

3-4

Figure 3-4 RN_CC_SETUP message
Transaction value: This information element indicates the value of the transaction.
Cm msg type: This information element indicates the type of the CM message.
III. MAP_SEND_ROUTINE_INFORMATION_REQ
The message is invoked by the gateway MSC (GMSC) to interrogate the HLR in
order to route a call to the called MS. See Figure 3-5 for the detailed information of
this message.

Signaling Analysis

3-5

Figure 3-5 MAP_SEND_ROUTINE_INFORMATION_REQ message
gmsc Address: This information element indicates the GMSC address.
Msisdn: This information element indicates the MSISDN number.
IV. RN_CC_CALL_PROCEEDING
This state exists for a mobile originating call when the mobile station has received
acknowledgement that the network has received all call information necessary to
effect call establishment. See Figure 3-6 for the detailed information of this message.

Signaling Analysis

3-6

Figure 3-6 RN_CC_CALL_PROCEEDING message
V. MAP_SEND_ROUTINE_INFORMATION_CNF
This message is used to confirm the MAP_SEND_ROUTINE_INFORMATION_REQ

Signaling Analysis

3-7

Figure 3-7 MAP_SEND_ROUTINE_INFORMATION_CNF message
imsi: This information element indicates the ISMI number.
VI. ADD_REQ
This message is a request sent by the media gateway controller (MGC) to the media
gateway (MGW) for adding a termination to a context. See Figure 3-8 for the detailed
Signaling Analysis

3-8

Figure 3-8 ADD_REQ message
address: This information element indicates the IP address of the termination.
transactionId: This information element indicates the identifier of the transaction.
VII. ADD_REPLY
This message is a response to the ADD_REQ message. See Figure 3-9 for the
Signaling Analysis

3-9

Figure 3-9 ADD_REPLY message
VIII. RN_RAB_ASSIGNMENT_REQUEST
This message is sent by the core network to request the establishment, modification
or release of one or more radio access bearers (RABs) for the same UE. This
message is a request for RAB assignment. See Figure 3-10 for the detailed

Signaling Analysis

3-10

Figure 3-10 RN_RAB_ASSIGNMENT_REQUEST message
IX. NTFY_REQ
This message is a request for reporting the events occurring in the MGW to the MGC.
See Figure 3-11 for the detailed information of this message.

Figure 3-11 NTFY_REQ message
Signaling Analysis

3-11
X. NTFY_REPLY
This message is a response to the NTFY_REQ message. See Figure 3-12 for the

Figure 3-12 NTFY_REPLY message
XI. RN_RAB_ASSIGNMENT_RESPONSE
This message is sent by the RNC to report the outcome of the request from the RAB
ASSIGNMENT REQUEST message. See Figure 3-13 for the detailed information of
this message.

Signaling Analysis

3-12

Figure 3-13 RN_RAB_ASSIGNMENT_RESPONSE message
XII. RN_CC_ALERTING
This message is sent by the network to the calling mobile station to indicate that the
called subscriber alerting has been initiated. See Figure 3-14 for the detailed

Signaling Analysis

3-13

Figure 3-14 RN_CC_ALERTING message
XIII. MOD_REQ
This message is a request for modifying a termination. See Figure 3-15 for the
Signaling Analysis

3-14

Figure 3-15 MOD_REQ message
XIV. RN_CC_CONNECT
This message is sent by the network to the calling mobile station to indicate call
acceptance by the called subscriber. See Figure 3-16 for the detailed information of
this message.

Figure 3-16 RN_CC_CONNECT message
Signaling Analysis

3-15
cm message type: This information element indicates the type of the CM message.
XV. MOD_REPLY
This message is a response to the MOD_REQ message. See Figure 3-17 for the

Figure 3-17 MOD_REPLY message
XVI. RN_CC_CONNECT_ACKNOWLEDGE
This message is sent by the network to the called mobile station to indicate that the
mobile station has been awarded the call. It shall also be sent by the calling mobile
station to the network to acknowledge the offered connection. See Figure 3-18 for the
Signaling Analysis

3-16

Figure 3-18 RN_CC_CONNECT_ACKNOWLEDGE message
XVII. RN_CC_DISCONNECT
This message is sent by the network to indicate that the end-to-end connection is
cleared. See Figure 3-19 for the detailed information of this message.
Signaling Analysis

3-17

Figure 3-19 RN_CC_DISCONNECT message
XVIII. RN_CC_RELEASE
This message is sent from the network to the mobile station to indicate that the
network intends to release the transaction identifier, and that the receiving equipment
shall release the transaction identifier after sending RELEASE COMPLETE. See
Figure 3-20 for the detailed information of this message.
Signaling Analysis

3-18

Figure 3-20 RN_CC_RELEASE message
XIX. RN_CC_RELEASE_COMPLETE
This message is sent from the network to the mobile station to indicate that the
network has released the transaction identifier and that the mobile station shall
release the transaction identifier. See Figure 3-21 for the detailed information of this
message.
Signaling Analysis

3-19

Figure 3-21 RN_CC_RELEASE_COMPLETE message
XX. SUB_REQ
This message is a request for deleting the connection between a termination and a
context. See Figure 3-22 for the detailed information of this message.
Signaling Analysis

3-20

Figure 3-22 SUB_REQ message
XXI. SUB_REPLY
This message is a response to the SUB_REQ message. See Figure 3-23 for the

Figure 3-23 SUB_REPLY message
Signaling Analysis

3-21
3.1.4 Call Failure Procedure
Suppose the called number does not exist.

Figure 3-24 Procedure of call failure due to non-existence of the called number
Signaling Analysis

3-22
3.1.5 Call Failure Messages Traced

Figure 3-25 Call failure messages generated due to non-existence of the called number
Signaling Analysis
Chapter 4 Analysis of Iu Interface Protocol

4-1
4.1 Overview
In typical UMTS R4 networking of 3GPP, as for Iu interface, MGW implements the
function of negotiation with user plane. The basis procedure is as shown in Figure 4-1.
T
r
a
n
s
i
t
N
e
t
w
o
r
k
RNC
MSC
Server
MGW
MSC
Server
MGW
RNC
RANAP
RANAP
MGW
Control
OoB Codec
Negotiation
Control
Plane
User
Plane
Radio
Bearer
Iu Bearer
CN
bearer Iu Bearer Radio Bearer
End to end connection
Bearer
Req
UE UE
Bearer
Req
Bearer
Req
MGW
Control
OoB Codec
Negotiation
OoB Codec
Negotiation

Figure 4-1 Typical UMTS R4 networking
Bearer is established by interaction between MGW and RNC through Q.AAL2 protocol
and user plane negotiation is implemented over Iu UP protocol. Q.AAL2 and lu UP
protocols are closely associated with services and the key to understand mobile service
processing of MGW and locate Iu interface problems.
4.2 Q.AAL2 Protocol Application
AAL2 signaling system mainly implements the following functions: establish and
release AAL2 connection between two AAL2 signaling nodes; maintain and manage
path and channel resources within the signaling system.
At service subscriber module (CMU) requests, related nodes in AAL2 signaling network
exchange signaling messages to establish and release AAL2 connection. Maintenance
and management function is activated based on indication of maintenance console or
Signaling Analysis

4-2
by system due to detected faults. And the function must be implemented in conjunction
with two adjacent nodes of managed objects such as path and channel.
At Iu interface, RNC initiates Q.AAL2 establishment, while both RNC and MGW can
initiate release.
Entities of Q.AAL2 protocol use primitives such as ERQ, ECF, REL, RLC, RES, RSC,
BLC, and UBL to interact.
The following introduces some basic interaction and common errors.
4.2.1 The process of Normal Establishment
The process of normal establishment is as shown in Figure 4-2:
RNC QAAL2
ERQ
EST.RSP
Timer_ERQ
EST.IND
ECF
Service Subscriber
Module (CMU)

Figure 4-2 The process of normal establishment
When MS originates a call, RNC sends a Q.AAL2 establishment request to MGW upon
receiving a RAB assignment request.
Upon receiving an establishment request, the Q.AAL2 module of MGW allocates AAL2
resources. In the event of successful allocation, the Q.AAL2 module of MGW sends
establishment indication to service subscriber module (CMU) to facilitate allocating call
handling and control resources.
If the Q.AAL2 module receives an establishment response from service subscriber
module (CMU) before timer_ERQ expires, the Q.AAL2 module sends an
acknowledgement message to RNC. Then bearer is established.
4.2.2 Establishment Failure
I. Failure of Resource Allocation
Failure of AAL2 resource allocation results in establishment failure. The process is as
Signaling Analysis

4-3
RNC QAAL2
ERQ
RLC
Service Subscriber
Module (CMU)

Figure 4-3 The process of Failure of Resource Allocation
After receiving a RNC establishment request, the Q.AAL2 module sends a release
ackowledgement message to RNC in the case of failed AAL2 resource allocation. The
call fails.
Causes of AAL2 resource allocation failure involves the following: unvailable physical
ports corresponding to PATH; insufficient remaining bandwidth of PVC corresponding
to PATH; insufficicent users supported by VMGW.
II. Fails in Processing Resource
Failure in processing resources results in establishment failure. The process is as
RNC
QAAL2
ERQ
REL.RSP
Timer_ERQ
EST.IND
RLC
Service Subscriber
Module (CMU)

Figure 4-4 The process of Fails in Processing Resource
After receiving a RNC establishment request message, the Q.AAL2 module of MGW
sends establishment indication to service subscriber module (CMU) in the case of
sucessful AAL2 resource allocation.
If service subscriber module (CMU) fails in processing resources, it sends back a
release response and Q.AAL2 sends a release acknowledgement message to RNC,
and the call fails.
Signaling Analysis

4-4
Common faults of service subscriber module (CMU) involve the following: insufficient
call control resources; session control resource timeout; and failure of AAL2 resource
occupation.
III. Timer_ERQ Expires
Timer_ERQ expiring results in establishment failure. The process is as shown in Figure
4-5.
RNC QAAL2
ERQ
Timer_ERQ
EST.IND
RLC
Service Subscriber
Module (CMU)

Figure 4-5 The process of Timer_ERQ Expiring
After receiving a RNC establishment request, the Q.AAL2 module of MGW sends
establisment indication to the service subscriber module (CMU) in the case of
successful AAL2 resource allocation.
During resource processing, if service subscriber module (CMU) does not send a
response before timer_ERQ expires, the Q.AAL2 module sends a release
acknowledgement message to RNC, and the call fails.
Common causes for service subscriber module (CMU) expiry involve the following:
insufficient voice handling resources; and internal communication timeout.
4.2.3 Normal Release
The process or normal release is as shown in Figure 4-6.
Signaling Analysis

4-5
RNC Q.AAL2
REL
RLC
Timer_REL
REL
RLC
Service Subscriber
Module (CMU)

Figure 4-6 The process or normal release
After MS subscriber hooks on, RNC sends a release request of Q.AAL2 module to
MGW and QAAL2 module of MGW informs the service subscriber module (CMU) of
call resource release. Then QAAL2 module of MGW returns a RLC.
4.2.4 Example of Q.AAL2 Trace
Example of Q.AAL2 trace during normal call and release is as shown in Figure 4-7.

Figure 4-7 The process Q.AAL2 trace during normal call and release
4.2.5 Examples of Important Messages of Q.AAL2
I. ERQ message
ERQ is to establish request messages. Give prime concern to ceid, osaid, nsap,
alc, and sugr.
These messages will determine successful connection of AAL2. While failure occurs, it
is necessary to analyze if these messages are properly input.
ERQ message format is as shown in Figure 4-8.
Signaling Analysis

4-6

Figure 4-8 ERQ message format
II. ECF message
ECF is to establish acknowledgement messages. Give prime concern to osaid.
ECF message indicates successful establishment. The information of message is only
used to analyze the event later.
ECF message format is as shown in Figure 4-9.
Signaling Analysis

4-7

Figure 4-9 ECF message format
III. REL message
REL is to release message. Give prime concern to cause.
In the case of abnormal release, you can locate causes through cause values of
several protocol standards.
REL message format is as shown in Figure 4-10.
Signaling Analysis

4-8

Figure 4-10 REL message format
IV. RLC message
RLC is release acknowledgement message. Give prime concern to cause.
In the case of release acknowledgement, cause is meaningless. When connection is
established and multimedia gateway replies a RLC to peer RNC in the case of receiving
ERQ, cause records cause values.
When Q.AAL2 establishment of Iu interface fails, you shall check RLC message.
RLC message format is as shown in Figure 4-11.

Figure 4-11 RLC message format
Signaling Analysis

4-9
4.3 Iu UP Application
Used at user plane of radio network layer at lu interface, namely lu UP protocol layer, lu
UP is applied to transmit user data related to RAB.
One lu UP protocol instance is only associated with one RAB. For a designated UE, the
number of lu UP instances used by RAB is identical to that of one RAB.
As shown in Figure 4-12. Iu UP instances exist between CN and UTRAN, namely at lu
access point. When RAB sends user data at lu UP layer, instances of lu UP protocol
exist at each access point of lu interface. And these instances are established,
re-located, and released together with related RAB.
UTRAN
UE CN
Access Stratum
Non-Access Stratum
Radio
(Uu)
Iu
Iu UP
Radio
Iu UP
User plane
Data
Bearers
protocols
Transport
Layer
NAS Data
Stream
Radio
User plane
Data
Bearers
protocols
NAS Data
Stream
protocols
protocols

Figure 4-12 Up protocol in UTRAN architecture
4.3.2 Major Functions of Iu UP
Iu UP involves transparency and support modes. In the transparency mode, lu UP only
supports transparent transmission of user data. While in the support mode, lu UP must
support initialization, rate control, time alignment, error event processing, and frame
quality classification. Initialization must proceed during RAB assignment, so
unsuccessful UP initialization process during voice calls shall occur. And you can trace
initialization messages in MGW.
The process of successful initialization is as shown in Figure 4-13. The process of
unsuccessful initialization is as shown in Figure 4-14.
Signaling Analysis

4-10
*
Transfer Of User Data
CN/
RNC
Initialization
2)
])m)
Initialization ACK
* It can be repeated n times
2) optional
RNC/
CN

Figure 4-13 Successful initialization
(2)
(1)
*
CN
RNC
Initialization
2)
])m)
Initialization NACK
* after n repetitions
2) optional
(1) Negative ACKnowledgement
(2) Acknowledgement timeout

Figure 4-14 Unsuccessful initialization
Common causes of failed initialization lie in the following:
RFCI set configured in MGW do not contain RFCI set of RNC.
UP version of MGW is not compatible with that of RNC.
RFCI number carried with a call exceeds 10.
Common causes for initialisation timeout lie in the following:
AAL2 path of lu interface is not established correctly.
Incorrect Cyclic Redundancy Check (CRC) of initial messages.
4.3.3 Example of lu UP Trace in Voice Call
Example of lu UP trace in voice call is as shown in Figure 4-15.
Signaling Analysis

4-11

Figure 4-15 Example of lu UP Trace in Voice Call
4.4 Basic Signaling Procedure at Iu Interface
The interaction process between MGW and RNC at Iu interface is listed in the
following:
1) User originates a call and Q.AAL2 is established.
2) UP is initialized.
3) User hooks on and Q.AAL2 is released.
Compared with UP support mode, UP initialization is absent in transparency mode.
Typical services in support mode involve voice and non-transparent data services. And
typical services in transparency mode include VP (H324M) and transparent data
services.
4.4.2 Voice Call Establishment and Release
Voice call establishment and release processes are shown in Figure 4-16:
RNC
QAAL2
ERQ
EST.RSP
Service subscriber
module (CMU)
EST.IND
ECF
INIT
UP
Establish UP
instance
INIT ACK
REL
REL.RSP
REL.IND
RLC
Release UP
instance

Figure 4-16 Voice Call Establishment and Release
Signaling Analysis

4-12
4.4.3 VP Call Establishment and Release
VP call establishment and release processes are shown in Figure 4-17:
RNC QAAL2
ERQ
EST.RSP
Service subscriber
module (CMU)
EST.IND
ECF
UP
Establish UP
instance
REL
REL.RSP
REL.IND
RLC
Release UP
instance

Figure 4-17 VP Call Establishment and Release
4.4.4 Examples of Iu UP Important Messages
I. Initialization request message
Give prime concern to modVer, RFCs, and modeVerSupp. Inconsistency of them
at MGW and RNC shall lead to initialization failure.
Initialization request message is as shown in Figure 4-18.
Signaling Analysis

4-13

Figure 4-18 Initialization request message
II. Initialization acknowledgement message
Give prime concern to ackNack whose value is ack in the case of successful
initialization and nack in the case of initialization failure.
Initialization acknowledgement message is as shown in Figure 4-19 and Figure 4-20.
Signaling Analysis

4-14

Figure 4-19 Success in Initialization acknowledgement message

Figure 4-20 Failure in Initialization acknowledgement message
4.5 Case Analysis of Iu Interface Fault
4.5.1 Overview
Call failure is the common service problem at Iu interface. In some cases, you can
locate causes through traced messages of Q.AAL2 and Iu UP interface in
conjunction with Mc interface trace, internal interface trace and configuration
query.
Signaling Analysis

4-15
4.5.2 Unsuccessful Q.AAL2 Signaling Establishment
I. Symptom
An intra-VMSC call originated by a MS subscriber fails before the called party answers
the call. You can find that MGW replies RLC after receiving ERQ through tracing
Q.AAL2 interface messages, as shown in Figure 4-21.

Figure 4-21 Unsuccessful Q.AAL2 Signaling Establishment
II. Handling process
1) Check cause of RLC. The cause is temporary failure. You must draw a
conclusion through specific analysis.

Figure 4-22 Check cause of RLC
2) As shown in Figure 4-23, Open the ERQ message and analyze important
information and probable errors.
Signaling Analysis

4-16

Figure 4-23 Check ERQ message
path identifier in ceid is 1, which indicates PATH ID used by RNC is 1. Check MGW
configuration. PATH with ID of 1 is available and correct.
nsap value is 09 08 09 08 09 08 09 08 09 08 09 08 09 08 09 08 09 08 09 07. Check
configuration of adjacent nodes in MGW. Addresses are identical and correct.
Bi-directional rates and packet sizes in alc are correct. Check PVC flow configuration
in MGW. Remaining bandwidth is sufficient and correct.
sugr value is 080011. The highest byte is 0, corresponding to VMGW ID in MGW.
The second highest byte is 8, corresponding to CMU board number of MGW. These
Signaling Analysis

4-17
two values are correct. Then query ATM resource number in ASU board by executing
LST AAL2VMGW. Resource number corresponding to No.0 VMGW is 0. In this case,
ATM resources cannot be allocated in No. 0 VMGW. The causes for unsuccessful
subscriber call and Q.AAL2 signaling establishment lie in here.
LST AAL2VMGW: BN=0, VMGWID=0;
RETCODE = 0 Successful execution
Query VMGW information
--------------------
Board number VMGW number maximum user number
0 0 0
(Result = 1)
END
3) Modify configuration. Set user number of No.0 VMGW by executing SET
AAL2VMGW to 12000. Re-call succeeds.
III. Cause location of similar problems
1) Check RLC bit error. For error code, locate cause of bit error with a unique cause
and probable causes of common bit errors.
2) Analyze ERQ messages and exclude incorrect RNC messages and configuration.
3) Query MGW data configuration and troubleshoot errors.
4.5.3 Unsuccessful Iu UP Initialization
I. Symptom description
An intra-VMSC call originated by a MS subscriber fails before the called party answers
the call. Trace QAAL2 interface messages and find no error. Trace Iu UP interface
messages and find that negotiation fails because MGW replies NACK directly after
receiving an initialization request, as shown in Figure 4-24.

Figure 4-24 Unsuccessful Iu UP Initialization
Signaling Analysis

4-18
II. Handling process
1) As shown in Figure 4-25. Check the cause value of NACK message. If the cause
value is initialization failure, RFCI negotiation fails.

Figure 4-25 Check the cause value of NACK message
2) As shown in Figure 4-26, open Initialization request message to analyze RFCI
set. RFCI set carries three RFCs and each RFC three subflows. According to
subflow length, the rates of three RFCs are 12.2 K, 0, and mute frame, which are
correct AMRs.
Signaling Analysis

4-19

Figure 4-26 Check Initialization request message
3) Check RFC configuration of MGW by executing LST RFCI. RFCI numbers
corresponding to 12.2K and mute frame are 7 and 8 respectively. The RFCI is
valid. However, RFCI number corresponding to 0 is 63. The RFCI is invalid.
Therefore, RNC with the rate of 0 cannot be matched in MGW, so initialization
fails.
LST RFCI:;
RETCODE = 0 Successful execution
RFCI set
------
Rfci number Sending interval (ms) coding/decoding RFC length frame
type subflow number subflow 1 subflow 2 subflow 3 subflow
Signaling Analysis

4-20
4 subflow 5 subflow 6
7 20 0 244 7 3 81 103 60 0 0 0
0 20 0 95 0 2 42 53 0 0 0 0
1 20 0 103 1 2 49 54 0 0 0 0
2 20 0 118 2 2 55 63 0 0 0 0
3 20 0 134 3 2 58 76 0 0 0 0
4 20 0 148 4 2 61 87 0 0 0 0
5 20 0 159 5 2 75 84 0 0 0 0
6 20 0 204 6 3 65 99 40 0 0 0
8 20 0 39 8 3 39 0 0 0 0 0
63 20 0 0 15 3 0 0 0 0 0 0
16 5 0 320 16 1 320 0 0 0 0 0
17 10 0 640 17 1 640 0 0 0 0 0
18 20 0 576 18 1 576 0 0 0 0 0
19 20 0 672 19 1 672 0 0 0 0 0
20 40 0 576 20 1 576 0 0 0 0 0
(Result = 15)
RFCI set (continuation)
--------
Rfci number subflow 7
7 0
0 0
1 0
2 0
3 0
4 0
5 0
6 0
8 0
63 0
16 0
17 0
18 0
19 0
20 0
(Result = 15)
END
4) Modify RFCI number corresponding to 0 to 9 by executing SET RFCI in MGW.
Re-call succeeds.
Signaling Analysis

4-21
III. Cause location
1) You can locate causes of initialization NACK bit error of Iu UP. Causes include:
failed initialization; incorrect CRC; frame number mismatch; and incorrect version.
2) Check initialization messages based on bit errors. For failed initialization, you
must check the consistency between messages and MGW configuration. For
incorrect version, you must check traced messages of Mc interface to determine
whether the version delivered by MSC Server is compatible with that by RNC.

HUAWEI UMTS Circuit-Switched Core Network Appendix A Abbreviations

A-1
Appendix A Abbreviations
Abbreviation Full name
3
3GPP 3
rd
Generation Partnership Project
3PTY Three-Party service
A
AAL ATM Adaptation Layer
AAL1 ATM Adaptation Layer Type 1
AAL2 ATM Adaptation Layer type 2
AAL5 ATM Adaptation Layer type 5
ACK ACKnowledgement
ACM Address Complete Message
AG Access Gateway
ALCAP Access Link Control Application Part
ANM Answer Message
AoC Advice of Charge
APM APplication transport Mechanism
ASE Application Service Element
ASN.1 Abstract Syntax Notation One
ATM Asynchronous Transfer Mode
B
BC Bearer Control
BCF Bearer Control Function
BCSM Basic Call State Module
BER Bit Error Rate
BIB Backward Indicator Bit
BICC Bearer Independent Call Control
B-ISUP Broadband ISDN User Part
BLA Block Acknowledge signal
BLO Blocking signal
BNC Backbone Network Connection

A-2
BNCL Backbone Network Connection Link
BSC Base Station Controller
BSN Backward Sequence Number
BSS Base Station Subsystem;
BSSAP Base Station Subsystem Application Part
BSSMAP Base Station Subsystem Management Application Part
C
CAI Charge Advice Information
CAMEL Customized Applications for Mobile network Enhanced Logic
CAP CAMEL Application Part; Amplitude Phase modulation
CC Connection Confirm
CCR Continuity Check Request
CFB Call Forwarding Busy
CFN Connection Frame Number
CFNRC Call Forwarding on mobile subscriber Not Reachable
CFNRY Call Forwarding No Reply
CFU Call Forwarding Unconditional
CGB Circuit Group Blocking
CGBA Circuit Group Blocking ACK
CGI Cell Global Identification
CGU Circuit Group Unblocking
CGUA Circuit Group Unblocking ACK
CIC Circuit Identification Code
Call Instance Code
CLIP Calling Line Identification Presentation
CLIR Calling Line Identification Restriction
CM Call Management
CMD Command
CMN Call Mediation Node
CN Core Network
COLP COnnected Line Identification Presentation
COLR COnnected Line Identification Restriction
CPG Call Progress

A-3
CR Connection Request
CREF Connection REFused
CRG Customized RinGing
CS Circuit switched
CSF Call Service Function
CUG Closed User Group
CW Call Waiting
D
DCCH Dedicated Control CHannel
DDI Direct-Dialing-In
DP Detection Point
DPC Destination (Signaling)Point Code
DTAP Direct Transfer Application Part
DTMF Dual Tone Multi Frequency
DUP Date User Part
E
EC Echo Cancellation
ECT Explicit Call Transfer
ED Expedited Data
EDP Event Detection Point
F
FAA FAcility Accepted
FAC Facilities
FACCH Fast Associated Control Channel
FISU Fill-In Signal Unit
FOT FOrward-Transfer signal
FRJ Facility ReJect
FSN Frame Switching Network Board
G
GMLC Gateway Mobile Location Center
GMSC Gateway Mobile Switching Center
GPRS General Packet Radio Service

A-4
GSM Global System for Mobile Communications
gsmSCF GSM Service Control Function
gsmSRF GSM Specialized Resource Function
gsmSSF GSM Service Switching Function
GSN Gateway Serving Node
GT Global Title
GVNS Global Virtual Network Services
H
HLR Home Location Register
HOLD Call Hold
I
IAM Initial Address Message
ID IDentification/IDentity
IDP Individual Development Plan
IDS Informix Dynamic Server
IETF Internet Engineering Task Force
IF Information Frame
IMSI International Mobile Subscriber Identity
INAP Intelligent Network Application Protocol
INR Information Request
IP Internet Protocol
ISDN Integrated Services Digital Network
ISUP ISDN User Part
ITU International telecommunications union
ITU-T International Telecommunication Union - Telecommunication
Standardization Sector
IWF InterWorking Function
L
LA Location Area
LAI Location Area Identity
LCS Location Services
LM Layer Management
M

A-5
M2PA MTP2 Peer Adaptation Layer
M2UA SS7 MTP2-User Adaptation Layer
M3UA SS7 MTP3-User Adaptation Layer
MAC Media Access Control
MAP Mobile Application Part
MCF Message Communication Function
MEGACO Media Gateway Control
MG, MGW Media Gateway
MGC Media Gateway Controller
MGCP Media Gateway Control Protocol
MID Message Identification
MM Mobility Management
MPTY Multiparty Service
MS Mobile Station
MSB MSC Basic Configuration
MSC Mobile Service Switching Center
MSISDN Mobile Station International ISDN Number
MTC Mobile Terminated Call
MTP Message Transfer Part
MTP3b Message transfer part (broadband)
N
NGN Next Generation Network
NMS Network Management System
NSS Network SubSystem
O
OAM Operation Administration and Maintenance
O-CSI Originating CAMEL Subscription Information
OMAP Operation and Maintenance Application Part
OMC Operation and Maintenance Center
OPC Originating signaling Point Code
OSI Open Systems Interconnection
P

A-6
PDU Protocol Data Unit
PLMN Public Land Mobile Network
PS Packet Switched
PSTN Public Switched Telephone Network
PVC Permanent Virtual Channel
R
RACH Random Access CHannel
RAN Radio Access Network
RANAP Radio Access Network Application Part
REL RELease
REQ REQuest
RES Resume
RFC Request for Comments
RLC Radio Link Control
RNC Radio Network Controller
RNS Radio network sub-system
S
SAAL Signaling ATM Adaptation Layer
SAAL-NNI Signaling ATM adaptation layer for network to network interfaces
SCCP Signaling Connection Control Part
SCP Service Control Point
SCTP Stream Control Transmission Protocol
SDCCH Stand-alone Dedicated Control Channel
SDP Session description protocol
SDU Service data unit
SG Signaling Gateway
SGSN Serving GPRS Support Node
SI Service Indicator
SIF Signaling Information Field
SIO Service Information Octet
SLC Signaling Link Code
SLS Signaling Link Selection Code
SMC Short Message Center (used for SMS)

A-7
SMS Short Message Service
SN Service Node
SS7 Signaling System No.7
SSF Service Switching Function; Sub-Service Field
SSN SubSystem Number
SSP Service Switching Point
STP Signaling Transfer Point
T
TC Transcoder
TCAP Transaction Capabilities Application Part
TCH Traffic CHannel
TCP Transmission Control Protocol
TDM Time Division Multiplexing
TE Terminal Equipment
TFO Tandem Free Operation
TMG Trunk Media Gateway
TMSI Temporary Mobile Subscriber Identifier
TS Technical specification
TUP Telephone User Part
U
UDT Unit DaTa
UDTS Unit DaTa Service
UE User Equipment
UMTS Universal Mobile Telecommunications System
UNI User Network Interface
UP User Plane
UTRAN UMTS Terrestrial Radio Access Network
V
V5UA V5 User Adaptation Layer
VLR Visitor Location Register
VMSC Visited Mobile Switching Center, Visited MSC
VPN Virtual Private Network

A-8
W
WCDMA Wide(band) Code Division Multiple Access

UMTS CS Protocols and Signaling Analysis

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

UMTS CS Protocols and Signaling Analysis

Uploaded by

Copyright:

Available Formats

Part 1 Overview

Table of Contents i .........................................................................................

Mandatory parameter with fixed length

You might also like