MSOFTX3000 V200R010C10 Typical Signaling Flows User Manual 01 PDF

Typical Signaling Flows User Manual
This function can be used to quickly locate and resolve problems. Normally there is no way
to avoid that some user data such as International Mobile Subscriber Identity (IMSI) will be
used during the troubleshooting. However, this function provides an anonymous data
processing method.
You are obligated to take considerable measures, in compliance with the laws of the
countries concerned and the user privacy policies of your company, to ensure that the
personal data of users is fully protected.
Basic Services
Supplementary Services
Value-added Services
Mobility Management
Security Management
Subscriber Data Management
Handover Management
Appendix - Protocol Compliance
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
Basic Services
Voice Services
Short Message Services
Fax Services
Parent topic: Typical Signaling Flows User Manual
Voice Services
Voice services are classified as intra-MSC calls and inter-MSC calls.
Intra-MSC Calls
Inter-MSC Calls
Bearer Establishment and Release
Parent topic: Basic Services
Intra-MSC Calls
Intra-MSC calls refer to the calls that are made between two subscribers served by the
same MSC.
Intra-MSC calls can be divided into the following two types:
A 3G mobile subscriber calls another 3G mobile subscriber served by the same
MSC.
MSC.
NOTE:
A 2G mobile subscriber calls a 3G mobile subscriber served by the same MSC. This
scenario is similar to the preceding two, and thus it is not described.
Basic 3G Call Flow
Basic 2G Call Flow
Parent topic: Voice Services
Basic 3G Call Flow

Service Model
Signaling Flow
Description of the Signaling Flow
Description of Associated Measurement Entities
Service Model
MSC.
Early assignment is applied in the call.
After the conversation ends, the caller releases the call first.
Signaling Flow
Figure 1 shows the signaling flow of a normal 3G call.
Figure 1 Signaling flow of a normal 3G call
As shown in Figure 1, Px refers to the measurement point of the originating side and Qx
refers to the measurement point of the terminating side.
Caller:
P1, P2, P3, P4, P5, P6
Callee:
Q1, Q2, Q3, Q4, Q5
The signaling flow of an intra-MSC 3G call is as follows:
1. The originating UE (UE-O, RNC on the caller side) sends a connection
management (CM) service request message carrying the cell information, service
type, user ID, and authentication parameters about the UE-O to the MSC/VLR.
2. The MSC/VLR sends a COMMON ID message to the originating RNC (RNC-O).
3. The authentication and encryption flow is started on the caller side. In this
process, the MSC may need to obtain the authentication set from the
HLR/authentication center (AuC). For details, see 3G Authentication and
Encryption.
4. If the encryption process is not started after the authentication process ends, the
MSC/VLR sends a CM service accept message to notify the UE-O that the
service access request has been accepted. If the encryption process is started
after the authentication process ends, it indicates that the service access request
has been accepted by the MSC/VLR; thus, the MSC/VLR does not need to send
the CM service accept message, and the UE-O directly sends a Setup message
carrying the called number and the bearer capability of the UE-O to the
MSC/VLR.
5. Upon receipt of the data about the UE-O, the MSC/VLR determines whether the
call can continue based on the service type and the subscription data about the
UE-O. If the call can continue, the MSC/VLR returns a Call proceeding message
to the UE-O.
6. The MSC/VLR analyzes the called number, locates the HLR, and then sends a
MAP_SEND_ROUTING_INFORMATION_REQ message to the HLR.
7. The HLR queries the VLR serving the UE-T based on the international mobile
subscriber identity (IMSI) of the UE-T, and then sends a
MAP_PROVIDE_ROAMING_NUMBER_IND message to this VLR to request a
mobile station roaming number (MSRN).
8. The VLR allocates an MSRN for the UE-T, and then returns a
MAP_PROVIDE_ROAMING_NUMBER_RSP message carrying the MSRN to the

HLR.
9. The HLR sends a MAP_SEND_ROUTING_INFORMATION_CNF message
carrying the MSRN to the MSC/VLR serving the UE-O.
10. The MSC/VLR sends a PAGING message to the UE-T through the terminating
RNC (RNC-T), and waits for a paging response.
11. The bearer establishment flow on the caller side is started. For details, see
Bearer Establishment Flow (ATM-enabled Iu Interface).
12. If the paging is successful, the UE-T sends a PAGING RESPONSE message to
the RNC-T, which transparently forwards the message to the MSC/VLR.
13. The MSC/VLR sends a COMMON ID message to the RNC-T.
14. The authentication and encryption flow is started on the callee side, which is the
same as the flow on the caller side.
15. The MSC/VLR sends a Setup message to the UE-T to set up the call.
16. The UE-T responds with a CALL CONFIRMED message to accept the call.
17. The MSC/VLR establishes the user plane bearer on the callee side in the same
way as establishing the bearer on the caller side.
18. The callee is alerted and the UE-T sends an Alerting message to the MSC/VLR.
Upon receipt of the message, the MSC/VLR also sends an Alerting message to
the UE-O.
19. The MSC/VLR sends a MOD REQ message, instructing the MGW to play the
ringback tone.
20. The MGW returns a MOD REPLY message to the MSC/VLR and plays the
ringback tone.
21. The callee answers the call and the UE-T sends a Connect message to the
MSC/VLR.
22. Upon receipt of the Connect message, the MSC/VLR sends a MOD REQ
message, instructing the MGW to stop playing the ringback tone.
23. The MGW returns a MOD REPLY message to the MSC/VLR and stops playing
the ringback tone.
24. The MSC/VLR sends a Connect message to the UE-O.
25. The UE-O sends a Connect acknowledge message to the MSC/VLR. The
MSC/VLR transparently forwards this message to the UE-T. Then, the call is
established.
26. The caller and the callee start the conversation.

27. After a period of time, the UE-O starts the call release flow. For details, see
Bearer Release Flow (ATM-enabled Iu Interface).
Table 1 lists common measurement entities used on the originating side. Table 2 lists
common measurement entities used on the terminating side.
Table 1 Measurement points on the originating side
Measurement Point
Measurement Entity Measurement Unit
in Flowchart
Measurement Type
Call Attempts
UTRAN Subscriber
Originated Calls
MO try call times

(LAI)
Traffic Measurement
Global Components
For LAI
P2
Wrong Dialing Times
UTRAN Subscriber
Originated Calls
Total Traffic of the

Office
P3
SRI Requests
MSC Basic Services
MSC Basic Functions
MSRN Received
Times
MSC Basic Services
MSC Basic Functions
Call Attempts
Intra-MSC Calls
P1
P4
UTRAN Subscriber
Originated Calls
UTRAN Subscriber
Call Completion Times
Originated Calls
Wrong Dialing Times
P5
Call Completion Times Intra-MSC Calls

Answer Times
Answer Times
Answer Times
P6
MO response times
(LAI)
Average Call Setup
Time

Office
Total Traffic of
Office
Total Traffic of
Office
Total Traffic of
Office
Total Traffic of
Office
the
the
the
the
Traffic Measurement
Global Components
For LAI
UTRAN Subscriber
Originated Calls
Office
Intra-MSC Calls
Office
Traffic Measurement
Global Components
For LAI
UTRAN Subscriber
Originated Calls
Office
Table 2 Measurement points on the terminating side

Measurement Point
in Flowchart
Q1
Q2
Q3
Q4
Q5
Measurement Type
Paging Times
Successful Mobile
Terminated Calls
Call Processing
Number of First
Pagings to Iu
Interface
Paging
MSC Basic Services
Number of First
Pagings in Calls
Paging
MSC Basic Services
Paging Times
MSC Basic Services
MSC Basic Functions
LAI paging times (LAI)
Traffic Measurement
Global Components
For LAI
Paging Response
Times
Successful Mobile
Terminated Calls
Call Processing
Number of First
Paging Responses
from Iu Interface
Paging
MSC Basic Services
Number of Responses
to First Pagings in
Paging
Calls
MSC Basic Services
Paging Response
Times
MSC Basic Services
MSC Basic Functions
Paging response
times (LAI)
Traffic Measurement
Global Components
For LAI
3G TERMINATED
CALL_ATTEMPT
3G TERMINATED
ALERT
MO connect times
(LAI)
3G TERMINATED
ANSWER
MT response times
(LAI)
3G TERMINATED
CALL ESTABLISH
AVERAGE TIME
UTRAN Subscriber
Terminated Calls
UTRAN Subscriber
Terminated Calls
Traffic Measurement
For LAI
UTRAN Subscriber
Terminated Calls
Traffic Measurement
For LAI

Office
Office
UTRAN Subscriber
Terminated Calls

Office
Global Components
Office
Global Components
Parent topic: Intra-MSC Calls

Basic 2G Call Flow

Service Model
Signaling Flow
Service Model
MSC.
After the conversation ends, the caller releases the call first.
Signaling Flow
Figure 1 shows the signaling flow of a normal 2G call.
Figure 1 Intra-MSC call flow
Caller:
P1, P2, P3, P4, P5, P6, P7

Callee:
Q1, Q2, Q3, Q4, Q5
The signaling flow of an intra-MSC 2G call is as follows:
1. The MS-O (BSC on the caller side) sends a connection management (CM)
service request message carrying the cell information, service type, user ID, and
authentication parameters about the MS-O to the MSC.
2. The authentication and encryption flow is started on the caller side. In this
process, the MSC may need to obtain the authentication set from the
HLR/authentication center (AuC). For details, see 2G Authentication and
Encryption.
3. If the encryption process is not started after the authentication process ends, the
MSC/VLR sends a CM service accept message to notify the MS-O that the
service access request has been accepted. If the encryption process is started
after the authentication process ends, it indicates that the service access request
has been accepted by the MSC/VLR; thus, the MSC/VLR does not need to send
the CM service accept message, and the MS-O directly sends a Setup message
carrying the called number and the bearer capability of the MS-O to the
MSC/VLR.
4. Upon receipt of the data about the MS-O, the MSC/VLR determines whether the
call can continue based on the service type and the subscription data about the
MS-O. If the call can continue, the MSC/VLR returns a Call proceeding message
to the MS-O.
5. The MSC analyzes the called number, locates the HLR based on the called
number, and then sends a MAP_SEND_ROUTING_INFORMATION_REQ
message to the HLR.
6. The HLR queries the VLR serving the MS-T based on the international mobile
subscriber identity (IMSI) of the MS-T, and then sends a
MAP_PROVIDE_ROAMING_NUMBER_IND message to this VLR to request a
mobile station roaming number (MSRN).
7. The VLR allocates an MSRN for the MS-T, and then returns a
MAP_PROVIDE_ROAMING_NUMBER_RSP message carrying the MSRN to the
HLR.
8. The HLR sends a MAP_SEND_ROUTING_INFORMATION_CNF message
carrying the MSRN to the MSC/VLR serving the MS-O.
9. The MSC sends a PAGING message to the MS-T through the BSC-T, and waits
for a paging response.
10. The bearer establishment flow on the caller side is started. For details, see
Bearer Establishment Flow (TDM-enabled A Interface).
11. If the paging is successful, the MS-T sends a PAGING RESPONSE message to
the BSC-T, which transparently forwards the message to the MSC.
12. The authentication and encryption flow is started on the callee side, which is the
same as that flow on the caller side.
13. The MSC/VLR sends a Setup message to the MS-T to set up the call.
14. The MS-T responds with a CALL CONFIRMED message to accept the call.
15. The MSC/VLR establishes the user plane bearer on the callee side in the same
way as establishing the bearer on the caller side.
16. The callee is alerted and the MS-T sends an Alerting message to the MSC/VLR.
Upon receipt of the message, the MSC/VLR also sends an Alerting message to
the MS-O.
17. The MSC/VLR sends a MOD REQ message, instructing the MGW to play the
ringback tone.
ringback tone.
19. The callee answers the call and the MS-T sends a Connect message to the
MSC/VLR.
20. Upon receipt of the Connect message, the MSC/VLR sends a MOD REQ
message, instructing the MGW to stop playing the ringback tone.
the ringback tone.
22. The MSC/VLR sends a Connect message to the MS-O.
23. The MS-O sends a Connect acknowledge message to the MSC/VLR. The
MSC/VLR transparently forwards this message to the MS-T. Then, the call is
established.
25. After a period of time, the MS-O starts the call release flow. For details, see
Bearer Release Flow (TDM-enabled A Interface).
Measurement Point
in Flowchart
P1
Call Attempts
GSM Subscriber
Originated Calls
MO try call times

(LAI)
Traffic Measurement
Global Components
For LAI
Office
SRI Requests
MSC Basic Services
MSC Basic Functions
MSRN Received
Times
MSC Basic Services
MSC Basic Functions
Call Attempts
Intra-MSC Calls
Wrong Dialing Times
P3
Seizure Times
P4
GSM Subscriber
Originated Calls
GSM Subscriber
Originated Calls
Wrong Dialing Times

P6
P7

Office
GSM Subscriber
Originated Calls
Incoming Calls in
Mobile Office
Directions
P2
P5
Measurement Type
MO connect times
(LAI)
Traffic Measurement
For LAI
Incoming Calls in
Call Completion Times Mobile Office
Directions
GSM Subscriber
Call Attempts
Originated Calls
Bearer Traffic
Total Traffic of
Office
Total Traffic of
Office
Total Traffic of
Office
Total Traffic of
Office
the
the
the
the
Global Components
Bearer Traffic
Office
Office
Answer Times
Intra-MSC Calls
MO response times
(LAI)
Traffic Measurement
Global Components
For LAI
Incoming Calls in
Mobile Office
Bearer Traffic
Directions
Answer Times
Average Call Setup

Time
GSM Subscriber
Originated Calls

Office

Measurement Point
in Flowchart
Paging Times
Q1
Q2
Call Processing
Number of First
Paging
Pagings to A Interface
MSC Basic Services
Number of First
Pagings in Calls
Paging
MSC Basic Services
Paging Times
MSC Basic Services
MSC Basic Functions
Traffic Measurement
Global Components
For LAI
Paging Response
Times
Successful Mobile
Terminated Calls
Call Processing
Number of First
Paging Responses
from A Interface
Paging
MSC Basic Services
Number of Responses
to First Pagings in
Paging
Calls
MSC Basic Services
Paging Response
Times
MSC Basic Services
MSC Basic Functions
Paging response
times (LAI)
Traffic Measurement
Global Components
For LAI
2G TERMINATED
CALL ATTEMPT
GSM Subscriber
Terminated Calls
Outgoing Calls in
Mobile Office
Directions
GSM Subscriber
Terminated Calls
Traffic Measurement
For LAI
Outgoing Calls in
Mobile Office
Q3
Seizure Times
Q4
Successful Mobile
Terminated Calls
Measurement Type
3G TERMINATED
ALERT
2G TERMINATED
ALERT

Office
Bearer Traffic
Office
Global Components
Q5
Call Completion Times Directions
Bearer Traffic
2G TERMINATED
ANSWER
MT response times
(LAI)
GSM Subscriber
Terminated Calls
Traffic Measurement
For LAI
Outgoing Calls in
Mobile Office
Directions

Office
GSM Subscriber
Terminated Calls

Office
Answer Times
2G TERMINATED
CALL ESTABLISH
AVERAGE TIME
Parent topic: Intra-MSC Calls

Global Components
Bearer Traffic
Inter-MSC Calls
Inter-MSC calls refer to the calls that are made between two subscribers served by
different MSCs. The setup of an inter-MSC call requires the help of inter-MSC signaling and
trunk resources. Generally, ISDN user part (ISUP) or Bearer Independent Call Control
(BICC) is used as the inter-MSC signaling.
This topic describes the following scenarios when ISUP is used as the inter-MSC signaling:
MS -> UE
MS -> public switched telephone network (PSTN)
When BICC is used as the inter-MSC signaling, inter-MSC calls can be divided into the
following types by bearer establishment mode:
Calls established in forward fast mode
Calls established in forward slow mode
Calls established in backward slow mode
NOTE:
The bearer establishment modes are defined as follows:
Fast/slow: When an IAM message carries channel information, it indicates that the
fast bearer establishment mode is used; when an IAM message does not carry
any channel information, it indicates that the slow bearer establishment mode is
used.
Forward/backward: Assume that IP bearer is used between the MSC-O and the
MSC-T. If IP Bearer Control Protocol (IPBCP) Request (or the first packet) is sent
by the MSC-O, it indicates that the forward bearer establishment mode is used; if
IPBCP Request (or the first packet) is sent by the MSC-T, it indicates that the
backward bearer establishment mode is used.
Inter-MSC Call Flow (MS -> UE)
Inter-MSC Call Flow (MS -> PSTN)
Inter-MSC Call Flow (UE -> UE, BICC Forward Fast Mode)
Inter-MSC Call Flow (UE -> UE, BICC Forward Slow Mode)
Inter-MSC Call Flow (UE -> UE, BICC Backward Slow Mode)
Inter-MSC Call Flow (SIP UE->SIP UE)
Inter-MSC Call Flow (PRA)

Inter-MSC Call Flow (MS -> UE)

Service Model
Signaling Flow
Service Model
A 2G mobile subscriber calls a 3G mobile subscriber.
ISDN user part (ISUP) signaling is used between the MSCs.
During the call, the callee releases the call first.
Signaling Flow
Figure 1 shows the signaling flow of an inter-MSC call between a 2G mobile subscriber and
a 3G mobile subscriber.
Figure 1 Signaling flow of an inter-MSC call between a 2G mobile subscriber and a 3G
mobile subscriber
Caller:
P1, P2, P3
Callee:
Q1, Q2, Q3, Q4
The signaling flow of an inter-MSC call between a 2G mobile subscriber and a 3G mobile
subscriber is as follows:
1. After a call is originated, the caller side completes routing, addressing, obtains
the mobile station roaming number (MSRN), and prepares resources for bearer
establishment. For details, see Bearer Establishment Flow (TDM-enabled A
Interface). Then, the MSC-O sends an IAM message carrying the information
(such as the caller category and called number) necessary for call setup and
other optional information (such as the calling number) to the MSC-T.
NOTE:
When the MSC-O selects routing (in this case, Carrier identification code is set
to 10 and the MSC-O controls circuits) by sending an IAM message, the MSC-T
selects routing (in this case, Carrier identification code is set to 10 and the
MSC-T does not control circuits) before it receives the IAM message from the
MSC-O. This results in a call dual seizure and the following occurs:
The MSC-O discards the incoming IAM message after it receives the
message from the MSC-T.
The MSC-T releases the call resources of the local MSC on which
Carrier identification code is set to 10, attempts a second call setup,
selects routing again, and sends an IAM message after it receives the
IAM message from the MSC-O.
2. If the called number contained in the IAM message is incomplete, the MSC-O
sends an subsequent address message (SAM) message carrying the missed part
of the called number to the MSC-T. Multiple SAM messages can be sent in a call.
3. The bearer establishment flow on the callee side is started. For details, see
Bearer Establishment Flow (ATM-enabled Iu Interface). When the callee is
alerted, the MSC-T sends an address complete message (ACM) message to the
MSC-O. At this time, the caller hears the ringback tone.
4. The callee answers the call. The MSC-T sends an answer message (ANM)
message to the MSC-O. The conversation starts.
5. The callee releases the call. The MSC-T sends a release (REL) message
carrying the release cause code to the MSC-O. At the same time, the MSC-T
releases the bearer resources on the callee side. For details, see Bearer
Release Flow (TDM-enabled A Interface) and Bearer Release Flow (ATMenabled Iu Interface).
6. The MSC-O sends a Radio Link Control (RLC) message to the MSC-T and
releases the bearer resources on the caller side at the same time. The RLC
message is used to indicate that the other end is idle and can be used for another
call.
Measurement Point
in Flowchart
Seizure Times
Outgoing Traffic in
Trunk Office
Directions
Bearer Traffic
Seizure Times
Outgoing Calls

Office
Alerting Message
Received Times
Outgoing Traffic in
Trunk Office
Directions
Bearer Traffic
P1
P2
Measurement Type
Call Completion Times Outgoing Calls

Office
Answer Times
Outgoing Traffic in
Trunk Office
Directions
Bearer Traffic
Answer Times
Outgoing Calls

Office
P3

Measurement Point
in Flowchart
Seizure Times
Incoming Traffic in
Trunk Office
Directions
Bearer Traffic
Seizure Times
Incoming Calls

Office
3G TERMINATED
CALL_ATTEMPT
UTRAN Subscriber
Terminated Calls

Office
Q1
Q2
Measurement Type
UTRAN Subscriber
3G INCOMING CALL
Terminated Incoming
ATTEMPT
Calls
3G TERMINATED
UTRAN Subscriber
ALERT
Terminated Calls
MT connect times
Traffic Measurement
(LAI)
For LAI
UTRAN Subscriber
3G INCOMING

Office
Office
Global Components
Q3
Q4
ALERT
Terminated Incoming Office

Calls
Incoming Traffic in
Alerting Message
Trunk Office
Bearer Traffic
Received Times
Directions
Call Completion Times Incoming Calls
Office
3G TERMINATED
UTRAN Subscriber
ANSWER
Terminated Calls
Office
MT response times
Traffic Measurement
Global Components
(LAI)
For LAI
3G TERMINATED
UTRAN Subscriber
CALL ESTABLISH
Terminated Calls
Office
AVERAGE TIME
UTRAN Subscriber
3G INCOMING
Terminated Incoming
ANSWER
Office
Calls
Incoming Traffic in
Answer Times
Trunk Office
Bearer Traffic
Directions
Answer Times
Incoming Calls
Office
Parent topic: Inter-MSC Calls

Inter-MSC Call Flow (MS -> PSTN)

Service Model
Signaling Flow
Service Model
A 2G mobile subscriber calls a public switched telephone network (PSTN)
subscriber.
Signaling Flow
Figure 1 shows the signaling flow of an inter-MSC call between a 2G mobile subscriber and
a PSTN subscriber.
Figure 1 Signaling flow of an inter-MSC call between a 2G mobile subscriber and a PSTN
subscriber
As shown in Figure 1, P1, P2, P3, P4 refers to the measurement points.
The signaling flow of an inter-MSC call between a 2G mobile subscriber and a PSTN
subscriber is as follows:
1. After a call is originated, the caller side completes routing, addressing, obtains
the mobile station roaming number (MSRN), and prepares resources for bearer
establishment. For details, see Bearer Establishment Flow (TDM-enabled A
Interface). Then, the MSC sends an IAM message carrying the information (such
as the caller category and called number) necessary for call setup and other
optional information (such as the calling number) to the PSTN.
2. When the resource allocation on the callee side is complete and the callee is
alerted, the PSTN sends an address complete message (ACM) message to the
MSC. At this time, the caller hears the ringback tone.
3. The callee answers the call. The PSTN sends an answer message (ANM)
message to the MSC. The conversation starts.
4. During the call, the PSTN subscriber hangs up. The PSTN sends a release (REL)
message to the MSC, and at the same time releases the call.
5. The MSC releases the bearer resources on the caller side, and at the same time
returns a Radio Link Control (RLC) message to the PSTN. The RLC message is
used to indicate that the other end is idle and can be used for another call.
Table 1 lists common measurement entities.
Table 1 Measurement points
Measurement Point
in Flowchart
GSM Subscriber
Originated Calls
GSM Subscriber
2G OUTGOING CALL
Originated Outgoing
ATTEMPT
Calls
Call Attempts
P1
MO try call times

(LAI)
Wrong Dialing Times
Seizure Times
P2
Seizure Times
Measurement Type
Office
Office
Traffic Measurement
Global Components
For LAI
GSM Subscriber
Originated Calls
Outgoing Traffic in
Trunk Office
Directions
Outgoing Calls

Office
Bearer Traffic
Office
Alerting Message
Received Times
P3

2G OUTGOING
ALERT
Answer Times
Answer Times
Call Attempts
P4
Outgoing Traffic in
Trunk Office
Directions
2G OUTGOING
ANSWER
MO response times
(LAI)
Answer Times
Average Call Setup
Time
GSM Subscriber
Originated Calls
GSM Subscriber
Originated Outgoing
Calls
Outgoing Traffic in
Trunk Office
Directions
Outgoing Calls
GSM Subscriber
Originated Calls
GSM Subscriber
Originated Outgoing
Calls
Traffic Measurement
For LAI
Incoming Calls in
Mobile Office
Directions
GSM Subscriber
Originated Calls

Bearer Traffic
Office
Office
Office
Bearer Traffic
Office
Office
Office
Global Components
Bearer Traffic
Office
Inter-MSC Call Flow (UE -> UE, BICC Forward Fast Mode)
Service Model
Signaling Flow
Service Model
A 3G mobile subscriber calls another 3G mobile subscriber served by different
MSCs.
Bearer Independent Call Control (BICC) signaling is used between the MSCs.
The call is established in forward fast mode.
Signaling Flow
Figure 1 shows the signaling flow of an inter-MSC call between two 3G mobile subscribers.
Figure 1 Signaling flow of an inter-MSC call between two 3G mobile subscribers
Caller:
P1, P2, P3, P4
Callee:
Q1, Q2, Q3, Q4
The signaling flow of an inter-MSC call between two 3G mobile subscribers is as follows:
1. After the caller side completes service access (service initialization, authentication
and encryption, and routing), a bearer is established on the radio access network
(RAN) side of the caller. For details, see Bearer Establishment Flow (ATMenabled Iu Interface).
2. The originating MSC (MSC-O) sends an ADD REQ message to the originating
MGW (MGW-O), instructing MGW-O to add IP termination bearer resources on
the CN side of the caller and initiate tunneling negotiation. For details about the
indication information, see the bT-TunOpt in ADD REQ (bT).
3. MGW-O replies with an ADD REPLY message containing the termination
information.
4. MGW-O sends a NTFY REQ message to MSC-O, reporting a tunnel indication
event and tunnel request message. For details about the tunnel request message,
see the bT-TunnelInd-DATA in NTFY REQ (bT).
5. MSC-O replies with a NTFY REPLY message.
6. MSC-O selects a route for the call based on the local end information, contains
the tunneled information in an IAM message, and sends it to the terminating MSC
(MSC-T), informing that forward establishment is used. For details about the
tunneled information, see IAM (APP).
7. MSC-T sends an ADD REQ message to the terminating MGW (MGW-T),
instructing MGW-T to add IP termination bearer resources on the CN side of the
callee and informing MGW-T of the tunnel request message. For details about the
tunnel request message, see the bT-BearInfoTrans in ADD REQ (bT).
8. MGW-T replies with an ADD REPLY message containing the termination
information.
9. MGW-T sends a NTFY REQ message to MSC-T, reporting a tunnel indication
event and the tunnel request acceptance message. For details about the tunnel
request acceptance message, see the bT-TunnelInd-DATA in NTFY REQ (bT).
10. MSC-T replies with a NTFY REPLY message.
11. Bearer establishment on the RAN side of the callee is similar with that on the RAN
side of the caller.
12. Upon receiving the tunnel request acceptance message sent by MGW-T, MSC-T
constructs and replies with an APM message to MSC-O. For details about the
tunnel request acceptance message, see the bearer-Control-Info in APM
(Initiating bCI).
13. MSC-O sends a MOD REQ message containing the tunneled information that is
carried in the APM message to MGW-O, transparently sending the tunnel request
acceptance message sent by MGW-T. For details about the tunnel request
acceptance message, see the bT-BearInfoTrans in MOD REQ (bT).
14. MGW-O replies with a MOD REPLY message.
15. MGW-O sends a TRC_IU/NB_UP_INIT_TOIP message to MGW-T, starting
NB_UP initiation.
16. MGW-T replies with a TRC_IU/NB_UP_ACK_FRMIP message.
17. MGW-T sends a NTFY REQ message to MSC-T, reporting the bearer
establishment event on the callee side.
19. MGW-O sends a NTFY REQ message to MSC-O, reporting the bearer
establishment event on the caller side.
21. After a bearer is established and Iu interface resources are allocated on the RAN
side of the callee, MSC-T sends an address complete message (ACM) message
to MSC-O and the callee is alerted.
22. MSC-T sends a MOD REQ message containing signalsDescriptor to MGW-T,
instructing MGW-T to play the ringback tone.
23. MGW-T replies with a MOD REPLY message, indicating that the ringback tone is
played.
24. After the callee answers the phone, MSC-T sends an ANM message to MSC-O.
25. MSC-T sends a MOD REQ message to MGW-T, instructing MGW-T to stop
playing the ringback tone.
stopped.
27. During the call, MGW-O sends an RTCP_SEND_MSG message to MGW-T,

monitoring the quality of Real-Time Transport Protocol (RTP) packets sent and
received by the local end.
28. MGW-O receives an RTCP_RCV_MSG message sent by MGW-T, monitoring the
quality of RTP packets sent and received by the peer end.
29. After the callee releases the call, MSC-T sends a REL message to MSC-O. This
message is sent by the party who releases the call. It contains the release cause
value.
30. MSC-O replies with a Radio Link Control (RLC) message, releasing bearer
resources.
31. MSC-O sends a SUB REQ message to MGW-O, instructing MGW-O to release
termination resources on the CN side of the caller.
32. MGW-O replies with a SUB REPLY message.
33. MSC-T sends a SUB REQ message to MGW-T, instructing MGW-T to release
termination resources on the CN side of the callee.
34. MGW-T replies with a SUB REPLY message.
35. Bearer resources are released on the RAN side of the caller. For details, see
36. Bearer release on the RAN side of the callee is similar with that on the RAN side
of the caller.
Measurement Point
in Flowchart
UTRAN Subscriber
Originated Calls
UTRAN Subscriber
3G OUTGOING CALL
Originated Outgoing
ATTEMPT
Calls
Call Attempts
P1
MO try call times

(LAI)
Wrong Dialing Times
Measurement Type
Office
Office
Traffic Measurement
Global Components
For LAI
UTRAN Subscriber
Seizure Times
P2
Originated Calls
Outgoing Traffic in
Trunk Office
Outgoing Calls

Office
Alerting Message
Received Times
Outgoing Traffic in
Trunk Office
Bearer Traffic
UTRAN Subscriber
Originated Calls
UTRAN Subscriber
3G OUTGOING
Originated Outgoing
ALERT
Calls
MO connect times
Traffic Measurement
(LAI)
For LAI
Incoming Calls in
Directions
Outgoing Traffic in
Answer Times
Trunk Office
Answer Times
Answer Times
P4
Bearer Traffic
Seizure Times
P3
Office
3G OUTGOING
ANSWER
MO response times
(LAI)
Answer Times
Average Call Setup
Time
Outgoing Calls
UTRAN Subscriber
Originated Calls
UTRAN Subscriber
Originated Outgoing
Calls
Traffic Measurement
For LAI
Incoming Calls in
Mobile Office
Directions
UTRAN Subscriber
Originated Calls

Office
Office
Office
Global Components
Bearer Traffic
Bearer Traffic
Office
Office
Office
Global Components
Bearer Traffic
Office

Measurement Point
in Flowchart
Measurement Type
Q1
Q2
Seizure Times
Incoming Calls

Office
3G TERMINATED
CALL_ATTEMPT
UTRAN Subscriber
Terminated Calls

Office
UTRAN Subscriber
3G INCOMING CALL Terminated Incoming Total Traffic of the
ATTEMPT
Office
Calls
3G TERMINATED
ALERT
MT connect times
(LAI)
Q3
3G INCOMING
ALERT
Alerting Message
Received Times
UTRAN Subscriber
Terminated Calls
Traffic Measurement
For LAI
UTRAN Subscriber
Terminated Incoming
Calls
Incoming Traffic in
Trunk Office
Directions

3G TERMINATED
ANSWER
MT response times
(LAI)
3G TERMINATED
CALL ESTABLISH
AVERAGE TIME
Q4
3G INCOMING
ANSWER
Answer Times
Answer Times

Office
Global Components
Office
Bearer Traffic
Office
Office
UTRAN Subscriber
Terminated Calls
Traffic Measurement
Global Components
For LAI
UTRAN Subscriber
Terminated Calls

Office
UTRAN Subscriber
Terminated Incoming
Office
Calls
Incoming Traffic in
Trunk Office
Bearer Traffic
Directions
Incoming Calls
Office

Inter-MSC Call Flow (UE -> UE, BICC Forward Slow Mode)
Service Model
Signaling Flow
Service Model
MSCs.
The call is established in forward slow mode.
Signaling Flow
Caller:
P1, P2, P3, P4
Callee:
Q1, Q2, Q3, Q4
the CN side of the caller and wait for follow-up messages. For details about the
information.
4. MSC-O constructs and sends an IAM message to MSC-T, informing that forward
establishment is used. For details about bearer establishment mode, see IAM
(APP).
5. MSC-T sends an ADD REQ message to MGW-T, instructing MGW-T to add IP
termination bearer resources on the CN side of the callee.
information.
side of the caller.
8. MSC-T replies with an APM message, indicating MSC-O that delayed bearer
establishment is used.
9. MSC-O sends a MOD REQ message to MGW-O, instructing MGW-O to report
the tunneled information. For details about the tunneled information, see the bTTunnelInd in MOD REQ (bT).

13. MSC-O contains the tunneled information in an APM message and sends it to
MSC-T. For details about the tunneled information, see APM (Initiating bCI).
14. After MSC-T selects a route for the call based on the IEs in the APM message
and the local end information, MSC-T sends a MOD REQ message containing
bearer information that is carried in the IAM message to MGW-T, transparently
sending the tunnel request message sent by MGW-O. For details about the
tunnel request message, see the bT-BearInfoTrans in MOD REQ (bT).
15. MGW-T replies with a MOD REPLY message.
tunnel request acceptance message, see APM (Receiving bCI).
19. MSC-O sends a MOD REQ message containing the tunneled information that is
acceptance message sent by MGW-T. For details about the tunnel request
NB_UP initiation.
played.
stopped.
35. After the callee releases the call, MSC-T sends a release (REL) message to
MSC-O. This message is sent by the party who releases the call. It contains the
release cause value.
resources.
of the caller.

Measurement Point
in Flowchart
UTRAN Subscriber
Originated Calls
UTRAN Subscriber
3G OUTGOING CALL
Originated Outgoing
ATTEMPT
Calls
Call Attempts
P1
MO try call times

(LAI)
Wrong Dialing Times
Seizure Times
P2
UTRAN Subscriber
Originated Calls
Outgoing Traffic in
Trunk Office

Office

Office
Bearer Traffic
Seizure Times
Outgoing Calls

Office
Alerting Message
Received Times
Outgoing Traffic in
Trunk Office
Bearer Traffic
UTRAN Subscriber
Originated Calls
UTRAN Subscriber
3G OUTGOING
Originated Outgoing
ALERT
Calls
MO connect times
Traffic Measurement
(LAI)
For LAI
Incoming Calls in
Directions
Outgoing Traffic in
Answer Times
Trunk Office
Answer Times
Answer Times
P4

Office
Traffic Measurement
Global Components
For LAI
P3
Measurement Type
3G OUTGOING
ANSWER
Outgoing Calls
UTRAN Subscriber
Originated Calls
UTRAN Subscriber
Originated Outgoing
Calls

Office
Office
Office
Global Components
Bearer Traffic
Bearer Traffic
Office
Office
Office
MO response times
(LAI)
Answer Times
Average Call Setup
Time
Traffic Measurement
For LAI
Incoming Calls in
Mobile Office
Directions
UTRAN Subscriber
Originated Calls
Global Components
Bearer Traffic
Office

Measurement Point
in Flowchart
Measurement Type
Q1
Q2
Q3
Seizure Times
Incoming Calls

Office
3G TERMINATED
CALL_ATTEMPT
UTRAN Subscriber
Terminated Calls

Office
UTRAN Subscriber
3G INCOMING CALL
Terminated Incoming
ATTEMPT
Calls
3G TERMINATED
UTRAN Subscriber
ALERT
Terminated Calls
MT connect times
Traffic Measurement
(LAI)
For LAI
UTRAN Subscriber
3G INCOMING
Terminated Incoming
ALERT
Calls
Incoming Traffic in
Alerting Message
Trunk Office
Received Times
Directions
3G TERMINATED
ANSWER
MT response times
(LAI)
3G TERMINATED
CALL ESTABLISH
AVERAGE TIME
Q4
3G INCOMING
ANSWER

Office
Office
Global Components
Office
Bearer Traffic
Office
Office
UTRAN Subscriber
Terminated Calls
Traffic Measurement
Global Components
For LAI
UTRAN Subscriber
Terminated Calls

Office
UTRAN Subscriber
Terminated Incoming
Office
Calls
Answer Times
Incoming Traffic in
Trunk Office
Directions
Bearer Traffic
Answer Times
Incoming Calls

Office

Inter-MSC Call Flow (UE -> UE, BICC Backward Slow Mode)
Service Model
Signaling Flow
Service Model
MSCs.
The call is established in backward slow mode.
Signaling Flow
Caller:
P1, P2, P3, P4
Callee:
Q1, Q2, Q3, Q4
the CN side of the caller and wait for follow-up messages. For details about the
information.
4. MSC-O constructs and sends an IAM message to MSC-T, informing that
backward establishment is used. For details about bearer establishment mode,
see IAM (APP).
5. MSC-T sends an ADD REQ message to MGW-T, instructing MGW-T to add IP
termination bearer resources on the CN side of the callee.
information.
side of the caller.
8. MSC-T sends a MOD REQ message to MGW-T, instructing MGW-T to report the
tunneled information. For details about the tunneled information, see the bTTunnelInd in MOD REQ (bT).
tunnel request acceptance message, see APM (Initiating bCI).
13. MSC-O sends a MOD REQ message containing the bearer information that is
message sent by MGW-T. For details about the tunnel request message, see the
bT-BearInfoTrans in MOD REQ (bT).
17. Upon receiving the tunnel request acceptance message sent by MGW-O, MSC-O
constructs and replies with an APM message to MSC-T. For details about the
tunnel request acceptance message, see APM (Receiving bCI).
18. MSC-T sends a MOD REQ message containing the tunneled information that is
carried in the APM message to MGW-T, transparently sending the tunnel request
acceptance message sent by MGW-O. For details about the tunnel request
NB_UP initiation.

played.
stopped.
34. After the callee releases the call, MSC-T sends a release (REL) message to
MSC-O. This message is sent by the party who releases the call. It contains the
resources.
of the caller.
Measurement Point Measurement Entity Measurement Unit

in Flowchart
UTRAN Subscriber
Originated Calls
UTRAN Subscriber
3G OUTGOING CALL
Originated Outgoing
ATTEMPT
Calls
Call Attempts
P1
MO try call times

(LAI)
Wrong Dialing Times
Seizure Times
P2
UTRAN Subscriber
Originated Calls
Outgoing Traffic in
Trunk Office

Office

Office
Bearer Traffic
Seizure Times
Outgoing Calls

Office
Alerting Message
Received Times
Outgoing Traffic in
Trunk Office
Bearer Traffic
UTRAN Subscriber
Originated Calls
UTRAN Subscriber
3G OUTGOING
Originated Outgoing
ALERT
Calls
MO connect times
Traffic Measurement
(LAI)
For LAI
Incoming Calls in
Directions
Outgoing Traffic in
Answer Times
Trunk Office
Answer Times
Answer Times
P4

Office
Traffic Measurement
Global Components
For LAI
P3
Measurement Type
3G OUTGOING
ANSWER
MO response times
Outgoing Calls

Office
Office
Office
Global Components
Bearer Traffic
Bearer Traffic
Office
Office
UTRAN Subscriber
Originated Calls
UTRAN Subscriber
Originated Outgoing
Office
Calls
Traffic Measurement
Global Components
(LAI)
Answer Times
Average Call Setup

Time
For LAI
Incoming Calls in
Mobile Office
Directions
UTRAN Subscriber
Originated Calls
Bearer Traffic

Office

Measurement Point
in Flowchart
Measurement Type
Q1
Q2
Q3
Seizure Times
Incoming Calls

Office
3G TERMINATED
CALL_ATTEMPT
UTRAN Subscriber
Terminated Calls

Office
UTRAN Subscriber
3G INCOMING CALL
Terminated Incoming
ATTEMPT
Calls
3G TERMINATED
UTRAN Subscriber
ALERT
Terminated Calls
MT connect times
Traffic Measurement
(LAI)
For LAI
UTRAN Subscriber
3G INCOMING
Terminated Incoming
ALERT
Calls
Incoming Traffic in
Alerting Message
Trunk Office
Received Times
Directions
3G TERMINATED
ANSWER
MT response times
(LAI)
3G TERMINATED
CALL ESTABLISH
AVERAGE TIME
Q4
3G INCOMING
ANSWER

Office
Office
Global Components
Office
Bearer Traffic
Office
Office
UTRAN Subscriber
Terminated Calls
Traffic Measurement
Global Components
For LAI
UTRAN Subscriber
Terminated Calls

Office
UTRAN Subscriber
Terminated Incoming
Office
Calls
Answer Times
Answer Times
Incoming Traffic in
Trunk Office
Directions
Incoming Calls

Bearer Traffic
Office
Inter-MSC Call Flow (SIP UE->SIP UE)

Service Model
Signaling Flow
Service Model
A 3G mobile subscriber calls another 3G mobile subscriber served by a different
mobile switching center (MSC) server.
Session Initiation Protocol (SIP) signaling is used between MSCs.
The SIP media negotiation proceeds between the INVITE message and the 183
message. The 100rel message is supported.
During the call, the called party releases the call first.
Signaling Flow
Figure 1 Signaling Flow

Originating party:
P1; P2; P3; P4
Terminating party:
Q1; Q2; Q3; Q4
The signaling flow of an inter-MSC call between 3G mobile subscribers is as follows:

1. Based on the local office information, the MSC-O determines to route the call out
through a SIP trunk. The MSC-O instructs the media gateway (MGW) to prepare
the bearer resources and to report the channel information. After the MGW
reports the channel information, the MSC-O packs the information in the INVITE
message and then sends the message to the MSC-T. The Support header field
indicates that the 100rel message is supported.
2. The MSC-T selects a route for the call based on the information elements (IEs)
contained in the INVITE message and the local office information, sends the
bearer information in the INVITE message to the MGW, and requests the MGW
to prepare bearer resources. After the MGW reports the bearer information, the
MSC-T constructs and returns a reliable 183 message to the MSC-O.
3. The MSC-O sends a PRACK message in response to the 183 message and
processes the 200 message returned from the MSC-T to ensure the reliability of
the 183 message.
4. On setting up the bearer on the terminating side and assigning the required Iu
interface resources, the MSC-T returns a reliable 180 message to the MSC-O. At
this point, the called party is alerted and the calling party hears the ringback tone.
5. After the called party answers the call, and the MSC-T sends a 200 FOR INVITE
message to the MSC-O. The MSC-O then returns a ACK message. At this time,
the call is connected.
6. The called party releases the call. The MSC-T sends a BYE message to MSC-O.
The BYE containing the release cause value is sent by the party that releases the
call first.
7. MSC-O sends a 200 message in response to the MSC-T and releases the bearer
resources on the originating side at the same time. For details, see 3G Bearer
Release Flow. The 200 message indicates that the peer end is free and is
available for the next call.
Table 1 lists common measurement entities used on the originating side.
Measurement Point
in Flowchart
UTRAN Subscriber
Originated Calls
3G OUTGOING CALL UTRAN Subscriber
Call Attempts
Measurement Type
Office
ATTEMPT
P1
P2
Originated Outgoing
Calls
Traffic Measurement
MOC Attempts (LAI)
For LAI
UTRAN Subscriber
Wrong Dialing Times
Originated Calls
Outgoing Traffic in
Seizure Times
Trunk Office
Directions

Office
Bearer Traffic
Outgoing Calls

Office
Alerting Message
Received Times
Outgoing Traffic in
Trunk Office
Directions
Bearer Traffic
UTRAN Subscriber
Originated Calls
UTRAN Subscriber
3G OUTGOING
Originated Outgoing
ALERT
Calls
MOC Completion
Traffic Measurement
Times (LAI)
For LAI
Incoming Calls in
Directions
Outgoing Traffic in
Answer Times
Trunk Office
Directions
Answer Times
Answer Times
P4
Global Components
Seizure Times
P3
Office
3G OUTGOING
ANSWER
MOC Answer Times
(LAI)
Answer Times
Outgoing Calls
UTRAN Subscriber
Originated Calls
UTRAN Subscriber
Originated Outgoing
Calls
Traffic Measurement
For LAI
Incoming Calls in
Mobile Office
Directions

Office
Office
Office
Global Components
Bearer Traffic
Bearer Traffic
Office
Office
Office
Global Components
Bearer Traffic
Average Call Setup

Time
UTRAN Subscriber
Originated Calls

Office

Measurement Point
in Flowchart
Measurement Type
Q1
Q2
Q3
Seizure Times
Incoming Calls

Office
3G TERMINATED
CALL_ATTEMPT
UTRAN Subscriber
Terminated Calls

Office
UTRAN Subscriber
3G INCOMING CALL
Terminated Incoming
ATTEMPT
Calls
3G TERMINATED
UTRAN Subscriber
ALERT
Terminated Calls
MTC Completion
Traffic Measurement
Times (LAI)
For LAI
UTRAN Subscriber
3G INCOMING
Terminated Incoming
ALERT
Calls
CMN Alerting
Incoming Traffic in
Message Received
Trunk Office
Times
Directions
3G TERMINATED
ANSWER
MTC Answer Times
(LAI)
3G TERMINATED
CALL ESTABLISH
AVERAGE TIME
Q4
3G INCOMING
ANSWER
CMN Answer Times
Answer Times

Office
Office
Global Components
Office
Bearer Traffic
Office
Office
UTRAN Subscriber
Terminated Calls
Traffic Measurement
Global Components
For LAI
UTRAN Subscriber
Terminated Calls

Office
UTRAN Subscriber
Terminated Incoming
Office
Calls
Incoming Traffic in
Trunk Office
Bearer Traffic
Directions
Incoming Calls
Office

Inter-MSC Call Flow (PRA)

Service Model
Signaling Flow
Service Model
The private branch exchange (PBX) connects to the 2/3G network through the
primary rate access (PRA) interface.
The PRA trunk is used between the MSC and the PBX.
Signaling Flow
Figure 1 shows the signaling flow of an inter-MSC call connected through the PRA trunk.
Figure 1 Signaling flow of an inter-MSC call connected through the PRA trunk
As shown in Figure 1, P1, P2, P3 refers to the measurement points.

The signaling flow of an inter-MSC call connected through the PRA trunk is as follows:
1. The MSC requests the MGW to establish bearer. The MGW establishes the
bearer and then informs the MSC of the bearer establishment result. If bearer
establishment is successful, the MSC sends a SETUP message to the PBX.
2. Upon receipt of the SETUP message, the PBX checks whether the address
carried in the message is complete, and then returns a SETUP ACKNOWLEDGE
message to the MSC based on the check result.
If the address is complete, the PBX returns a CALL PROCEEDING
message to the MSC and prepares to establish bearer at the same
time.
If the address is incomplete, the PBX requests the missed address
information by sending the SETUP ACKNOWLEDGE message to the
MSC. Then, the MSC sends the missed address information to the PBX.
3. The paging is successful. The callee is alerted. The PBX sends an ALERTING
message to the MSC. Then, the MSC transparently forwards this message to the
caller. At this time, the caller hears the ringback tone and the callee is being
alerted.
4. After the callee answers the call, the PBX sends a CONNECT message, notifying
the MSC that the call is connected.
5. After receiving the CONNECT message, the MSC returns a CONNECT
ACKNOWLEDGE message to the PBX. At this time, the channels selected by the
MSC and the PBX for the caller and the callee are connected immediately, and
the circuit from the caller to the callee is formed to transmit user information.
7. The callee releases the call. The PBX sends a DISCONNECT message, notifying
the MSC to release the call.
8. The MSC sends a RELEASE message to the PBX, and instructs the MGW to
release the bearer resources at the same time.
9. Upon receipt of the RELEASE message, the PBX instructs the MGW-B to
release the bearer resources, and at the same time returns a RELEASE
COMPLETE message to the MSC.

Measurement Point
in Flowchart
Seizure Times
Outgoing Traffic in
Trunk Office
Directions
Bearer Traffic
Seizure Times
Outgoing Calls

Office
Alerting Message
Received Times
Outgoing Traffic in
Trunk Office
Directions
Bearer Traffic
P1
P2
Measurement Type

Office
Answer Times
Outgoing Traffic in
Trunk Office
Directions
Bearer Traffic
Answer Times
Outgoing Calls

Office
P3

Bearer Establishment and Release

Bearer flow involves the allocation and release of the Iu/A interface resources and voice
channels in basic voice calls.
NOTE:
In a bearer flow, voice channel allocation is also called assignment. There are two types of
assignment: early assignment and late assignment.
On the caller side:
Early assignment: A voice channel is allocated after the network sends a
Call proceeding message to the caller (to complete the routing and
addressing) and before the callee is alerted during the setup of a call.
Late assignment: A voice channel is allocated after the callee is alerted
during the setup of a call.
On the callee side:
Early assignment: A voice channel is allocated after the network receives
the Call confirmed message from the callee.
Late assignment: A voice channel is allocated after the network receives
the Connect message from the callee.
Bearer Establishment Flow (TDM-enabled A Interface)
Bearer Establishment Flow (IP-enabled A Interface)
Bearer Establishment Flow (ATM-enabled Iu Interface)
Bearer Establishment Flow (IP-enabled Iu Interface)
Bearer Release Flow (TDM-enabled A Interface)
Bearer Release Flow (IP-enabled A Interface)
Bearer Release Flow (ATM-enabled Iu Interface)
Bearer Release Flow (IP-enabled Iu Interface)
Bearer Establishment Flow (TDM-enabled A Interface)

Service Model
Signaling Flow
Service Model
The BSC and the MGW are connected over time division multiplexing (TDM).
The BSC and the MSC are connected over MTP3-User Adaptation Layer (M3UA)
in non-peer-to-peer mode. That is, the MSC connects to the MGW over M3UA
links and exchanges Base Station Subsystem Application Part (BSSAP) messages
with the BSC over Message Transfer Part Layer 3 (MTP3) links provided by the
MGW that has the embedded signaling gateway function.
Signaling Flow
Figure 1 shows the signaling flow of bearer establishment (TDM-enabled A interface).
Figure 1 Signaling flow of bearer establishment (TDM-enabled A interface)
As shown in Figure 1, P1, P2, P3, and P4 refer to the measurement points.
The signaling flow of bearer establishment (TDM-enabled A interface) is as follows:
1. The MSC sends an ADD REQ message, requesting the MGW to add a
termination.
2. The MGW dynamically allocates TDM resources and replies with an ADD REPLY
message containing the termination information.
3. The MSC sends an ASSIGNMENT REQUEST message to the BSC.
4. The BSC sends a RADIO BEARER SETUP message, allocating a radio channel
to the MS.
5. The MS seizes the allocated radio channel and replies with a RADIO BEARER
SETUP COMPLETE message.
6. The BSC establishes bearer on the access side with the MGW, and sends an
ASSIGNMENT COMPLETE message to the MSC, indicating that the assignment
is complete.
Measurement Point
in Flowchart
P1
P2
P3
Measurement Type
Number of Sent Add

Requests
H248 MGW
Transaction
Measurement
Signaling and
Interfaces
Number of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Bytes of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Number of Received
Add Responses
H248 MGW
Transaction
Measurement
Signaling and
Interfaces
Number of Received
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Bytes of Received
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Traffic Channel
GSM Assignment
Assignment Requests
MSC Basic Services
Half-Rate Channel
Assigned Times
GSM Assignment
MSC Basic Services
FR AMR Used Times

GSM Assignment
During Assignment
MSC Basic Services
P4
Successful Traffic
GSM Assignment
Channel Assignments
MSC Basic Services
Half-Rate Channel
Successfully Assigned GSM Assignment
Times
MSC Basic Services
Traffic Channel
Assignment Failure
due to Radio
Resource
Unavailability
Average Duration of
GSM Channel
Assignment
Assignment Failures
Answer Times
GSM Assignment
MSC Basic Services
GSM Assignment
MSC Basic Services
GSM Subscriber
Originated Calls
Incoming Calls in
Mobile Office

Office
Parent topic: Bearer Establishment and Release

Bearer Traffic
Bearer Establishment Flow (IP-enabled A Interface)

Service Model
Signaling Flow
Service Model
The BSC and the MGW are connected over IP.
After IP bearer is used on the A interface, the Base Station Subsystem Application
Part (BSSAP) message can be transmitted between the BSC and the MSC or
transparently transmitted by the MGW that forwards IP packets without parsing
MTP3-User Adaptation Layer (M3UA) messages.
Signaling Flow
Figure 1 shows the signaling flow of bearer establishment (IP-enabled A interface).
Figure 1 Signaling flow of bearer establishment (IP-enabled A interface)
As shown in Figure 1, P1, P2, P3, and P4 refer to the measurement points.
The signaling flow of bearer establishment (IP-enabled A interface) is as follows:

1. The MSC sends an ADD REQ message to the MGW, requesting the MGW to
add an IP termination and notifying the MGW of the codecs used by a call.
2. The MGW dynamically allocates IP resources and replies with an ADD REPLY
message containing information about the termination, such as the IP address
and port number.
3. The MSC sends an ASSIGNMENT REQUEST message to the BSC. This
message contains the IP address and port number allocated by the MGW, and
the supported codec set.
4. The BSC sends a RADIO BEARER SETUP message, allocating a radio channel
to the MS.
5. The MS seizes the allocated radio channel and replies with a RADIO BEARER
6. The BSC replies with an ASSIGNMENT COMPLETE message containing the
codec chosen by the BSC, and the IP address and port number on the user
plane.
7. The MSC sends a MOD REQ message to the MGW, requesting the MGW to
modify termination properties. This message contains the IP address and port
number allocated on the BSC.
8. The MGW replies with a MOD REPLY message.
9. The MGW sends a NTFY REQ message to the MSC, informing the MSC of the
bearer establishment event.
10. The MSC replies with a NTFY REPLY message.
Measurement Point
in Flowchart
P1
Measurement Type
Number of Sent Add

Requests
H248 MGW
Transaction
Measurement
Signaling and
Interfaces
Number of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Bytes of Sent
H248 MGW Basic
Signaling and
P2
P3
P4
Messages
Measurement
Interfaces
Number of Received
Add Responses
H248 MGW
Transaction
Measurement
Signaling and
Interfaces
Number of Received
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Bytes of Received
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Traffic Channel
GSM Assignment
Assignment Requests
MSC Basic Services
Half-Rate Channel
Assigned Times
GSM Assignment
MSC Basic Services
FR AMR Used Times

GSM Assignment
During Assignment
MSC Basic Services
Successful Traffic
GSM Assignment
Channel Assignments
MSC Basic Services
Half-Rate Channel
Successfully Assigned GSM Assignment
Times
MSC Basic Services
Traffic Channel
Assignment Failure
due to Radio
Resource
Unavailability
Average Duration of
GSM Channel
Assignment
Assignment Failures
Answer Times
GSM Assignment
MSC Basic Services
GSM Assignment
MSC Basic Services
GSM Subscriber
Originated Calls
Incoming Calls in
Mobile Office

Office

Bearer Traffic
Bearer Establishment Flow (ATM-enabled Iu Interface)

Service Model
Signaling Flow
Service Model
The RNC and the MGW are connected over asynchronous transfer mode (ATM).
The RNC and the MSC are connected over MTP3-User Adaptation Layer (M3UA)
links and exchanges Radio Access Network Application Part (RANAP) messages
with the RNC over Message Transfer Part Layer 3 Broadband (MTP3B) links
provided by the MGW that has the embedded signaling gateway function.
Signaling Flow
Figure 1 shows the signaling flow of bearer establishment (ATM-enabled Iu interface).
Figure 1 Signaling flow of bearer establishment (ATM-enabled Iu interface)
As shown in Figure 1, P1, P2, P3, P4, P5, and P6 refer to the measurement points.
The signaling flow of bearer establishment (ATM-enabled Iu interface) is as follows:
1. The MSC sends an ADD REQ message, requesting the MGW to add a
termination.
2. The MGW dynamically allocates ATM resources and replies with an ADD REPLY
message containing the termination information.
3. The MSC sends an radio access bearer (RAB) ASSIGNMENT REQUEST
message to the RNC.
4. The RNC sends a RADIO BEARER SETUP message, allocating a radio channel
to the UE.
5. The UE seizes the allocated radio channel and replies with a RADIO BEARER
6. The RNC sends an ERQ message containing information about the connection
element identifier and ATM Adaptation Layer Type 2 (AAL2) service endpoint
address, requesting the MGW to establish AAL2 connections.
7. The MGW replies with an ECF message.
8. The RNC sends a TRC_IU/NB_UP_INIT (Sent by RNC) message to the MGW,
starting initiation. This message contains information about the channel and
remote feature control (RFC) sub-flow combination.
9. The MGW replies with a TRC_IU/NB_UP_INIT (Sent by MGW) message.
10. The MGW sends a NTFY REQ message to the MSC, reporting the bearer
establishment event.
11. Upon receipt of the event, the MSC replies with a NTFY REPLY message.
12. The RNC sends an RAB ASSIGNMENT RESPONSE message to the MSC,
indicating that the assignment is complete.
Measurement Point
in Flowchart
H248 MGW
Measurement Type
P1
P2
P3
P4
P5
Number of Sent Add

Requests
Transaction
Measurement
Signaling and
Interfaces
Number of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Bytes of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Number of Received
Add Responses
H248 MGW
Transaction
Measurement
Signaling and
Interfaces
Number of Received
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Bytes of Received
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Traffic Channel
WCDMA Assignment MSC Basic Services
Assignment Requests
Number of Received
Notify Requests
H248 MGW
Transaction
Measurement
Signaling and
Interfaces
Number of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Bytes of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
H248 MGW
Number of Sent Notify
Transaction
Responses
Measurement
Signaling and
Interfaces
Number of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Bytes of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Successful Traffic
Channel Assignments
P6
Assignment Failure
due to IUUP Failure
Average Duration of
WCDMA Channel
Assignment

UTRAN Subscriber
Assignment Failures
Originated Calls
Office
Assignment Failures
Incoming Calls in
Mobile Office
Bearer Traffic

Bearer Establishment Flow (IP-enabled Iu Interface)

Service Model
Signaling Flow
Service Model
The RNC and the MGW are connected over IP.
After IP bearer is used on the Iu interface, the Radio Access Network Application
Part (RANAP) message can be transmitted between the RNC and the MSC or
Signaling Flow
Figure 1 shows the signaling flow of bearer establishment (IP-enabled Iu interface).
Figure 1 Signaling flow of bearer establishment (IP-enabled Iu interface)
As shown in Figure 1, P1, P2, P3, P4, P5, and P6 refer to the measurement points.
The signaling flow of bearer establishment (IP-enabled Iu interface) is as follows:
1. The MSC sends an ADD REQ message to the MGW, requesting the MGW to
add an IP termination and notifying the MGW of the codecs used by a call.
2. The MGW dynamically allocates IP resources and replies with an ADD REPLY
message containing information about the termination, such as the IP address
and port number.
3. The MSC sends an radio access bearer (RAB) ASSIGNMENT REQUEST
message to the RNC. This message contains the IP address and port number
allocated by the MGW, and the supported codec set.
4. The RNC sends a RADIO BEARER SETUP message, allocating a radio channel
to the UE.
5. The UE seizes the allocated radio channel and replies with a RADIO BEARER
6. The RNC sends a TRC_IU/NB_UP_INIT_TOIP message to the MGW. This
message contains information such as the IP address, port number, and remote
feature control (RFC) sub-flow combination.
7. The MGW replies with a TRC_IU/NB_UP_ACK_FRMIP message.
bearer establishment event.
10. The RNC replies with a RAB ASSIGNMENT RESPONSE message, indicating that
the RAB assignment is complete.
Measurement Point
in Flowchart
P1
Measurement Type
Number of Sent Add

Requests
H248 MGW
Transaction
Measurement
Signaling and
Interfaces
Number of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Bytes of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
H248 MGW
Number of Received
Add Responses
Transaction
Measurement
Signaling and
Interfaces
Number of Received
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Bytes of Received
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
P2
P3
P4
P5
Traffic Channel
Assignment Requests
Number of Received
Notify Requests
H248 MGW
Transaction
Measurement
Signaling and
Interfaces
Number of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Bytes of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
H248 MGW
Number of Sent Notify
Transaction
Responses
Measurement
Signaling and
Interfaces
Number of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Bytes of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Successful Traffic
Channel Assignments
P6
Assignment Failure
due to IUUP Failure
Average Duration of
WCDMA Channel
Assignment
Assignment Failures
Assignment Failures
UTRAN Subscriber
Originated Calls
Incoming Calls in
Mobile Office

Office
Bearer Traffic

Bearer Release Flow (TDM-enabled A Interface)

Service Model
Signaling Flow
Service Model
The BSC and the MGW are connected over time division multiplexing (TDM).
The BSC and the MSC are connected over MTP3-User Adaptation Layer (M3UA)
links and exchanges Base Station Subsystem Application Part (BSSAP) messages
with the BSC over Message Transfer Part Layer 3 (MTP3) links provided by the
MGW that has the embedded signaling gateway function.
Signaling Flow
Figure 1 shows the signaling flow of bearer release (TDM-enabled A interface).
Figure 1 Signaling flow of bearer release (TDM-enabled A interface)
As shown in Figure 1, P1 and P2 refer to the measurement points.

The signaling flow of bearer release (TDM-enabled A interface) is as follows:
1. After a call lasts for a period of time, an MS releases the call and sends a
Disconnect message to the MSC.
2. The MSC sends a Release message to MS-O, requesting resource release.
3. MS-O replies with a Release complete message to the MSC.
4. The MSC sends a CLEAR COMMAND message, requesting the BSC to release
air interface resources.
5. The BSC replies with a CLEAR COMPLETE message.
6. The MSC sends a SUB REQ message to the MGW, starting to release TDM
termination resources.
7. The MGW replies with a SUB REPLY message, indicating that the resource
release is complete.
NOTE:
After the MS releases the call, the MSC sends a Disconnect message to the peer MS,
which actively sends a Release message to request the release of radio resources. Later,
the MSC serving the peer MS requests the release of the resources on the user plane and
signaling plane. This process is the same as the process on the side of the MS that
releases the call first.
Measurement Point
in Flowchart
P1
P2
Measurement Type
Number of Sent
Subtract Requests
H248 MGW
Transaction
Measurement
Signaling and
Interfaces
Number of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Bytes of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Number of Received
Subtract Responses
H248 MGW
Transaction
Measurement
Signaling and
Interfaces
Number of Received
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Bytes of Received
Messages
H248 MGW Basic

Measurement

Signaling and
Interfaces
Bearer Release Flow (IP-enabled A Interface)

Service Model
Signaling Flow
Service Model
The BSC and the MGW are connected over IP.
After IP bearer is used on the A interface, the Base Station Subsystem Application
Part (BSSAP) message can be transmitted between the BSC and the MSC or
Signaling Flow
Figure 1 shows the signaling flow of bearer release (IP-enabled A interface).
Figure 1 Signaling flow of bearer release (IP-enabled A interface)

The signaling flow of bearer release (IP-enabled A interface) is as follows:
1. After a call lasts for a period of time, an MS releases the call and sends a
2. On the calling side, the MSC sends a Release message to the MS, requesting
the MS to release resources.
3. The MS replies with a Release complete message.
4. The MSC sends a CLEAR COMMAND message to the BSC, requesting the BSC
to release air resources.
5. The BSC replies with a CLEAR COMPLETE message.
6. The MSC sends a SUB REQ message to the MGW, starting to release IP
7. The MGW replies with a SUB REPLY message, indicating that IP termination
resources are successfully released.
bearer release event.
NOTE:
After the MS releases the call, the MSC sends a Disconnect message to the peer MS,
the MSC serving the peer MS requests the release of the resources on the user plane and
signaling plane. This process is the same as the process on the side of the MS that
Measurement Point
in Flowchart
P1
Measurement Type
Number of Sent
Subtract Requests
H248 MGW
Transaction
Measurement
Signaling and
Interfaces
Number of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Bytes of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
P2
Number of Received
Subtract Responses
H248 MGW
Transaction
Measurement
Signaling and
Interfaces
Number of Received
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Bytes of Received
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces

Bearer Release Flow (ATM-enabled Iu Interface)

Service Model
Signaling Flow
Service Model
The RNC and the MGW are connected over asynchronous transfer mode (ATM).
The RNC and the MSC are connected over MTP3-User Adaptation Layer (M3UA)
links and exchanges Radio Access Network Application Part (RANAP) messages
with the RNC over Message Transfer Part Layer 3 Broadband (MTP3B) links
provided by the MGW that has the embedded signaling gateway function.
Signaling Flow
Figure 1 shows the signaling flow of bearer release (ATM-enabled Iu interface).
Figure 1 Signaling flow of bearer release (ATM-enabled Iu interface)

The signaling flow of bearer release (ATM-enabled Iu interface) is as follows:
1. After a call lasts for a period of time, a UE releases the call and sends a
2. The MSC sends a Release message to the UE to request resource release.
3. The UE replies with a Release complete message.
4. The MSC sends an IU RELEASE COMMAND message, requesting the RNC to
release air interface resources.
5. The RNC sends a REL message, requesting the MGW to release ATM
Adaptation Layer Type 2 (AAL2) connections.
6. The MGW replies with a RLC message.
7. The RNC replies with an IU RELEASE COMPLETE message to the MSC,
indicating that air resource release is complete.
8. The MSC sends a SUB REQ message to the MGW, starting to release ATM
9. The MGW replies with a SUB REPLY message, indicating that the resource
release is complete.
10. The MGW sends a NTFY REQ message to the MSC, reporting the resource
release event.
11. The MSC replies with a NTFY REPLY.
NOTE:
After the UE releases the call, the MSC sends a Disconnect message to the peer UE,
the MSC serving the peer UE requests the release of the resources on the user plane and
signaling plane. This process is the same as the process on the side of the UE that
Measurement Point
in Flowchart
P1
P2
Measurement Type
Number of Sent
Subtract Requests
H248 MGW
Transaction
Measurement
Signaling and
Interfaces
Number of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Bytes of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Number of Received
Subtract Responses
H248 MGW
Transaction
Measurement
Signaling and
Interfaces
Number of Received
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Bytes of Received
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces

Bearer Release Flow (IP-enabled Iu Interface)

Service Model
Signaling Flow
Service Model
The RNC and the MGW are connected over IP.
After IP bearer is used on the Iu interface, the Radio Access Network Application
Part (RANAP) message can be transmitted between the RNC and the MSC or
Signaling Flow
Figure 1 shows the signaling flow of bearer release (IP-enabled Iu interface).
Figure 1 Signaling flow of bearer release (IP-enabled Iu interface)

The signaling flow of bearer release (IP-enabled Iu interface) is as follows:
1. After a call lasts for a period of time, a UE releases the call and sends a
2. The MSC sends a Release message to the UE, requesting the UE to release
resources.
3. The UE replies with a Release complete message.
4. The MSC sends a IU RELEASE COMMAND message to the RNC, requesting the
RNC to release air resources.
5. The RNC replies with an IU RELEASE COMPLETE message, indicating that the
air resources are successfully released.
6. The MSC sends a SUB REQ message to the MGW, starting to release IP
7. The MGW replies with a SUB REPLY message, indicating that IP termination
resources are successfully released.
bearer release event.
NOTE:
After the UE releases the call, the MSC sends a Disconnect message to the peer UE,
the MSC serving the peer UE requests the release of the resources on the user plane and
signaling plane. This process is the same as the process on the side of the UE that
Measurement Point
in Flowchart
P1
Measurement Type
Number of Sent
Subtract Requests
H248 MGW
Transaction
Measurement
Signaling and
Interfaces
Number of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Bytes of Sent
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
P2
Number of Received
Subtract Responses
H248 MGW
Transaction
Measurement
Signaling and
Interfaces
Number of Received
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces
Bytes of Received
Messages
H248 MGW Basic

Measurement
Signaling and
Interfaces

Short Message Services

SMMO
SMMT
Short Message Notification
SMMO
Short message mobile origination (SMMO) refers to the process that an UE/MS sends a
short message to the short message center (SMC), and the SMC returns a report to the
UE/MS, notifying whether the short message is sent successfully or not.
SMMO Flow
Parent topic: Short Message Services
SMMO Flow
Service Model
Signaling Flow
Service Model
A UE/MS sends a short message. The short message mobile originated (SMMO) flow is
the same for both the 2G and 3G networks.
Signaling Flow
Figure 1 shows the SMMO signaling flow.
Figure 1 SMMO signaling flow

The SMMO signaling flow is as follows:
1. The UE/MS sends a connection management (CM) service request message

carrying the cell information, service type, called number, user ID, and
authentication parameters about the UE/MS to the MSC.
2. The authentication and encryption flow is started. For details, see Security
Management.
3. After the MSC accepts the CM service request, the UE/MS sends a CP DATA
message carrying the short message data and related address information to the
MSC through the Iu/A interface.
4. Upon receipt of the CP DATA message, the MSC returns a CP ACK message to
the UE/MS, notifying that the CP DATA message has been received (which does
not mean that the SMC has received the short message).
5. The MSC requests user data from the VLR, and checks the subscription data
about the UE/MS and whether the local MSC supports the short message service
(SMS).
If the local MSC does not support SMMO or the UE/MS subscribes to
the Call Restriction SS, the MSC directly returns a message to notify the
UE/MS that the SMMO request is rejected.
If the local MSC supports SMMO or the UE/MS does not subscribe to
the Call Restriction SS, the MSC obtains the SMC address from the
short message, and then transparently transmits the short message to
the SMC through the MAP_MO_FORWARD_SHORT_MESSAGE_REQ
message.
6. After receiving the request, the SMC checks the data validity. If the check is
passed, the SMC returns a MAP_MO_FORWARD_SHORT_MESSAGE_CNF
message to the MSC.
7. The MSC returns a CP DATA message to the UE/MS, notifying that the short
message has been sent to the SMC successfully.
8. The UE/MS returns a CP ACK message to the MSC, notifying that the CP DATA
message has been received.
9. If the length of the short message exceeds the limit, the UE/MS divides the short
message into several parts, and send them through the CP DATA message.
Measurement Point
in Flowchart

SMMO Attempts
Short Message
Service
MSC Basic Services
Send SMMO Times
MSC Basic Services
MSC Basic Functions
Send SMMO Times
Traffic Measurement
For location area
Global Components
identity (LAI)
P1
P2
P3
P4
Measurement Type
SMMO Failures due to Short Message

Unknown Subscribers Service
MSC Basic Services
SMMO Failures due to

Short Message
ZC-based Service
Service
Barring
MSC Basic Services

Protocol Data Errors Service
MSC Basic Services

MO Service Barring Service
MSC Basic Services

Unknown SMC
Service
MSC Basic Services
SMMO Failures due to

Short Message
Invalid short message
Service
(SM) Entity Address
MSC Basic Services

No Subscriber in SMC Service
MSC Basic Services
SMMO Success
Times
MSC Basic Services
Short Message
Service
Send SMMO Success

MSC Basic Services
Times
SMMO Success
Times (LAI)
MSC Basic Functions
Traffic Measurement
Global Components
For LAI
Parent topic: SMMO

SMMT
Short message mobile termination (SMMT) refers to the process that the SMC sends a
short message to the UE/MS, and the UE/MS returns a report to the SMC, notifying
whether the short message is received successfully or not.
SMMT Flow
SMMT Flow
Service Model
Signaling Flow
Service Model
A UE/MS receives a short message. The short message mobile terminated (SMMT) flow is
the same for both the 2G and 3G networks.
Signaling Flow
Figure 1 shows the SMMT signaling flow.
Figure 1 SMMT signaling flow

As shown in Figure 1, P1, P2, P3, P4, P5 refers to the measurement points.
The SMMT signaling flow is as follows:

1. Upon receipt of a short message from a UE/MS, the SMC uses the called number
contained in the message to locate the HLR, and then sends a
MAP_SEND_ROUTING_INFO_FOR_SM message to the HLR.
2. The HLR checks the user information after receiving the
MAP_SEND_ROUTING_INFO_FOR_SM message.
If the HLR finds that the UE/MS data does not exist, the roaming of the
UE/MS is not allowed, the UE/MS has subscribed to the barring of
outgoing international calls (BOIC) service, the UE/MS does not
subscribe to the short message service (SMS), MNRF (Mobile-StationNot-Reachable-Flag) is set to TRUE, MCEF (Mobile-Station-MemoryCapacity-Exceeded-Flag) is set to TRUE, or the UE/MS data has been
deleted by the roam-to MSC/VLR, the HLR sends the failure cause to
the SMC. If the SMS priority is set to High, and MNRF and MCEF are
set to TRUE, the HLR still returns the MSC number.
Otherwise, the HLR sends a
MAP_SEND_ROUTING_INFO_FOR_SM_ACK message carrying the
routing information (including the number of the MSC serving the
callee)to the HLR.
3. Based on the obtained MSC number, the SMC sends a
MAP_MT_FORWARD_SHORT_MESSAGE_IND message to the MSC,
transparently forwarding the short message to the MSC. The MSC requests
UE/MS data from the VLR, and then checks the current subscription data of the
UE/MS and mobility management status. If the MSC finds that the UE/MS data
does not exist in the VLR, the current UE/MS state is international mobile
subscriber identity (IMSI) detached, the roaming of the UE/MS to the location
area is not allowed, or the UE/MS does not subscribe to the SMMT service, the
MSC returns an SMMT failure response to the SMC. If the current UE/MS state
is IMSI detached and the roaming of the UE/MS to the location area is prohibited,
the MSC sets MNRF to TRUE in the VLR at the same time.
4. The MSC sends a PAGING message to the UE/MS. If no response is received,
the MSC sends a failure message carrying the cause code "absent subscriber" to
the SMC, and sets MNRF to TRUE in the VLR.
5. The paging is successful. The UE/MS returns a PAGING RESPONSE message to
the MSC.
6. The MSC initiates the service access process, and authenticates and encrypts
the UE/MS.
7. After the access process is complete, the MSC sends a CP DATA message
carrying the short message and related information to the UE/MS.

8. The UE/MS returns a CP ACK message to the MSC, notifying that the CP DATA
message is received (which does not mean that the UE/MS has received the
short message).
9. Upon receipt of the short message, the UE/MS sends a CP DATA message to the
MSC, indicating that the UE/MS has received the short message.
10. The MSC returns a CP ACK message to the UE/MS, indicating that it has
received the CP DATA message.
11. Through a MAP_MT_FORWARD_SHORT_MESSAGE_RSP message, the MSC
notifies the SMC that the short message is sent successfully.
NOTE:
After the access process is complete, the MSC sends a CP DATA message to the
UE/MS. If the UE/MS returns a message indicating that the memory overflows, the
MSC sends an SMMT failure message carrying the corresponding cause code to
the SMC.
If a short message terminated by a mobile subscriber must be divided into several
parts for transmission, the next part can be sent only after the previous part is
sent successfully. If one part fails to be sent, the subsequent parts will not be sent
any more.
Measurement Point
in Flowchart
SMMT Attempts
Short Message
Service
Receive SMMT Times MSC Basic Services

SMMT Attempts (LAI)
P1
Measurement Type
MSC Basic Services
MSC Basic Functions
Traffic Measurement
Global Components
For LAI
SMMT Failures due to

Short Message
Unidentified
Service
Subscribers
SMMT Failures due to
Short Message
ZC-based Service
MSC Basic Services
MSC Basic Services
P2
P3
P4
P5
Barring
Service
Number of First
Pagings in Short
Message Service
Paging
MSC Basic Services
Paging Times
MSC Basic Services
MSC Basic Functions
Traffic Measurement
Global Components
For LAI
Number of Responses
to First Pagings in
Paging
Short Message
Service
MSC Basic Services
Paging Response
Times
MSC Basic Services
MSC Basic Functions
Paging response
times (LAI)
Traffic Measurement
Global Components
For LAI
SMMT Failures due to Short Message

Busy Subscribers
Service
MSC Basic Services

Illegal Subscribers
Service
MSC Basic Services

System Faults
Service
MSC Basic Services
SMMT Success Times
Short Message
Service
MSC Basic Services
Receive SMMT
Success Times
MSC Basic Services
MSC Basic Functions
SMMT Success Times Traffic Measurement

Global Components
(LAI)
For LAI
Parent topic: SMMT
Short Message Notification

In an short message mobile terminated (SMMT) flow, if a short message fails to be sent
due to no response for paging, no response from the callee, or UE/MS memory overflow,
the SMC sends a short message status report to the HLR, notifying the HLR of the Mobile
Station International ISDN Number (MSISDN) of the callee and the originating SMC. Then,
the HLR stores the information in the data record (that is, message waiting data,
abbreviated as messages-waiting-data (MWD)) of the callee, and sets mobile station not
reachable flag (MNRF) in the HLR. At the same time, the SMC temporarily stores the short
message that fails to be sent.
The short message notification flow is indispensable for successful SMMT. The short
message notification flow is categorized as follows:
The flow of notifying the SMC that a UE/MS is reachable.
When a UE/MS reaccesses the network due to call origination, call termination, or
location update, the MSC sends a notification that a short message can be sent
now because the UE/MS is reachable. Then, the HLR informs the SMC that a
short message can be sent now. This process repeats until the short message is
sent successfully or the short message validity period is due.
The flow of notifying the SMC that the memory of a UE/MS is usable.
When the memory of a UE/MS can store a new short message because an old
short message is deleted, the UE/MS sends a notification, informing the MSC that
its memory is usable. Upon receipt of the notification, the MSC sends a notification
to the SMC through the HLR, informing the SMC that a short message can be sent
now because the memory of the UE/MS is usable. Then, the HLR informs the
SMC that a short message can be sent now. This process repeats until the short
message is sent successfully or the short message validity period is due.
Flow of Notifying the SMC that a UE/MS Is Reachable
Flow of Notifying the SMC that the Memory of a UE/MS Is Usable
Flow of Notifying the SMC that a UE/MS Is Reachable

Service Model
Signaling Flow
Service Model
In an short message mobile terminated (SMMT) flow, a short message fails to be sent due
to no response for paging or no response from the callee.
Signaling Flow
Figure 1 shows the flow of notifying the SMC that a UE/MS is reachable.
Figure 1 Signaling flow of notifying the SMC that a UE/MS is reachable

The signaling flow of notifying the SMC that a UE/MS is reachable is as follows:
1. A UE/MS reaccesses the network due to call origination, call termination, or
location update.
2. The MSC sends a service access request or a data check request for location
update to the VLR.
3. The MSC requests user data from the VLR. If MNRF is set, the MSC clears the
setting. At the same time, the MSC sends a notification, informing the HLR that a
short message can be sent now because the UE/MS is reachable.
4. The HLR checks user data. If MNRF is set, the HLR clears the setting, and sends
an AlertSC (MAP_ALERT_SERVICE_CENTRE) message to the SMC.

5. Upon receipt of the AlertSC message, the SMC responds to the HLR, and then
tries to send a short message again at an appropriate time. For details, see
SMMT Flow.
None.
Parent topic: Short Message Notification
Flow of Notifying the SMC that the Memory of a UE/MS Is

Usable
Service Model
Signaling Flow
Service Model
In an short message mobile terminated (SMMT) flow, a short message fails to be sent due
to UE/MS memory overflow.
Signaling Flow
Figure 1 shows the signaling flow of notifying the SMC that the memory of a UE/MS is
usable.
Figure 1 Signaling flow of notifying the SMC that the memory of a UE/MS is usable
As shown in Figure 1, P1, P2 refers to the measurement points.

The signaling flow of notifying the SMC that the memory of a UE/MS is usable is as follows:
1. A UE/MS sends a message to the MSC through the A or Iu interface, notifying the
MSC that the memory of the UE/MS is usable.
2. The MSC sends a MAP_READY_FOR_SHORT_MESSAGE_REQ message

carrying the cause that the memory of the UE/MS is usable to the HLR.
3. The HLR responds to the MSC/VLR with a
MAP_READY_FOR_SHORT_MESSAGE_CNF message.
4. Upon receipt of the response, the MSC sends a response to the UE/MS.
5. The HLR checks user data. If mobile-station-memory-capacity-exceeded-flag
(MCEF) is set, the HLR clears the setting, and sends an AlertSC
(MAP_ALERT_SERVICE_CENTRE) message to the SMC.
6. Upon receipt of the AlertSC message, the SMC responds to the HLR, and then
tries to send a short message again at an appropriate time. For details, see
SMMT Flow.
Measurement Point
in Flowchart
P1
P2
Short Message
Service
Short Message
SMMA Success Times
Service
SMMA Attempts
Parent topic: Short Message Notification

Measurement Type
MSC Basic Services
MSC Basic Services
Fax Services
Intra-MSC TS61 Fax Service Flow
Inter-MSC TS61 Fax Service Flow

Service Model
Signaling Flow
Service Model
MSC.
time division multiplexing (TDM) bearer is used between the BSC and the MGW.
The BSC and the MSC are connected through MTP3-User Adaptation Layer
(M3UA) in non-peer-to-peer mode, that is, the MSC connects to the MGW through
M3UA links, and exchanges Base Station Subsystem Application Part (BSSAP)
messages with the BSC through the MGW that has the embedded signaling
gateway function.
During the call, the caller triggers the voice-to-fax service.
Signaling Flow
Figure 1 shows the intra-MSC TS61 fax service signaling flow.
Figure 1 Intra-MSC TS61 fax service signaling flow
As shown in Figure 1, P1 refers to the measurement point.

The intra-MSC TS61 fax service signaling flow is as follows:
1. A normal voice call is originated. For the signaling flow of the call, see Basic 2G
Call Flow.
2. The originating MS (MS-O) sends a MODIFY message carrying the fax bearer
capability (BC) to the MSC, requesting the modification of the service type from
voice to fax.
3. Based on the subscribed service type and the network capability, the MSC
checks the BC to determine whether the modification is allowed.
If the modification is allowed, the MSC sends a MODIFY message
carrying the fax BC to the terminating MS (MS-T).

If the modification is not allowed, the MSC returns a MODIFY REJECT
message to the MS-O.
4. Upon receipt of the MODIFY message, the MS-T checks the BC to determine
whether the service type can be changed to the fax service.
If the modification is allowed, the MS-T returns a MODIFY COMPLETE
message carrying the supported the fax BC to the MSC.
If the modification is not allowed, the MS-T returns a MODIFY REJECT
message to the MSC.
5. Based on the subscribed service type and the network capability, the MSC
checks the fax BC carried in the message. If the fax BC passes the check, the
MSC sends a MOD REQ message to the MGW to request the modification of the
service type of the MS-T.
6. After modifying the service type successfully, the MGW returns a MOD REPLY
message to the MSC.
7. The MSC sends an ASSIGNMENT REQUEST message carrying CHANNEL
TYPE, instructing the terminating BSC (BSC-T) to change the service type of the
air interface from voice to data.
8. After modifying the service type successfully, the BSC-T returns an
ASSIGNMENT COMPLETE message to the MSC.
9. The MSC sends a MOD REQ message, instructing the MGW to change the
service type of the MS-O from voice to data.
message to the MSC.
TYPE, instructing the originating BSC (BSC-O) to change the service type of the
air interface from voice to data.
12. After modifying the service type successfully, the BSC-O returns an
13. The MSC returns a MODIFY COMPLETE message to the MS-O.
14. The MSC sends a MOD REQ message, requesting the MGW to activate
interworking function (IWF) and start bottom-layer negotiation.
15. The MGW returns a MOD REPLY message.
16. The MGW sends an NTFY REQ message to the MSC to report the bottom-layer
negotiation result.
17. The MSC returns an NTFY REPLY message to the MGW.
18. The MS-O starts sending the fax, and the MS-T starts receiving the fax.
Measurement Point
in Flowchart
P1
Alternate Speech/Data
Bearer Service
Applied Times
Parent topic: Fax Services

Measurement Type
MSC Special Services

Service Model
Signaling Flow
Service Model
A 2G mobile subscriber calls a public switched telephone network (PSTN)
subscriber.
Time division multiplexing (TDM) bearer is used between the BSC and the MGW.
During the call, the caller triggers the voice-to-fax service.
Signaling Flow
Figure 1 shows the inter-MSC TS61 fax service signaling flow.
Figure 1 Inter-MSC TS61 fax service signaling flow

The inter-MSC TS61 fax service signaling flow is as follows:
1. A voice call is originated. For the signaling flow of the call, see Inter-MSC Call
Flow (MS -> PSTN).
2. The MS-O sends a MODIFY message carrying the fax bearer capability (BC) to
the MSC, requesting the modification of the service type from voice to fax.
3. The MSC sends a MOD REQ message, requesting the MGW to change the
service type of the outgoing-to-PSTN termination from voice to data.
message to the MSC.
5. The MSC sends a MOD REQ message, requesting the MGW to change the
service type of the termination on the access side from voice to data.
message to the MSC.

TYPE, instructing the BSC-O to change the service type of the air interface from
voice to data.
8. After modifying the service type successfully, the BSC-O returns an
9. The MSC returns a MODIFY COMPLETE message to the MS-O.
11. The MGW returns a MOD REPLY message.
negotiation result.
13. The MSC returns an NTFY REPLY message to the MGW.
Measurement Point
in Flowchart
P1
Bearer Service
Applied Times

Measurement Type

Service Model
Signaling Flow
Service Model
MSC.
The BSC and the MSC are connected through MTP3-User Adaptation Layer
(M3UA) in non-peer-to-peer mode, that is, the MSC connects to the MGW through
M3UA links, and exchanges Base Station Subsystem Application Part (BSSAP)
messages with the BSC through the MGW that has the embedded signaling
gateway function.
Signaling Flow
The signaling flow of the intra-MSC TS62 fax service is almost the same as that of a normal
call (only IEs in certain messages are different). For details, see Figure 1.
Figure 1 Intra-MSC TS62 fax service signaling flow

The intra-MSC TS62 fax service signaling flow is as follows:
1. The MS-O sends a Setup message carrying the fax bearer capability (BC) to the
MSC, notifying the MSC of the TS62 fax service.
2. The MSC checks and finds that both the subscriber and the network support the
TS62 service. Then, the MSC returns a Call proceeding message to the MS-O.
3. The MSC sends an send routing information (SRI) message to the HLR based on
the fax BC.
4. The MSC establishes the bearer on the caller side. The MSC establishes a data
termination on the caller side. It assigns the air interface on the caller side, and
allocates the air interface channels of the data service type.
5. The MSC sends a Setup message carrying the fax BC to the MS-T, notifying the
MS-T of the TS62 service.
6. The MS-T supports the TS62 service, and thus returns a Call confirmed message
carrying the supported fax BC to the MSC.
7. The MSC establishes the bearer on the callee side in the same way as
establishing the bearer on the caller side.
8. The MS-T sends an Alerting message to the MSC. Upon receipt of the message,
the MSC forwards the Alerting message to the MS-O.
9. The callee answers the call and the MS-T sends a Connect message to the MSC.
11. Upon receipt of the MOD REQ message, the MGW returns a MOD REPLY
message to the MSC.
12. Upon receipt of the Connect acknowledge message from the MS-T, the MSC
sends a Connect acknowledge message to the MS-O.
negotiation result.
14. Upon receipt of the NTFY REQ message, the MSC returns an NTFY REPLY
message to the MGW.
Measurement Point
in Flowchart
P1
Bearer Service
Applied Times

Measurement Type

Service Model
Signaling Flow
Service Model
A 2G mobile subscriber calls a 2G mobile subscriber served by another MSC.
Bearer Independent Call Control (BICC) signaling is used between the MSCs. The
bearer is established in forward fast mode.
Signaling Flow
The signaling flow of the inter-MSC TS62 fax service is almost the same as that of a normal
call (only IEs in certain messages are different). For details, see Figure 1.
Figure 1 Inter-MSC TS62 fax service signaling flow

The inter-MSC TS62 fax service signaling flow is as follows:
1. Based on the local office information, the originating MSC (MSC-O) determines to
route the call out through a BICC trunk. The MSC sends a bearer establishment
message to the MGW and requests the MGW to report the channel information.
After the MGW reports the channel information, this information is packed in an
outgoing message and sent out. Different from a voice call, User Service
Information is set to data service.
2. The terminating MSC (MSC-T) selects a route for the call based on the IEs
contained in the IAM message and the local office information, sends the bearer
information in the IAM message to the MGW, and requests the MGW to prepare
bearer resources. After the MGW reports the bearer information, the MSC-T
constructs and returns an APM message to the MSC-O.
3. On setting up the bearer on the callee side and assigning the required Iu interface
resources, the MSC-T returns an address complete message (ACM) message to
the MSC-O. At this time, the callee is alerted and the caller hears the ringback
tone.
4. The callee answers the call, and the MSC-T returns an answer message (ANM)
message to the MSC-O. Then, the caller starts sending the fax, and the callee
starts receiving the fax.
Measurement Point
in Flowchart
Measurement Type
P1
TERMINATED
INCOMING DATA
CALL ATTEMPT
Outgoing Calls in
Mobile Office
Bearer Traffic
P2
TERMINATED
INCOMING DATA
ALERT
Outgoing Calls in
Mobile Office
Bearer Traffic
TERMINATED
INCOMING DATA
ANSWER
Outgoing Calls in
Mobile Office
Bearer Traffic
Automatic Facsimile
G3 Applied Times
Bearer Service
P3

Supplementary Services
Basic Operations
Number Presentation
Call Completion
Multi Party SS (MPTY)
Call Forwarding
USSD
Call Restriction
Basic Operations
Description of the different statuses of the supplementary services
The basic operations about supplementary services include registration, deregistration,
activation, deactivation, and query. These operations enable carriers or users to control or
use the supplementary services more conveniently and flexibly. They can be performed by
carriers, users, or the system without subscription.
Description of the different statuses of the supplementary services
Status
Active Status
Active Status
Register Status
Example
Active
Not Active
Registered
Explanation
network element
(NE) Location
The supplementary
services are
activated.
The supplementary
services are
subscribed on the
HLR and the HLR
brings the service
status to the MSC
server during location
update.
The supplementary
services are
deactivated.
The supplementary
services are
subscribed on the
HLR and the HLR
brings the service
status to the MSC
update.
The supplementary
services are
registered.
The supplementary
services are
subscribed on the
HLR and the HLR
brings the service
status to the MSC
update.
The supplementary
The supplementary
services are
subscribed on the
HLR and the HLR
Register Status
Provision Status
Provision Status
Quiescence Status
Quiescence Status
Not Registered
Provisioned
services are
deregistered.
brings the service

status to the MSC
update.
The supplementary
services are
subscribed on the
The supplementary
HLR and the HLR
services are provided. brings the service
status to the MSC
update.
The supplementary
services are
subscribed on the
HLR and the HLR
brings the service
status to the MSC
update.
Not Provisioned
The supplementary
services are not
provided.
Quiescent
The supplementary
services are
subscribed on the
The supplementary
HLR and the HLR
services are disabled. brings the service
status to the MSC
update.
Not Quiescent
The supplementary
services are
subscribed on the
The supplementary
HLR and the HLR
services are enabled. brings the service
status to the MSC
update.
NOTE:
The MSC server checks only the Active Status and Quiescence Status of the
supplementary services.
Provided that the supplementary services are subscribed on the HLR correctly,
abnormal circumstances do not occur on the MSC server.
Supplementary Service Registration Flow
Supplementary Service Activation Flow
Supplementary Service Deactivation Flow
Supplementary Service Query Flow
Supplementary Service Deregistration Flow
Parent topic: Supplementary Services
Supplementary Service Registration Flow

Service Model
Signaling Flow
Service Model
A supplementary service is registered.
Signaling Flow
Figure 1 shows the signaling flow of supplementary service registration.
Figure 1 Signaling flow of supplementary service registration

The signaling flow of supplementary service registration is as follows:
1. A UE/MS sends a connection management (CM) service request message to the
MSC/VLR to request service access.
2. The MSC/VLR starts the authentication and encryption process.
3. If the MSC/VLR accepts the service access request, the UE/MS sends a
Register message to the MSC/VLR. The MSC/VLR transparently forwards this

message to the HLR. This message carries all the registered operation codes
and the operation code of the supplementary service to be registered.
4. The HLR registers the corresponding supplementary service and responds to the
MSC/VLR with a Facility message. Then, the MSC/VLR transparently forwards
this message to the UE/MS, notifying that the supplementary service is registered
successfully.
5. The HLR sends the related registration information to the VLR.
NOTE:
To use a supplementary service, a user must register the service on the HLR first.
Measurement Point
in Flowchart
Measurement Type
Mobile Application
Illegal Supplementary
Signaling and
Part (MAP) Standard
Service Operation
Interfaces
Operations
P1
Supplementary
Service Status Error
MAP Standard
Operations
Signaling and
Interfaces
Supplementary
MAP Standard
Service Incompatible Operations
Signaling and
Interfaces
Parent topic: Basic Operations

Supplementary Service Activation Flow

Service Model
Signaling Flow
Service Model
A supplementary service is activated.
Signaling Flow
Figure 1 shows the signaling flow of supplementary service activation.
Figure 1 Signaling flow of supplementary service activation

The signaling flow of supplementary service activation is as follows:

MAP_ACTIVATE_SS_REQ message to the MSC/VLR. The MSC/VLR
transparently forwards this message to the HLR. This message carries the
operation code of the supplementary service to be activated.
4. The HLR checks the user information. If a password is required, the HLR sends a
MAP_GET_PASSWORD_REQ message to the MSC/VLR. Then, the MSC/VLR
transparently forwards this message to the UE/MS.
5. Upon receipt of the MAP_GET_PASSWORD_REQ message, the UE/MS
prompts the user to enter the password. After the password is entered, the
UE/MS sends a MAP_GET_PASSWORD_RSP message to the MSC/VLR. Then,
the MSC/VLR transparently forwards this message to the HLR.
6. The HLR verifies the password. If the password is correct, the HLR activates the
supplementary service and returns a MAP_ACTIVATE_SS_RSP message to the
MSC/VLR. Then, the MSC/VLR transparently forwards this message to the
UE/MS, notifying that the supplementary service is activated successfully.
7. The HLR sends the related information to the VLR.
NOTE:
Certain services need not be activated and can be used directly after registration.
Measurement Point
in Flowchart
Measurement Type
Mobile Application
Signaling and
Part (MAP) Standard
Service Operation
Interfaces
Operations
Supplementary
P1
MAP Standard
Operations
Signaling and
Interfaces
Supplementary
MAP Standard
Service Incompatible Operations
Signaling and
Interfaces
Supplementary
Signaling and
MAP Standard
Service Subscription
Violation
Operations

Interfaces
Supplementary Service Deactivation Flow

Service Model
Signaling Flow
Service Model
A supplementary service is deactivated.
Signaling Flow
Figure 1 shows the signaling flow of supplementary service deactivation.
Figure 1 Signaling flow of supplementary service deactivation

The signaling flow of supplementary service deactivation is as follows:

MAP_DEACTIVATE_SS_REQ message to the MSC/VLR. The MSC/VLR
operation code of the supplementary service to be deactivated.
4. The HLR checks the user information. If a password is required, the HLR sends a
MAP_GET_PASSWORD_REQ message to the MSC/VLR. Then, the MSC/VLR
5. Upon receipt of the MAP_GET_PASSWORD_REQ message, the UE/MS
prompts the user to enter the password. After the password is entered, the
UE/MS sends a MAP_GET_PASSWORD_RSP message to the MSC/VLR. Then,
the MSC/VLR transparently forwards this message to the HLR.
6. The HLR verifies the password. If the password is correct, the HLR deactivates
the supplementary service and returns a MAP_DEACTIVATE_SS_RSP message
to the MSC/VLR. Then, the MSC/VLR transparently forwards this message to the
UE/MS, notifying that the supplementary service is deactivated successfully.
7. The HLR sends the related information to the VLR.
Measurement Point
in Flowchart
Measurement Type
Mobile Application
Signaling and
Part (MAP) Standard
Service Operation
Interfaces
Operations
P1
Supplementary
MAP Standard
Operations
Signaling and
Interfaces
Supplementary
Service Subscription
Violation
MAP Standard
Operations
Signaling and
Interfaces

Supplementary Service Query Flow

Service Model
Signaling Flow
Service Model
A supplementary service is queried.
Signaling Flow
Figure 1 shows the signaling flow of supplementary service query.
Figure 1 Signaling flow of supplementary service query

The signaling flow of supplementary service query is as follows:
MAP_INTERROGATE_SS_REQ message to the MSC/VLR. The MSC/VLR
operation code of the supplementary service to be queried.
4. The HLR queries the related information and returns a

MAP_INTERROGATE_SS_RSP message to the MSC/VLR. The MSC/VLR
Measurement Point
in Flowchart
P1
Measurement Type
Mobile Application
Signaling and
Part (MAP) Standard
Service Operation
Interfaces
Operations
Supplementary
Service Unavailable
MAP Standard
Operations

Signaling and
Interfaces
Supplementary Service Deregistration Flow

Service Model
Signaling Flow
Service Model
A supplementary service is deregistered.
Signaling Flow
Figure 1 shows the signaling flow of supplementary service deregistration.
Figure 1 Signaling flow of supplementary service deregistration

The signaling flow of supplementary service deregistration is as follows:
MAP_ERASE_SS_REQ message to the MSC/VLR. The MSC/VLR transparently

forwards this message to the HLR. This message carries the operation code of
the supplementary service to be deregistered.
4. The HLR deregisters the corresponding supplementary service and responds to
the MSC/VLR with a MAP_ERASE_SS_RSP message. Then, the MSC/VLR
transparently forwards this message to the UE/MS, notifying that the
supplementary service is deregistered successfully.
5. The HLR sends the related deregistration information to the VLR.
Measurement Point
in Flowchart
P1
Measurement Type
Illegal Supplementary MAP Standard

Service Operation
Operations
Signaling and
Interfaces
Supplementary
Signaling and
Interfaces
MAP Standard
Operations

Number Presentation
The number presentation services are used to determine whether to display the line identity
(LI) of the other party on the terminal of the caller or the callee. Line identity information
includes the integrated services digital network (ISDN)/Mobile Station International ISDN
Number (MSISDN) of the caller or the callee and the sub-addresses (optional; the public
land mobile network (PLMN) does not manage the sub-addresses).
Line identity is divided into two types:
Calling Line Identity (CLI): used to identify a caller.
Connected Line Identity (COL): used to identify a connected subscriber, that is,
the final callee. In a common call, the callee is the connected subscriber; in a
forwarded call, the forwarded-to subscriber is the connected subscriber.
The Presentation Indicator (PI) and Screening Indicator (SI) are also sent when an LI is
sent.
PI:
Presentation allowed
Presentation restricted
Number not available due to interworking
SI:
User-provided, verified and passed
User-provided, verified and failed
Network provided
Based on the type of the displayed number (calling number or connected number) and
whether to display the number, number presentation services are categorized as follows:
Calling line identification presentation (CLIP)
Calling line identification restriction (CLIR)
Connected line identification presentation (COLP)
Connected line identification restriction (COLR)
NOTE:
CLIP and CLIR are mutually exclusive, and CLIR enjoys a higher priority than
CLIP. When both CLIP and CLIR are registered, the system starts the CLIR
service flow generally. If the parameter Override Category is set to Enable for
CLIP, the system starts the CLIP service flow.
COLP and COLR are mutually exclusive, and COLR enjoys a higher priority than
COLP. When both COLP and COLR are registered, the system starts the COLR
service flow generally. If the parameter Override Category is set to Enable for
COLP, the system starts the COLP service flow.
CLIP Flow
CLIR Flow
COLP Flow
COLR Flow
CLIP Flow
Service Model
Signaling Flow
Service Model
MSC.
The caller does not subscribe to the calling line identification restriction (CLIR)
service.
The callee subscribes to the calling line identification presentation (CLIP) service.
Signaling Flow
Figure 1 shows the CLIP signaling flow.
Figure 1 CLIP signaling flow

The CLIP signaling flow is as follows:
1. The UE-O calls the UE-T. After accessing the network, the UE-O sends a Setup
message to the MSC/VLR. The parameter Calling party binary-coded data (BCD)
number in the message contains calling line identification (CLI), push initiator (PI),
and service information (SI). Upon receipt of the Setup message, the MSC/VLR
requests the Mobile Station International integrated services digital network
(ISDN) Number (MSISDN) and subscription data of the caller from the HLR.
2. The MSC/VLR originates the send routing information (SRI) flow.

3. The MSC/VLR requests the subscription data of the callee, constructs a Setup
message based on the CLI, PI, and SI received from the caller side, and then
sends the Setup message to the UE-T. This Setup message carries the MSISDN
of the caller. In this message, SI is set to Network provided and PI is set to
Presentation allowed for the caller. Later, the callee is alerted, and the calling
number is displayed on the mobile phone of the callee.
Measurement Point
in Flowchart
P1
Invocation of
Supplementary
Services
Measurement Type
Supplementary
Services
Bearer Traffic
Implement of
Supplementary
Supplementary
Services
Services Successfully
Bearer Traffic
Parent topic: Number Presentation

CLIR Flow
Service Model
Signaling Flow
Service Model
MSC.
The caller subscribes to the calling line identification restriction (CLIR) service.
The callee does not enable the calling line identification presentation (CLIP)
override function.
Signaling Flow
Figure 1 shows the CLIR signaling flow.
Figure 1 CLIR signaling flow

The CLIR signaling flow is as follows:
1. The UE-O calls the UE-T. After accessing the network, the UE-O sends a Setup
message to the MSC/VLR. The parameter Calling party binary-coded data (BCD)
number in the message contains calling line identification (CLI), push initiator (PI),
and service information (SI). Upon receipt of the Setup message, the MSC/VLR
requests the Mobile Station International ISDN Number (MSISDN) and
subscription data of the caller from the HLR.
2. The MSC/VLR originates the send routing information (SRI) flow.

3. The MSC/VLR requests the subscription data of the callee, constructs a Setup
message based on the CLI, PI, and SI received from the caller side, and then
sends the Setup message to the UE-T. This Setup message does not contain the
MSISDN of the caller. In the message, SI is set to Network provided and PI is set
to Presentation restricted for the caller. Later, the callee is alerted, but the calling
number is not displayed on the mobile phone of the callee.
Measurement Point
in Flowchart
P1
Invocation of
Supplementary
Services
Measurement Type
Supplementary
Services
Bearer Traffic
Implement of
Supplementary
Supplementary
Services
Bearer Traffic

COLP Flow
Service Model
Signaling Flow
Service Model
A, B, and C are 3G mobile subscribers. Subscriber A calls subscriber B, and the
call is forwarded to subscriber C unconditionally.
Subscriber A subscribes to the connected line identification presentation (COLP)
service.
Subscriber C does not subscribe to the connected line identification restriction
(COLR) service.
Signaling Flow
Figure 1 shows the COLP signaling flow.
Figure 1 COLP signaling flow

The COLP signaling flow is as follows:
1. UE-A calls UE-B. After accessing the network, UE-A sends a Setup message to
the MSC/VLR. The parameter Calling party binary-coded data (BCD) number in
the message contains calling line identification (CLI), push initiator (PI), and
service information (SI). Upon receipt of the Setup message, the MSC/VLR
2. The MSC/VLR locates subscriber B and originates the send routing information
(SRI) flow to obtain the mobile station roaming number (MSRN) of subscriber B.
After finding that subscriber B subscribes to the call forwarding unconditional
(CFU) service, the HLR returns the subscribed CFU information about subscriber
B.
3. The MSC/VLR locates subscriber C and originates the SRI flow to obtain the
MSRN of subscriber C.
4. The MSC/VLR sends a Setup message to UE-C.
5. Subscriber C answers the call and UE-C sends a Connect message to the
MSC/VLR.
6. Based on the subscription data of the caller, the MSC/VLR sets Connected
number in the Connect message. The value of Connected number contains
connected line identity (COL), SI (Network provided), and PI (Presentation
allowed). The MSC/VLR sends a Connect message carrying the connected
number to UE-A. Later, the connected number is displayed on the mobile phone
of the caller.
Measurement Point
in Flowchart
P1
Invocation of
Supplementary
Services
Measurement Type
Supplementary
Services
Bearer Traffic
Implement of
Supplementary
Supplementary
Services
Bearer Traffic

COLR Flow
Service Model
Signaling Flow
Service Model
A, B, and C are 3G mobile subscribers. Subscriber A calls subscriber B, and the
call is forwarded to subscriber C unconditionally.
Subscriber A does not subscribe to the connected line identification presentation
(COLP) service.
Subscriber C subscribes to the connected line identification restriction (COLR)
service.
Signaling Flow
Figure 1 shows the COLR signaling flow.
Figure 1 COLR signaling flow

The COLR signaling flow is as follows:
1. UE-A calls UE-B. After accessing the network, UE-A sends a Setup message to
the MSC/VLR. The parameter Calling party binary-coded data (BCD) number in
the message contains calling line identification (CLI), push initiator (PI), and
service information (SI). Upon receipt of the Setup message, the MSC/VLR
2. The MSC/VLR locates subscriber B and originates the send routing information
(SRI) flow to obtain the mobile station roaming number (MSRN) of subscriber B.
After finding that subscriber B subscribes to the Call Forwarding - Unconditional
(CFU) service, the HLR returns the subscribed CFU information about subscriber
B.
3. The MSC/VLR locates subscriber C and originates the SRI flow to obtain the
MSRN of subscriber C.
4. The MSC/VLR sends a Setup message to UE-C.
5. Subscriber C answers the call and UE-C sends a Connect message to the
MSC/VLR.
6. Based on the subscription data of the connected subscriber, the MSC/VLR sets
Connected number in the Connect message. The value of Connected number
contains connected line identity (COL), SI (Network provided), and PI
(Presentation restricted). The MSC/VLR sends a Connect message that does not
carry the connected number to UE-A. Later, the connected number is not
displayed on the mobile phone of the caller.
Measurement Point
in Flowchart
P1
Invocation of
Supplementary
Services
Measurement Type
Supplementary
Services
Bearer Traffic
Implement of
Supplementary
Supplementary
Services
Bearer Traffic

Call Completion
The call completion services contain the call hold (CH) service and the call wait (CW)
service.
Call hold: It enables a CH service subscriber to hold an established call and then
to retrieve the call whenever needed. When the call is held, the network still
reserves the resources allocated to the call.
If the service subscriber holds only one call, the subscriber can:
retrieve the call.
originate a new voice call.
release the call.
If the service subscriber holds one call and talks with a subscriber in another call,
the subscriber can:
alternate between the two calls.
release the ongoing call.
release the held call.
release both calls.
receive a notification for a new incoming call.
Call wait: When there is a new incoming call to the CW service subscriber who has
established a call, the CW service subscriber receives the message "Call is
waiting" and hears the prompt tone, and the waiting subscriber hears the waiting
announcement.
If the service subscriber holds only one call, the subscriber can:
hold or release the established call and then answer the new call when
the established call is active.
answer the new call directly or release the held call and then answer the
new call when the subscriber is holding the established call.
answer the new call directly or hold the established call and then answer
the new call when the subscriber is being held.
ignore or reject the new call when the subscriber does not want to
answer the new call.
CH Flow
CW Flow
CW Failure Flow
CH Flow
Service Model
Signaling Flow
Service Model
A and B are 3G mobile subscribers served by the same MSC.
C is a fixed-line subscriber.
Subscriber A subscribes to the call hold (CH) service.
Subscribers A and B are in an active call.
Subscriber A holds the call with subscriber B, and then calls subscriber C.
Signaling Flow
Figure 1 shows the CH signaling flow.
Figure 1 CH signaling flow

The CH signaling flow is as follows:
1. UE-A calls UE-B. During the call, UE-A sends a Hold message to the MSC/VLR.
Any party who subscribes to the CH service can originate a CH service request
by selecting the corresponding function on the menu of the mobile phone.
2. The MSC/VLR checks the user information obtained from the HLR during the first
call setup, and finds that UE-A has subscribed to the CH service. Then, the
MSC/VLR requests the MGW to change the bearer relation by sending a MOV
REQ message and requests the MGW to play the CH announcement to UE-B
through a MOD REQ message.
3. The MSC/VLR sends a Hold Acknowledge message, notifying UE-A that the CH
request has been accepted.

4. The MSC/VLR sends a Facility message, notifying UE-B that the call is held. If
the parameter for determining whether to display an indication on the screen is
set to Yes, a CH indication message (for example, call on hold) is displayed on
the mobile phone of UE-B; otherwise, no CH indication message is displayed on
the mobile phone of UE-B.
5. UE-A originates a call to PSTN-C.
6. During the call between PSTN-C and UE-A, UE-A sends a Hold message to the
MSC/VLR and originates a swap operation, that is, it holds the call with PSTN-C
and retrieves the call with UE-B. This request can be originated through the menu
of the mobile phone.
7. At the same time, UE-A sends a Retrieve message to the MSC/VLR to retrieve
the held call with UE-B.
8. Upon receipt of the Retrieve request, the MSC/VLR returns a Hold Acknowledge
message to UE-A, indicating that the Hold request is accepted.
9. The MSC/VLR sends a MOV REQ message, instructing the MGW to change the
bearer relation. After establishing the bearer, the MGW returns a MOV REPLY
message to the MSC/VLR.
10. The MSC/VLR returns a Retrieve acknowledge message to UE-A, indicating that
the Retrieve request is accepted.
11. The MSC/VLR sends a Facility message, notifying UE-B to retrieve the call with
UE-A.
12. The MSC/VLR sends a call progress (CPG) message to MSC-C serving PSTNC, notifying MSC-C to hold the call with PSTN-C.
13. Subscribers A and B are in an active call; the call between subscribers A and C is
held.
Measurement Point
in Flowchart
P1
Invocation of
Supplementary
Services
Supplementary
Services
Measurement Type
Bearer Traffic
P2
Implement of
Supplementary
Supplementary
Services
Bearer Traffic
P3
Invocation of
Supplementary
Services
Supplementary
Services
Bearer Traffic
P4
Implement of
Supplementary
Supplementary
Services
Bearer Traffic
Parent topic: Call Completion

CW Flow
Service Model
Signaling Flow
Service Model
Subscribers A and C are 3G mobile subscribers served by the same mobile
switching center (MSC) server.
Subscriber B is a fixed-line subscriber.
Subscriber A subscribes to the call hold (CH) service and the call waiting (CW)
service.
Subscribers A and B are in an active call.
Subscriber C calls subscriber A. Subscriber C hears the CW announcement or a
ring back tone. Subscriber A presses the answer key. The CH flow is initiated for
subscriber B. If the CH flow succeeds, subscriber C talks with subscriber A. If the
CH flow fails, the call is not connected.
Signaling Flow
Figure 1 shows the CW signaling flow.
Figure 1 CW signaling flow

The CW signaling flow is as follows:
1. UE-A calls PSTN-B. During the call, UE-C calls UE-A. If UE-A wants to answer
the call, UE-A presses the answer key and sends a Hold message to the MSC
server/visitor location register (VLR).
2. The MSC server/VLR sends a MOV REQ message, instructing the media
gateway (MGW) to change the bearer relationship. After the bearer is
established, the MGW returns a MOV REPLY message to the MSC server/VLR.
3. The MSC server/VLR checks the user information obtained from the home
location register (HLR) during the first call setup, and finds that UE-A has
subscribed to the CH service. Then, the MSC server/VLR sends a Hold
Acknowledge message, notifying UE-A that the Hold request is accepted.
4. UE-A sends a Connect message to the MSC server/VLR. Then, the MSC
server/VLR transparently forwards the message to UE-C.
5. At the same time, the MSC server/VLR sends a MOV REQ message, instructing
the MGW to change the bearer relationship. After establishing the bearer, the
MGW returns a MOV REPLY message to the MSC server/VLR.
6. After UE-A receives the Connect acknowledge message from UE-C, the call is
connected.
7. UE-A and UE-C start the conversation.
Measurement Point
in Flowchart
Invocation of
Supplementary
Services
Measurement Type
Supplementary
Services
Bearer Traffic
Implement of
Supplementary
Supplementary
Services
Bearer Traffic
P2
Invocation of
Supplementary
Services
Supplementary
Services
Bearer Traffic
P3
Implement of
Supplementary
Supplementary
Services
Bearer Traffic
P1

CW Failure Flow
Service Model
Signaling Flow
Service Model
Subscribers A and C are 3G mobile subscribers served by the same mobile
switching center (MSC) server.
Subscriber B is a fixed-line subscriber.
Subscriber A does not subscribe to the call waiting (CW) service.
When subscribers A and B are in an active call, subscriber C calls subscriber A.
NOTE:
The MSC server releases the call when subscriber C calls subscriber A if subscriber A does
not subscribe to the CW or call forwarding service. If subscriber A subscribes to the call
forwarding service, the MSC server forwards the call.
Signaling Flow
Figure 1 shows the CW failure signaling flow when subscriber A does not subscribe to the
CW or call forwarding service.
Figure 1 CW failure signaling flow

The CW failure signaling flow is as follows:
1. UE-C calls UE-A, and sends a Setup message to the MSC server/visitor location
register (VLR).
2. Upon receipt of the Setup message, the MSC server/VLR returns a Call
proceeding message to UE-C, notifying UE-C that the network is processing the
Setup request.
3. The MSC server/VLR locates UE-A and originates the send routing information
(SRI) flow to obtain the mobile station roaming number (MSRN) of UE-A. After
checking the UE-A data, the MSC server/VLR finds that UE-A does not subscribe
to the CW service; Therefore, the MSC server/VLR does not send a Setup
message to UE-A.
4. The MSC server/VLR sends a radio access bearer (RAB) ASSIGNMENT
REQUEST message to UE-C, allocating terrestrial resources and air interface
resources for UE-C. This assignment aims to play the failure announcement to
UE-C.
5. Upon receipt of an RAB ASSIGNMENT RESPONSE message from UE-C, the
MSC server/VLR sends a Disconnect message in which the cause-value is userbusy to UE-C.
6. At the same time, the MSC server/VLR requests the media gateway (MGW) to
play the failure announcement to UE-C. After the failure announcement is played,
the MSC server/VLR releases the network resources and air interface resources
seized by the call.
NOTE:
Assume that UE-A who subscribes to the CW service is engaged in an active call with
PSTN-B, UE-C calls UE-A, and UE-C is being alerted. At this time, when UE-D calls UE-A,
UE-D receives a message indicating that the called party is busy and the call fails.
None.
Multi Party SS (MPTY)

The Multi Party SS(MPTY) service enables a subscriber to talk with multiple parties in
multiple calls at the same time. That is, three or more subscribers (attendees) can be
engaged in one call at the same time. An MPTY call must be originated and established by
one subscriber (the controlling party). The controlling party can perform the following
operations:
Hold the MPTY call and then retrieve it when needed.
Hold the MPTY call and originate a new call, for example to subscriber D.
Alternate between the MPTY call and the call with subscriber D, that is, hold the
MPTY call and talk with subscriber D, or hold the call with subscriber D and then
activate the MPTY call.
Start private conversation with any remote party in the MPTY call.
Release a remote party.
Release the MPTY call.
Flow of Originating an Multi Party SS (MPTY) by the Controlling Party
Flow of Holding an MPTY Call by the Controlling Party
Flow of Activating a Held MPTY Call by the Controlling Party
Flow of Adding a Remote Party to an MPTY Call
Flow of Splitting an MPTY Call
MPTY Call Failure Flow
Flow of Originating an Multi Party SS (MPTY) by the

Controlling Party
Service Model
Signaling Flow
Service Model
A and C are 3G mobile subscribers served by the same MSC.
B is a fixed-line subscriber.
Subscriber A is the controlling party, and subscribes to the call hold (CH) service
and the MultiParty (MPTY) service.
Signaling Flow
Figure 1 shows the signaling flow of originating an Multi Party SS (MPTY) by the controlling
party.
Figure 1 Signaling flow of originating an Multi Party SS (MPTY) by the controlling party

The signaling flow of originating an Multi Party SS (MPTY) by the controlling party is as
follows:
1. UE-A and PSTN-B are engaged in a call. UE-A holds the call with PSTN-B, and
starts a call with UE-C. At this time, UE-A sends a Facility message to the
MSC/VLR to originate an Multi Party SS (MPTY). This operation can be
implemented through the menu of the mobile phone.
2. Upon receipt of the Facility message from UE-A, the MSC/VLR returns a Facility
message based on the subscription data of UE-A, notifying UE-A that the MPTY
service request is accepted.
3. The MSC/VLR sends a Facility message to UE-C, adding UE-C to the Multi Party
SS (MPTY).
4. The MSC/VLR sends the first call progress (CPG) message to PSTN-B to
activate the call between UE-A and PSTN-B.
5. The MSC/VLR sends the second CPG message to PSTN-B, adding PSTN-B to
the Multi Party SS (MPTY).
6. UE-A, PSTN-B, and UE-C are engaged in an Multi Party SS (MPTY).
Measurement Point
in Flowchart
Measurement Type
P1
Invocation of
Supplementary
Services
Supplementary
Services
Bearer Traffic
P2
Implement of
Supplementary
Supplementary
Services
Bearer Traffic
Parent topic: Multi Party SS (MPTY)

Flow of Holding an MPTY Call by the Controlling Party

Service Model
Signaling Flow
Service Model
B is a fixed-line subscriber.
and the MultiParty (MPTY) service.
Subscribers A, B, and C are engaged in the MPTY call.
Signaling Flow
Figure 1 shows the signaling flow of holding an MPTY call by the controlling party.
Figure 1 Signaling flow of holding an MPTY call by the controlling party

The signaling flow of holding an MPTY call by the controlling party is as follows:
1. UE-A expects to hold the MPTY call. UE-A chooses the Hold function from the
menu of the mobile phone, and sends a Facility message to the MSC/VLR,
requesting the MSC/VLR to hold the MPTY call.
2. Upon receipt of the Hold MPTY request from UE-A, the MSC/VLR responds with
a Facility message, notifying that the Hold MPTY request is accepted. At the
same time, the MSC/VLR needs to notify the remote parties that the controlling
party has originated a CH request. After the remote parties hear the notification,
the MPTY call is held.
3. The MSC/VLR sends a Facility message to UE-C, notifying that the MPTY call is
held by the controlling party. At this time, the message "on hold" is displayed on
UE-C.
4. The MSC/VLR sends a call progress (CPG) message to the network serving
PSTN-B, notifying that the MPTY call is held by the controlling party.
NOTE:
When the controlling party originates a Hold MPTY request, the MSC/VLR needs to notify
all the remote parties that the controlling party has originated a CH request. When a remote
party originates a Hold MPTY request, the MSC/VLR needs to notify the controlling party
only.
None.
Flow of Activating a Held MPTY Call by the Controlling

Party
Service Model
Signaling Flow
Service Model
B and D are fixed-line subscribers.
and the multiparty (MPTY) service.
Subscriber A holds the MPTY call.
Signaling Flow
Figure 1 shows the signaling flow of activating a held MPTY call by the controlling party.
Figure 1 Signaling flow of activating a held MPTY call by the controlling party

The signaling flow of activating a held MPTY call by the controlling party is as follows:
1. UE-A sends a Facility message, requesting the MSC/VLR to retrieve the MPTY
call.
2. Upon receipt of the Retrieve MPTY request, the MSC/VLR responds with a
Facility message to UE-A, notifying that the Retrieve MPTY request is accepted.
At the same time, the MSC/VLR notifies PSTN-B, UE-C, and PSTN-D that the
MPTY call is activated, that is, the MSC/VLR needs to notify all the four parties
of the MPTY call.
3. The MSC/VLR sends a Facility message, notifying UE-C that the MPTY call is
retrieved.
4. The MSC/VLR sends a call progress (CPG) message, notifying PSTN-B that the
MPTY call is retrieved.
5. The MSC/VLR sends a CPG message, notifying PSTN-D that the MPTY call is
retrieved.
6. UE-A, PSTN-B, UE-C, and PSTN-D are engaged in the MPTY call again.
None.
Flow of Adding a Remote Party to an MPTY Call

Service Model
Signaling Flow
Service Model
Subscribers A, B, and C are engaged in an MPTY call.
Signaling Flow
Figure 1 shows the signaling flow of adding a remote party to an MPTY call.
Figure 1 Signaling flow of adding a remote party to an MPTY call

The signaling flow of adding a remote party to an MPTY call is as follows:
1. UE-A holds the MPTY call, and then originates a call to PSTN-D. After the new
call is connected, UE-A adds PSTN-D to the MPTY call by choosing the
corresponding function from the menu of the mobile phone, and sends a Facility
message to the MSC/VLR, requesting to add PSTN-D to the MPTY call.
2. Upon receipt of the Build MPTY request, the MSC/VLR responds with a Facility
message to UE-A, notifying that the Build MPTY request is accepted. At the
same time, the MSC/VLR notifies PSTN-B, UE-C, and PSTN-D to join the MPTY
call, that is, the MSC/VLR needs to notify all the four parties of the MPTY call.
3. The MSC/VLR sends the first Facility message to UE-C to activate the call
between UE-A and PSTN-B.
4. The MSC/VLR sends the second Facility message to UE-C, adding UE-C to the
MPTY call.
5. The MSC/VLR sends the first call progress (CPG) message to PSTN-B to
activate the call between UE-A and PSTN-B.
6. The MSC/VLR sends the second CPG message to PSTN-B, adding PSTN-B to
the MPTY call.
7. The MSC/VLR sends a CPG message to PSTN-D, adding PSTN-D to the MPTY
call.
8. UE-A, PSTN-B, UE-C, and PSTN-D are engaged in the MPTY call.
None.
Flow of Splitting an MPTY Call

Service Model
Signaling Flow
Service Model
When subscribers A, B, C, and D are engaged in an MPTY call, subscriber A
originates a Split MPTY (private communication) request to subscriber D.
Signaling Flow
Figure 1 shows the signaling flow of splitting an MPTY call.
Figure 1 Signaling flow of splitting an MPTY call

The signaling flow of splitting an MPTY call is as follows:
1. UE-A sends a Facility message to MSC/VLR, requesting to start private
communication with PSTN-D.
2. Upon receipt of the Split MPTY request, the MSC/VLR responds with a Facility
message to UE-A, notifying that the Split MPTY request is accepted. At the same
time, the MSC/VLR notifies PSTN-B and UE-C to hold the MPTY call and notifies
PSTN-D to exit the MPTY call and then start private communication with UE-A,
that is, the MSC/VLR needs to notify all the four parties involved in the MPTY
call.
3. The MSC/VLR sends a call progress (CPG) message, notifying UE-B that the call
is held.
4. The MSC/VLR sends a Facility message, notifying UE-C that the call is held.
5. The MSC/VLR sends a CPG message to PSTN-D, notifying that the call is
disconnected. At this time, UE-A and PSTN-D can talk in private, and both the
calls to PSTN-D and UE-C are held.
None.
MPTY Call Failure Flow

Service Model
Signaling Flow
Service Model
Signaling Flow
Figure 1 shows the signaling flow of an MPTY call failure.
Figure 1 Signaling flow of an MPTY call failure

The signaling flow of an MPTY call failure is as follows:
1. UE-A and PSTN-B are engaged in a call. UE-A holds the call with PSTN-B, and
starts a call with UE-C. At this time, UE-A sends a Facility message to the
MSC/VLR to originate an MPTY call. This operation can be implemented through
the menu of the mobile phone.
2. The MSC/VLR responds to UE-A based on the subscription data of UE-A and
whether the network supports MPTY. If UE-A does not subscribe to the MPTY
service, the MSC/VLR sends a Facility message, notifying UE-A that the MPTY
call setup fails. In this case, neither the call between UE-A and UE-C nor the held
call between UE-A and PSTN-B is affected after UE-A fails to originate an MPTY
call.
3. If the network does not support MPTY (generally because the preparation of the
resources by the MGW is not ready), the MSC/VLR sends a Facility message to
notify UE-A of the MPTY setup failure, and sends a Disconnect message to UEA, PSTN-B, and UE-C. In this case, both the call between UE-A and UE-C and
the held call between UE-A and PSTN-B are released.
None.
Call Forwarding
When a call forwarding service is triggered, the system forwards a call to a third party
(public land mobile network (PLMN) subscriber, public switched telephone network (PSTN)
subscriber, integrated services digital network (ISDN) subscriber, or voice mailbox) based
on the requirement of a carrier, network, or subscriber. The call forwarding services are
classified as follows:
Call forwarding unconditional (CFU): All calls to a CFU service subscriber are
forwarded to a third party.
Call forwarding busy (CFB): All calls to a CFB service subscriber are forwarded to
a third party when the CFB service subscriber is busy. The CFB service is divided
into two types based on the specific call forwarding cause:
Network determined user busy (NDUB)
User determined user busy (UDUB)
Call forwarding no reply (CFNRy): If a CFNRy service subscriber does not answer
an incoming call for a long time after being alerted, the call is forwarded to a third
party after the answer timer expires.
Call forwarding on mobile subscriber not reachable (CFNRc): If the radio channel
between the network and a CFNRc service subscriber is disconnected, when the
CFNRc service subscriber is called, the call is forwarded to a third party. The
CFNRc service is triggered because of the following:
No response for paging
Radio channel assignment failure
MS/UE power-off
NOTE:
Based on the location where the forwarding occurs, the call forwarding services can be
categorized as follows:
Call forwarding at the home location (GMSC)
Call forwarding at the destination (visited mobile switching center (VMSC))
CFU
CFB
CFNRy Flow
CFNRc Flow
CFU
Flow of Forwarding a Call to a Mobile Subscriber
Flow of Forwarding a Call to a Fixed-Line Subscriber
Parent topic: Call Forwarding
Flow of Forwarding a Call to a Mobile Subscriber

Service Model
Signaling Flow
Service Model
A, B, and C are 3G mobile subscribers.
Subscriber B subscribes to the call forwarding - unconditional (CFU) service and
sets the forwarded-to subscriber to subscriber C.
Signaling Flow
Figure 1 shows the signaling flow of forwarding a call to a mobile subscriber.
Figure 1 Signaling flow of forwarding a call to a mobile subscriber

The signaling flow of forwarding a call to a mobile subscriber is as follows:
1. UE-A sends a Setup message to originate a call.
2. Based on the information about UE-B in the Setup message, the GMSC
originates an send routing information (SRI) flow to HLR-B serving UE-B.
3. During the routing flow, HLR-B checks whether UE-B has subscribed to the CFU
service, and then sends a MAP_SEND_ROUTING_INFORMATION_CNF
message. The GMSC analyzes the message returned by HLR-B.
If the GMSC finds that call forwarding data is contained in the message,
it originates an SRI flow to UE-C (forwarded-to subscriber) based on
the call forwarding data.
If the GMSC finds that the message does not contain any call
forwarding data, it routes the call to MSC-B.
4. The GMSC sends an IAM message to MSC-C to originate a call.
5. If the MAP_SEND_ROUTING_INFORMATION_CNF message indicates that the
GMSC needs to notify UE-A that the call is forwarded, the GMSC sends a Notify
message to UE-A.
Measurement Point
in Flowchart
P1
P2
Call Forwarding
Traffic
Call Forwarding
Forward Call Attempts
Traffic
Parent topic: CFU

Measurement Type
Office
Office
Flow of Forwarding a Call to a Fixed-Line Subscriber

Service Model
Signaling Flow
Service Model
A and B are 3G mobile subscribers.
Subscriber C is a fixed-line subscriber.
Subscriber B subscribes to the call forwarding - unconditional (CFU) service and
sets the forwarded-to subscriber to subscriber C.
Signaling Flow
Figure 1 shows the signaling flow of forwarding a call to a fixed-line subscriber.
Figure 1 Signaling flow of forwarding a call to a fixed-line subscriber

The signaling flow of forwarding a call to a fixed-line subscriber is as follows:
3. During the routing flow, HLR-B checks whether UE-B has subscribed to the CFU
service, and then sends a MAP_SEND_ROUTING_INFORMATION_CNF
message. The GMSC analyzes the message returned by HLR-B.
If the GMSC finds that call forwarding data is contained in the message
and the forwarded-to subscriber is a public switched telephone network
(PSTN) subscriber, it prepares to route the call out.
If the GMSC finds that the message does not contain any call
forwarding data, it routes the call to MSC-B.
4. The GMSC sends an IAM message to PSTN-C to originate a call.
5. The GMSC sends a Notify message to notify UE-A that the call is forwarded.
Whether this process is triggered depends on the data configuration.
Measurement Point
in Flowchart
P1
Call Forwarding
Traffic
Parent topic: CFU

Measurement Type
Office
CFB
NDUB Flow
UDUB Flow
NDUB Flow
Service Model
Signaling Flow
Service Model
Subscriber B subscribes to the call forwarding on mobile subscriber busy (CFB)
service and sets the forwarded-to subscriber to subscriber C.
Signaling Flow
Figure 1 shows the network determined user busy (condition) (NDUB) signaling flow.
Figure 1 NDUB signaling flow

The NDUB signaling flow is as follows:
3. Based on the routing information and the mobile station roaming number (MSRN)
of UE-B, the GMSC sends an IAM message to MSC-B. Upon receipt of the
message, MSC-B checks the UE-B data (including the current status of UE-B and
the forwarded-to number) in the VLR.
4. During the setup of the call, MSC-B finds that UE-B is in NDUB state (for
example, in an active call). Then, MSC-B checks whether UE-B has subscribed to
the CFB service.
If UE-B has not subscribed to the CFB service, the call fails.
If UE-B has subscribed to the CFB service, MSC-B sends an IAM
message to PSTN-C based on the forwarded-to number.
5. MSC-B sends a Notify message to UE-A and UE-B, notifying that the call is
forwarded. Whether this process is triggered depends on the data configuration.
NOTE:
The flow of forwarding a call to a mobile subscriber due to NDUB is similar to that of
forwarding a call to a fixed-line subscriber due to NDUB. The only difference is that MSC-B
needs to obtain the routing data from the HLR serving the forwarded-to mobile subscriber
and then originate the call based on the routing data.
Measurement Point
in Flowchart
P1
Call Forwarding
Traffic
Parent topic: CFB

Measurement Type
Office
UDUB Flow
Service Model
Signaling Flow
Service Model
Subscriber B subscribes to the call forwarding on mobile subscriber busy (CFB)
service and sets the forwarded-to subscriber to subscriber C.
Signaling Flow
Figure 1 shows the user determined user busy (UDUB) signaling flow.
Figure 1 UDUB signaling flow

The UDUB signaling flow is as follows:
message, MSC-B checks the UE-B data in the VLR.
4. MSC-B sends a paging message to UE-B. After a paging response is received,
MSC-B sends a Setup message to UE-B to start the call setup flow on the callee
side.
5. When UE-B is alerted, UE-B rejects the call, that is, the UDUB service is
triggered. At this time, UE-B sends a Disconnect message to MSC-B.
6. MSC-B checks whether UE-B has subscribed to the CFB service.
If UE-B has not subscribed to the CFB service, the call fails.
If UE-B has subscribed to the CFB service, MSC-B sends an IAM
message to PSTN-C based on the forwarded-to number.
NOTE:
The flow of forwarding a call to a mobile subscriber due to UDUB is similar to that of
forwarding a call to a fixed-line subscriber due to UDUB. The only difference is that MSC-B
needs to obtain the routing data from the HLR serving the forwarded-to mobile subscriber
and then originate the call based on the routing data.
Measurement Point
in Flowchart
P1
Call Forwarding
Traffic
Parent topic: CFB

Measurement Type
Office
CFNRy Flow
Service Model
Signaling Flow
Service Model
Subscriber B subscribes to the call forwarding no reply (CFNRy) service and sets
the forwarded-to subscriber to subscriber C.
Signaling Flow
Figure 1 shows the CFNRy signaling flow.
Figure 1 CFNRy signaling flow

The CFNRy signaling flow is as follows:
side.
5. When a paging message is sent to UE-B, UE-B returns a Call confirmed
message, and MSC-B starts a no-reply timer.
6. If UE-B does not answer the call, after the no-reply timer expires, MSC-B checks
whether UE-B has subscribed to the CFNRy service.
If UE-B has not subscribed to the CFNRy service, MSC-B sends a
Release message, notifying UE-A that the call fails.
If UE-B has subscribed to the CFNRy service, MSC-B sends an IAM
message to LE-C based on the forwarded-to number.
NOTE:
The CFNRy flow for forwarding a call to a mobile subscriber is similar to that for forwarding
a call to a fixed-line subscriber. The only difference is that MSC-B needs to obtain the
routing data from the HLR serving the forwarded-to mobile subscriber and then originate the
call based on the routing data.
Measurement Point
in Flowchart
P1
Call Forwarding
Traffic
Measurement Type
Office

CFNRc Flow
Service Model
Signaling Flow
Service Model
Subscriber B subscribes to the call forwarding on mobile subscriber not reachable
(CFNRc) service and sets the forwarded-to subscriber to subscriber C.
Signaling Flow
Figure 1 shows the CFNRc signaling flow.
Figure 1 CFNRc signaling flow

The CFNRc signaling flow is as follows:
side.
5. If UE-B does not respond to the paging message from MSC-B, MSC-B checks
whether UE-B has subscribed to the CFNRc service.
If UE-B has not subscribed to the CFNRc service, MSC-B sends a
Release message, notifying UE-A that the call fails.
If UE-B has subscribed to the CFNRc service, MSC-B sends an IAM
message to LE-C based on the forwarded-to number.
6. MSC-B sends a Notify message to UE-A, notifying that the call is forwarded.
Whether this process is triggered depends on the data configuration.
NOTE:
The CFNRc flow for forwarding a call to a mobile subscriber is similar to that for forwarding
a call to a fixed-line subscriber. The only difference is that MSC-B needs to obtain the
routing data from the HLR serving the forwarded-to mobile subscriber and then originate the
call based on the routing data.
Measurement Point
in Flowchart
P1
Call Forwarding
Traffic

Measurement Type
Office
USSD
Unstructured Supplementary Service Data (USSD) enables subscribers to interact with the
GSM/Universal Mobile Telecommunications System (UMTS) network proactively. It features
simple operation and excellent service scalability. USSD can provide information for
subscribers in an interactive way. In addition to query of their IMSIs and MSISDNs,
subscribers can query information such as stock exchange and weather forecast and play
interactive games.
USSD can be classified into two types:
Man-Machine interface (MMI)-based USSD: Transmits text strings between the
MS and the network transparently.
Application-based MMI: Transmits data between the MS and the network
transparently. It applies to transmission of data between network applications and
corresponding applications of the MS.
NOTE:
The USSD services used at present are almost based on MMI. Therefore, this
document focuses on the MMI-based USSD services.
The USSD service flows are basically the same in a 2G and a 3G network. This
document focuses on the implementation of MMI-based USSD services in a 2G
network.
User-Initiated USSD Flow (MS->MSC)
User-Initiated USSD Flow (MS->MSC->HLR)
User-Initiated USSD Flow (MS->MSC->HLR->USSD Center)
USSD Center-Initiated USSD Flow (USSD Center->HLR->MSC->MS)
User-Initiated USSD Flow (MS->MSC)

Service Model
Signaling Flow
Service Model
A mobile subscriber originates an unstructured supplementary service data (USSD)
message. The message is sent to the MSC for processing.
Signaling Flow
Figure 1 shows the signaling flow of the user-initiated USSD operation (MS->MSC).
Figure 1 Signaling flow of the user-initiated USSD operation (MS->MSC)

The signaling flow of the user-initiated USSD operation (MS->MSC) is as follows:
1. After the connection between the MSC/VLR and the MS is set up, the MS sends
a REGISTER message carrying the USSD service request to the MSC/VLR.
2. After processing the USSD service request, the MSC/VLR sends a Release
complete message to the MS to release the connection. The message carries the
processing result of the USSD service request, where the information contained in
the Facility parameter varies according to the processing result:
If the USSD request is accepted, USSD String returned by the MSC is
contained in the Facility parameter.
If the USSD request is rejected, the rejection cause returned by the
MSC is contained in the Facility parameter.
If an error is detected, the error cause returned by the MSC is

None.
Parent topic: USSD
User-Initiated USSD Flow (MS->MSC->HLR)

Service Model
Signaling Flow
Service Model
message. The message is sent to the MSC and then forwarded to the HLR for processing.
Signaling Flow
Figure 1 shows the signaling flow of the user-initiated USSD operation (MS->MSC->HLR).
Figure 1 Signaling flow of the user-initiated USSD operation (MS->MSC->HLR)

The signaling flow of the user-initiated USSD operation (MS->MSC->HLR) is as follows:
a REGISTER message to the MSC/VLR.
2. The MSC/VLR sets up a session with the HLR, maps the information in the
REGISTER message to the
MAP_PROCESS_UNSTRUCTURED_SS_REQUEST_REQ message, and then
sends the message to the HLR.

3. If the MS is required to perform other USSD operations, the HLR sends a
MAP_UNSTRUCTURED_SS_REQUEST_IND message to the MSC/VLR. The
message contains the USSD service request. If the MS is not required to perform
other USSD operations, the HLR proceeds with 8.
4. The MSC/VLR maps the information in the
MAP_UNSTRUCTURED_SS_REQUEST_IND message to the Facility message,
and then sends the message to the MS.
5. The MS returns a Facility message to the MSC/VLR. The message contains the
response to the USSD service request.
6. The MSC/VLR maps the response in the Facility message to the
MAP_UNSTRUCTURED_SS_REQUEST_RSP message, and then sends the
message to the HLR.
7. If the MS is required to perform other USSD operations, steps 3 to 6 are
repeated to complete the subsequent USSD interaction between the HLR and the
MS. After the USSD interaction is complete, the HLR sends a
MAP_PROCESS_UNSTRUCTURED_SS_REQUEST_CNF message to end the
session with the MSC/VLR.
8. The MSC/VLR sends a Release complete message to release the connection.
The message carries the processing result of the USSD service request, where
the information contained in the Facility parameter varies according to the
processing result:
None.
Parent topic: USSD
User-Initiated USSD Flow (MS->MSC->HLR->USSD Center)

Service Model
Signaling Flow
Service Model
message. The message is sent to the MSC and then forwarded to the USSD center
through the HLR for processing.
Signaling Flow
Figure 1 shows the signaling flow of the user-initiated USSD operation (MS->MSC->HLR>USSD Center).
Figure 1 Signaling flow of the user-initiated USSD operation (MS->MSC->HLR->USSD
center)
The signaling flow of the user-initiated USSD operation (MS->MSC->HLR->USSD center) is
as follows:
a REGISTER message carrying the USSD service request to the MSC/VLR.
2. The MSC/VLR sets up a session with the HLR, maps the information in the
REGISTER message to the
MAP_PROCESS_UNSTRUCTURED_SS_REQUEST_REQ message, and then
sends the message to the USSD center through the HLR.
3. If the MS is required to perform other USSD operations, the USSD center sends
a MAP_UNSTRUCTURED_SS_REQUEST_IND message to the MSC/VLR. The
message contains the USSD service request. If the MS is not required to perform
other USSD operations, the USSD center proceeds with 8.
4. The MSC/VLR maps the information in the
MAP_UNSTRUCTURED_SS_REQUEST_IND message to the Facility message,
and then sends the message to the MS.
MAP_UNSTRUCTURED_SS_REQUEST_RSP message, and then transparently
transfers the message to the USSD center through the HLR.
repeated to complete the subsequent USSD interaction between the USSD
center and the MS. After the USSD interaction is complete, the USSD center
transparently transfers a
MAP_PROCESS_UNSTRUCTURED_SS_REQUEST_CNF message to end the
session with the MSC/VLR.
8. The MSC server sends a Release complete message to release the connection.
The message carries the processing result of the USSD service request, where
the information contained in the Facility parameter varies according to the
processing result:
None.
Parent topic: USSD

USSD Center-Initiated USSD Flow (USSD Center->HLR>MSC->MS)

Service Model
Signaling Flow
Service Model
The unstructured supplementary service data (USSD) center originates a USSD message.
The message is sent to the HLR and then forwarded to the MS through the MSC.
Signaling Flow
Figure 1 shows the signaling flow of the USSD center-initiated USSD operation (USSD
center->HLR->MSC->MS).
Figure 1 Signaling flow of the USSD center-initiated USSD operation (USSD center->HLR-
>MSC->MS)
The signaling flow of the USSD center-initiated USSD operation (USSD center->HLR>MSC->MS) is as follows:
1. The USSD center sets up a session with the HLR serving the target MS, and then
transparently transfers a MAP_UNSTRUCTURED_SS_REQUEST_IND message
to the MSC/VLR through the HLR.

2. If the target MS is reachable, after the connection between the MSC/VLR and the
MS is set up, the MSC/VLR sends a REGISTER message carrying the USSD
service request to the MS.
MAP_UNSTRUCTURED_SS_REQUEST_RSP message, and then transparently
transfers the message to the USSD center through the HLR.
repeated to complete the subsequent USSD interaction between the USSD
center and the MS.
6. After the USSD interaction is complete, the USSD center transparently transfers
a MAP_CLOSED_IND message to end the session with the MSC/VLR.
7. The MSC/VLR sends a Release complete message to release the connection.
None.
Parent topic: USSD
Call Restriction
The Call Restriction SS allows mobile subscribers to bar the incoming or outgoing calls with
special attributes. Call Restriction SS are classified into Barring of Outgoing Calls (BO)
services and Barring of Incoming Calls (BI) services. BO services are dedicated for callers
and BI services are dedicated for callees.
BO services
Barring of All Outgoing Calls (BAOC): When the BAOC service is
activated, a mobile subscriber cannot call any subscriber.
Barring of All Outgoing International Calls (BOIC): When the BOIC
service is activated, a mobile subscriber cannot call subscribers (mobile
subscribers or fixed subscribers) outside the home public land mobile
network (PLMN) country.
Barring of Outgoing International Calls Except Those Directed to the
Home PLMN Country (BOIC-exHC): When the BOIC-exHC service is
activated, a mobile subscriber cannot call any subscriber outside the
home PLMN country where the subscriber is roaming. After the
subscriber roams outside the home PLMN country, the subscriber can
call only subscribers (mobile subscribers or fixed subscribers) in the
home PLMN country.
BI services
Barring of All Incoming Calls (BAIC): When the BAIC service is activated,
a mobile subscriber cannot receive any call.
Barring of Incoming Calls When Roaming Outside Home PLMN Country
(BIC-ROAM): After the BIC-ROAM service is activated, a mobile
subscriber cannot receive any call when the subscriber is roaming outside
the home PLMN country. Subscribers can select one or several types of
call barring service. If service administration rights are granted for
subscribers during service provisioning, subscribers can activate or
deactivate Call Restriction SS through their MSs by using the preset
passwords.
BAOC Flow
BOIC Flow
BAIC Flow

BAOC Flow
Service Model
Signaling Flow
Service Model
The caller is a 3G mobile subscriber.
The caller has subscribed to the barring of all outgoing calls (BAOC) service.
Signaling Flow
Figure 1 shows the BAOC signaling flow.
Figure 1 BAOC signaling flow

The BAOC signaling flow is as follows:
1. After accessing the network, UE-A sends a Setup message to the MSC/VLR.
2. The MSC queries the VLR for the subscriber data and subscription data of the
caller, and then checks the service based on the call barring information and call
attribute.
If the caller has subscribed to the BAOC service, the MSC/VLR bars the
call. In this case, the MSC/VLR sends a Disconnect message to UE-A to
release the call.
If the caller has not subscribed to the BAOC service, the MSC/VLR
originates the send routing information (SRI) flow to continue the call.

Measurement Point
in Flowchart
P1
Measurement Type
Office
Office
Call Barring Times
Intra-MSC Calls
Call Barred Times
UTRAN Subscriber
Originated Calls
Invocation of
Supplementary
Services
Supplementary
Services
Bearer Traffic
Implement of
Supplementary
Supplementary
Services
Bearer Traffic
Parent topic: Call Restriction

BOIC Flow
Service Model
Signaling Flow
Service Model
The caller has subscribed to the barring of outgoing international calls (BOIC)
service.
Signaling Flow
Figure 1 shows the BOIC signaling flow.
Figure 1 BOIC signaling flow

The BOIC signaling flow is as follows:
2. The MSC queries the VLR for the subscriber data and subscription data of the
caller, and then checks the service based on the call barring information and call
attribute.
If the caller has subscribed to the BOIC service and the call is an
international call, the MSC/VLR bars the call. In this case, the MSC/VLR
sends a Disconnect message to UE-A to release the call.
If the caller has not subscribed to the BOIC service or the call is not an
international call, the MSC/VLR originates the send routing information

(SRI) flow to continue the call.
Measurement Point
in Flowchart
P1
Measurement Type
Office
Office
Call Barring Times
Intra-MSC Calls
Call Barred Times
UTRAN Subscriber
Originated Calls
Invocation of
Supplementary
Services
Supplementary
Services
Bearer Traffic
Implement of
Supplementary
Supplementary
Services
Bearer Traffic

BAIC Flow
Service Model
Signaling Flow
Service Model
The callee has subscribed to the barring of all incoming calls (BAIC) service.
Signaling Flow
Figure 1 shows the BAIC signaling flow.
Figure 1 BAIC signaling flow

The BAIC signaling flow is as follows:
2. The MSC/VLR originates the send routing information (SRI) flow. If the HLR
determines that the callee has subscribed to the BAIC service, it sets the call
barring indication and carries it in the response sent to the MSC/VLR.
3. The MSC/VLR determines that the callee has subscribed to the BAIC service
through analysis. Then, the MSC/VLR bars the call and sends a Disconnect
message to UE-A.

Measurement Point
in Flowchart
P1
Measurement Type
3G TERMINATED
CALL BARRING
TIMES
UTRAN Subscriber
Terminated Calls

Office
Call Barring Times
Intra-MSC Calls

Office
Invocation of
Supplementary
Services
Supplementary
Services
Bearer Traffic
Implement of
Supplementary
Supplementary
Services
Bearer Traffic

Value-added Services
PPS
MVPN Service
VP Service
PPS
The Pre-Paid Service (PPS) allows mobile subscribers to open an account with the service
provider by paying a certain amount of money beforehand or buying a card with a fixed face
value (for example, a rechargeable card) for the use of voice telecom services. During call
setup, the system determines whether to connect or reject the call based on the account
balance. After the call is connected, the system performs real-time charging by deducting
fees from the subscriber account. When the account balance is used up, the system
disconnects the call.
PPS->MS Call Flow
MS->PPS Call Flow
PPS->Service Number Flow
PPS Call Failure Owing to the Insufficient Balance of the Caller Account
PPS Call Failure Owing to the Invalid Caller Account
PPS Call Failure Owing to the Insufficient Balance of the Callee Account
PPS Call Failure Owing to the Invalid Callee Account
Parent topic: Value-added Services
PPS->MS Call Flow

Service Model
Signaling Flow
Service Model
A prepaid service (PPS) subscriber calls an ordinary 2G subscriber.
Signaling Flow
Figure 1 shows the signaling flow of the PPS->MS call.
Figure 1 Signaling flow of the PPS->MS call
As shown in Figure 1, P1, P2, P3, P4, P5, P6, P7, P8, P9, P10 refers to the measurement
point.
The signaling flow of the PPS->MS call is as follows:
1. On receiving a Setup message from the caller, the MSCa/VLR/SSP obtains the
subscriber data of the caller from the VLR. Based on the originating CAMEL
subscription information (O-CSI) of the caller, the MSCa/VLR/SSP triggers the
PPS service, and then sends the area code of the place where the
MSCa/VLR/SSP is located to the SCP through the initial detection point (IDP)
message.
2. On receiving the IDP message, the SCP analyzes the account of the caller. If the
account is valid, the SCP determines the tariff based on the caller location and
called number information contained in the IDP message, and converts the
balance into the conversation duration. The SCP then sends the request report
BCSM event (RRBE), apply charging (AC), furnish charging information (FCI),
and Continue messages to the MSCa/VLR/SSP.
3. On receiving the Continue message, the MSCa/VLR/SSP sends a
MAP_SEND_ROUTING_INFORMATION_REQ message to HLRb serving the
callee, requesting HLRb to send the routing information. HLRb sends a
MAP_PROVIDE_ROAMING_NUMBER_IND message to obtain the mobile station
roaming number (MSRN) of the callee, and then sends the MSRN to the
MSCa/VLR/SSP.
4. The MSCa/VLR/SSP connects the call based on the MSRN.
5. The caller and the callee start conversation.
6. After the caller or the callee releases the call, the MSCa/VLR/SSP sends the
apply charging report (ACR) and event report basic call state model (ERB)
messages to SCPa, reporting the charging information and the call release event.
7. The SCP sends a release call (RC) message to the MSCa/VLR/SSP, requesting
the MSCa/VLR/SSP to release the call.
8. The MSCa/VLR/SSP releases the call.
Measurement Point
Measurement Entity
in Flowchart
Measurement Unit Measurement Type
intelligent network
(IN) Services
P1
Number of Sent InitialDP

Messages
P2
Number of Received
RequestReportBCSMEvent CAP Operations
Messages
IN Services
P3
Number of Received
CAP Operations
ApplyCharging Messages
IN Services
P4
Number of Received
FurnishChargingInformation CAP Operations
Messages
IN Services
P5
Number of Received
Continue Messages
IN Services
Attempting number (WIN

user TK outgoing)
P6
Seizure Times
Connecting number (WIN
user TK outgoing)
P7
Alerting Message
Received Times
Answering number (WIN
user TK outgoing)
P8
Answer Times
CAP Operations
CAP Operations
IN Subscribers
Originated Outgoing
Trunk Calls
Outgoing Traffic in
Trunk Office
Directions
IN Subscribers
Originated Outgoing
Trunk Calls
Outgoing Traffic in
Trunk Office
Directions
IN Subscribers
Originated Outgoing
Trunk Calls
Outgoing Traffic in
Trunk Office
Directions
IN Services
Bearer Traffic
IN Services
Bearer Traffic
IN Services
Bearer Traffic
P9
Number of Sent
ApplyChargingReport
Messages
CAP Operations
IN Services
P10
Number of Sent
EventReportBCSM
Messages
CAP Operations
IN Services
Parent topic: PPS

MS->PPS Call Flow

Service Model
Signaling Flow
Service Model
An ordinary 2G subscriber calls a prepaid service (PPS) subscriber.
Signaling Flow
Figure 1 shows the signaling flow of the MS->PPS call.
Figure 1 Signaling flow of the MS->PPS call
Caller:
P1, P2, P3, P4, P5, P6
Callee:
Q1, Q2, Q3
The signaling flow of the MS->PPS call is as follows:
1. On receiving the call originated by the 2G subscriber, the MSCa/VLR/SSP
determines that the caller is not a PPS subscriber, and therefore sends a

callee to obtain the routing information. HLRb queries the database, determines
that the callee is a PPS subscriber, and therefore sends a
MAP_SEND_ROUTING_INFORMATION_CNF message to the MSCa/VLR/SSP.
This message contains the subscription information of the callee.
2. After obtaining the address of SCPb from the subscription information, the
MSCa/VLR/SSP sends an initial detection point (IDP) message to SCPb. This
message contains the area code of the place where the MSCa/VLR/SSP is
located. On receiving the IDP message, SCPb analyzes the account of the callee.
If the account is valid, SCPb determines the tariff based on the home area and
actual location of the callee, and converts the balance into the conversation
duration. The conversation duration is sent to the MSCa/VLR/SSP through the
request report BCSM event (RRBE), apply charging (AC), and Connect
messages.
3. On receiving the Connect message, the MSCa/VLR/SSP initiates the send routing
information (SRI) and provide roaming number (PRN) flows to HLRb again to
obtain the mobile station roaming number (MSRN) of the callee.
messages to SCPb, reporting the charging information and the call release event.
7. SCPb sends a release call (RC) message to the MSCa/VLR/SSP, requesting the
MSCa/VLR/SSP to release the call.
Measurement Point
Measurement Entity
in Flowchart
P1

Messages
CAP Operations
IN Services
P2
Number of Received
Messages
IN Services
P3
Number of Received
CAP Operations
IN Services
P4
Number of Received
Connect Messages
CAP Operations
IN Services
P5
Number of Sent
ApplyChargingReport
Messages
CAP Operations
IN Services
P6
Number of Sent
EventReportBCSM
Messages
CAP Operations
IN Services

Measurement Point
in Flowchart
Q1
Attempting number
(TK incoming office
calling WIN)
Seizure Times
Q2
Connecting number
(TK incoming office
calling WIN)
Alerting Message
Received Times
Q3
Answering number
(TK incoming office
calling WIN)
Answer Times
IN Subscribers
Terminated Incoming
Trunk Calls
Incoming Traffic in
Trunk Office
Directions
IN Subscribers
Terminated Incoming
Trunk Calls
Incoming Traffic in
Trunk Office
Directions
IN Subscribers
Terminated Incoming
Trunk Calls
Incoming Traffic in
Trunk Office
Directions
Parent topic: PPS

Measurement Type
IN Services
Bearer Traffic
IN Services
Bearer Traffic
IN Services
Bearer Traffic
PPS->Service Number Flow

Service Model
Signaling Flow
Service Model
A prepaid service (PPS) subscriber calls a service number.
Signaling Flow
Figure 1 shows the PPS->service number signaling flow.
Figure 1 PPS->service number signaling flow
As shown in Figure 1, P1, P2, P3, P4, P5, P6, P7, P8, P9, P10, P11, P12, P13, P14 refers
to the measurement point.
The PPS->service number signaling flow is as follows:
service, and then sends the area code of the place where the MSCa/VLR/SSP is
located to the SCP through the initial detection point (IDP) message.
2. The SCP analyzes the IDP message and determines that the called number is a
toll-free number. The SCP then sends the request report BCSM event (RRBE),
counter mode (CTR), and prompt and collect User information (PC) message to
the MSCa/VLR/SSP.
3. The PPS subscriber selects a service language as prompted.
4. The PPS subscriber selects a call operator flow as prompted.
5. Based on the system configuration, the SCP sends the disconnect forward
connection (DFC), RRBE, and Connect messages to the MSC/VLR. If the
selected call operator flow is a pay service, the SCP also sends an apply
charging (AC) message after sending the RRBE message.
6. On receiving the Connect message, the MSCa/VLR/SSP connects the call.
7. The operator offers the service to the subscriber.
8. After the PPS subscriber releases the call, the MSCa/VLR/SSP sends the apply
charging report (ACR) and event report basic call state model (ERB) messages
to the SCP, reporting the charging information and the call release event.
9. The SCP sends a release call (RC) message, requesting the MSCa/VLR/SSP to
release the call.
Measurement
Point in
Flowchart
Measurement Entity
Measurement
Unit
P1
Number of Sent InitialDP Messages
CAP Operations IN Services
P2
Number of Received
RequestReportBCSMEvent Messages
P3
Number of Received
ConnectToResource Messages
P4
Number of Received
PromptAndCollectUserInformation
Messages
P5
Number of Sent
PromptAndCollectUserInformationResult CAP Operations IN Services
Messages
Number of Received
Measurement
Type
P6
DisconnectForwardConnection
Messages
P7
Number of Received
RequestReportBCSMEvent Messages
P8
Number of Received ApplyCharging

Messages
P9
Number of Received Connect

Messages
Attempting number (WIN user TK

outgoing)
P10
Seizure Times
Connecting number (WIN user TK

outgoing)
P11
Alerting Message Received Times
Answering number (WIN user TK

outgoing)
P12
Answer Times
IN Subscribers
Originated
Outgoing Trunk
Calls
Outgoing Traffic
in Trunk Office
Directions
IN Subscribers
Originated
Outgoing Trunk
Calls
Outgoing Traffic
in Trunk Office
Directions
IN Subscribers
Originated
Outgoing Trunk
Calls
Outgoing Traffic
in Trunk Office
Directions
IN Services
Bearer Traffic
IN Services
Bearer Traffic
IN Services
Bearer Traffic
P13
Number of Sent ApplyChargingReport

Messages
P14
Number of Sent EventReportBCSM

Messages
Parent topic: PPS

PPS Call Failure Owing to the Insufficient Balance of the

Caller Account
Service Model
Signaling Flow
Service Model
A prepaid service (PPS) subscriber calls an ordinary 2G subscriber, a public
switched telephone network (PSTN) subscriber, or a PPS subscriber.
During the conversation, the balance of the caller is insufficient for a one-minute
conversation.
Signaling Flow
Figure 1 shows the signaling flow in which a PPS subscriber calls an ordinary 2G subscriber
and the call is released because of insufficient balance of the caller.
Figure 1 Signaling flow of a PPS call failure owing to the insufficient balance of the caller
account
point.
The signaling flow of a PPS call failure owing to the insufficient balance of the caller account
is as follows:
account is valid, the SCP determines the tariff based on the caller location and
called number information contained in the IDP message, and converts the
balance into the conversation duration. The SCP then sends the request report
BCSM event (RRBE), apply charging (AC), furnish charging information (FCI),
and Continue messages to the MSCa/VLR/SSP.
3. On receiving the Continue message, the MSCa/VLR/SSP initiates the send

routing information (SRI) and provide roaming number (PRN) flows to obtain the
mobile station roaming number (MSRN) of the callee and connects the call based
on the MSRN.
4. The caller and the callee start conversation. The SSP records the conversation
duration. When the balance of the caller account is insufficient for a one-minute
conversation, the SSP starts the insufficient balance warning timer (the timer
duration is configurable) based on the maximum conversation duration contained
in the last AC message sent by the SCP. The SSP then requests the MGW to
play an announcement to the subscriber, informing the subscriber that the balance
is insufficient.
5. When the balance is exhausted, the MSCa/VLR/SSP sends the apply charging
report (ACR) and event report basic call state model (ERB) messages to the
SCP, reporting the charging information and the call release event.
release the call.
Measurement Point
Measurement Entity
in Flowchart
P1

Messages
CAP Operations
IN Services
P2
Number of Received
Messages
IN Services
P3
Number of Received
CAP Operations
IN Services
P4
Number of Received
Messages
IN Services
P5
Number of Received
Continue Messages
IN Services
CAP Operations
IN Subscribers
user TK outgoing)
Originated Outgoing
Trunk Calls
Outgoing Traffic in
Trunk Office
Directions
IN Subscribers
Originated Outgoing
Trunk Calls
Outgoing Traffic in
Trunk Office
Directions
IN Subscribers
Originated Outgoing
Trunk Calls
Outgoing Traffic in
Trunk Office
Directions
IN Services
P9
Number of Sent
ApplyChargingReport
Messages
CAP Operations
IN Services
P10
Number of Sent
EventReportBCSM
Messages
CAP Operations
IN Services
P6
Seizure Times
user TK outgoing)
P7
Alerting Message
Received Times
user TK outgoing)
P8
Answer Times
Parent topic: PPS

Bearer Traffic
IN Services
Bearer Traffic
IN Services
Bearer Traffic
PPS Call Failure Owing to the Invalid Caller Account

Service Model
Signaling Flow
Service Model
A prepaid service (PPS) subscriber calls an ordinary 2G subscriber, a public
switched telephone network (PSTN) subscriber, or a PPS subscriber.
When a PPS subscriber originates a call, the SCP finds that the account of the
caller is invalid.
Signaling Flow
Figure 1 shows the signaling flow of a PPS call failure owing to the invalid caller account.
Figure 1 Signaling flow of a PPS call failure owing to the invalid caller account
As shown in Figure 1, P1, P2, P3, P4, P5, P6 refers to the measurement point.
The signaling flow of a PPS call failure owing to the invalid caller account is as follows:
SCP determines that the caller account is invalid (null or expired), the subscriber
is not authorized, the called PSTN number does not contain the area code, or the
area code of the called PSTN number is incorrect, the SCP sends the request
report BCSM event (RRBE), connect to resource (CTR), and play announcement
(PA) messages to the MSCa/VLR/SSP.
3. On receiving the PA message, the MSCa/VLR/SSP requests the MGW to play an
announcement to the subscriber, informing the subscriber that the account is
invalid. After the announcement ends, the MSCa/VLR/SSP sends a specialized
resource report (SRR) message to the SCP, informing the SCP that the
announcement playing is complete.
release the call.
NOTE:
If the subscriber releases the call before the announcement playing is complete, the
MSCa/VLR/SSP sends the event report basic call state model (ERB) and SRR messages
to the SCP. After that, the SCP does not send the RC message again.
Measurement
Measurement Entity
Point in Flowchart
P1

Messages
CAP Operations
IN Services
P2
Number of Received
Messages
IN Services
P3
Number of Received
ConnectToResource
Messages
CAP Operations
IN Services
P4
Number of Received
PlayAnnouncement
Messages
CAP Operations
IN Services
Number of Sent
SpecializedResourceReport CAP Operations
IN Services
P5
Messages
P6
Number of Received
ReleaseCall Messages
CAP Operations
Parent topic: PPS

IN Services
PPS Call Failure Owing to the Insufficient Balance of the

Callee Account
Service Model
Signaling Flow
Service Model
A prepaid service (PPS) subscriber is called.
During the conversation, the balance of the callee is insufficient for a one-minute
conversation.
Signaling Flow
Figure 1 shows the signaling flow in which a PPS subscriber is called and the call is
released because of insufficient balance of the callee.
Figure 1 Signaling flow of a PPS call failure owing to the insufficient balance of the callee
account
Caller:
P1, P2, P3, P4, P5, P6
Callee:
Q1, Q2, Q3
The signaling flow of a PPS call failure owing to the insufficient balance of the callee
account is as follows:
determines that the caller is not a PPS subscriber, and therefore initiates the
send routing information (SRI) and provide roaming number (PRN) flows to HLRb
serving the callee. HLRb queries the database, determines that the callee is a
PPS subscriber, and therefore sends the subscription information of the callee to
the MSCa/VLR/SSP.
located. On receiving the IDP message, SCPb analyzes the account of the callee.
If the account is valid, SCPb determines the tariff based on the home area and
actual location of the callee, and converts the balance into the conversation
duration. The conversation duration is sent to the MSCa/VLR/SSP through the
request report BCSM event (RRBE), apply charging (AC), and Connect
messages.
3. On receiving the Connect message, the MSCa/VLR/SSP sends the
MAP_SEND_ROUTING_INFORMATION_REQ message to HLRb again to obtain
the mobile station roaming number (MSRN) of the callee.
5. The caller and the callee start conversation. The SSP records the conversation
duration. When the balance of the callee account is insufficient for a one-minute
conversation, the SSP starts the insufficient balance warning timer (the timer
duration is configurable). The SSP then requests the MGW to play an
announcement to the PPS subscriber, informing the PPS subscriber that the
balance is insufficient.
6. When the balance is exhausted, the MSCa/VLR/SSP sends the apply charging
report (ACR) and event report basic call state model (ERB) messages to SCPb,
reporting the charging information and the call release event.
7. SCPb sends a release call (RC) message, requesting the MSCa/VLR/SSP to
release the call.

Measurement Point
Measurement Entity
in Flowchart
P1

Messages
CAP Operations
IN Services
P2
Number of Received
Messages
IN Services
P3
Number of Received
CAP Operations
IN Services
P4
Number of Received
Connect Messages
CAP Operations
IN Services
P5
Number of Sent
ApplyChargingReport
Messages
CAP Operations
IN Services
P6
Number of Sent
EventReportBCSM
Messages
CAP Operations
IN Services

Measurement Point
in Flowchart
Q1
Attempting number
(TK incoming office
calling WIN)
Seizure Times
Q2
Connecting number
(TK incoming office
calling WIN)
Alerting Message
Received Times
Q3
Answering number
(TK incoming office
calling WIN)
Answer Times
IN Subscribers
Terminated Incoming
Trunk Calls
Incoming Traffic in
Trunk Office
Directions
IN Subscribers
Terminated Incoming
Trunk Calls
Incoming Traffic in
Trunk Office
Directions
IN Subscribers
Terminated Incoming
Trunk Calls
Incoming Traffic in
Trunk Office
Measurement Type
IN Services
Bearer Traffic
IN Services
Bearer Traffic
IN Services
Bearer Traffic
Directions
Parent topic: PPS
PPS Call Failure Owing to the Invalid Callee Account

Service Model
Signaling Flow
Service Model
A prepaid service (PPS) subscriber is called.
When connecting the call to the called PPS subscriber, the SCP finds that the
account of the callee is invalid.
Signaling Flow
Figure 1 shows the signaling flow of a PPS call failure owing to the invalid callee account.
Figure 1 Signaling flow of a PPS call failure owing to the invalid callee account
As shown in Figure 1, P1, P2, P3, P4, P5, P6 refers to the measurement point.
The signaling flow of a PPS call failure owing to the invalid callee account is as follows:
1. On receiving the Setup message from the caller, the MSCa/VLR/SSP obtains the
subscriber data of the caller from the VLR. The MSCa/VLR/SSP determines that
the callee is not a PPS subscriber, and therefore initiates the send routing
information (SRI) and provide roaming number (PRN) flows to HLRb serving the
callee. HLRb queries the database, determines that the callee is a PPS
subscriber, and therefore sends the subscription data of the callee to the
MSCa/VLR/SSP.
2. The MSCa/VLR/SSP obtains the address of SCPb based on the subscription
data of the callee, and then sends the area code of the place where the
MSCa/VLR/SSP is located to SCPb through the initial detection point (IDP)
message.
3. On receiving the IDP message, SCPb analyzes the callee account. If the SCP
determines that the callee account is invalid (null, expired, or insufficient for a oneminute conversation) or the subscriber is not authorized, the SCP sends the
request report BCSM event (RRBE), connect to resource (CTR), and play
announcement (PA) messages to the MSCa/VLR/SSP. (If MSCb has the
announcement resource, the CTR message is sent. If MSCb does not have the
announcement resource, the establish temporary connection (ETC) message is
sent.)
4. On receiving the PA message, the MSCa/VLR/SSP requests the MGW to play an
announcement to the subscriber, informing the subscriber that the account is
invalid. After the announcement ends, the MSCa/VLR/SSP sends a specialized
resource report (SRR) message to SCPb, informing SCPb that the announcement
playing is complete.
release the call.
Measurement
Measurement Entity
Point in Flowchart
P1
P2

Messages

CAP Operations
IN Services
Number of Received
IN Services
Messages
P3
Number of Received
ConnectToResource
Messages
CAP Operations
IN Services
P4
Number of Received
PlayAnnouncement
Messages
CAP Operations
IN Services
P5
Number of Sent
SpecializedResourceReport CAP Operations
Messages
IN Services
P6
Number of Received
ReleaseCall Messages
IN Services
CAP Operations
Parent topic: PPS

MVPN Service
The Mobile Virtual Private Network (MVPN) is also called Virtual Private Mobile Network
(VPMN). It is a logical voice private network built on the public switched telephone network
(PSTN) and public land mobile network (PLMN) networks. It facilitates communication within
the enterprise user group by adopting speed dialing and the private numbering scheme. The
MVPN service delivered on the PLMN provides mobile group subscribers with a private
network service similar to that delivered by the Private Branch Exchange (PBX) on the
PSTN.
MVPN->MS Call Flow
MVPN->MVPN Call Flow Using a Long Number
MVPN->MVPN Call Flow Using a Short Number
MS->MVPN Call Flow
MVPN->MS Call Flow

Service Model
Signaling Flow
Service Model
An mobile virtual private network (MVPN) subscriber calls an ordinary 2G subscriber.
Signaling Flow
Figure 1 shows the signaling flow of the MVPN->MS call.
Figure 1 Signaling flow of the MVPN->MS call
point.
The signaling flow of the MVPN->MS call is as follows:
2. On receiving the IDP message, the SCP analyzes the caller account. If the
account is valid and the SCP needs to charge the caller for the toll call (that is,
the caller and the callee are not in the same charging area), the SCP sends an
any time interrogation (ATI) message to HLRb to query the information on the
location and status of the callee. HLRb sends a Provide Subscriber Information
(PSI) message to the MSCb/VLR, requesting the MSCb/VLR to query the
information on the location and status of the callee. The MSCb/VLR sends the
query result to HLRb through the PSI ack message. HLRb sends the callee
information to the SCP through the ATI ack message.
3. The SCP sends the request report BCSM event (RRBE) and apply charging (AC)
messages to the MSCa/VLR/SSP. In addition, the SCP charges the caller,
generates a call detail record (CDR), and sends an furnish charging information
(FCI) message to the SSP, requesting the SSP to add the relevant contents to
the CDR. The SCP then sends a Continue message to the MSCa/VLR/SSP,
indicating that the intelligent network (IN) call flow is complete.
4. The MSCa/VLR/SSP initiates the send routing information (SRI) and provide
roaming number (PRN) flows to HLRb serving the callee.
5. The MSCa/VLR/SSP connects the call based on the mobile station roaming
number (MSRN).
release the call.

Measurement Point
Measurement Entity
in Flowchart
P1

Messages
CAP Operations
IN Services
P2
Number of Received
Messages
IN Services
P3
Number of Received
CAP Operations
IN Services
P4
Number of Received
Messages
IN Services
P5
Number of Received
Continue Messages
IN Services

user TK outgoing)
P6
Seizure Times
user TK outgoing)
P7
Alerting Message
Received Times
user TK outgoing)
P8
Answer Times
P9
Number of Sent
ApplyChargingReport
Messages
Number of Sent
CAP Operations
IN Subscribers
Originated Outgoing
Trunk Calls
Outgoing Traffic in
Trunk Office
Directions
IN Subscribers
Originated Outgoing
Trunk Calls
Outgoing Traffic in
Trunk Office
Directions
IN Subscribers
Originated Outgoing
Trunk Calls
Outgoing Traffic in
Trunk Office
Directions
CAP Operations
IN Services
Bearer Traffic
IN Services
Bearer Traffic
IN Services
Bearer Traffic
IN Services
P10
EventReportBCSM
Messages
CAP Operations
Parent topic: MVPN Service

IN Services
MVPN->MVPN Call Flow Using a Long Number

Service Model
Signaling Flow
Service Model
A mobile virtual private network (MVPN) subscriber calls another MVPN
subscriber.
A long number is used to originate the call.
Signaling Flow
Figure 1 shows the signaling flow in which an MVPN subscriber uses a long number to call
another MVPN subscriber.
Figure 1 Signaling flow of the MVPN->MVPN call using a long number
Caller:
P1, P2, P3, P4, P5, P6, P7, P8, P9, P10, P11, P12, P13, P14
Callee:
Q1, Q2, Q3
The signaling flow of the MVPN->MVPN call using a long number is as follows:
1. On receiving the Setup message from the caller, the MSCa/VLR/SSP obtains the
subscription data of the caller from the VLR, and then triggers the Mobile
Originated (MO) intelligent network (IN) flow based on the subscription data of
the caller. For details, see MVPN->MS Call Flow.
2. The MSCa/VLR/SSP initiates the send routing information (SRI) and provide
roaming number (PRN) flows to HLRb serving the callee. HLRb queries the
database. The query result indicates that the callee is also an MVPN subscriber.
Therefore, HLRb sends the subscription data of the callee to the MSCa/VLR/SSP.
3. The MSCa/VLR/SSP triggers the Mobile Terminated (MT) IN flow based on the
subscription data of the callee.
4. The MSCa/VLR/SSP initiates the SRI and PRN flows again. HLRb sends the
mobile station roaming number (MSRN) of the callee to the MSCa/VLR/SSP.
release the call.
Measurement Point
Measurement Entity
in Flowchart
P1

Messages
CAP Operations
IN Services
P2
Number of Received
Messages
IN Services
P3
Number of Received
CAP Operations
IN Services
P4
Number of Received
Messages
IN Services
P5
Number of Received
Continue Messages
CAP Operations
IN Services
P6

Messages
CAP Operations
IN Services
P7
Number of Received
Messages
IN Services
P8
Number of Received
CAP Operations
IN Services
P9
Number of Received
Connect Messages
IN Services

user TK outgoing)
P10
Seizure Times
user TK outgoing)
P11
Alerting Message
Received Times
user TK outgoing)
P12
Answer Times
CAP Operations
IN Subscribers
Originated Outgoing
Trunk Calls
Outgoing Traffic in
Trunk Office
Directions
IN Subscribers
Originated Outgoing
Trunk Calls
Outgoing Traffic in
Trunk Office
Directions
IN Subscribers
Originated Outgoing
Trunk Calls
Outgoing Traffic in
Trunk Office
Directions
IN Services
Bearer Traffic
IN Services
Bearer Traffic
IN Services
Bearer Traffic
P13
Number of Sent
ApplyChargingReport
Messages
CAP Operations
IN Services
P14
Number of Sent
EventReportBCSM
Messages
CAP Operations
IN Services

Measurement Point
in Flowchart
Q1
Attempting number
(TK incoming office
calling WIN)
Seizure Times
Q2
Connecting number
(TK incoming office
calling WIN)
Alerting Message
Received Times
Q3
Answering number
(TK incoming office
calling WIN)
Answer Times
IN Subscribers
Terminated Incoming
Trunk Calls
Incoming Traffic in
Trunk Office
Directions
IN Subscribers
Terminated Incoming
Trunk Calls
Incoming Traffic in
Trunk Office
Directions
IN Subscribers
Terminated Incoming
Trunk Calls
Incoming Traffic in
Trunk Office
Directions

Measurement Type
IN Services
Bearer Traffic
IN Services
Bearer Traffic
IN Services
Bearer Traffic
MVPN->MVPN Call Flow Using a Short Number

Service Model
Signaling Flow
Service Model
A mobile virtual private network (MVPN) subscriber calls another MVPN
subscriber.
A short number is used to originate the call.
Signaling Flow
The signaling flow of the MVPN->MVPN call using a short number is the similar to the
signaling flow of the MVPN->MVPN call using a long number. For details, see MVPN>MVPN Call Flow Using a Long Number.
The difference between the signaling flow of the MVPN->MVPN call using a short number
and the signaling flow of the MVPN->MVPN call using a long number is as follows: When
the mobile terminal (MT) intelligent network (IN) flow is initiated, SCPa analyzes the
information element CalledPartyNumber in the initial detection point (IDP) message sent by
the MSCa/VLR/SSP and determines whether the called number is a short number. If the
called number is a short number, SCPa finds the real number that matches the short
number.
See MVPN->MVPN Call Flow Using a Long Number.
MS->MVPN Call Flow

Service Model
Signaling Flow
Service Model
An ordinary 2G subscriber calls a mobile virtual private network (MVPN) subscriber.
Signaling Flow
Figure 1 shows the signaling flow of the MS->MVPN call.
Figure 1 Signaling flow of the MS->MVPN call
Caller:
P1, P2, P3, P4, P5, P6, P7, P8, P9
Callee:
Q1, Q2, Q3
The signaling flow of the MS->MVPN call is as follows:
determines that the caller is not an MVPN subscriber, and therefore sends a

callee to obtain the routing information. HLRb queries the database, determines
that the callee is an MVPN subscriber, and therefore sends a
MAP_SEND_ROUTING_INFORMATION_CNF message to the MSCa/VLR/SSP.
This message contains the subscription information of the callee.
located. SCPa determines the tariff based on the home area and actual location
of the callee and sends the tariff information to the MSCa/VLR/SSP through the
request report BCSM event (RRBE) and apply charging (AC) messages. In
addition, SCPa changes the value of Generic Number in the Connect message to
"Special prefix 60 + Country code + Real number of the caller", and sends the
called number to the MSCa/VLR/SSP through the Connect message.
3. On receiving the Connect message, the MSCa/VLR/SSP initiates the send routing
information (SRI) and provide roaming number (PRN) flows to HLRb again to
obtain the mobile station roaming number (MSRN) of the callee.
messages to SCPb, reporting the charging information and the call release event.
release the call.
Measurement Point
Measurement Entity
in Flowchart
P1

Messages
CAP Operations
IN Services
P2
Number of Received
Messages
IN Services
P3
Number of Received
CAP Operations
IN Services
P4
Number of Received
Connect Messages
CAP Operations
IN Services
Attempting number
(MOBILE Call WIN)
Mobile-to-IN Calls
IN Services
Seizure Times
Outgoing Traffic in
Trunk Office
Directions
Bearer Traffic
Connecting number
(MOBILE Call WIN)
Mobile-to-IN Calls
IN Services
Alerting Message
Received Times
Outgoing Traffic in
Trunk Office
Directions
Bearer Traffic
Answering number
(MOBILE Call WIN)
Mobile-to-IN Calls
IN Services
Answer Times
Outgoing Traffic in
Trunk Office
Directions
Bearer Traffic
P8
Number of Sent
ApplyChargingReport
Messages
CAP Operations
IN Services
P9
Number of Sent
EventReportBCSM
Messages
CAP Operations
IN Services
P5
P6
P7

Measurement Point
in Flowchart
Q1
Attempting number
(TK incoming office
calling WIN)
Seizure Times
Connecting number
(TK incoming office
calling WIN)
Measurement Type
IN Subscribers
Terminated Incoming IN Services
Trunk Calls
Incoming Traffic in
Trunk Office
Bearer Traffic
Directions
IN Subscribers
Trunk Calls
Q2
Alerting Message
Received Times
Q3
Answering number
(TK incoming office
calling WIN)
Answer Times
Incoming Traffic in
Trunk Office
Directions
Bearer Traffic
IN Subscribers
Trunk Calls
Incoming Traffic in
Trunk Office
Bearer Traffic
Directions

VP Service
Basic Intra-MSC VP Call Flow
Basic Inter-MSC VP Call Flow Using BICC Signaling
Basic Inter-MSC VP Call Flow Using ISUP Signaling
Basic Intra-MSC VP Call Flow

Service Model
Signaling Flow
Service Model
A 3G subscriber calls another 3G subscriber served by the same MSC server.
The RNC and the MGW are connected through asynchronous transfer mode
(ATM).
The RNC and the MSC server are connected through MTP3-User Adaptation
Layer (M3UA) in non-peer-to-peer mode; that is, the MSC server connects to the
MGW through M3UA links and exchanges Radio Access Network Application Part
(RANAP) messages with the RNC through the MGW that has the embedded
signaling gateway function.
The caller releases the call first.
Signaling Flow
The 3G intra-MSC video phone (VP) call flow is the same as the ordinary 3G intra-MSC call
flow. Figure 1 shows the signaling flow of the 3G intra-MSC VP call.
Figure 1 Signaling flow of the 3G intra-MSC VP call
Caller:
P1, P2, P3, P4
Callee:
Q1, Q2, Q3
The signaling flow of the 3G intra-MSC VP call is as follows:
1. The originating UE (UE-O) sends a Setup message to the MSC. In the

information element Bearer capability of the Setup message, independent
transmit clock (ITC) is set to Unified Display Interface (UDI) and ORA is set to
H.223&H.245.
2. On receiving the Setup message, the MSC/VLR determines whether to continue
the call based on the service type and the service subscription information of the
UE-O. If the MSC/VLR determines to continue the call, it sends a Call proceeding
message to notify the UE-O that the call is being connected.
3. The MSC sends a send routing information (SRI) message to the HLR to obtain
the routing information and the mobile station roaming number (MSRN).
4. The caller side initiates the bearer setup flow. For details about the bearer setup
flow, see 3G Bearer Establishment.
5. The MSC sends a Setup message to the terminating UE (UE-T). In the
information element Bearer capability of the Setup message, ITC is set to UDI
and ORA is set to H.223&H.245.
6. The UE-T sends a CALL CONFIRMED message to the MSC.
7. The MSC/VLR sets up the user plane bearer on the callee side. The process is
the same as that on the caller side.
8. The UE-T is alerted and sends an Alerting message to the MSC/VLR. On
receiving the Alerting message, the MSC/VLR forwards it to the UE-O.
9. The MSC/VLR sends a MOD REQ message to the MGW, requesting the MGW
to play the ringback tone.
ringback tone.
11. The callee answers the call and the UE-T sends a Connect message to the
MSC/VLR.
12. On receiving the Connect message, the MSC/VLR sends a MOD REQ message
to the MGW, requesting the MGW to stop playing the ringback tone.
the ringback tone.
14. The MSC/VLR sends a Connect message to the UE-O.
15. The UE-O sends a Connect acknowledge message to the MSC/VLR. The
MSC/VLR then forwards this message to the UE-T. The call is connected.
16. The UE-O and the UE-T perform the H.245 negotiation and open the H.245 audio
and video logical channels.
17. The caller and the callee start the VP conversation.

18. After the UE-O releases the call, the H.245 audio and video logical channels
between the UE-O and the UE-T are closed and the H.245 session is complete.
The call is then released. For details about the bearer release flow, see 3G
Bearer Release.
Measurement Point
in Flowchart
P1
Call Attempts
UTRAN Subscriber
Originated Calls
MO try call times

(LAI)
Traffic Measurement
Global Components
For LAI
VP Call Attempts
Wrong Dialing Times
P2

Office
UTRAN VP Subscriber Total Traffic of the

Originated Calls
Office
UTRAN Subscriber
Originated Calls
Office
VP Call Failures due

to No Support from
Bearer Capability
UTRAN VP Subscriber
Office
OfficeOriginated Calls
Call Attempts
Intra-MSC Calls
UTRAN Subscriber
Originated Calls

P3
Measurement Type
Answer Times
VP Call Completion
Times
Answer Times
Answer Times

Office
Office
Office
Traffic Measurement
Global Components
For LAI
UTRAN VP Subscriber
Office
UTRAN Subscriber
Originated Calls
Office
Intra-MSC Calls
Office
P4
MO response times
(LAI)
Average Call Setup
Time
Traffic Measurement Global Components

For LAI
UTRAN Subscriber
Originated Calls
Office
UTRAN VP Subscriber
VP Call Answer Times Total Traffic of the
Office

Measurement Point
in Flowchart
Q1
Q2
Q3
3G TERMINATED
CALL_ATTEMPT
Measurement Type
UTRAN Subscriber
Terminated Calls
Office
VP Call Attempts
Terminated Calls
Office
3G TERMINATED
UTRAN Subscriber
ALERT
Terminated Calls
Office
MO connect times
Traffic Measurement
Global Components
(LAI)
For LAI
VP Call Completion
Times
Terminated Calls
Office
3G TERMINATED
UTRAN Subscriber
ANSWER
Terminated Calls
Office
MT response times
Traffic Measurement
Global Components
(LAI)
For LAI
VP Call Answer Times
Terminated Calls
Office
3G TERMINATED
UTRAN Subscriber
CALL ESTABLISH
Terminated Calls
Office
AVERAGE TIME
Parent topic: VP Service

Basic Inter-MSC VP Call Flow Using BICC Signaling

Service Model
Signaling Flow
Service Model
A 3G subscriber calls another 3G subscriber served by another MSC server.
Bearer Independent Call Control (BICC) signaling is used between MSCs.
The forward delay mode is adopted to set up the bearer.
Signaling Flow
The 3G inter-MSC video phone (VP) call flow is the same as the ordinary 3G inter-MSC call
flow. Figure 1 shows the signaling flow of the 3G inter-MSC VP call using BICC signaling.
Figure 1 Signaling flow of the 3G inter-MSC VP call using BICC signaling
Caller:
P1, P2, P3
Callee:
Q1, Q2, Q3

The signaling flow of the 3G inter-MSC VP call using BICC signaling is as follows:
1. Based on the local office information, the originating MSC (MSC-O) determines to
route the call out through a BICC trunk. The MSC-O sends a message to the
MGW, requesting the MGW to prepare the bearer but not to report the tunnel
information. On receiving the response from the MGW, the MSC-O sends an IAM
message to the terminating MSC (MSC-T).
2. Based on the local office information and the information elements contained in
the IAM message, the MSC-T completes route selection and bearer preparation,
and then sends an APM message to the MSC-O.
3. The MSC-O sends a message to the MGW, requesting the MGW to set up the
bearer and report the tunnel information. On receiving the tunnel information from
the MGW, the MSC-O packs the tunnel information in the APM messages and
sends this message to the MSC-T.
4. On receiving the APM message, the MSC-T forwards the tunnel information
contained in the APM message to the MGW and requests the MGW to reports
the local tunnel information. The MGW sends the local tunnel information to the
MSC-T. The MSC-T packs the local tunnel information in an APM message and
sends this message to the MSC-O.
5. On setting up the bearer on the callee side and assigning the required Iu interface
resources, the MSC-T sends an address complete message (ACM) message to
the MSC-O. At this point, the callee is alerted and the caller hears the ringback
tone.
6. After the callee answers the call, the MSC-T sends an answer message (ANM)
message to the MSC-O.
and video logical channels. The caller and the callee start the VP conversation.
8. After the UE-T releases the call, the H.245 audio and video logical channels
The MSC-T then sends a release (REL) message to the MSC-O. The REL
message is sent by the party who release the call. This message contains the
releases the bearer resource on the caller side. For details about the bearer
release flow, see 3G Bearer Release. This message indicates that the peer end
is free and is available for the next call.

Measurement Point
in Flowchart
P1
Seizure Times
Outgoing Traffic in
Trunk Office
Seizure Times
Outgoing Calls
VP Call Attempts
Alerting Message
Received Times
P2
P3
Measurement Type
Bearer Traffic

Office
Originated Calls
Office
Outgoing Traffic in
Trunk Office
Bearer Traffic
Office
VP Call Completion
Times

Originated Calls
Office
Answer Times
Outgoing Traffic in
Trunk Office
Bearer Traffic

Office
Originated Calls
Office
Answer Times
Outgoing Calls

Measurement Point
in Flowchart
Q1
Seizure Times
Incoming Traffic in
Trunk Office
Directions
Seizure Times
Incoming Calls
VP Call Attempts
3G TERMINATED
CALL_ATTEMPT
Measurement Type
Bearer Traffic

Office
Terminated Calls
Office
UTRAN Subscriber
Terminated Calls

Office
3G INCOMING CALL UTRAN Subscriber

ATTEMPT
Terminated Incoming Office
Calls
3G TERMINATED
ALERT
MT connect times
(LAI)
3G INCOMING
ALERT
Q2
UTRAN Subscriber
Terminated Calls
Traffic Measurement
For LAI
UTRAN Subscriber
Terminated Incoming
Calls
Global Components
Office
VP Call Completion
Times

Terminated Calls
Office
Alerting Message
Received Times
Incoming Traffic in
Trunk Office
Directions

3G TERMINATED
ANSWER
MT response times
(LAI)
3G TERMINATED
CALL ESTABLISH
AVERAGE TIME
Q3

Office
Bearer Traffic
Office
Office
UTRAN Subscriber
Terminated Calls
Traffic Measurement
Global Components
For LAI
UTRAN Subscriber
Terminated Calls

Office
UTRAN Subscriber
Terminated Incoming
Office
Calls
Incoming Traffic in
Answer Times
Trunk Office
Bearer Traffic
Directions
Answer Times
Incoming Calls
Office
Terminated Calls
Office
3G INCOMING
ANSWER

Basic Inter-MSC VP Call Flow Using ISUP Signaling

Service Model
Signaling Flow
Service Model
A 3G subscriber calls another 3G subscriber served by another MSC server.
ISDN user part (ISUP) signaling is used between MSCs.
Signaling Flow
The 3G inter-MSC video phone (VP) call flow is the same as the ordinary 3G inter-MSC call
flow. Figure 1 shows the signaling flow of the 3G inter-MSC VP call using ISUP signaling.
Figure 1 Signaling flow of the 3G inter-MSC VP call using ISUP signaling
Caller:
P1, P2, P3
Callee:
Q1, Q2, Q3
The signaling flow of the 3G inter-MSC VP call using ISUP signaling is as follows:
1. After the call is originated, the caller side completes the send routing information
(SRI) and Provide Roaming Number (PRN) flows and is ready to set up the
bearer. For details about the bearer setup flow, see 3G Bearer Establishment.
The originating MSC (MSC-O) sends an IAM message to the terminating MSC
(MSC-T). This message contains the mandatory information (such as the caller
category and called number) required to set up the call and some optional
information (such as the calling number).
2. If the called number contained in the IAM message is incomplete, the MSC-O
sends an subsequent address message (SAM) message containing the
incomplete called number to the MSC-T. Multiple SAM messages can be sent
during a call.
3. The bearer is set up on the callee side. For details about the bearer setup flow,
see 3G Bearer Establishment. After the callee is alerted, the MSC-T sends an
address complete message (ACM) message to the MSC-O. At this point, the
caller hears the ringback tone.
4. After the callee answers the call, the MSC-T sends an answer message (ANM)
message to the MSC-O.
and video logical channels. The caller and the callee start the VP conversation.
6. After the UE-T releases the call, the H.245 audio and video logical channels
The MSC-T then sends a release (REL) message to the MSC-O. The REL
message is sent by the party who release the call. This message contains the
release cause value. Meanwhile, the MSC-T releases the bearer resource on the
callee side. For details about the bearer release flow, see 3G Bearer Release.
releases the bearer resource on the caller side. This message indicates that the
peer end is free and is available for the next call.
Measurement Point
in Flowchart
P1
Measurement Type
Seizure Times
Outgoing Traffic in
Trunk Office
Bearer Traffic
Seizure Times
Outgoing Calls

Office
P2
P3
VP Call Attempts

Originated Calls
Office
Alerting Message
Received Times
Outgoing Traffic in
Trunk Office
Bearer Traffic
Office
VP Call Completion
Times

Originated Calls
Office
Answer Times
Outgoing Traffic in
Trunk Office
Bearer Traffic

Office
Originated Calls
Office
Answer Times
Outgoing Calls

Measurement Point
in Flowchart
Q1
Seizure Times
Incoming Traffic in
Trunk Office
Directions
Seizure Times
Incoming Calls
VP Call Attempts
3G TERMINATED
CALL_ATTEMPT
Q2
Measurement Type
Bearer Traffic

Office
Terminated Calls
Office
UTRAN Subscriber
Terminated Calls

Office
UTRAN Subscriber
3G INCOMING CALL
Terminated Incoming
ATTEMPT
Office
Calls
3G TERMINATED
UTRAN Subscriber
ALERT
Terminated Calls
Office
MT connect times
Traffic Measurement
Global Components
(LAI)
For LAI
UTRAN Subscriber
3G INCOMING
Terminated Incoming
ALERT
Office
Calls
VP Call Completion
Terminated Calls
Times
Office
Alerting Message
Received Times
Incoming Traffic in
Trunk Office
Directions

3G TERMINATED
ANSWER
MT response times
(LAI)
3G TERMINATED
CALL ESTABLISH
AVERAGE TIME
Q3
Bearer Traffic
Office
Office
UTRAN Subscriber
Terminated Calls
Traffic Measurement
Global Components
For LAI
UTRAN Subscriber
Terminated Calls

Office
UTRAN Subscriber
Terminated Incoming
Office
Calls
Incoming Traffic in
Answer Times
Trunk Office
Bearer Traffic
Directions
Answer Times
Incoming Calls
Office
Terminated Calls
Office
3G INCOMING
ANSWER

Mobility Management
Common Location Update
Periodic Location Update
Independent Location Update
Combined Location Update
Location Cancellation
IMSI Detach
Common Location Update

When an MS is powered on or is on the move, if the location area identifier that the MS
receives from the BTS is not the same as that stored in the MS, the MS originates a
location update request to the network to update the location area identifier.
2G Common Location Update
Parent topic: Mobility Management

Successful Intra-VLR Common Location Update (Only VLR Is Involved)
Successful Intra-VLR Common Location Update (VLR and HLR Are Involved)
Unsuccessful Intra-VLR Common Location Update
Successful Inter-VLR Common Location Update (Initiated Using IMSI)
Successful Inter-VLR Common Location Update (Initiated Using TMSI)
Unsuccessful Inter-VLR Common Location Update
Parent topic: Common Location Update
Successful Intra-VLR Common Location Update (Only VLR

Is Involved)
Service Model
Signaling Flow
Service Model
A 2G subscriber initiates a location update in the same MSC/VLR area.
Only the interaction with the VLR is involved in the location update.
Signaling Flow
Figure 1 shows the signaling flow of a successful intra-VLR common location update, where
only the VLR is involved.
Figure 1 Signaling flow of a successful intra-VLR common location update (only VLR is
involved)
As shown in Figure 1, P1, P2 refers to the measurement point.
The signaling flow of a successful intra-VLR common location update (only VLR is involved)
is as follows:
1. The MS sends a Location updating request message to the MSC. The message
carries the temporary mobile subscriber identifier (TMSI)/international mobile

subscriber identity (IMSI) of the MS, the location area identity (LAI), and the
location update type.
2. The MSC sends a MAP_UPDATE_LOCATION_AREA_REQ message, requesting
the VLR to perform a location update.
3. The MSC/VLR initiates the authentication and encryption flow. This flow is
optional.
4. The VLR updates the location of the MS, stores the new LAI, and assigns a new
TMSI (assigned in the TMSI re-assignment flow, which is optional) for the MS.
Then, the VLR sends a MAP_UPDATE_LOCATION_AREA_ACK message,
notifying the MSC that the location update is successful.
5. The MSC sends a Location updating accept message carrying the new TMSI,
notifying the MS that the location update is successful.
6. The MSC releases the channel. The location update is complete.
Measurement Point
in Flowchart
P1
P2
Measurement Type
Location Update
Requests
Location Management
MSC Basic Functions
Service
Location Update
Requests in the VLR
Location Management
MSC Basic Functions
Service
Update location
request times (LAI)
Traffic Measurement
Global Components
For LAI
Location Update
Requests
MSC Basic Services
Successful Location
Updates in the VLR
Location Management
MSC Basic Functions
Service
Success Rate of
Location Update
Location Management
MSC Basic Functions
Service
Parent topic: 2G Common Location Update
MSC Basic Functions

Successful Intra-VLR Common Location Update (VLR and

HLR Are Involved)
Service Model
Signaling Flow
Service Model
The interaction with the VLR is also involved in the location update.
Signaling Flow
both the VLR and the HLR are involved.
Figure 1 Signaling flow of a successful intra-VLR common location update (VLR and HLR
are involved)
The signaling flow of a successful intra-VLR common location update (VLR and HLR are
involved) is as follows:
3. The MSC/VLR determines that no authentication sets are available. Then, the
MSC/VLR obtains authentication sets from the HLR and initiates the
authentication flow. This flow is optional.
4. As the subscriber data in the VLR has been removed, the VLR sends a
MAP_UPDATE_LOCATION_REQ message, requesting the HLR to perform a
location update.
5. The HLR sends a MAP-INSERT-SUBSCRIBER-DATA_IND message, instructing
the VLR to insert the updated location data of the subscriber.
6. After successfully inserting the updated location data of the subscriber, the VLR
sends a MAP-INSERT-SUBSCRIBER-DATA_RSP message to the HLR.
7. The HLR sends a MAP_UPDATE_LOCATION_CNF message, notifying the VLR
that the location update is successful.
8. The VLR sends a MAP_UPDATE_LOCATION_AREA_ACK message, notifying
the MSC that the location update is successful.
9. The MSC/VLR initiates the encryption flow. This flow is optional.
10. The MSC sends a Location updating accept message, notifying the MS that the
location update is successful.
NOTE:
The HLR is involved in the location update if any of the following conditions is met:
The MS/UE registers with the network for the first time.
The location update is an inter-MSC location update.
If the VLR does not store the subscriber data or the subscriber data is
unconfirmed, the VLR initiates a location update to the HLR. Bit 13 of P658
controls this process.
Measurement Point
in Flowchart
P1
Measurement Type
Location Update
Requests
Location Management
MSC Basic Functions
Service
Location Update
Requests in the VLR
Location Management
MSC Basic Functions
Service
Update location
request times (LAI)
Traffic Measurement
Global Components
For LAI
Location Update
MSC Basic Services
MSC Basic Functions
Requests
P2
Successful Location
Updates in the VLR
Location Management
MSC Basic Functions
Service
Success Rate of
Location Update
Location Management
MSC Basic Functions
Service


Service Model
Signaling Flow
Service Model
The location update fails because of roaming restriction.
NOTE:
A location update also fails if authentication fails. For details, see 2G Authentication and
Encryption. This topic focuses on the location update failure caused by roaming restriction.
Signaling Flow
Figure 1 shows the signaling flow of unsuccessful intra-VLR common location update.
Figure 1 Signaling flow of unsuccessful intra-VLR common location update

The signaling flow of unsuccessful intra-VLR common location update is as follows:

optional.
4. The VLR checks the subscriber data and finds that roaming restriction is enabled
for the subscriber. Then, the VLR sends a
MAP_UPDATE_LOCATION_AREA_ACK message to the MSC.
5. The MSC sends a Location updating reject message, notifying the MS that the
location update is rejected.
Measurement Point
in Flowchart
P1
Measurement Type
Location Update
Requests
Location Management
MSC Basic Functions
Service
Location Update
Requests in the VLR
Location Management
MSC Basic Functions
Service
Update location
request times (LAI)
Traffic Measurement
Global Components
For LAI
Location Update
Requests
MSC Basic Services
MSC Basic Functions
Location Update
Failures Caused by
Location Management
Roaming Prohibition
MSC Basic Functions
Service
for Personal
Handyphone Systems
P2
Location Update
Failures Caused by
Location Management MSC Basic Functions
Cell Prohibition in the Service
Location Area
Location Update
Failures Caused by
Other Factors
Location Management
MSC Basic Functions
Service

Successful Inter-VLR Common Location Update (Initiated

Using IMSI)
Service Model
Signaling Flow
Service Model
A 2G subscriber initiates a location outside the home VLR.
The temporary mobile subscriber identifier (TMSI) is considered as unreliable by
the MS or the TMSI re-assignment is not configured; therefore, the MS uses the
international mobile subscriber identity (IMSI) to initiate the location update.
Signaling Flow
Figure 1 shows the signaling flow of successful inter-VLR common location update (initiated
by using IMSI).
Figure 1 Signaling flow of successful inter-VLR common location update (initiated by using
IMSI)
The signaling flow of successful inter-VLR common location update (initiated by using IMSI)
is as follows:
carries the IMSI of the MS, the location area identity (LAI), and the location
update type.

4. The VLR checks the subscriber data and finds that the subscriber is roaming from
the previous vlr (PVLR). Then, the VLR sends a
MAP_UPDATE_LOCATION_REQ message to the HLR.
5. The HLR sends a MAP_CANCEL_LOCATION_REQ message, instructing the
VLR to delete the data of the subscriber.
6. On receiving the MAP_CANCEL_LOCATION_REQ message, the PVLR sends a
MAP_CANCEL_LOCATION_RSP message to the HLR.
NOTE:
When the MS initiates location update by using TMSI for the first time, the VLR
obtains the IMSI from the PVLR if PVLR data is configured on the local MSC. If
the operation fails, the MSC obtains the IMSI from the MS and then uses the IMSI
to perform the location update.
unconfirmed, the VLR initiates a location update to the HLR. Bit 13 of
P658 controls this process.

Measurement Point
in Flowchart
P1
P2
Measurement Type
Location Update
Requests
Location Management
MSC Basic Functions
Service
Location Update
Requests During
Roaming
Location Management
MSC Basic Functions
Service
Update location
request times (LAI)
Traffic Measurement
Global Components
For LAI
Location Update
Requests
MSC Basic Services
Successful Location
Updates During
Roaming
Location Management
MSC Basic Functions
Service
Success Rate of
Location Update
Location Management
MSC Basic Functions
Service
Successful Location
Updates During
National Roaming
Location Management
MSC Basic Functions
Service
MSC Basic Functions
Successful Location
Location Management
Updates During
MSC Basic Functions
Service
International Roaming

Using TMSI)
Service Model
Signaling Flow
Service Model
The location update is initiated by using the temporary mobile subscriber identifier
(TMSI).
Signaling Flow
by using TMSI).
TMSI)
The signaling flow of successful inter-VLR common location update (initiated by using TMSI)
is as follows:
carries the TMSI of the MS, the location area identity (LAI), and the location
update type.
the previous vlr (PVLR). Then, the VLR obtains the TMSI and authentication sets
from the PVLR. On obtaining the authentication sets, the MSC/VLR initiates the
4. The VLR sends a MAP_UPDATE_LOCATION_REQ message, requesting the
HLR to perform a location update.
NOTE:
When the MS initiates location update by using TMSI for the first time, the VLR
the operation fails, the MSC obtains the IMSI from the MS and then uses the IMSI

Measurement Point
in Flowchart
P1
P2
Measurement Type
Location Update
Requests
Location Management
MSC Basic Functions
Service
Location Update
Requests During
Roaming
Location Management
MSC Basic Functions
Service
Update location
request times (LAI)
Traffic Measurement
Global Components
For LAI
Location Update
Requests
MSC Basic Services
Successful Location
Updates During
Roaming
Location Management
MSC Basic Functions
Service
Success Rate of
Location Update
Location Management
MSC Basic Functions
Service
Successful Location
Updates During
National Roaming
Location Management
MSC Basic Functions
Service
MSC Basic Functions
Successful Location
Location Management
Updates During
MSC Basic Functions
Service

Service Model
Signaling Flow
Service Model
The location update fails because of roaming restriction of Check international
mobile equipment identity (IMEI) failure.
Signaling Flow
Figure 1 shows the signaling flow of unsuccessful inter-VLR common location update.
Figure 1 Signaling flow of unsuccessful inter-VLR common location update

The signaling flow of unsuccessful inter-VLR common location update is as follows:
carries the temporary mobile subscriber identifier (TMSI) of the MS, the location
area identity (LAI), and the location update type.
10. The VLR checks the subscriber data for roaming restriction, and then sends a
MAP_UPDATE_LOCATION_AREA_ACK message carrying the check result to
the MSC.
11. If roaming restriction is enabled for the subscriber, the MSC sends a Location
updating reject message, notifying the MS that the location update is rejected.
Then, the MSC releases the channel.
12. If roaming restriction is not enabled for the subscriber, the MSC initiates the
Check IMEI flow by sending a Check_IMEI_REQ message to the equipment
identity register (EIR). This flow is optional.
13. If the Check IMEI flow fails, the MSC sends a Location updating reject message,
notifying the MS that the location update is rejected.
NOTE:

Measurement Point
in Flowchart
P1
P2
Measurement Type
Location Update
Requests
Location Management
MSC Basic Functions
Service
Location Update
Requests During
Roaming
Location Management
MSC Basic Functions
Service
Update location
request times (LAI)
Traffic Measurement
Global Components
For LAI
Location Update
Requests
MSC Basic Services
Location Update
Failures Caused by
Location Area
Prohibition in the
Network
Location Management
MSC Basic Functions
Service
Location Update
Failures Caused by
public land mobile
network (PLMN)
Prohibition
Location Management
MSC Basic Functions
Service
Location Update
Failures Caused by
Roaming Prohibition
Location Management
MSC Basic Functions
Service

MSC Basic Functions

Successful Intra-VLR Common Location Update (Only VLR Is Involved)
Successful Intra-VLR Common Location Update (VLR and HLR Are Involved)
Successful Inter-VLR Common Location Update (Initiated Using IMSI)
Successful Inter-VLR Common Location Update (Initiated Using TMSI)
Parent topic: Common Location Update
Successful Intra-VLR Common Location Update (Only VLR

Is Involved)
Service Model
Signaling Flow
Service Model
Only the interaction with the VLR is involved in the location update.
Signaling Flow
only the VLR is involved.
Figure 1 Signaling flow of a successful intra-VLR common location update (only VLR is
involved)
The signaling flow of a successful intra-VLR common location update (only VLR is involved)
is as follows:
1. The UE sends a Location updating request message to the MSC. The message
subscriber identity (IMSI) of the UE, the location area identity (LAI), and the
optional.
4. The VLR updates the location of the UE, stores the new LAI, and assigns a new
TMSI for the UE. Then, the VLR sends a
MAP_UPDATE_LOCATION_AREA_ACK message, notifying the MSC that the
5. The MSC sends a Location updating accept message carrying the new TMSI,
notifying the MS that the location update is successful.
Measurement Point
in Flowchart
P1
P2
Measurement Type
Location Update
Requests
Location Management
MSC Basic Functions
Service
Location Update
Requests in the VLR
Location Management
MSC Basic Functions
Service
Update location
request times (LAI)
Traffic Measurement
Global Components
For LAI
Location Update
Requests
MSC Basic Services
Successful Location
Updates in the VLR
Location Management
MSC Basic Functions
Service
Success Rate of
Location Update
Location Management
MSC Basic Functions
Service
MSC Basic Functions

Successful Intra-VLR Common Location Update (VLR and

HLR Are Involved)
Service Model
Signaling Flow
Service Model
The interaction with the VLR is also involved in the location update.
Signaling Flow
both the VLR and the HLR are involved.
Figure 1 Signaling flow of a successful intra-VLR common location update (VLR and HLR
are involved)
The signaling flow of a successful intra-VLR common location update (VLR and HLR are
involved) is as follows:
4. As the subscriber data in the VLR has been removed, the VLR sends a
MAP_UPDATE_LOCATION_REQ message, requesting the HLR to perform a

location update.
10. The MSC sends a Location updating accept message, notifying the UE that the
NOTE:
Measurement Point
in Flowchart
P1
Measurement Type
Location Update
Requests
Location Management
MSC Basic Functions
Service
Location Update
Requests in the VLR
Location Management
MSC Basic Functions
Service
Update location
request times (LAI)
Traffic Measurement
Global Components
For LAI
P2
Location Update
Requests
MSC Basic Services
Successful Location
Updates in the VLR
Location Management
MSC Basic Functions
Service
Success Rate of
Location Update
Location Management
MSC Basic Functions
Service

MSC Basic Functions

Service Model
Signaling Flow
Service Model
The location update fails because of roaming restriction.
NOTE:
A location update also fails if authentication fails. For details, see 3G Authentication and
Encryption. This topic focuses on the location update failure caused by roaming restriction.
Signaling Flow
Figure 1 shows the signaling flow of unsuccessful intra-VLR common location update.
Figure 1 Signaling flow of unsuccessful intra-VLR common location update

The signaling flow of unsuccessful intra-VLR common location update is as follows:
optional.
4. The VLR checks the subscriber data and finds that roaming restriction is enabled
for the subscriber. Then, the VLR sends a
MAP_UPDATE_LOCATION_AREA_ACK message to the MSC.
5. The MSC sends a Location updating reject message, notifying the UE that the
location update is rejected.
Measurement Point
in Flowchart
P1
Measurement Type
Location Update
Requests
Location Management
MSC Basic Functions
Service
Location Update
Requests in the VLR
Location Management
MSC Basic Functions
Service
Update location
request times (LAI)
Traffic Measurement
Global Components
For LAI
Location Update
Requests
MSC Basic Services
MSC Basic Functions
Location Update
Failures Caused by
Location Management
Roaming Prohibition
MSC Basic Functions
Service
for Personal
Handyphone Systems
P2
Location Update
Failures Caused by
Location Management
MSC Basic Functions
Cell Prohibition in the Service
Location Area
Location Update
Failures Caused by
Other Factors
Location Management
MSC Basic Functions
Service


Using IMSI)
Service Model
Signaling Flow
Service Model
The temporary mobile subscriber identifier (TMSI) is considered as unreliable by
the UE or the TMSI re-assignment is not configured; therefore, the UE uses the
international mobile subscriber identity (IMSI) to initiate the location update.
Signaling Flow
by using IMSI).
IMSI)
The signaling flow of successful inter-VLR common location update (initiated by using IMSI)
is as follows:
carries the IMSI of the UE, the location area identity (LAI), and the location
update type.
the previous vlr (PVLR). Then, the VLR sends a
MAP_UPDATE_LOCATION_REQ message to the HLR.
NOTE:
When the UE initiates location update by using TMSI for the first time, the VLR
the operation fails, the MSC obtains the IMSI from the UE and then uses the IMSI

Measurement Point
in Flowchart
P1
P2
Measurement Type
Location Update
Requests
Location Management
MSC Basic Functions
Service
Location Update
Requests During
Roaming
Location Management
MSC Basic Functions
Service
Update location
request times (LAI)
Traffic Measurement
Global Components
For LAI
Location Update
Requests
MSC Basic Services
Successful Location
Updates During
Roaming
Location Management
MSC Basic Functions
Service
Success Rate of
Location Update
Location Management
MSC Basic Functions
Service
Successful Location
Updates During
National Roaming
Location Management
MSC Basic Functions
Service
MSC Basic Functions
Successful Location
Location Management
Updates During
MSC Basic Functions
Service

Using TMSI)
Service Model
Signaling Flow
Service Model
The location update is initiated by using the temporary mobile subscriber identifier
(TMSI).
Signaling Flow
by using TMSI).
Figure 1 Signaling flow of the successful inter-VLR common location update (initiated by
using TMSI)
The signaling flow of successful inter-VLR common location update (initiated by using TMSI)
is as follows:
carries the TMSI of the UE, the location area identity (LAI), and the location
update type.
the VLR to insert the updated location update of the subscriber.
NOTE:
When the UE initiates location update by using TMSI for the first time, the VLR
the operation fails, the MSC obtains the IMSI from the UE and then uses the IMSI

Measurement Point
in Flowchart
P1
P2
Measurement Type
Location Update
Requests
Location Management
MSC Basic Functions
Service
Location Update
Requests During
Roaming
Location Management
MSC Basic Functions
Service
Update location
request times (LAI)
Traffic Measurement
Global Components
For LAI
Location Update
Requests
MSC Basic Services
Successful Location
Updates During
Roaming
Location Management
MSC Basic Functions
Service
Success Rate of
Location Update
Location Management
MSC Basic Functions
Service
Successful Location
Updates During
National Roaming
Location Management
MSC Basic Functions
Service
MSC Basic Functions
Successful Location
Location Management
Updates During
MSC Basic Functions
Service

Service Model
Signaling Flow
Service Model
The location update fails because of roaming restriction of Check international
mobile equipment identity (IMEI) failure.
Signaling Flow
Figure 1 shows the signaling flow of unsuccessful inter-VLR common location update.
Figure 1 Signaling flow of unsuccessful inter-VLR common location update

The signaling flow of unsuccessful inter-VLR common location update is as follows:
carries the temporary mobile subscriber identifier (TMSI) of the UE, the location
area identity (LAI), and the location update type.
10. The VLR checks the subscriber data for roaming restriction, and then sends a
MAP_UPDATE_LOCATION_AREA_ACK message carrying the check result to
the MSC.
11. If roaming restriction is enabled for the subscriber, the MSC sends a Location
updating reject message, notifying the UE that the location update is rejected.
Then, the MSC releases the channel.
12. If roaming restriction is not enabled for the subscriber, the MSC initiates the
Check IMEI flow by sending a Check_IMEI_REQ message to the equipment
identity register (EIR). This flow is optional.
13. If the Check IMEI flow fails, the MSC sends a Location updating reject message,
notifying the UE that the location update is rejected.
NOTE:

Measurement Point
in Flowchart
P1
P2
Measurement Type
Location Update
Requests
Location Management
MSC Basic Functions
Service
Location Update
Requests During
Roaming
Location Management
MSC Basic Functions
Service
Update location
request times (LAI)
Traffic Measurement
Global Components
For LAI
Location Update
Requests
MSC Basic Services
Location Update
Failures Caused by
Location Area
Prohibition in the
Network
Location Management
MSC Basic Functions
Service
Location Update
Failures Caused by
public land mobile
network (PLMN)
Prohibition
Location Management
MSC Basic Functions
Service
Location Update
Failures Caused by
Roaming Prohibition
Location Management
MSC Basic Functions
Service

MSC Basic Functions
Periodic Location Update

When an MS enters an area without network coverage or the MS encounters a power
failure, the MS is detached from the network without sending an international mobile
subscriber identity (IMSI) DETACH message. In such a case, the VLR cannot set a detach
flag for the IMSI. Therefore, if the subscriber is called, circuit and radio resources will be
wasted.
Periodic location update enables an MS to originate a location update periodically,
regardless of whether it moves to a new location area. If the MS does not originate a
periodic location update after a specified period, the VLR sets the IMSI to the detached
state. In this way, circuit and radio resources are saved.
Periodic location update generally involves the VLR only. The signaling flow is similar to that
of intra-VLR common location update. For details, see Successful Intra-VLR Common
Location Update (Only VLR Is Involved) for 2G or Successful Intra-VLR Common Location
Update (Only VLR Is Involved) for 3G.
Independent Location Update

When a subscriber originates a service request, independent location update enables the
MSC to automatically initiate a location update if it detects that the data of the subscriber is
not available or acknowledged in the VLR. For example, when a subscriber originates a
call, the MSC automatically initiates a location update while connecting the call, if it detects
that the data of the subscriber is not available or acknowledged in the VLR. The process is
not known to the subscriber.
The signaling flow of independent location update is similar to that of common location
update. For details, see Successful Intra-VLR Common Location Update (Only VLR Is
Involved) for 2G or Successful Intra-VLR Common Location Update (Only VLR Is Involved)
for 3G.
Combined Location Update

If the Gs interface is present in the network and the MS supports both CS and PS services,
an RAI-VLR mapping table (routing area identity (RAI) represents Routing Area Identity) is
created on the SGSN. An association is established between the SGSN and the VLR, and
each of them saves the integrated services digital network (ISDN) number of the other. In
this way, the SGSN can identify the correct VLR based on the RAI.
Combined location update enables simultaneous update of the routing area (RA) and the
location area (LA). As only one radio interface is involved in this process, radio resources
are saved. Combined location update usually occurs in the following scenarios:
An MS enters a new RA.
An MS attached to general packet radio service (GPRS) initiates an international
mobile subscriber identity (IMSI) attach.
An MS initiates GPRS attach and IMSI attach simultaneously.
NOTE:
Combined location update can be categorized as intra-SGSN combined location update and
inter-SGSN combined location update. This document focuses only on intra-SGSN
combined location update.
Successful Combined Location Update
Unsuccessful Combined Location Update
Successful Combined Location Update

Service Model
Signaling Flow
Service Model
A 3G subscriber initiates a combined location update.
The location area (LA) is updated in the VLR.
The routing area (RA) is updated in the SGSN.
Signaling Flow
Figure 1 shows the signaling flow of successful intra-SGSN combined location update.
Figure 1 Signaling flow of successful intra-SGSN combined location update

The signaling flow of successful intra-SGSN combined location update is as follows:

1. The UE sends a Routing area updating request message, instructing the SGSN to
initiate an RA location update.
2. The SGSN obtains the location update type from the request. If the location
update type is international mobile subscriber identity (IMSI) attach of combined
RA/LA location update or LA change along with RA update, the SGSN obtains the
VLR number from the RAI-VLR mapping table, and then sends a Location
updating request to the VLR. At the same time, the SGSN initiates the RA
location update flow.
3. The MSC/VLR and the SGSN initiate the authentication and security management
flow. This flow is optional.
location update is successful. If re-assignment of temporary mobile subscriber
identifier (TMSI) is required, the VLR also sends the assigned TMSI to the
SGSN.
9. If the RA location update is successful, the SGSN sends a Routing area updating
accept message to the UE.
10. On receiving the message, the UE sends a Routing area updating complete to the
SGSN.
11. If the VLR re-assigns a TMSI in the combined location update flow, the SGSN
sends a TMSI reallocation complete message to the VLR.
NOTE:
The signaling flows of 2G combined location update and 3G combined location update are
the same.

Measurement Point
in Flowchart
P1
Measurement Type
Location Update
Requests
Location Management
MSC Basic Functions
Service
Combined Normal
Intra-VLR Location
Updates
Location Management
MSC Basic Functions
Service
Inter-VLR Combined
Normal Location
Updates
Location Management
MSC Basic Functions
Service
Update location
request times (LAI)
Traffic Measurement
Global Components
For LAI
Location Update
Requests
MSC Basic Services
MSC Basic Functions
Successful Combined
Location Management
Normal Intra-VLR
MSC Basic Functions
Service
Location Updates
P2
Inter-VLR Successful
Location Management
Combined Normal
MSC Basic Functions
Service
Location Updates
Success Rate of
Location Update
Location Management
MSC Basic Functions
Service
Parent topic: Combined Location Update

Unsuccessful Combined Location Update

Service Model
Signaling Flow
Service Model
A 3G subscriber initiates a combined location update.
The location area is updated in the VLR.
The routing area (RA) is updated in the SGSN.
The location area (LA) location update fails because of roaming restriction.
Signaling Flow
Figure 1 shows the signaling flow of unsuccessful intra-SGSN combined location update.
Figure 1 Signaling flow of unsuccessful intra-SGSN combined location update

The signaling flow of unsuccessful intra-SGSN combined location update is as follows:

1. The UE sends a Routing area updating request message, instructing the SGSN to
initiate RA location update.
2. The SGSN obtains the location update type from the request. If the location
update type is international mobile subscriber identity (IMSI) attach of combined
RA/LA location update or LA change along with RA update, the SGSN obtains the
VLR number from the RAI-VLR mapping table, and then sends a Location
updating request to the VLR. At the same time, the SGSN initiates the RA
location update flow.
3. The MSC/VLR and the SGSN initiate the authentication and security management
flow. This flow is optional.
8. The MSC/VLR checks the subscriber data and finds that roaming restriction is
enabled for the subscriber. Then, the MSC/VLR sends a Location updating reject
message, notifying the SGSN that the location update is rejected.
9. On receiving the message, the SGSN sends a Routing area updating accept
message to the UE if the RA location update is successful. The message carries
an information element (IE) indicating that the RA location update is successful. If
the RA location update also fails, the SGSN sends a Routing area updating reject
message to the UE.
Measurement Point
in Flowchart
Location Update
Requests
Measurement Type
Location Management
MSC Basic Functions
Service
Combined Normal
Intra-VLR Location
Updates
P1
P2
Location Management
MSC Basic Functions
Service
Inter-VLR Combined
Normal Location
Updates
Location Management
MSC Basic Functions
Service
Update location
request times (LAI)
Traffic Measurement
Global Components
For LAI
Location Update
Requests
MSC Basic Services
Location Update
Failures Caused by
Location Area
Prohibition in the
Network
Location Management
MSC Basic Functions
Service
Location Update
Failures Caused by
PLMN Prohibition
Location Management
MSC Basic Functions
Service
Location Update
Failures Caused by
Roaming Prohibition
Location Management
MSC Basic Functions
Service
Parent topic: Combined Location Update

MSC Basic Functions
Location Cancellation
Location cancellation means to send a Cancel Location message from the HLR to delete
the data of a subscriber from the VLR. When a subscriber roams from one VLR to another
and initiates a location update, the HLR, on receiving the location update request sent from
the MSC/VLR, initiates the Cancel Location flow to delete the data of the subscriber from
the previous VLR if it detects that the VLR where the subscriber is roaming has changed.
Cancel Location
Cancel Location
Service Model
Signaling Flow
Service Model
A 2G or 3G subscriber roams from one VLR to another and initiates a location
update.
The HLR deletes the data of the subscriber from the previous HLR.
Signaling Flow
Figure 1 shows the Cancel Location signaling flow.
Figure 1 Cancel Location signaling flow

The Cancel Location signaling flow is as follows:
1. On receiving the location update request from the MSC/VLR, the HLR detects
that the VLR where the subscriber is roaming has changed. Then, the HLR sends
a MAP_CANCEL_LOCATION_REQ message carrying the international mobile
subscriber identity (IMSI) of the subscriber to the previous vlr (PVLR).
2. The PVLR deletes the data of the subscriber, and then sends a
None.
Parent topic: Location Cancellation

IMSI Detach
When an MS does not initiate any network operation (for example, location update or
making calls) for a long time or is switched off, the VLR automatically sets the subscriber to
the detached state. When a subscriber who is in detached state is called, the system does
not page the subscriber. Thus, the radio channel resources are saved.
There are two types of international mobile subscriber identity (IMSI) detach:
Implicit IMSI detach: After the implicit IMSI detach timer times out, the VLR
automatically sets the subscriber to the detached state.
Whether to initiate implicit IMSI detach is also determined by the time interval of
periodic location update. If the time interval specified for implicit location update is
longer than that specified for periodic location update, the VLR does not initiate
implicit IMSI detach if the subscriber has initiated periodic location update within
the time interval. In such a case, the VLR initiates implicit IMSI detach only when
the subscriber does not initiate periodic location update after moving into an area
without signal coverage.
NOTE:
The implicit IMSI detach timer is actually a counter. It records the time within which
an MS does not initiate any network operation (for example, location update or
making calls). When the counter reaches the specified IMSI detach time, the VLR
sets the subscriber to the detached state.
Explicit IMSI detach: An MS initiates the IMSI detach flow when the subscriber
powers off the MS, and the VLR sets the subscriber to the detached state.
Explicit IMSI Detach
Explicit IMSI Detach

Service Model
Signaling Flow
Service Model
A 3G subscriber powers off the UE and the system initiates the explicit international mobile
subscriber identity (IMSI) detach flow.
Signaling Flow
Figure 1 shows the signaling flow of explicit IMSI detach.
Figure 1 Signaling flow of explicit IMSI detach

The signaling flow of explicit IMSI detach is as follows:
1. When a 3G subscriber powers off the UE, the UE sends an IMSI detach
indication message to the MSC, and then releases the wireless connection.
2. On receiving the message, the MSC sends a MAP_DETACH_IMSI_IND
message, instructing the VLR to set the UE to the IMSI detach state.
3. After setting the UE to the IMSI detach state, the VLR sends a
MAP_DETACH_IMSI_RSP message to the MSC.
4. The MSC releases the channel. The IMSI detach flow is complete.
NOTE:
The IMSI detach flow is the same for both the 2G and 3G networks.
Measurement Point
in Flowchart
P1
Measurement Type
IMSI Detached Times
Location Management
MSC Basic Functions
Service
IMSI Detach Times
MSC Basic Services
Imsi detach times

(LAI)
Traffic Measurement
Global Components
For LAI
Parent topic: IMSI Detach

MSC Basic Functions
Security Management
Authentication and Encryption
Authentication and Encryption

2G Authentication and Encryption
Parent topic: Security Management

2G authentication and encryption helps to improve the network security by preventing
illegitimate subscribers (for example, subscribers using SIMs with a cloned international
mobile subscriber identity (IMSI) and key identity (KI)) from using network services.
Whether to perform authentication is determined by the carrier. To protect investment of
carriers, authentication is usually performed in each call setup, location update, or
supplementation service activation without call connection.
Successful Authentication
Unsuccessful Authentication Due to Network Denial
Parent topic: Authentication and Encryption
Service Model
Signaling Flow
Service Model
Authentication on a 2G subscriber is successful when the subscriber attempts a service
access.
Signaling Flow
Figure 1 shows the signaling flow of successful authentication of a 2G subscriber.
Figure 1 Signaling flow of successful authentication of a 2G subscriber
As shown in Figure 1, P1, P2, P3, P4 refers to the measurement point.

The successful authentication flow of a 2G subscriber is as follows:
1. On receiving a location update, call, or supplementary service request, the
MSC/VLR determines whether to perform authentication according to the data
configuration. If authentication is not required, the MSC/VLR skips the
authentication flow. If authentication is required, the VLR checks whether
authentication triplets are available. If authentication triplets are available, the
VLR sends an Authentication request to the MS. If no authentication triplets are

available, the VLR obtains authentication sets from the HLR.
2. The MSC/VLR identifies the HLR serving the subscriber based on the
international mobile subscriber identity (IMSI) carried in the received request, and
then sends a MAP_SEND_AUTHENTICATION_INFO_REQ message to the HLR.
The message carries the IMSI of the subscriber and the number of required
authentication sets (5 by default and can be configured as required).
3. The HLR requests the authentication center (AuC) (usually integrated with the
HLR) for five authentication sets, and then sends a
MAP_SEND_AUTHENTICATION_INFO_RSP message carrying the authentication
sets to the MSC/VLR.
4. The MSC/VLR sends an Authentication request message carrying the first
authentication set to the MS and stores the remaining authentication sets in the
VLR.
5. On receiving the authentication request, the MS sends the random number
(RAND) contained in the authentication set to the subscriber identity module
(SIM). The SIM uses the algorithm A3 (A3) authentication algorithm to generate
an SRES by using the RAND and the individual subscriber authentication key (Ki)
stored in the SIM and uses the A8 authentication algorithm to generate a cipher
key (Kc). Then, the SIM sends the SRES and cipher key (Kc) to the MS and the
MS sends an Authentication response message carrying the SRES to the
MSC/VLR.
6. The MSC/VLR compares the SRES reported by the MS and the SRES provided
by the AuC. If the SRESs are the same, the MSC/VLR passes the authentication
and sends a CIPHER MODE COMMAND message to start the encryption flow. If
the SRESs are not the same, the MSC/VLR denies the authentication and sends
an Authentication reject message to the MS. On receiving the message, the MS
stops accessing the network and adds the network to the list of unauthorized
networks.
7. The MS uses the algorithm A5 (A5) encryption algorithm to perform encryption
calculation by using the encryption mode (M), encryption key (Kc), and Time
Division Multiple Access (TDMA) frame number, and then sends a CIPHER
MODE COMPLETE message to the BSC. The BSC uses the A5 encryption
algorithm to decrypt and restore the message. If there is no error, the BSC
forwards the CIPHER MODE COMPLETE message to the MSC/VLR. At this
point, the network access of the MS is complete.
NOTE:
If only encryption is configured for a certain event in the authentication configuration table,
the system automatically triggers the authentication flow if there is no encryption context
available in the VLR.
Measurement Point
in Flowchart
Measurement Type
P1
AUTH Requests
Authentication
MSC Basic Functions
P2
AUTH Success Times Authentication
MSC Basic Functions
P3
Set Cipher Mode

Times
MSC Basic Services
MSC Basic Functions
P4
Set Cipher Mode

Success Times
MSC Basic Services
MSC Basic Functions
Parent topic: 2G Authentication and Encryption


Service Model
Signaling Flow
Service Model
The authentication on a 2G subscriber fails because of network denial when the subscriber
attempts a service access.
Signaling Flow
Figure 1 shows the signaling flow of unsuccessful authentication of a 2G subscriber due to
network denial.
Figure 1 Signaling flow of unsuccessful authentication of a 2G subscriber due to network
denial
The signaling flow of unsuccessful authentication of a 2G subscriber due to network denial
is as follows:
MSC/VLR sends an Authentication request message carrying authentication sets
to the MS.
(RAND) contained in the authentication set to the subscriber identity module
(SIM). The SIM then uses the algorithm A3 (A3) authentication algorithm to
generate an SRES by using the RAND and the individual subscriber authentication
key (Ki) stored in the SIM and uses the A8 authentication algorithm to generate a
cipher key (Kc). Then, the SIM sends the SRES and cipher key (Kc) to the MS
and the MS sends an Authentication response message carrying the SRES to the
MSC/VLR.
3. The MSC/VLR compares the SRES reported by the MS and the SRES provided
by the authentication center (AuC). If the SRESs are not the same, the MSC/VLR
denies the authentication and sends a
MAP_AUTHENTICATION_FAILURE_REPORT_REQ message to the HLR. The
message carries the international mobile subscriber identity (IMSI) of the
subscriber, cause of the authentication failure, and ID of the MSC/VLR.
4. The MSC/VLR sends an Authentication reject message to the MS at the same
time. On receiving the message, the MS stops accessing the network and adds
the network to the list of unauthorized networks.
5. On receiving the failure report, the HLR sends a
MAP_AUTHENTICATION_FAILURE_REPORT_RSP message, notifying the
MSC/VLR that it has known the authentication failure.
Measurement Point
in Flowchart
Measurement Type
P1
Authentication
MSC Basic Functions
AUTH Failures due to

Authentication
Illegal SRES
MSC Basic Functions
TMSI-based AUTH
Failures due to Illegal Authentication
SRES
MSC Basic Functions
P2
AUTH Requests


3G authentication and encryption helps to improve the network security from the following
aspects:
Network authentication on the subscriber: Prevents illegitimate subscribers (for
example, subscribers using SIMs with a cloned international mobile subscriber
identity (IMSI) and key identity (KI)) from using network services.
Subscriber authentication on the network and integrity protection: Protects
subscribers against attacks from illegitimate networks.
Whether to perform authentication is determined by the carrier. To protect investment of
carriers, authentication is usually performed in each call setup, location update,
supplementation service activation without call connection, or short message service (SMS)
exchange.
Unsuccessful Authentication Due to UE Denial
Parent topic: Authentication and Encryption
Service Model
Signaling Flow
Service Model
Authentication on a 3G subscriber is successful when the subscriber attempts a service
access.
Signaling Flow
Figure 1 shows the signaling flow of successful authentication of a 3G subscriber.
Figure 1 Signaling flow of successful authentication of a 3G subscriber
As shown in Figure 1, P1, P2, P3, P4 refers to the measurement point.

The successful authentication flow of a 3G subscriber is as follows:
MSC/VLR determines whether to perform authentication according to the data
configuration. If authentication is not required, the MSC/VLR skips the
authentication flow. If authentication is required, the VLR checks whether
authentication quintuples are available. If authentication quintuples are available,
the VLR sends an Authentication request to the UE. If no authentication quintuples

are available, the VLR obtains authentication sets from the HLR.
2. The MSC/VLR identifies the HLR serving the subscriber based on the
international mobile subscriber identity (IMSI) carried in the received request, and
then sends a MAP_SEND_AUTHENTICATION_INFO_REQ message to the HLR.
The message carries the IMSI of the subscriber and the number of required
authentication sets (can be configured as required).
3. The HLR requests the authentication center (AuC) (usually integrated with the
HLR) for five authentication quintuples, and then sends a
MAP_SEND_AUTHENTICATION_INFO_RSP message carrying the authentication
quintuples to the MSC/VLR.
4. The MSC/VLR sends an Authentication request message carrying the first
authentication quintuple to the UE and stores the remaining authentication sets in
the VLR.
(RAND) contained in the authentication quintuple to the user service identity
module (USIM). The USIM performs the following processing based on the
RAND, authentication token (AUTN), and the authentication key (K) stored in the
USIM:
1. Checks the AUTN: The USIM checks whether the mobile access code
(MAC) contained in the AUTN is the same as the MAC calculated by
using the RAND. If the MACs are not the same, the USIM sends an
Authentication failure message carrying the failure cause value to the
MSC/VLR. The authentication flow is ended.
2. Checks the sequence number (SQN): The USIM checks whether the
SQN stored in it is the same as the SQN calculated by using the AUTN.
If the SQNs are not the same, the USIM sends an Authentication failure
message carrying the failure cause value to the MSC/VLR. The
authentication flow is ended.
3. Calculates a Universal Mobile Telecommunications System (UMTS)
ciphering key (CK) and an integrity key (IK) by using the RAND, uses
the UMTS CK and IK to overwrite the original CK and IK, and sends an
Authentication response message carrying the authentication result to
the MSC/VLR.
6. The MSC/VLR compares the SRES reported by the UE and the expected
response (XRES) provided by the AuC. If the SRES is the same as XRES, the
MSC/VLR passes the authentication and sends a SECURITY MODE COMMAND
message to start the encryption flow. The message carries the encryption and
integrity protection algorithms supported by the MSC/VLR.

7. The RNC chooses a common algorithm from the algorithms supported by the
MSC/VLR, UE, and nodeB to start encryption and integrity protection, and then
sends a SECURITY MODE COMPLETE message to the MSC/VLR. If there is no
common algorithms among the algorithms supported by the MSC/VLR, UE, and
nodeB and the network is not ready to use an unencrypted connection, the RNC
ends a SECURITY MODE REJECT message to the MSC/VLR. At this point, the
network access of the UE is complete.
NOTE:
If only encryption is configured for a certain event in the authentication configuration table,
the system automatically triggers the authentication flow if there is no encryption context
available in the VLR.
Measurement Point
in Flowchart
Measurement Type
P1
AUTH Requests
Authentication
MSC Basic Functions
P2
AUTH Success Times Authentication
MSC Basic Functions
P3
Set Cipher Mode

Times
MSC Basic Services
MSC Basic Functions
P4
Set Cipher Mode

Success Times
MSC Basic Services
MSC Basic Functions


Service Model
Signaling Flow
Service Model
The authentication on a 3G subscriber fails because of network denial when the subscriber
Signaling Flow
network denial.
Figure 1 Signaling flow of unsuccessful authentication of a 3G subscriber due to network
denial
The signaling flow of unsuccessful authentication of a 3G subscriber due to network denial
is as follows:
MSC/VLR sends an Authentication request message carrying authentication
quintuples to the UE.
2. The UE checks the authentication token (AUTN) and sequence number (SQN) in
sequence. Then, the UE calculates the SRES and sends an Authentication
response carrying the SRES to the MSC/VLR.
3. The MSC/VLR compares the SRES reported by the UE and the expected
response (XRES) provided by the authentication center (AuC). If the SRES is not
the same as the XRES, the MSC/VLR denies the authentication and sends a
4. The MSC/VLR sends an Authentication reject message to the UE at the same
time. On receiving the message, the UE stops accessing the network and adds
the network to the list of unauthorized networks.
Measurement Point
in Flowchart
Measurement Type
P1
Authentication
MSC Basic Functions
AUTH Failures due to

Authentication
Illegal SRES
MSC Basic Functions
TMSI-based AUTH
Failures due to Illegal Authentication
SRES
MSC Basic Functions
P2
AUTH Requests

Unsuccessful Authentication Due to UE Denial

Service Model
Signaling Flow
Service Model
The authentication on a 3G subscriber fails because of UE denial when the subscriber
Signaling Flow
network denial.
Figure 1 Signaling flow of unsuccessful authentication of a 3G subscriber due to UE denial

The signaling flow of unsuccessful authentication of a 3G subscriber due to UE denial is as
follows:
MSC/VLR sends an Authentication request message carrying authentication
quintuples to the UE.
2. The UE checks the authentication token (AUTN) and sequence number (SQN) in
sequence. When checking the AUTN, if the UE finds that the mobile access code
(MAC) contained in the AUTN is not the same as the calculated MAC, or the
MACs are the same but the SQN calculated by using the AUTN exceeds the
specified range, the authentication fails and the UE sends an Authentication failure
message to the MSC/VLR. The message carries the cause of the authentication
failure.
3. On the Authentication failure message, the MSC/VLR sends a
5. At the same time, the MSC/VLR sends a location update request or service reject
message to the UE.
Measurement Point
in Flowchart
Measurement Type
P1
AUTH Requests
Authentication
MSC Basic Functions
P2
Negative AUTH
Responses by
Subscribers
Authentication
MSC Basic Functions

Subscriber Data Management

Purge MS is an important subscriber data management function.
Purge MS is triggered if subscriber data is deleted from the VLR because the subscriber
remains inactive within the specified period (24 hours by default and can be changed as
required) or the administrator deletes subscriber data records from the VLR.
When the data of a subscriber is deleted from the VLR, the VLR sends a Purge MS request
to the HLR. On receiving the request, the HLR adds a Purge flag to the corresponding
subscriber data record. When the subscriber receives a call, the HLR directly prompts that
the subscriber is unreachable and releases the call when it is requested for the routing
information. In this way, the provide roaming number (PRN) flow is not performed and thus
the signaling interaction efficiency is improved.
Purge MS Flow
Purge MS Flow
Service Model
Signaling Flow
Service Model
The VLR removes subscriber data from the database because the subscriber remains
inactive within the specified period or the administrator deletes the corresponding
subscriber data record for management purpose.
Signaling Flow
Figure 1 shows the Purge MS signaling flow.
Figure 1 Purge MS signaling flow

The Purge MS signaling flow is as follows:
1. If a subscriber remains inactive within the specified period or the administrator
deletes the corresponding subscriber data record for management purpose, the
VLR deletes the data of the subscriber from the database and sends a
MAP_PURGE_MS_REQ message to the HLR. The message carries the
international mobile subscriber identity (IMSI) of the subscriber to be purged.
2. The HLR adds a Purge flag to the corresponding subscriber data record and
sends a MAP_PURGE_MS_CNF to the VLR.
None.
Parent topic: Subscriber Data Management

Handover Management
UMTS Handover
GSM Handover
GSM-UMTS Handover
UMTS Handover
Universal Mobile Telecommunications System (UMTS) handover (also known as relocation
in UMTS) means to hand over a UMTS subscriber between RNCs in the UMTS network. It
serves the following purposes:
Ensures the conversation quality when the subscriber is on the move.
Balances the traffic to improve the overall performance of the system.
UMTS handovers are categorized into the following types:
Intra-MSC handover: a handover between two RNCs connected to the same MSC
in the UMTS network
Basic inter-MSC handover: a handover where the UE is handed over from a
controlling MSC (MSC A) to another MSC (MSC B)
Subsequent inter-MSC handback: a handover where the UE is handed back from
MSC B to MSC A
Subsequent inter-MSC handover to a third party: a handover where the UE is
handed over from MSC B to a third MSC (MSC B')
NOTE:
Depending on whether the Iur interface is present between RNCs, there are two types of
handover in the UMTS network: soft handover and hard handover.
Hard handover: This type of handover is performed between RNCs without using
the Iur interface under the control of the MSC. It may cause a change in radio
resources.
Soft handover: This type of handover is performed through the Iur interface under
the control of the RNC. It does not cause a change in radio resources. It is
transparent to the MSC.
This document focuses only on the hard handover.
3G Intra-MSC Handover
3G Inter-MSC Handover (A->B)
3G Subsequent Inter-MSC Handback (A->B->A)
3G Subsequent Inter-MSC Handover to a Third Party (A->B->B')
Parent topic: Handover Management

Service Model
Signaling Flow
Service Model
An intra-MSC handover is performed for a 3G mobile subscriber.
Hard handover is applied in the relocation.
Signaling Flow
Figure 1 shows the signaling flow of 3G intra-MSC handover.
Figure 1 Signaling flow of 3G intra-MSC handover

The signaling flow of 3G intra-MSC handover is as follows:
1. RNC-A sends a RELOCATION REQUIRED message, requesting 3G-MSC-A to
initiate a handover. The message carries mandatory information elements (IEs)

such as Relocation Type, CAUSE, SourceID, and TargetID.
2. On receiving the RELOCATION REQUIRED message, 3G-MSC-A queries the
RNC ID table for the target RNC. If 3G-MSC-A finds that it is connecting to the
target RNC, it adds an endpoint for RNC-B on the MGW and modifies the stream
direction between endpoints in the context. Then, 3G-MSC-A sends a
RELOCATION REQUEST message, requesting RNC-B to allocate the required
radio resources.
3. On receiving the RELOCATION REQUEST message, RNC-B allocates the
required radio resources and sets up the access bearer with the MGW. Then,
RNC-B sends a RELOCATION REQUEST ACKNOWLEDGE message to 3GMSC-A. The message carries the RABID of the bearer successfully set up or the
RABID of the bearer unsuccessfully set up and the failure cause.
4. If 3G-MSC-A receives the RELOCATION REQUEST ACKNOWLEDGE message
from RNC-B, it indicates that the radio resources are ready and the UE can be
handed over from RNC-A to RNC-B. At this point, 3G-MSC-A constructs a
RELOCATION COMMAND message by using the IEs contained in the
RELOCATION REQUEST ACKNOWLEDGE message and then sends the
message to RNC-A.
5. RNC-A sends an RR-HO-Command message, instructing the UE to hand over to
RNC-B.
6. At this point, the UE has detected a new radio channel. The requirement for
access to the new radio channel is met but actually the UE is not switched to the
channel. As the current handover is a speech handover, a speech channel must
be established in advance. Therefore, RNC-B sends a RELOCATION DETECT
message to 3G-MSC-A. On receiving the message, 3G-MSC-A requests the
MGW to change the stream direction between endpoints in the context, and then
connects the peer endpoint to the new endpoint to set up a speech channel.
7. The UE accesses the new channel and sends an RR-HO-Complete message to
RNC-B.
8. After the UE connects to RNC-B successfully through the newly established
speech channel, RNC-B sends a RELOCATION COMPLETE message to 3GMSC-A.
9. 3G-MSC-A sends an IU RELEASE COMMAND message, instructing RNC-A to
release the radio resources and the bearer between the RNC and the MGW.
10. After releasing the radio resources, RNC-A sends an IU RELEASE COMPLETE
message, requesting 3G-MSC-A to release the endpoint of RNC-A from the
MGW. At this point, the handover is complete.

Measurement Point
in Flowchart
P1
P2
Requested Intra-MSC Handover between

HOs from RNC
WCDMA RNCs
MSC Basic Services
Inter-RNC HOs due to

Handover between
Radio Resource
WCDMA RNCs
Reasons
MSC Basic Services
Inter-RNC HOs due to Handover between

O&M Intervention
WCDMA RNCs
MSC Basic Services

Resource Optimization WCDMA RNCs
MSC Basic Services
Intra-MSC Handover
Requested Times
Local MSC Handover MSC Basic Services
Out LAI HO times

(LAI)
Traffic Measurement
Global Components
For LAI
Requested Intra-MSC
HOs to RNC
IN LAI HO times (LAI)
P3
Measurement Type
Traffic Measurement
Global Components
For LAI
HO Failures due to
Handover between
Unknown Target RNC WCDMA RNCs
MSC Basic Services
HO Failures due to
Resource
Unavailability
Handover between
WCDMA RNCs
MSC Basic Services
HO Failures due to
Unsupported Ciphering Handover between
and Integrity
WCDMA RNCs
Protection Algorithms
MSC Basic Services
HO Failures due to
Unavailability of
Requested
Guaranteed Bit Rate
MSC Basic Services
Handover between
WCDMA RNCs
P4
P5
Handover Failures
Responded by the
Source or Target
HO Failures due to
HO Completion
Timeout
Handover between
WCDMA RNCs
MSC Basic Services
HO Failures due to
Radio Interface
Failures
Handover between
WCDMA RNCs
MSC Basic Services
Successful Intra-MSC Handover between

HOs from RNC
WCDMA RNCs
MSC Basic Services

HOs to RNC
WCDMA RNCs
MSC Basic Services
Out LAI HO success

times (LAI)
Traffic Measurement
Global Components
For LAI
IN LAI HO success
times (LAI)
Traffic Measurement
Global Components
For LAI
Successful Intra-MSC
Handover Times
Parent topic: UMTS Handover

Service Model
Signaling Flow
Service Model
An inter-MSC handover is performed for a 3G mobile subscriber.
The controlling MSC is 3G-MSC-A and the target MSC is 3G-MSC-B.
Signaling Flow
Figure 1 shows the signaling flow of 3G inter-MSC handover.
Figure 1 Signaling flow of 3G inter-MSC handover
Caller:
P1, P2, P3, P4, P5
Callee:
Q1, Q2, Q3, Q4, Q5
The signaling flow of 3G inter-MSC handover is as follows:

location of the target cell based on the location area identity (LAI)/global cell
identity (GCI) and determines that the current handover is an inter-MSC
handover. Then, 3G-MSC-A constructs a MAP_PREPARE_HANDOVER_REQ
message by using the IEs contained in the RELOCATION REQUIRED message
and sends the message to request 3G-MSC-B to prepare for the handover.
3. 3G-MSC-B requests VLR-B for a handover number. At the same time, 3G-MSCB constructs a RELOCATION REQUEST message and sends it to request RNCB to allocate required radio resources. 3G-MSC-B requests radio resources from
RNC-B and handover number from VLR-B concurrently. It sends the
MAP_PREPARE_HANDOVER_RSP message to 3G-MSC-A only after receiving
the responses from RNC-B and VLR-B.
4. After allocating radio resources, RNC-B sends a RELOCATION REQUEST
ACKNOWLEDGE message to 3G-MSC-B.
5. After VLR-B allocates the handover number, 3G-MSC-B sends a
MAP_PREPARE_HANDOVER_RSP message to notify 3G-MSC-A that the
handover preparation is complete. The message carries the handover number,
which can be used by 3G-MSC-A to establish a speech channel to 3G-MSC-B.
6. 3G-MSC-A analyzes the handover number and selects an outgoing route based
on the handover number. If the routing is successful, 3G-MSC-A sends an IAM
message to 3G-MSC-B.
7. If 3G-MSC-B determines that the called number carried in the IAM message is a
handover number, it sends a MAP_Send_Handover_Report_RSP message,
requesting VLR-B to release the handover number. The message can be sent at
any time after 3G-MSC-B receives the IAM message. At the same time, 3GMSC-B sends an address complete message (ACM) message to 3G-MSC-A.
8. After an inter-MSC circuit is set up, 3G-MSC-A constructs a RELOCATION
COMMAND message by using the contents resolved from the
MAP_PREPARE_HANDOVER_RSP message, and then sends the message to
instruct RNC-A to hand over the UE to RNC-B.
9. On detecting the correct UE, RNC-B sends a RELOCATION DETECT message
to 3G-MSC-B. At this point, the UE has detected a new radio channel. The
requirement for access to the new radio channel is met but actually the UE is not
switched to the channel. As the current handover is a speech handover, a speech
channel must be established in advance.

10. 3G-MSC-B transparently transfers the RELOCATION DETECT message to 3GMSC-A through a MAP_PROCESS_ACCESS_SIGNALLING message. On
receiving the message, 3G-MSC-A requests the MGW to change the stream
direction between endpoints in the context, and then connects the peer endpoint
to the new endpoint.
11. A new channel is established, and the subscriber continues the conversation or
uses other services through the channel. RNC-B sends a RELOCATION
COMPLETE message to notify 3G-MSC-B that the inter-MSC handover is
complete.
12. 3G-MSC-B transparently transfers the RELOCATION COMPLETE message
through a MAP_SEND_END_SIGNAL_REQ message, notifying 3G-MSC-A that
the inter-MSC handover is complete.
release the terrestrial and radio resources.
14. After releasing the terrestrial and radio resources, RNC-A sends an IU RELEASE
COMPLETE message to 3G-MSC-A.
15. 3G-MSC-B sends an answer message (ANM) message to 3G-MSC-A. The
handover is complete.
16. After the conversion ends, 3G-MSC-A sends a release (REL) message to 3GMSC-B to release the call and the inter-MSC circuit.
17. 3G-MSC-A sends a MAP_SEND_END_SIGNAL_RSP message, instructing 3GMSC-B to release the inter-MSC Mobile Application Part (MAP) resources.
Measurement Point
in Flowchart
P1
Measurement Type
Requested Inter-MSC Handover between

Handovers from RNC WCDMA RNCs
MSC Basic Services

Handover between
Radio Resource
WCDMA RNCs
Reasons
MSC Basic Services
O&M Intervention
WCDMA RNCs

P2
P3
P4
P5
MSC Basic Services

MSC Basic Services
Basic Outgoing
Handover Requests
Out LAI HO times

(LAI)
Traffic Measurement
Global Components
For LAI
HO Failures due to
Handover between
MSC Basic Services
HO Failures due to
Resource
Unavailability
Handover between
WCDMA RNCs
MSC Basic Services
HO Failures due to
Unsupported
Handover between
Ciphering and Integrity WCDMA RNCs
MSC Basic Services
HO Failures due to
Unavailability of
Handover between
Requested
WCDMA RNCs
Guaranteed Bit Rate
MSC Basic Services
Handover Failures
Responded by the
Source or Target
HO Failures due to
HO Completion
Timeout
Handover between
WCDMA RNCs
MSC Basic Services
HO Failures due to
Radio Interface
Failures
Handover between
WCDMA RNCs
MSC Basic Services
Successful Inter-MSC Handover between

HOs from RNC
WCDMA RNCs
MSC Basic Services
Successful Basic
Outgoing Handover
Requests
Handover between
WCDMA RNCs
MSC Basic Services
Out LAI HO success

times (LAI)
Traffic Measurement
Global Components
For LAI

Measurement Point
in Flowchart
Q1
Q2
Q3
Q4
Q5
Measurement Type
Basic Incoming
Handover Requests
Successful Basic
Outgoing Handover
Requests
Handover between
WCDMA RNCs
Traffic Measurement
Global Components
For LAI
MSC Basic Services
HO Failures due to
Handover between
MSC Basic Services
HO Failures due to
Resource
Unavailability
Handover between
WCDMA RNCs
MSC Basic Services
HO Failures due to
Unsupported
Handover between
MSC Basic Services
HO Failures due to
Unavailability of
Handover between
Requested
WCDMA RNCs
Guaranteed Bit Rate
MSC Basic Services
Handover Failures
Responded by the
Source or Target
HO Failures due to
HO Completion
Timeout
Handover between
WCDMA RNCs
MSC Basic Services
HO Failures due to
Radio Interface
Failures
Handover between
WCDMA RNCs
MSC Basic Services
IN LAI HO success
times (LAI)
Successful Inter-MSC
HOs to RNC
Successful Basic
Traffic Measurement
Global Components
For LAI
Handover between
MSC Basic Services
WCDMA RNCs
Incoming Handover
Requests


Service Model
Signaling Flow
Service Model
The controlling MSC of the UE is 3G-MSC-A.
A subsequent handback is performed after an inter-MSC handover. That is, a 3G
subscriber is handed over from 3G-MSC-A to 3G-MSC-B and then back to 3GMSC-A.
Signaling Flow
Figure 1 shows the signaling flow of 3G subsequent inter-MSC handback.
Figure 1 Signaling flow of 3G subsequent inter-MSC handback

Caller:
P1, P2, P3, P4, P5
Callee:
Q1, Q2, Q3, Q4, Q5
The signaling flow of 3G subsequent inter-MSC handback is as follows:
1. RNC-B sends a RELOCATION REQUIRED message, requesting 3G-MSC-B to
2. 3G-MSC-B queries the location of the target location area or cell based on the
location area identity (LAI) or global cell identity (GCI) and determines that the
current handover is an inter-MSC handover. Then, 3G-MSC-B sends a
MAP_PREPARE_SUBSEQUENT_HANDOVER_REQ message to 3G-MSC-A.
The message carries information such as MSC ID of the target MSC and target
LAI/GCI.
3. 3G-MSC-A checks whether the current handover is a subsequent handback or a
subsequent handover to a third party based on the MSC ID. If 3G-MSC-A
determines that the current handover is a subsequent handover based on the
table query result, it constructs a RELOCATION REQUEST message by using
the IEs contained in the MAP_PREPARE_SUBSEQUENT_HANDOVER_REQ
message, and then sends the message to request RNC-A to allocate required
radio resources.
4. After allocating radio resources successfully, RNC-A sends a RELOCATION
REQUEST ACKNOWLEDGE message to 3G-MSC-A. The message carries
information about the allocated radio resources.
5. 3G-MSC-A sends a MAP_PREPARE_SUBSEQUENT_HANDOVER_RSP
message to notify 3G-MSC-B that the handover preparation is complete. The
message carries all the IEs contained in the RELOCATION REQUEST
ACKNOWLEDGE message.
6. 3G-MSC-B sends a RELOCATION COMMAND message, instructing RNC-B to
hand over the UE.
7. On detecting the correct UE, RNC-B sends a RELOCATION DETECT message
to 3G-MSC-A. At this point, the UE has detected a new radio channel. The

uses other services through the channel. RNC-A sends a RELOCATION
COMPLETE message to notify 3G-MSC-A that the handover is complete. At this
point, the subsequent handover is complete.
9. 3G-MSC-A sends a MAP_SEND_END_SIGNAL_RSP message, instructing 3GMSC-B to release the radio resources. The message carries all the IEs contained
in the RELOCATION COMPLETE message.
10. 3G-BSC-B sends an IU RELEASE COMMAND message, instructing RNC-B to
release the radio resources.
11. After releasing the radio resources, RNC-B sends an IU RELEASE COMPLETE
12. 3G-MSC-A sends a release (REL) message, instructing 3G-MSC-B to release
the inter-MSC trunk resources.
Table 1ists common measurement entities used on the originating side. Table 2lists common
measurement entities used on the terminating side.
Measurement Point
in Flowchart
P1
P2
Measurement Type

MSC Basic Services

Handover between
Radio Resource
WCDMA RNCs
Reasons
MSC Basic Services

O&M Intervention
WCDMA RNCs
MSC Basic Services

MSC Basic Services
Requests for
Subsequent Handover
(Local Office is
MSCb)
Out LAI HO times
Traffic Measurement
(LAI)
P3
P4
P5
For LAI
Global Components
HO Failures due to
Handover between
MSC Basic Services
HO Failures due to
Resource
Unavailability
Handover between
WCDMA RNCs
MSC Basic Services
HO Failures due to
Unsupported
Handover between
MSC Basic Services
HO Failures due to
Unavailability of
Handover between
Requested
WCDMA RNCs
Guaranteed Bit Rate
MSC Basic Services
Handover Failures
Responded by the
Source or Target
HO Failures due to
HO Completion
Timeout
Handover between
WCDMA RNCs
MSC Basic Services
HO Failures due to
Radio Interface
Failures
Handover between
WCDMA RNCs
MSC Basic Services

HOs from RNC
WCDMA RNCs
MSC Basic Services
Successful
Subsequent
Handovers to MSCa
(Local Office is
MSCa)
Out LAI HO success

times (LAI)
Traffic Measurement
Global Components
For LAI

Measurement Point
in Flowchart
Requests for
Measurement Type
Q1
Q2
Subsequent Handover
to MSCa (Local Office
is MSCa)
HOs to RNC
WCDMA RNCs
Q3
Q4
Q5
MSC Basic Services
Traffic Measurement
Global Components
For LAI
HO Failures due to
Handover between
MSC Basic Services
HO Failures due to
Resource
Unavailability
Handover between
WCDMA RNCs
MSC Basic Services
HO Failures due to
Unsupported
Handover between
MSC Basic Services
HO Failures due to
Unavailability of
Handover between
Requested
WCDMA RNCs
Guaranteed Bit Rate
MSC Basic Services
Handover Failures
Responded by the
Source or Target
HO Failures due to
HO Completion
Timeout
Handover between
WCDMA RNCs
MSC Basic Services
HO Failures due to
Radio Interface
Failures
Handover between
WCDMA RNCs
MSC Basic Services
IN LAI HO success
times (LAI)
HOs to RNC
Successful
Subsequent Handover
Times (Local Office is
MSCb)
Traffic Measurement
Global Components
For LAI
Handover between
MSC Basic Services
WCDMA RNCs

3G Subsequent Inter-MSC Handover to a Third Party (A->B>B')

Service Model
Signaling Flow
Service Model
The controlling MSC of the UE is 3G-MSC-A.
A subsequent handover to a third party is performed after an inter-MSC handover.
That is, a 3G subscriber is handed over from 3G-MSC-A to 3G-MSC-B and then
to 3G-MSC-B'.
Signaling Flow
Figure 1 shows the signaling flow of 3G subsequent inter-MSC handover to a third party.
Figure 1 Signaling flow of 3G subsequent inter-MSC handover to a third party
Caller:
P1, P2, P3, P4, P5, P6, P7
Callee:
Q1, Q2, Q3, Q4, Q5

The signaling flow of 3G subsequent inter-MSC handover to a third party is as follows:
1. RNC-B sends a RELOCATION REQUIRED message, requesting 3G-MSC-B to
LAI/GCI.
determines that the current handover is a subsequent handover to a third party
based on the table query result, it sends a MAP_PREPARE_HANDOVER_REQ
message to request 3G-MSC-B' to prepare for the handover. The message
carries all the IEs contained in the RELOCATION REQUIRED message.
4. 3G-MSC-B' requests VLR-B for a handover number. At the same time, 3G-MSCB' constructs a RELOCATION REQUEST message and sends it to request RNCB' to allocate required radio resources. 3G-MSC-B' requests radio resources
from RNC-B' and handover number from VLR-B concurrently. It sends the
the responses from RNC-B' and VLR-B'.
5. After allocating radio resources, RNC-B' sends a RELOCATION REQUEST
ACKNOWLEDGE message to 3G-MSC-B'.
6. After VLR-B' allocates the handover number, 3G-MSC-B' sends a
which can be used by 3G-MSC-A to establish a speech channel to 3G-MSC-B'.
message to 3G-MSC-B'.
8. If 3G-MSC-B' determines that the called number carried in the IAM message is a
requesting VLR-B' to release the handover number. The message can be sent at
any time after 3G-MSC-B' receives the IAM message. At the same time, 3G-
MSC-B' sends an address complete message (ACM) message to 3G-MSC-A.

message to notify 3G-MSC-B that the handover preparation is complete.
10. 3G-MSC-B sends a RELOCATION COMMAND message, instructing RNC-B to
hand over the UE.
11. On detecting the correct UE, RNC-B' sends a RELOCATION DETECT message
to 3G-MSC-B'. At this point, the UE has detected a new radio channel. The
12. 3G-MSC-B transparently transfers the RELOCATION DETECT message to 3GMSC-A through a MAP_PROCESS_ACCESS_SIGNALLING message. On
receiving the message, 3G-MSC-A requests the MGW to change the stream
uses other services through the channel. RNC-B' sends a RELOCATION
COMPLETE message to notify 3G-MSC-B' that the inter-MSC handover is
complete.
14. 3G-MSC-B' transparently transfers the RELOCATION COMPLETE message
15. 3G-MSC-B' sends an answer message (ANM) message to 3G-MSC-A. The
handover is complete. This message is optional. It is used to keep consistency
with inter-MSC trunk signaling.
the inter-MSC circuit.
18. 3G-MSC-B sends an IU RELEASE COMMAND message, instructing RNC-B to
19. After releasing the terrestrial and radio resources, RNC-b sends an IU RELEASE
COMPLETE message to 3G-MSC-B.
20. After the conversion ends, 3G-MSC-A sends an REL message to 3G-MSC-B' to
release the call and the inter-MSC circuit.
21. 3G-MSC-A sends a MAP_SEND_END_SIGNAL_RSP message, instructing 3GMSC-B' to release the inter-MSC MAP resources.

Measurement Point
in Flowchart
P1
P2

MSC Basic Services

Handover between
Radio Resource
WCDMA RNCs
Reasons
MSC Basic Services

O&M Intervention
WCDMA RNCs
MSC Basic Services

MSC Basic Services
Requests for
Subsequent Handover
(Local Office is
MSCb)
Out LAI HO times
(LAI)
P3
P4
Measurement Type
Traffic Measurement
Global Components
For LAI
Requests for
Subsequent Handover
to MSCc (Local Office
is MSCa)
HO Failures due to
Handover between
MSC Basic Services
HO Failures due to
Resource
Unavailability
Handover between
WCDMA RNCs
MSC Basic Services
HO Failures due to
Unsupported
Handover between
MSC Basic Services
HO Failures due to
Unavailability of
Requested
Guaranteed Bit Rat
P5
P6
Handover between
WCDMA RNCs
Handover Failures
Responded by the
Source or Target
HO Failures due to
HO Completion
Timeout
Handover between
WCDMA RNCs
MSC Basic Services
HO Failures due to
Radio Interface
Failures
Handover between
WCDMA RNCs
MSC Basic Services
Successful
Subsequent
Handovers to MSCc
(Local Office is
MSCa)

HOs from RNC
WCDMA RNCs
P7
MSC Basic Services
MSC Basic Services
Successful
Subsequent Handover
MSCb)
Out LAI HO success
times (LAI)
Traffic Measurement
Global Components
For LAI

Measurement Point
in Flowchart
Q1
Q2
Basic Incoming
Handover Requests

HOs to RNC
WCDMA RNCs
Measurement Type
MSC Basic Services
Traffic Measurement
Global Components
For LAI
HO Failures due to
Handover between
MSC Basic Services
HO Failures due to
Resource
Unavailability
Q3
Q4
Q5
Handover between
WCDMA RNCs
MSC Basic Services
HO Failures due to
Unsupported
Handover between
MSC Basic Services
HO Failures due to
Unavailability of
Handover between
Requested
WCDMA RNCs
Guaranteed Bit Rate
MSC Basic Services
Handover Failures
Responded by the
Source or Target
HO Failures due to
HO Completion
Timeout
Handover between
WCDMA RNCs
MSC Basic Services
HO Failures due to
Radio Interface
Failures
Handover between
WCDMA RNCs
MSC Basic Services
IN LAI HO success
times (LAI)
HOs to RNC
Successful Basic
Incoming Handover
Requests
Traffic Measurement
Global Components
For LAI
Handover between
MSC Basic Services
WCDMA RNCs

GSM Handover
GSM handover means to hand over a GSM subscriber from one BSC to another BSC in the
GSM network. It serves the following purposes:
Ensures the conversation quality when the subscriber is on the move.
Balances the traffic to improve the overall performance of the system.
GSM handovers are categorized into the following types:
Intra-MSC handover: a handover between two BSCs connected to the same MSC
in the GSM network
Basic inter-MSC handover: a handover where the MS is handed over from a
controlling MSC (MSC A) to another MSC (MSC B)
Subsequent inter-MSC handback: a handover where the MS is handed back from
MSC B to MSC A
Subsequent inter-MSC handover to a third party: a handover where the MS is
handed over from MSC B to a third MSC (MSC B')
2G Subsequent Inter-MSC Handover to a Third Party (A->B->B')
Service Model
Signaling Flow
Service Model
Signaling Flow
Figure 1 shows the signaling flow of 2G intra-MSC handover.
Figure 1 Signaling flow of 2G intra-MSC handover

The signaling flow of 2G intra-MSC handover is as follows:
1. BSC-A sends a HANDOVER REQUIRED message, requesting 2G-MSC-A to
such as Handover Type, Cause, SourceID, and TargetID.

2. On receiving the handover request, 2G-MSC-A queries the location of the target
cell based on the global cell identity (GCI) and determines that the current
handover is an intra-office handover. Then, 2G-MSC-A sends a HANDOVER
REQUEST message, requesting BSC-B to allocate required radio resources.
3. After allocating radio resources and a circuit, BSC-B sends a HANDOVER
REQUEST ACKNOWLEDGE message to 2G-MSC-A. The message carries the
information about the allocated radio resources and circuit.
4. If 3G-MSC-A receives the HANDOVER REQUEST ACKNOWLEDGE message
from BSC-B, it indicates that the radio resources are ready and the MS can be
handed over from BSC-A to BSC-B. At this point, 2G-MSC-A constructs a
HANDOVER COMMAND message by using the IEs contained in the HANDOVER
REQUEST ACKNOWLEDGE message, and then sends the message to BSC-A.
5. BSC-A sends an RI-HO-Command message, instructing the MS to hand over to
BSC-B.
6. At this point, the MS has detected a new channel. The requirement for access to
the new channel is met but actually the MS is not switched to the new channel.
BSC-B sends a HANDOVER DETECT message to 2G-MSC-A. This message is
optional in the handover process.
7. The MS accesses the new channel and sends an RI-HO-Complete message to
BSC-B.
uses other services through the channel. BSC-B sends a HANDOVER
COMPLETE message to notify 2G-MSC-A that the handover is complete.
9. 2G-MSC-A sends a CLEAR COMMAND message, instructing BSC-A to release
the radio resources.
10. After releasing the radio resources, BSC-A sends a CLEAR COMPLETE
message to 2G-MSC-A.
Table 1lists common measurement entities.
Measurement Point
in Flowchart
Intra-MSC Handover
from Cell Requested
GSM Cell Handover
Measurement Type
MSC Basic Services
Times
P1
P2
Handover from Cell

due to Better Cell
GSM Cell Handover
MSC Basic Services
Handover from Cell

due to Uplink Quality
GSM Cell Handover
MSC Basic Services
Handover from Cell

due to O&M
Interference
GSM Cell Handover
MSC Basic Services
Intra-MSC Handover
Requested Times
Out LAI HO times

(LAI)
Traffic Measurement
Global Components
For LAI
Intra-MSC Handover
to Cell Requested
Times
GSM Cell Handover

A to B HO Requests
P3
MSC Basic Services
Traffic Measurement
Global Components
For LAI
Handover between
MSC Basic Services
GSM Cells
Handover Failure due

to Radio Resource
GSM Cell Handover
Unavailability
MSC Basic Services

to Encryption
GSM Cell Handover
Algorithm Not
Supported
MSC Basic Services

to Speech Version
GSM Cell Handover
Unavailability
MSC Basic Services

to Terrestrial
GSM Cell Handover
Resource
Unavailability
MSC Basic Services
A to B HO Failed due
Handover between
to No Available Radio
GSM Cells
Resource
MSC Basic Services
A to B HO Failed due Handover between
to Terrestrial
GSM Cells
Resource Unavailable
MSC Basic Services
to Encryption
Handover between
Algorithm Not
GSM Cells
Supported
MSC Basic Services
Handover between
to Speech Version
GSM Cells
Unavailable
MSC Basic Services
Handover Failures
Responded by the
Source or Target
Out LAI HO success

times (LAI)
Traffic Measurement
Global Components
For LAI
IN LAI HO success
times (LAI)
Traffic Measurement
Global Components
For LAI
Handover Times
P4
Handover from Cell
GSM Cell Handover
Times
MSC Basic Services
Handover to Cell
GSM Cell Handover
Times
MSC Basic Services
A to B HO Succeeded
Handover between
GSM Cells
Parent topic: GSM Handover

MSC Basic Services

Service Model
Signaling Flow
Service Model
Signaling Flow
Figure 1 shows the signaling flow of 2G inter-MSC handover.
Figure 1 Signaling flow of 2G inter-MSC handover
Caller:
P1, P2, P3, P4
Callee:
Q1, Q2, Q3, Q4
The signaling flow of 2G inter-MSC handover is as follows:

2. On receiving the HANDOVER REQUIRED message, 2G-MSC-A queries the
message by using the IEs contained in the HANDOVER REQUIRED message,
and then sends the message to request 2G-MSC-B to prepare for the handover.
3. 2G-MSC-B requests VLR-B for a handover number. At the same time, 2G-MSCB constructs a HANDOVER REQUEST message and sends it to request BSC-B
to allocate required radio resources. 2G-MSC-B requests radio resources from
BSC-B and handover number from VLR-B concurrently. It sends the
the responses from BSC-B and VLR-B.
4. After allocating radio resources, BSC-B sends a HANDOVER REQUEST
8. After an inter-MSC circuit is set up, 2G-MSC-A constructs a HANDOVER
instruct BSC-A to hand over the MS to BSC-B.
9. On detecting the correct UE, BSC-B sends a HANDOVER DETECT message to
2G-MSC-B. At this point, the MS has detected a new radio channel. The
requirement for access to the new radio channel is met but actually the MS is not

10. 2G-MSC-B transparently transfers the HANDOVER DETECT message to 2GMSC-A through a MAP_PROCESS_ACCESS_SIGNALLING message. On
receiving the message, 2G-MSC-A requests MGW-A to change the stream
complete.
12. 2G-MSC-B transparently transfers the HANDOVER COMPLETE message
the terrestrial and radio resources.
14. After releasing the terrestrial and radio resources, BSC-A sends a CLEAR
NOTE:
2G-MSC-B requests radio resources from BSC-B and handover number from VLR-B
concurrently. Therefore, the sequence in which 2G-MSC-B receives the HANDOVER
REQUEST ACKNOWLEDGE and MAP_Send_Handover_Report_RSP messages is related
to VLR-B and BSC-B. 2G-MSC-B returns the MAP_Send_Handover_Report_RSP message
to 2G-MSC-A only after receiving the preceding two messages. The signaling flow shown in
Figure 1 is for illustration purpose only. The sequence in which the preceding two messages
are received may differ.
Measurement Point
in Flowchart
Measurement Type
Inter-MSC Handover
from Cell Requested
Times
GSM Cell Handover
MSC Basic Services
Handover from Cell

due to Better Cell
GSM Cell Handover
MSC Basic Services
Handover from Cell

GSM Cell Handover
MSC Basic Services
Handover from Cell

due to O&M
Interference
GSM Cell Handover
MSC Basic Services
Basic Outgoing
Handover Requests
Out LAI HO times

(LAI)
Traffic Measurement
Global Components
For LAI
P1
P2
P3
P4

to Radio Resource
GSM Cell Handover
Unavailability
MSC Basic Services

to Encryption
GSM Cell Handover
Algorithm Not
Supported
MSC Basic Services

to Speech Version
GSM Cell Handover
Unavailability
MSC Basic Services

to Terrestrial
GSM Cell Handover
Resource
Unavailability
MSC Basic Services
Handover Failures
Responded by the
Source or Target
Out LAI HO success

times (LAI)
Traffic Measurement
Global Components
For LAI
Successful Basic
Outgoing Handover
Requests
Handover from Cell
GSM Cell Handover
Times
MSC Basic Services

Measurement Point
in Flowchart
Q1
Q2
Q3
Q4
Measurement Type
Basic Incoming
Handover Requests
Inter-MSC Handover
to Cell Requested
Times
GSM Cell Handover
Traffic Measurement
Global Components
For LAI
MSC Basic Services

to Radio Resource
GSM Cell Handover
Unavailability
MSC Basic Services

to Encryption
GSM Cell Handover
Algorithm Not
Supported
MSC Basic Services

to Speech Version
GSM Cell Handover
Unavailability
MSC Basic Services

to Terrestrial
GSM Cell Handover
Resource
Unavailability
MSC Basic Services
Handover Failures
Responded by the
Source or Target
IN LAI HO success
times (LAI)
Traffic Measurement
Global Components
For LAI
Handover to Cell
GSM Cell Handover
Times
MSC Basic Services
Successful Basic
Incoming Handover
Requests


Service Model
Signaling Flow
Service Model
The controlling MSC of the MS is 2G-MSC-A.
A subsequent handback is performed after an inter-MSC handover. That is, a 2G
subscriber is handed over from 2G-MSC-A to 2G-MSC-B and then back to 2GMSC-A.
Signaling Flow
Figure 1 shows the signaling flow of 2G subsequent inter-MSC handback.
Figure 1 Signaling flow of 2G subsequent inter-MSC handback
Caller:
P1, P2, P3, P4
Callee:
Q1, Q2, Q3, Q4
The signaling flow of 2G subsequent inter-MSC handback is as follows:
1. BSC-B sends a HANDOVER REQUIRED message, requesting 2G-MSC-B to
LAI/GCI.
determines that the current handover is a subsequent handback based on the
table query result, it constructs a HANDOVER REQUEST message by using the
IEs contained in the MAP_PREPARE_SUBSEQUENT_HANDOVER_REQ
message, and then sends the message to request BSC-A to allocate required
radio resources.
4. After allocating radio resources successfully, BSC-A sends a HANDOVER
REQUEST ACKNOWLEDGE message to 2G-MSC-A. The message carries
information about the allocated radio resources.
message to notify 2G-MSC-B that the handover preparation is complete. The
message carries all the IEs contained in the HANDOVER REQUEST
ACKNOWLEDGE message.
6. 2G-MSC-B sends a HANDOVER COMMAND message, instructing BSC-B to
hand over the MS.
7. On detecting the correct MS, BSC-B sends a HANDOVER DETECT message to
2G-MSC-A. At this point, the MS has detected a new radio channel. The

uses other services through the channel. BSC-A sends a HANDOVER
COMPLETE message to notify 2G-MSC-A that the handover is complete. At this
point, the subsequent handover is complete.
9. 2G-MSC-A sends a MAP_SEND_END_SIGNAL_RSP message, instructing 2GMSC-B to release the radio resources. The message carries all the IEs contained
in the HANDOVER COMPLETE message.
10. 2G-BSC-B sends an CLEAR COMMAND message, instructing BSC-B to release
11. After releasing the radio resources, BSC-B sends a CLEAR COMPLETE
the inter-MSC trunk resources.
Measurement Point
in Flowchart
Measurement Type
Inter-MSC Handover
from Cell Requested
Times
GSM Cell Handover
MSC Basic Services
Handover from Cell

due to Better Cell
GSM Cell Handover
MSC Basic Services
Handover from Cell

GSM Cell Handover
MSC Basic Services
Handover from Cell

due to O&M
Interference
GSM Cell Handover
MSC Basic Services
P1
P2
Requests for
Subsequent Handover
(Local Office is
MSCb)
Out LAI HO times
(LAI)
Traffic Measurement
Global Components
For LAI
P3
P4

GSM Cell Handover
to Radio Resource
Unavailability
MSC Basic Services

to Encryption
GSM Cell Handover
Algorithm Not
Supported
MSC Basic Services

to Speech Version
GSM Cell Handover
Unavailability
MSC Basic Services

to Terrestrial
GSM Cell Handover
Resource
Unavailability
MSC Basic Services
Handover Failures
Responded by the
Source or Target
Out LAI HO success

times (LAI)
Traffic Measurement
Global Components
For LAI
Successful
Subsequent Handover
MSCb)
Handover from Cell
GSM Cell Handover
Times
MSC Basic Services

Measurement Point
in Flowchart
Q1
Q2
Measurement Type
Requests for
Subsequent Handover
to MSCa (Local Office
is MSCa)
Inter-MSC Handover
to Cell Requested
Times
GSM Cell Handover
MSC Basic Services
IN LAI HO times (LAI) Traffic Measurement Global Components
For LAI
Q3
Q4

to Radio Resource
GSM Cell Handover
Unavailability
MSC Basic Services

to Encryption
GSM Cell Handover
Algorithm Not
Supported
MSC Basic Services

to Speech Version
GSM Cell Handover
Unavailability
MSC Basic Services

to Terrestrial
GSM Cell Handover
Resource
Unavailability
MSC Basic Services
Handover Failures
Responded by the
Source or Target
IN LAI HO success
times (LAI)
Traffic Measurement
Global Components
For LAI
Handover to Cell
GSM Cell Handover
Times
Successful
Subsequent
Handovers to MSCa
(Local Office is
MSCa)
MSC Basic Services

2G Subsequent Inter-MSC Handover to a Third Party (A->B>B')

Service Model
Signaling Flow
Service Model
The controlling MSC of the MS is 2G-MSC-A.
A subsequent handover to a third party is performed after an inter-MSC handover.
That is, a 2G subscriber is handed over from 2G-MSC-A to 2G-MSC-B and then
to 2G-MSC-B'.
Signaling Flow
Figure 1 shows the signaling flow of 2G subsequent inter-MSC handover to a third party.
Figure 1 Signaling flow of 2G subsequent inter-MSC handover to a third party
Caller:
P1, P2, P3, P4, P5, P6
Callee:
Q1, Q2, Q3, Q4

The signaling flow of 2G subsequent inter-MSC handover to a third party is as follows:
1. BSC-B sends a HANDOVER REQUIRED message, requesting 2G-MSC-B to
LAI/GCI.
determines that the current handover is a subsequent handover to a third party
based on the table query result, it sends a MAP_PREPARE_HANDOVER_REQ
message to request 2G-MSC-B' to prepare for the handover. The message
carries all the IEs contained in the HANDOVER REQUIRED message.
4. 2G-MSC-B' requests VLR-B for a handover number. 2G-MSC-B' queries the
LAI/GCI table for the target cell. If it finds that the target cell is under the control
of its subordinate base station subsystem (BSS), it constructs a HANDOVER
REQUEST message and sends the message to request BSS-B to allocate
required radio resources. 2G-MSC-B' requests radio resources from BSC-B' and
handover number from VLR-B' concurrently. It sends the
the responses from BSC-B' and VLR-B'.
5. After allocating radio resources, BSC-B' sends a HANDOVER REQUEST
ACKNOWLEDGE message to 2G-MSC-B'.
6. After VLR-B' allocates the handover number, 2G-MSC-B' sends a
which can be used by 2G-MSC-A to establish a speech channel to 2G-MSC-B'.
message to 2G-MSC-B'.
8. If 2G-MSC-B' determines that the called number carried in the IAM message is a
requesting VLR-B' to release the handover number. The message can be sent at
any time after 2G-MSC-B' receives the IAM message. At the same time, 2GMSC-B' sends an address complete message (ACM) message to 2G-MSC-A.
message to notify 2G-MSC-B that the handover preparation is complete.
10. 2G-MSC-B sends a HANDOVER COMMAND message, instructing BSC-B to
hand over the MS.
11. On detecting the correct UE, BSC-B' sends a HANDOVER DETECT message to
2G-MSC-B'. At this point, the MS has detected a new radio channel. The
12. 2G-MSC-B' transparently transfers the HANDOVER DETECT message to 2GMSC-A through a MAP_PROCESS_ACCESS_SIGNALLING message. On
uses other services through the channel. BSC-B' sends a HANDOVER
COMPLETE message to notify 2G-MSC-B' that the inter-MSC handover is
complete.
14. 2G-MSC-B' transparently transfers the HANDOVER COMPLETE message
15. 2G-MSC-B' sends an answer message (ANM) message to 2G-MSC-A. The
handover is complete. This message is optional. It is used to keep consistency
with inter-MSC trunk signaling.
the inter-MSC circuit.
18. 2G-MSC-B sends a CLEAR COMMAND message, instructing BSC-B to release
19. After releasing the terrestrial and radio resources, BSC-B sends a CLEAR
COMPLETE message to 2G-MSC-B.
20. After the conversion ends, 2G-MSC-A sends an REL message to 2G-MSC-B' to
release the call and the inter-MSC circuit.
21. 2G-MSC-A sends a MAP_SEND_END_SIGNAL_RSP message, instructing 2GMSC-B' to release the inter-MSC MAP resources.
Measurement Point
in Flowchart
Measurement Type
Inter-MSC Handover
from Cell Requested
Times
GSM Cell Handover
MSC Basic Services
Handover from Cell

due to Better Cell
GSM Cell Handover
MSC Basic Services
Handover from Cell

GSM Cell Handover
MSC Basic Services
Handover from Cell

due to O&M
Interference
GSM Cell Handover
MSC Basic Services
P1
P2
Requests for
Subsequent Handover
(Local Office is
MSCb)
Out LAI HO times
(LAI)
P3
Traffic Measurement
Global Components
For LAI
Requests for
Subsequent Handover
to MSCc (Local Office
is MSCa)
to Radio Resource
GSM Cell Handover
Unavailability
MSC Basic Services

to Encryption
GSM Cell Handover
Algorithm Not
Supported
MSC Basic Services
P4

GSM Cell Handover
to Speech Version
Unavailability
to Terrestrial
GSM Cell Handover
Resource
Unavailability
P5
P6
MSC Basic Services
MSC Basic Services
Handover Failures
Responded by the
Source or Target
Successful
Subsequent
Handovers to MSCc
(Local Office is
MSCa)
Out LAI HO success

times (LAI)
Traffic Measurement
Global Components
For LAI
Successful
Subsequent Handover
MSCb)
Handover from Cell
GSM Cell Handover
Times
MSC Basic Services

Measurement Point
in Flowchart
Q1
Q2
Measurement Type
Basic Incoming
Handover Requests
Inter-MSC Handover
to Cell Requested
Times
GSM Cell Handover
Traffic Measurement
Global Components
For LAI

to Radio Resource
GSM Cell Handover
Unavailability
MSC Basic Services
MSC Basic Services
Q3
Q4

to Encryption
GSM Cell Handover
Algorithm Not
Supported
MSC Basic Services

to Speech Version
GSM Cell Handover
Unavailability
MSC Basic Services

to Terrestrial
GSM Cell Handover
Resource
Unavailability
MSC Basic Services
Handover Failures
Responded by the
Source or Target
IN LAI HO success
times (LAI)
Traffic Measurement
Global Components
For LAI
Handover to Cell
GSM Cell Handover
Times
Successful Basic
Incoming Handover
Requests
MSC Basic Services

GSM-UMTS Handover
GSM-UMTS handover ensures the conversation quality and prevents a call from
interruption.
GSM-UMTS handovers can be classified into the following types:
Intra-MSC handover from 3G to 2G
Intra-MSC handover from 2G to 3G
Inter-MSC handover from 3G to 2G
Inter-MSC handover from 2G to 3G
NOTE:
In addition to the basic handover from the controlling MSC (MSC-A) to the target MSC
(MSC-B), the intra-MSC and inter-MSC handovers between 3G to 2G consist of the
subsequent handback and subsequent handover to a third party (either 2G or 3G). The
principles are basically the same as those of GSM/Universal Mobile Telecommunications
System (UMTS) handovers. Therefore, detailed explanation is not provided in this
document.
Intra-MSC Handover from 3G to 2G
Inter-MSC Handover from 3G to 2G

Service Model
Signaling Flow
Service Model
The 3G subscriber is handed over to a 2G system.
Signaling Flow
Figure 1 shows the signaling flow of intra-MSC handover from 3G to 2G.
Figure 1 Signaling flow of intra-MSC handover from 3G to 2G

The signaling flow of intra-MSC handover from 3G to 2G is as follows:

such as Relocation Type, Cause, SourceID, and TargetID.
handover is an intra-office handover. Then, 3G-MSC-A sends a HANDOVER
REQUEST message, requesting BSC-B to allocate required radio resources. The
message carries all the information required by BSC-B to allocate the radio
resources. When constructing the message, 3G-MSC-A needs to complete the
interworking between the Universal Mobile Telecommunications System (UMTS)
handover request and the GSM handover request.
3. After allocating radio resources and a circuit, BSC-B sends a HANDOVER
4. If 3G-MSC-A receives the HANDOVER REQUEST ACKNOWLEDGE message
from BSC-B, it indicates that the radio resources are ready and the UE/MS can
be handed over from RNC-A to BSC-B. At this point, 3G-MSC-A constructs a
RELOCATION COMMAND message by using the IEs contained in the
HANDOVER REQUEST ACKNOWLEDGE message and sends the message to
RNC-A.
5. RNS-A sends an RR-HO-Command message, instructing the UE/MS to connect
to BSC-B.
6. At this point, the UE/MS has detected a new radio channel. The requirement for
access to the new radio channel is met but actually the UE/MS is not switched to
the channel. As the current handover is a speech handover, a speech channel
must be established in advance. Therefore, BSC-B sends a HANDOVER
DETECT message to 3G-MSC-A.
7. The UE/MS accesses the new channel and sends an RI-HO-Complete message
to BSC-B.
8. After the UE/MS connects to RNC-B successfully through the newly established
speech channel, BSC-B sends a HANDOVER COMPLETE message to 3G-MSCA.
release the radio resources and the bearer between the RNC and the MGW.
10. After releasing the radio resources, RNC-A sends an IU RELEASE COMPLETE
message, requesting 3G-MSC-A to release the endpoint of RNC-A from the
MGW. At this point, the handover is complete.

Measurement Point
in Flowchart
P1
P2
P3
Measurement Type
Requested Intra-MSC Handover between

HOs from RNC
WCDMA RNCs
MSC Basic Services

Handover between
Radio Resource
WCDMA RNCs
Reasons
MSC Basic Services

O&M Intervention
WCDMA RNCs
MSC Basic Services

MSC Basic Services
Intra-MSC Handover
Requested Times
Out LAI HO times

(LAI)
Traffic Measurement
Global Components
For LAI
Intra-MSC Handover
to Cell Requested
Times
GSM Cell Handover
Traffic Measurement
Global Components
For LAI
MSC Basic Services

to Radio Resource
GSM Cell Handover
Unavailability
MSC Basic Services

to Encryption
GSM Cell Handover
Algorithm Not
Supported
MSC Basic Services

to Speech Version
GSM Cell Handover
Unavailability
MSC Basic Services

to Terrestrial
GSM Cell Handover
Resource
Unavailability
MSC Basic Services
HO Failures due to No Handover between

Permission from the WCDMA RNCs
Target Side
HO Failures due to
Resource
Unavailability
Handover between
WCDMA RNCs
MSC Basic Services
HO Failures due to
and Integrity
WCDMA RNCs
MSC Basic Services
Handover Failures
Responded by the
Source or Target
P4
MSC Basic Services

HOs from RNC
WCDMA RNCs
MSC Basic Services
Handover to Cell
GSM Cell Handover
Times
MSC Basic Services
Out LAI HO success

times (LAI)
Traffic Measurement
Global Components
For LAI
IN LAI HO success
times (LAI)
Traffic Measurement
Global Components
For LAI
Handover Times
Parent topic: GSM-UMTS Handover

Service Model
Signaling Flow
Service Model
The 2G subscriber is handed over to a 3G system.
Signaling Flow
Figure 1 shows the signaling flow of intra-MSC handover from 2G to 3G.
Figure 1 Signaling flow of intra-MSC handover from 2G to 3G

The signaling flow of intra-MSC handover from 2G to 3G is as follows:

handover is an intra-office handover. Then, 2G-MSC-A sends a RELOCATION
REQUEST message, requesting RNC-B to allocate required radio resources.
3. After allocating radio resources and a circuit, RNC-B sends a RELOCATION
4. If 3G-MSC-A receives the RELOCATION REQUEST ACKNOWLEDGE message
from RNC-B, it indicates that the radio resources are ready and the UE/MS can
be handed over from BSC-A to RNC-B. At this point, 3G-MSC-A constructs a
HANDOVER COMMAND message by using the IEs contained in the
RELOCATION REQUEST ACKNOWLEDGE message and sends the message to
BSC-A.
5. BSC-A sends an RI-HO-Command message, instructing the UE/MS to hand over
to RNC-B.
6. At this point, the UE/MS has detected a new radio channel. The requirement for
access to the new radio channel is met but actually the UE/MS is not switched to
the channel. As the current handover is a speech handover, a speech channel
must be established in advance. Therefore, RNC-B sends a RELOCATION
DETECT message to 3G-MSC-A.
7. The UE/MS accesses the new channel and sends an RR-HO-Complete message
to RNC-B.
COMPLETE message to notify 3G-MSC-A that the handover is complete.
10. After releasing the radio resources, BSC-A sends a CLEAR COMPLETE
message to 3G-MSC-A.
Measurement Point
in Flowchart
Measurement Type
P1
P2
Intra-MSC Handover
from Cell Requested
Times
GSM Cell Handover
MSC Basic Services
Handover from Cell

due to Better Cell
GSM Cell Handover
MSC Basic Services
Handover from Cell

GSM Cell Handover
MSC Basic Services
Handover from Cell

due to O&M
Interference
GSM Cell Handover
MSC Basic Services
Intra-MSC Handover
Requested Times
Out location area

identity (LAI) HO
times (LAI)
Traffic Measurement
Global Components
For LAI
Requested Intra-MSC
HOs to RNC
P3
Traffic Measurement
Global Components
For LAI
HO Failures due to
Handover between
MSC Basic Services
HO Failures due to
Resource
Unavailability
Handover between
WCDMA RNCs
MSC Basic Services
HO Failures due to
and Integrity
WCDMA RNCs
MSC Basic Services
HO Failures due to
Unavailability of
Requested
Guaranteed Bit Rate
MSC Basic Services
Handover between
WCDMA RNCs

to Radio Resource
GSM Cell Handover
Unavailability
to Encryption
MSC Basic Services
Algorithm Not
Supported
P4
GSM Cell Handover
MSC Basic Services

to Code Conversion GSM Cell Handover
Unavailability
MSC Basic Services
Handover Failures
Responded by the
Source or Target
Out LAI HO success

times (LAI)
Traffic Measurement
Global Components
For LAI
IN LAI HO success
times (LAI)
Traffic Measurement
Global Components
For LAI
Handover Times
HOs to RNC
WCDMA RNCs
MSC Basic Services
Handover from Cell
GSM Cell Handover
Times
MSC Basic Services


Service Model
Signaling Flow
Service Model
Signaling Flow
Figure 1 shows the signaling flow of inter-MSC handover from 3G to 2G.
Figure 1 Signaling flow of inter-MSC handover from 3G to 2G
Caller:
P1, P2, P3, P4
Callee:
Q1, Q2, Q3, Q4
The signaling flow of inter-MSC handover from 3G to 2G is as follows:

such as Relocation Type, Cause, SourceID, and TargetID.
message by using the IEs contained in the RELOCATION REQUIRED message
3. 2G-MSC-B requests VLR-B for a handover number. At the same time, 2G-MSCB constructs a HANDOVER REQUEST message and sends it to request BSC-B
to allocate required radio resources.
4. After allocating radio resources, BSC-B sends a HANDOVER REQUEST
8. After an inter-MSC circuit is set up, 3G-MSC-A constructs a RELOCATION
instruct RNC-A to hand over the UE/MS to BSC-B.
9. On detecting the correct UE/MS, BSC-B sends a HANDOVER DETECT message
to 2G-MSC-B. At this point, the UE/MS has detected a new radio channel. The
requirement for access to the new radio channel is met but actually the UE/MS is
not switched to the channel. As the current handover is a speech handover, a
speech channel must be established in advance.

complete.
12. 2G-MSC-B transparently transfers the HANDOVER COMPLETE message
14. After releasing the terrestrial and radio resources, RNC-A sends an IU RELEASE
Measurement Point
in Flowchart
P1
Measurement Type

MSC Basic Services

Handover between
Radio Resource
WCDMA RNCs
Reason
MSC Basic Services

O&M Interventio
WCDMA RNCs
MSC Basic Services

MSC Basic Services
P2
P3
P4
Basic Outgoing
Handover Requests
Out LAI HO times

(LAI)
Traffic Measurement
Global Components
For LAI
HO Failures due to No
Handover between
Permission from the
WCDMA RNCs
Target Side
MSC Basic Services
HO Failures due to
Resource
Unavailability
Handover between
WCDMA RNCs
MSC Basic Services
HO Failures due to
Unsupported
Handover between
MSC Basic Services
Handover Failures
Responded by the
Source or Target
Out LAI HO success

times (LAI)
Traffic Measurement
Global Components
For LAI
Successful Basic
Outgoing Handover
Requests

HOs from RNC
WCDMA RNCs
MSC Basic Services

Measurement Point
in Flowchart
Q1
Q2
Measurement Type
Basic Incoming
Handover Requests
Inter-MSC Handover
to Cell Requested
Times
GSM Cell Handover
Traffic Measurement
Global Components
For LAI
MSC Basic Services
to Radio Resource
Unavailability
Q3
Q4
GSM Cell Handover
MSC Basic Services

to Encryption
GSM Cell Handover
Algorithm Not
Supported
MSC Basic Services

to Speech Version
GSM Cell Handover
Unavailability
MSC Basic Services

to Terrestrial
GSM Cell Handover
Resource
Unavailability
MSC Basic Services
Handover Failures
Responded by the
Source or Target
IN LAI HO success
times (LAI)
Traffic Measurement
Global Components
For LAI
Handover to Cell
GSM Cell Handover
Times
Successful Basic
Incoming Handover
Requests
MSC Basic Services


Service Model
Signaling Flow
Service Model
Signaling Flow
Figure 1 shows the signaling flow of inter-MSC handover from 2G to 3G.
Figure 1 Signaling flow of inter-MSC handover from 2G to 3G
Caller:
P1, P2, P3, P4
Callee:
Q1, Q2, Q3, Q4
The signaling flow of inter-MSC handover from 2G to 3G is as follows:

2. On receiving the HANDOVER REQUIRED message, 2G-MSC-A queries the
message by using the IEs contained in the HANDOVER REQUIRED message
3. 3G-MSC-B requests VLR-B for a handover number. At the same time, 3G-MSCB constructs a RELOCATION REQUEST message and sends it to request RNCB to allocate required radio resources.
4. After allocating radio resources, RNC-B sends a RELOCATION REQUEST
8. After an inter-MSC circuit is set up, 3G-MSC-A constructs a HANDOVER
instruct BSC-A to hand over the UE/MS to RNC-B.
9. On detecting the correct UE/MS, RNC-B sends a RELOCATION DETECT
message to 3G-MSC-B. At this point, the UE/MS has detected a new radio
channel. The requirement for access to the new radio channel is met but actually
the UE/MS is not switched to the channel. As the current handover is a speech
handover, a speech channel must be established in advance.

complete.
12. 3G-MSC-B transparently transfers the RELOCATION COMPLETE message
14. After releasing the terrestrial and radio resources, BSC-A sends a CLEAR
Measurement Point
in Flowchart
Measurement Type
Inter-MSC Handover
from Cell Requested
Times
GSM Cell Handover
MSC Basic Services
Handover from Cell

due to Better Cell
GSM Cell Handover
MSC Basic Services
Handover from Cell

GSM Cell Handover
MSC Basic Services
GSM Cell Handover
MSC Basic Services
P1
Handover from Cell

due to O&M
Interference
P2
P3
P4
Basic Outgoing
Handover Requests
Out LAI HO times

(LAI)
Traffic Measurement
Global Components
For LAI

to Radio Resource
GSM Cell Handover
Unavailability
MSC Basic Services

to Encryption
GSM Cell Handover
Algorithm Not
Supported
MSC Basic Services

to Code Conversion GSM Cell Handover
Unavailability
MSC Basic Services
Handover Failures
Responded by the
Source or Target
Out LAI HO success

times (LAI)
Traffic Measurement
Global Components
For LAI
Successful Basic
Outgoing Handover
Requests
Handover from Cell
GSM Cell Handover
Times
MSC Basic Services

Measurement Point
in Flowchart
Q1
Q2
Measurement Type
Basic Incoming
Handover Requests
Successful Basic
Outgoing Handover
Requests
Handover between
WCDMA RNCs
Traffic Measurement
Global Components
For LAI
MSC Basic Services
Q3
Q4
HO Failures due to
Handover between
MSC Basic Services
HO Failures due to
Resource
Unavailability
Handover between
WCDMA RNCs
MSC Basic Services
HO Failures due to
Unsupported
Handover between
MSC Basic Services
HO Failures due to
Unavailability of
Handover between
Requested
WCDMA RNCs
Guaranteed Bit Rate
MSC Basic Services
Handover Failures
Responded by the
Source or Target
IN LAI HO success
times (LAI)
HOs to RNC
Traffic Measurement
Global Components
For LAI
Handover between
MSC Basic Services
WCDMA RNCs
Successful Basic
Incoming Handover
Requests

Appendix - Protocol Compliance

Um/Uu Interface Protocol
A Interface Protocol
Iu-CS Interface Protocol
C/D Interface Protocol
E/Nc Interface Protocol (Handover Management of MAP)
G Interface Protocol
E Interface Protocol
Sv Interface Protocol
H.248 Protocol
Q.AAL2 Protocol
IU_UP/NB_UP Protocol
IPBCP Protocol
RTP/RTCP Protocol
CAP Protocol
ISUP Protocol
BICC Protocol
SIP Protocol
M2UA Protocol
M3UA Protocol
SCCP Protocol
PRA Protocol
SGs Interface Protocol
Um/Uu Interface Protocol

Description of the Um/Uu Interface Protocol
Description of the Common Part of Messages
Description of Registration Messages at the MM Sublayer
Description of Security Messages at the MM Sublayer
Description of Connection Management Messages at the MM Sublayer
Description of Call Establishment Messages at the CC Sublayer
Description of Call Clearing Messages at the CC Sublayer
Description of Supplementary Service Control Messages at the CC Sublayer
Description of Miscellaneous Messages at the CC Sublayer
Description of Associated IEs
Parent topic: Appendix - Protocol Compliance
Description of the Um/Uu Interface Protocol

Scenario Description
Message List
The base station subsystem (BSS)/universal terrestrial radio access network (UTRAN) is
located between the combination of MSC/VLR, MGW and the MS/UE. It communicates
with the BSS/UTRAN through Base Station Subsystem Application Part (BSSAP)/Radio
Access Network Application Part (RANAP) and with the MS/UE through the Um/Uu interface
protocol. Figure 1 shows the application of the Um/Uu interface protocol.
Figure 1 Application of the Um/Uu interface protocol
Message List
Table 1 List of common Um/Uu interface messages
Message
Direction Function
international
mobile subscriber
MSidentity (IMSI)
>MSC
DETACH
INDICATION
LOCATION
UPDATING
ACCEPT
LOCATION
UPDATING
MSC>MS
MSC>MS
This message is sent by the MS/UE to notify the network that

the MS/UE has been switched off. After reception of this
message, the network places the MS/UE in IMSI Detached
state so that it would not bother to page the MS/UE when
learning that some other parties are attempting to reach the
MS/UE. A readily apparent benefit of reducing unnecessary
paging is to save scarce radio resources.
This message is sent by the network to notify the MS/UE that
location update or IMSI attach in the network has been
completed.
location update or IMSI attach has failed.
REJECT
LOCATION
UPDATING
REQUEST
MS>MSC
AUTHENTICATION MSCREJECT
>MS
AUTHENTICATION MSCREQUEST
>MS
AUTHENTICATION MSRESPONSE
>MSC
AUTHENTICATION MSFAILURE
>MSC
IDENTITY
MSRESPONSE
>MSC
CM SERVICE
MSCACCEPT
>MS
CM SERVICE
REQUEST
MS>MSC
ALERTING
MS<>MSC
CALL
PROCEEDING
MSC>MS
CALL
CONFIRMED
MS>MSC
CONNECT
MS<>MSC
CONNECT
MS<ACKNOWLEDGE >MSC
This message is sent by the MS/UE to the network either to

request update of its location file (generic or periodic location
update) or to request IMSI attach.
authentication has failed. The receiving MS/UE should abort
all activities.
This message is sent by the network to the MS/UE to initiate
authentication of the MS/UE identity.
This message is sent by the MS/UE to deliver a calculated
authentication response to the network.
This message is sent by the MS/UE to notify the network that
authentication of the network has failed.
This message is sent by the MS/UE to provide the requested
identity to the network.
the requested service has been accepted.
This message is sent by the MS/UE to the network to request
a service for the Connection Management (CM) sublayer
entities, for example, circuit switched connection
establishment, supplementary services activation, short
message transfer, and location services.
This message is sent by the network to notify the calling
MS/UE that the called party is reached and alerted.
This message is sent by the network to notify the calling
MS/UE that the requested call establishment information has
been received and no more call establishment information will
be accepted.
This message is sent by the called MS/UE to confirm an
incoming call request.
This message is sent by the called MS/UE to indicate its
acceptance of the incoming call to the network. It is also sent
by the network to notify the calling MS/UE of call acceptance
by the called MS/UE.
This message is sent by the calling MS/UE to the network to
acknowledge call acceptance by the called MS/UE. It is also
sent by the network to notify the called MS/UE that the calling
MS/UE has been awarded the call.
In the mobile originating call (MOC) scenario, this message is
sent by the calling MS/UE to the network to provide more
information (called party binary-coded data (BCD) number
SETUP
MS>MSC
DISCONNECT
MS<>MSC
RELEASE
MS<>MSC
RELEASE
COMPLETE
MS<>MSC
FACILITY
MS<>MSC
MS>MSC
HOLD
MSCACKNOWLEDGE >MS
START dual tone
MSmultiple frequency
>MSC
(DTMF)
HOLD
START DTMF
MSCACKNOWLEDGE >MS
MS>MSC
STOP DTMF
MSCACKNOWLEDGE >MS
STOP DTMF
and calling party subaddress, for example) required to

continue the MOC. In the mobile terminated call (MTC)
scenario, this message is sent by the network to the called
MS/UE to provide more information required to continue the
MTC.
This message is sent, from the network to the MS/UE or
conversely, to indicate that the end-to-end connection has
been cleared.
conversely, to indicate that the sender intends to release the
transaction identifier and that the receiver should release the
transaction identifier after sending a RELEASE COMPLETE
message.
conversely, to indicate that the sender has released the
transaction identifier and the receiver should also release the
transaction identifier.
conversely, to request or acknowledge a supplementary
service.
This message is sent by the MS/UE to request the network to
place the existing call on hold.
This message is sent by the network to indicate that the
existing call has been placed on hold.
This message is sent by the MS/UE to the network. It
conveys the digit the network should reconvert back into a
DTMF tone which is then applied towards the remote user.
This message is sent by the network to the MS/UE to indicate
the successful initiation of the action requested by the START
DTMF message (conversion of the digit contained in this
message into a DTMF tone).
This message is sent by the MS/UE to request the network to
stop sending the DTMF tone towards the remote user.
the sending of the DTMF tone has been stopped.
Parent topic: Um/Uu Interface Protocol


Reference Standards
Table 1 describes the information element (IE) carried in the common part of messages.
Table 1 IE carried in the common part of messages
Information
Element
Description
(IE)
layer-3information
Conveys the information that the MS/UE intends to send to the network.
The reference point Um or Uu, between the MS/UE and the base station
subsystem (BSS)/universal terrestrial radio access network (UTRAN), adopts
a 3-layer protocol structure. Layer 3 is in essence the control layer, forcing
user control or system control information into dedicated logical channels
based on protocol type. It consists of three sublayers: Radio Resource
Management (RR), Mobility Management (MM), and Connection Management
(CM).
The CM sublayer provides multiple Call Control (CC) entities to allow parallel
call processing. It also provides Supplementary Service (SS) entity and Short
Message Service (SMS) entity to handle supplementary service and short
message service.
RR messages are terminated at the BSS/UTRAN where they are interpreted
into Base Station Subsystem Management Application Part (BSSMAP)/Radio
Access Network Application Part (RANAP) messages and flow on the A/Iu
interface. MM and CM messages, however, are terminated at the MSC. The
BSS/UTRAN passes these messages transparently on the A/Iu interface to the
MSC as DTAP messages.
An international mobile subscriber identity (IMSI) DETACH INDICATION

message is considered as an example here. In this example:
mm-layer-message indicates that the message belongs to the MM
sublayer.
skip-indicator indicates whether the message should be ignored. A
message received with skip indicator different from 0000 should be
ignored. A message received with skip indicator encoded as 0000

should not be ignored, unless it is ignored for other reasons.
mm-msg-type indicates the type of the message, for example, IMSI
DETACH INDICATION.
Reference Standards
For details, see 10.1 "Overview" in 3rd Generation Partnership Project (3GPP) TS24008830.
Description of Registration Messages at the MM Sublayer

IMSI DETACH INDICATION
LOCATION UPDATING ACCEPT
LOCATION UPDATING REJECT
LOCATION UPDATING REQUEST
IMSI DETACH INDICATION

Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the MS/UE to notify the network that the MS/UE has been
switched off. After reception of this message, the network places the MS/UE in international
mobile subscriber identity (IMSI) Detached state so that it would not bother to page the
MS/UE when learning that some other parties are attempting to reach the MS/UE. A readily
apparent benefit of reducing unnecessary paging is to save scarce radio resources.
Figure 1 shows the main IEs of the message.
Figure 1 IMSI DETACH INDICATION message
Associated IEs
Information Element (IE)
Description
Identifies the L3 protocol to which the L3
message belongs. In an IMSI DETACH

INDICATION message, Protocol Discriminator
takes the value 5, indicating that the message
belongs to the mobility management (MM)
protocol.
For details, see Protocol Discriminator.
Protocol Discriminator
Skip indicator
Indicates whether the message should be

ignored. A message received with skip
indicator different from 0000 should be
indicator encoded as 0000 should not be
ignored, unless it is ignored for other reasons.
For details, see Skip indicator.
Message Type
Indicates the type of the message. For an

IMSI DETACH INDICATION message, the
message type is IMSI DETACH INDICATION.
For details, see Message Type.
Mobile Station Classmark 1
Indicates general characteristics of the

MS/UE in multiband environment. It is
included in the Mobile Station Classmark IE.
For details, see Mobile Station Classmark 1.
Mobile Identity
Provides identity information of the MS/UE.

For details, see Mobile Identity.
Reference Standards
For details, see 9.2.12 "IMSI detach indication" in 3rd Generation Partnership Project
(3GPP) TS24008-830.
Parent topic: Description of Registration Messages at the MM Sublayer

Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the network to notify the MS/UE that location update or
international mobile subscriber identity (IMSI) attach in the network has been completed.
Figure 1 LOCATION UPDATING ACCEPT message
Associated IEs
Description

message belongs. In a LOCATION
UPDATING ACCEPT message, Protocol
Discriminator takes the value 5, indicating that
the message belongs to the mobility
management (MM) protocol.
Skip indicator

Message Type
Indicates the type of the message. For a

LOCATION UPDATING ACCEPT message,
the message type is LOCATION UPDATING
ACCEPT.
Location Area Identification
Provides unambiguous identification of

location areas where the MS/UE is staying.
The location area information is stored in
subscriber identity module (SIM)/user service
identity module (USIM).
For details, see Location Area Identification.
Mobile Identity

Reference Standards
For details, see 9.2.13 "Location updating accept" in 3rd Generation Partnership Project
(3GPP) TS24008-830.

Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the network to notify the MS/UE that location update or
international mobile subscriber identity (IMSI) attach has failed. Figure 1 shows the main
IEs of the message.
Figure 1 LOCATION UPDATING REJECT message
Associated IEs
Description
UPDATING REJECT message, Protocol
Skip indicator

Message Type

LOCATION UPDATING REJECT message,
REJECT.
Reject cause
Indicates the reason why LOCATION

UPDATING REQUEST from the MS/UE is
rejected by the network.
For details, see Reject cause.
Reference Standards
For details, see 9.2.14 "Location updating reject" in 3rd Generation Partnership Project
(3GPP) TS24008-830.

Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by a mobile terminal to the network side to request a location update
(normal or periodic location update) or an IMSI attach. Figure 1 shows the LOCATION
UPDATING REQUEST message.
Figure 1 LOCATION UPDATING REQUEST message
On a Multi-Operator Core Network (MOCN), when a mobile terminal that does not support
the MOCN feature initiates a location update (normal or periodic location update) or an
IMSI attach, it sends this message carrying the Redirect Attempt Flag information element
(IE) to the network side. Figure 2 shows the LOCATION UPDATING REQUEST message
carrying the Redirect Attempt Flag IE.
Figure 2 LOCATION UPDATING REQUEST message carrying the Redirect Attempt Flag
IE
Associated IEs
IE
Description

UPDATING REQUEST message, Protocol
Skip indicator

Message Type

LOCATION UPDATING REQUEST message,
REQUEST.
Location updating type
Indicates the type of location update.

For details, see Location updating type.
Ciphering Key Sequence Number
Indicates the sequence number of the

ciphering key.
For details, see Ciphering Key Sequence
Number.
Provides unambiguous identification of

location areas where the MS/UE is staying.
For details, see Location Area Identification.
Includes classmark1 corresponding to the

frequency band in use.
Mobile Identity


Redirect Attempt Flag
Indicates a redirection attempt for a mobile

terminal on a MOCN network.
For details, see Redirect Attempt Flag.
Reference Standards
For details, see section 9.2.15 "Location updating request" in 3GPP TS24008-830.
Description of Security Messages at the MM Sublayer

AUTHENTICATION REJECT
AUTHENTICATION REQUEST
AUTHENTICATION RESPONSE
AUTHENTICATION FAILURE
IDENTITY REQUEST
IDENTITY RESPONSE
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the network to notify the MS/UE that authentication has failed. The
receiving MS/UE should abort all activities. Figure 1 shows the main IEs of the message.
Figure 1 AUTHENTICATION REJECT message
Associated IEs
Description

message belongs. In an AUTHENTICATION
REJECT message, Protocol Discriminator
protocol.
Skip indicator
Message Type

AUTHENTICATION REJECT message, the
message type is AUTHENTICATION REJECT.
Reference Standards
For details, see 9.2.1 "Authentication reject" in 3rd Generation Partnership Project (3GPP)
TS24008-830.
Parent topic: Description of Security Messages at the MM Sublayer
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the network to the MS/UE to initiate authentication of the MS/UE
identity. Figure 1 shows the main IEs of the message.
Figure 1 AUTHENTICATION REQUEST message
Associated IEs
Description
REQUEST message, Protocol Discriminator
protocol.
Skip indicator

Message Type

AUTHENTICATION REQUEST message, the
message type is AUTHENTICATION
REQUEST.

ciphering key.
Number.
Spare Half Octet
Reserved for future use. It is half-octet long.

For details, see Spare Half Octet.
Authentication parameter random number

(RAND)
Provides the non-predictable number to be

used to calculate the authentication response
parameters.
For details, see Authentication parameter
RAND.
Provides the UE with a means of

Authentication Parameter AUTN (Universal authenticating the network.
Mobile Telecommunications System (UMTS)
For details, see Authentication Parameter
authentication challenge only)
AUTN (UMTS authentication challenge only).
Reference Standards
For details, see 9.2.2 "Authentication request" in 3rd Generation Partnership Project
(3GPP) TS24008-830.
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the MS/UE to deliver a calculated authentication response to the
network. Figure 1 shows the main IEs of the message.
Figure 1 AUTHENTICATION RESPONSE message
Associated IEs
Description
RESPONSE message, Protocol Discriminator
protocol.
Skip indicator

Message Type

AUTHENTICATION RESPONSE message,
the message type is AUTHENTICATION
RESPONSE.
Authentication Response parameter
Provides the network with the authentication

response calculated in the subscriber identity
module (SIM)/user service identity module
(USIM).
For details, see Authentication Response
parameter.
Reference Standards
For details, see 9.2.3 "Authentication response" in 3rd Generation Partnership Project
(3GPP) TS24008-830.
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the MS/UE to notify the network that authentication of the network
has failed. Figure 1 shows the main IEs of the message.
Figure 1 AUTHENTICATION FAILURE message
Associated IEs
Description

FAILURE message, Protocol Discriminator
protocol.
Skip indicator

Message Type

AUTHENTICATION FAILURE message, the
message type is AUTHENTICATION
FAILURE.
Reject Cause
Indicates the reason why the MS/UE rejects

to authenticate the network.
For details, see Reject cause.
Authentication Failure parameter
Provides the network with the necessary

information to begin a re-authentication
procedure when Universal Mobile
Telecommunications System (UMTS)
authentication challenge fails.
Reference Standards
For details, see 9.2.3a "AUTHENTICATION FAILURE" in 3rd Generation Partnership
Project (3GPP) TS24008-830.
IDENTITY REQUEST
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the network to the MS/UE to request the specified identity. Figure
1 shows the main IEs of the message.
Figure 1 IDENTITY REQUEST message
Associated IEs
Information Element
(IE)
Description
Identifies the L3 protocol to which the L3 message belongs. In an

IDENTITY REQUEST message, Protocol Discriminator takes the
value 5, indicating that the message belongs to the mobility
Indicates whether the message should be ignored. A message
Skip indicator
received with skip indicator different from 0000 should be ignored.

A message received with skip indicator encoded as 0000 should
not be ignored, unless it is ignored for other reasons.
Message Type
Indicates the type of the message. For an IDENTITY REQUEST

message, the message type is IDENTITY REQUEST.
Identity type
Specifies which identity is requested from the MS/UE.

For details, see Identity type.
Spare Half Octet

Reference Standards
For details, see 9.2.10 "Identity request" in 3rd Generation Partnership Project (3GPP)
TS24008-830.
IDENTITY RESPONSE
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the MS/UE to provide the requested identity to the network. Figure
Figure 1 IDENTITY RESPONSE message
Associated IEs
Description
message belongs. In an IDENTITY

RESPONSE message, Protocol Discriminator
protocol.
Skip indicator

Message Type

IDENTITY RESPONSE message, the
message type is IDENTITY RESPONSE.
Mobile Identity

Reference Standards
For details, see 9.2.11 "Identity response" in 3rd Generation Partnership Project (3GPP)
TS24008-830.
Description of Connection Management Messages at the

MM Sublayer
CM SERVICE ACCEPT
CM SERVICE REQUEST
CM SERVICE ACCEPT
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the network to notify the MS/UE that the requested service has
been accepted. Figure 1 shows the main IEs of the message.
Figure 1 CM SERVICE ACCEPT message
Associated IEs
Description

message belongs. In a connection
management (CM) SERVICE ACCEPT
message, Protocol Discriminator takes the
value 5, indicating that the message belongs
to the mobility management (MM) protocol.
Skip indicator
Message Type

Indicates the type of the message. For a CM
SERVICE ACCEPT message, the message
type is CM SERVICE ACCEPT.
Reference Standards
For details, see 9.2.5 "CM service accept" in 3rd Generation Partnership Project (3GPP)
TS24008-830.
Parent topic: Description of Connection Management Messages at the MM Sublayer
CM SERVICE REQUEST
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by a mobile terminal to the network side to request a connection
management (CM) service, such as circuit switched connection establishment,
supplementary service, short message service, and location service. Figure 1 shows the
CM SERVICE REQUEST message.
Figure 1 CM SERVICE REQUEST message
Associated IEs
IE
Description

message belongs. In a CM SERVICE
REQUEST message, Protocol Discriminator
protocol.
Skip indicator

Message Type
Indicates the type of the message. For a CM

SERVICE REQUEST message, the message
type is CM SERVICE REQUEST.
CM service type
Specifies which service is requested from the

network.
For details, see CM service type.

ciphering key.
Number.

Mobile Identity

Priority Level
Provides information defining the priority level

requested or applied.
For details, see Priority Level.
Reference Standards
For details, see 9.2.9 "CM service request" in 3GPP TS24008-830.

Parent topic: Description of Connection Management Messages at the MM Sublayer
Description of Call Establishment Messages at the CC

Sublayer
ALERTING
CALL PROCEEDING
CALL CONFIRMED
CONNECT
CONNECT ACKNOWLEDGE
SETUP
MODIFY
MODIFY COMPLETE
MODIFY REJECT
ALERTING
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the network to notify the calling MS/UE that the called party is
reached and alerted. Figure 1 shows the main IEs of the message.
Figure 1 ALERTING message
Associated IEs
Description

message belongs. In an ALERTING
to the call controller (CC) protocol.
Transaction identifier
Distinguishes a few message flows for a

given protocol discriminator and a given
session announcement protocol (SAP). Such
a message flow is called a transaction.
For details, see Transaction identifier.
Message Type

ALERTING message, the message type is
ALERTING.
Facility
Conveys supplementary service related

information.
For details, see Facility.
Progress indicator
Describes a mid-call event.

For details, see Progress indicator.
Reference Standards
For details, see 9.3.1 "Alerting" in 3rd Generation Partnership Project (3GPP) TS24008830.
Parent topic: Description of Call Establishment Messages at the CC Sublayer
CALL PROCEEDING
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the network to notify the calling MS/UE that the requested call
establishment information has been received and no more call establishment information will
be accepted. Figure 1 shows the main IEs of the message.
Figure 1 CALL PROCEEDING message
Associated IEs
Description

message belongs. In a CALL PROCEEDING

Message Type

CALL PROCEEDING message, the message
type is CALL PROCEEDING.
Bearer capability
Describes the supported bearer capability.

For details, see Bearer capability.
Reference Standards
For details, see 9.3.3 "Call proceeding" in 3rd Generation Partnership Project (3GPP)
TS24008-830.
CALL CONFIRMED
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the called MS/UE to confirm an incoming call request. Figure 1
shows the main IEs of the message.
Figure 1 CALL CONFIRMED message
Associated IEs
Description

message belongs. In a CALL CONFIRMED
Distinguishes a message flow for a given

protocol discriminator and a given session
announcement protocol (SAP). Such a
message flow is called a transaction.
Message Type

CALL CONFIRMED message, the message
type is CALL CONFIRMED.
Reference Standards
For details, see 9.3.2 "Call confirmed" in 3rd Generation Partnership Project (3GPP)
TS24008-830.
CONNECT
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the called MS/UE to indicate its acceptance of the incoming call to
the network. It is also sent by the network to notify the calling MS/UE of call acceptance by
the called MS/UE. Figure 1 shows the main IEs of the message.
Figure 1 CONNECT message
Associated IEs
Description

message belongs. In a CONNECT message,
Protocol Discriminator takes the value 3,
indicating that the message belongs to the
call controller (CC) protocol.

Message Type

CONNECT message, the message type is
CONNECT.
Facility

information.
Progress indicator

Connected number
Identifies the connected party of a call, for

example, 13107554238.
For details, see Connected number.
Reference Standards
For details, see 9.3.5 "Connect" in 3rd Generation Partnership Project (3GPP) TS24008830.
CONNECT ACKNOWLEDGE
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the calling MS/UE to the network to acknowledge call acceptance
by the called MS/UE. It is also sent by the network to notify the called MS/UE that the
calling MS/UE has been awarded the call. Figure 1 shows the main IEs of the message.
Figure 1 CONNECT ACKNOWLEDGE message
Associated IEs
Description

message belongs. In a CONNECT
ACKNOWLEDGE message, Protocol
the message belongs to the call controller
(CC) protocol.

Message Type

CONNECT ACKNOWLEDGE message, the
message type is CONNECT
ACKNOWLEDGE.
Reference Standards
For details, see 9.3.6 "Connect acknowledge" in 3rd Generation Partnership Project
(3GPP) TS24008-830.
SETUP
Message Function
Associated IEs
Reference Standards
Message Function
In the mobile originated call (MOC) scenario, this message is sent by the calling MS/UE to
the network to provide more information (called party binary-coded data (BCD) number and
calling party subaddress, for example) required to continue the MOC. In the mobile
terminated call (MTC) scenario, this message is sent by the network to the called MS/UE to
provide more information required to continue the MTC. Figure 1 shows the main IEs of the
message.
Figure 1 SETUP message
Associated IEs
Description

message belongs. In a SETUP message,

Message Type

SETUP message, the message type is
SETUP.
Repeat indicator
Indicates how the associated repeated

information elements should be interpreted
when included in a message.
For details, see Repeat indicator.
Bearer capability

Called party BCD number
Identifies the called party.

For details, see Called party BCD number.
Low layer compatibility
Provides a means for the addressed entity to

perform compatibility check.
For details, see Low layer compatibility.
Reference Standards
For details, see 9.3.23 "Setup" in 3rd Generation Partnership Project (3GPP) TS24008830.
MODIFY
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent, from the MS/UE to the network or conversely, to request a change in
bearer capability for a call. Figure 1 shows the main IEs of the message.
Figure 1 MODIFY message
Figure 2 shows Data Bearer Capability Octet in the message.

Figure 2 Data Bearer Capability Octet
Associated IEs
Description

message belongs. In a MODIFY message,

Message Type

MODIFY message, the message type is
MODIFY.

Bearer capability

Reference Standards
For details, see 9.3.13 "Modify" in 3rd Generation Partnership Project (3GPP) TS24008830.
MODIFY COMPLETE
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent, from the MS/UE to the network or conversely, to indicate that a
request to change bearer capability for a call has been fulfilled. Figure 1 shows the main
IEs of the message.
Figure 1 MODIFY COMPLETE message
Figure 2 shows Data Bearer Capability Octet in the message.

Figure 2 Data Bearer Capability Octet
Associated IEs
Description

message belongs. In a MODIFY COMPLETE

Message Type

MODIFY COMPLETE message, the
message type is MODIFY COMPLETE.

Bearer capability

Reference Standards
For details, see 9.3.14 "Modify complete" in 3rd Generation Partnership Project (3GPP)
TS24008-830.
MODIFY REJECT
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent, from the MS/UE to the network or conversely, to indicate that a
request to change bearer capability for a call failed to be fulfilled. Figure 1 shows the main
IEs of the message.
Figure 1 MODIFY REJECT message
Associated IEs
Description
message belongs. In a MODIFY REJECT


Message Type

MODIFY REJECT message, the message
type is MODIFY REJECT.
Bearer capability

Cause
Indicates the reason why a request to change

bearer capability for a call cannot be fulfilled.
For details, see Cause.
Reference Standards
For details, see 9.3.15 "Modify reject" in 3rd Generation Partnership Project (3GPP)
TS24008-830.
Description of Call Clearing Messages at the CC Sublayer

DISCONNECT
RELEASE
RELEASE COMPLETE
DISCONNECT
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent, from the network to the MS/UE or conversely, to indicate that the
end-to-end connection has been cleared. Figure 1 shows the main IEs of the message.
Figure 1 DISCONNECT message
Associated IEs
Description

message belongs. In a DISCONNECT

Message Type

DISCONNECT message, the message type
is DISCONNECT.
Cause
Indicates the reason why the end-to-end

connection is cleared.
Progress indicator

Reference Standards
For details, see 9.3.7 "Disconnect" in 3rd Generation Partnership Project (3GPP) TS24008830.
Parent topic: Description of Call Clearing Messages at the CC Sublayer
RELEASE
Message Function
Associated IEs
Reference Standards
Message Function
sender intends to release the transaction identifier and that the receiver should release the
transaction identifier after sending a RELEASE COMPLETE message. Figure 1 shows the
main IEs of the message.
Figure 1 RELEASE message
Associated IEs
Description

message belongs. In a RELEASE message,

Message Type

RELEASE message, the message type is
RELEASE.
Cause
Indicates the reason why the transaction

identifier is released.
Reference Standards
For details, see 9.3.18 "Release" in 3rd Generation Partnership Project (3GPP) TS24008830.
RELEASE COMPLETE
Message Function
Associated IEs
Reference Standards
Message Function
sender has released the transaction identifier and the receiver should also release the
transaction identifier. Figure 1 shows the main IEs of the message.
Figure 1 RELEASE COMPLETE message
Associated IEs
Description

message belongs. In a RELEASE
COMPLETE message, Protocol Discriminator
belongs to the call controller (CC) protocol.

Message Type

RELEASE COMPLETE message, the
message type is RELEASE COMPLETE.
Cause
Indicates the reason why the transaction

identifier is released.
Reference Standards
For details, see 9.3.19 "Release complete" in 3rd Generation Partnership Project (3GPP)
TS24008-830.
Description of Supplementary Service Control Messages at

the CC Sublayer
HOLD
FACILITY
HOLD ACKNOWLEDGE
RETRIEVE
RETRIEVE ACKNOWLEDGE
REGISTER
HOLD
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the MS/UE to request the network to place the existing call on
hold. Figure 1 shows the main IEs of the message.
Figure 1 HOLD message
Associated IEs
Description

message belongs. In a HOLD message,
Message Type

HOLD message, the message type is HOLD.
Reference Standards
For details, see 9.3.10 "Hold" in 3rd Generation Partnership Project (3GPP) TS24008-830.
Parent topic: Description of Supplementary Service Control Messages at the CC Sublayer
FACILITY
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent, from the network to the MS/UE or conversely, to request or
acknowledge a supplementary service. Figure 1 shows the main IEs of the message.
Figure 1 FACILITY message
Associated IEs
Description

message belongs. In a FACILITY message,
Protocol Discriminator takes the value B,
supplementary service (SS) protocol.

Message Type

FACILITY message, the message type is
FACILITY.
Facility

information.
Reference Standards
For details, see 9.3.9 "Facility" in 3rd Generation Partnership Project (3GPP) TS24008830.
HOLD ACKNOWLEDGE
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the network to indicate that the existing call has been placed on
hold. Figure 1 shows the main IEs of the message.
Figure 1 HOLD ACKNOWLEDGE message
Associated IEs
Description

message belongs. In a HOLD
ACKNOWLEDGE message, Protocol
the message belongs to the call controller
(CC) protocol.
Message Type

HOLD ACKNOWLEDGE message, the
message type is HOLD ACKNOWLEDGE.
Reference Standards
For details, see 9.3.10 "Hold Acknowledge" in 3rd Generation Partnership Project (3GPP)
TS24008-830.
RETRIEVE
Message Function
Associated IEs
Message Function
This message is sent by the MS/UE to request the retrieval of a held call. Figure 1 shows
the main IEs of the message.
Figure 1 RETRIEVE message
Associated IEs
Description
Message Type
Indicates the type of the message. For a RETRIEVE

message, the message type is RETRIEVE.

Message Function
Associated IEs
Message Function
This message is sent by the network to notify the MS/UE that call retrieval has been
successfully performed. Figure 1 shows the main IEs of the message.
Figure 1 RETRIEVE ACKNOWLEDGE message
Associated IEs
Description
Message Type
Indicates the type of the message. For a RETRIEVE

ACKNOWLEDGE message, the message type is
RETRIEVE ACKNOWLEDGE.

REGISTER
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent, from the network to the MS/UE or conversely, to assign a new
transaction identifier for call independent supplementary service control and to request or
acknowledge a supplementary service. Figure 1 shows the main IEs of the message.
Figure 1 REGISTER message
Associated IEs
Description

message belongs. In a REGISTER message,
call independent supplementary service (SS)
protocol.

Message Type

REGISTER message, the message type is
REGISTER.
Facility

information.
SS version indicator
Indicates the SS protocol version in use. It

must be present if the supplementary service
operation being invoked is implemented
according to the phase 2 or higher protocol
version.
Reference Standards
For details, see 2.4 "Register" in 3rd Generation Partnership Project (3GPP) TS24080-740.
Description of Miscellaneous Messages at the CC Sublayer

NOTIFY
START DTMF
START DTMF ACKNOWLEDGE
STOP DTMF
STOP DTMF ACKNOWLEDGE
NOTIFY
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent either from the MS/UE or from the network to convey call-related
information, such as user suspended. Figure 1 shows the main IEs of the message.
Figure 1 NOTIFY message

Associated IEs
Description

message belongs. In a NOTIFY message,

NOTIFY message, the message type is
Message Type
Notification indicator
NOTIFY.
Provides information pertaining to a call, such
as user suspended, user resumed, and
bearer change.
Reference Standards
For details, see 9.3.16 "Notify" in 3rd Generation Partnership Project (3GPP) TS24008840.
Parent topic: Description of Miscellaneous Messages at the CC Sublayer
START DTMF
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the MS/UE to the network. It conveys the digit the network should
reconvert back into a dual tone multiple frequency (DTMF) tone which is then applied
towards the remote user. Figure 1 shows the main IEs of the message.
Figure 1 START DTMF message
Associated IEs
Information Element
Description
(IE)
Identifies the L3 protocol to which the L3 message belongs. In a
START DTMF message, Protocol Discriminator takes the value 3,
Protocol Discriminator indicating that the message belongs to the call controller (CC)
protocol.
Distinguishes a message flow for a given protocol discriminator and

a given session announcement protocol (SAP). Such a message
flow is called a transaction.
Message Type
Indicates the type of the message. For a START DTMF message,

the message type is START DTMF.
Reference Standards
For details, see 9.3.24 "Start DTMF" in 3rd Generation Partnership Project (3GPP)
TS24008-830.

Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the network to the MS/UE to indicate the successful initiation of the
action requested by the START dual tone multiple frequency (DTMF) message (conversion
of the digit contained in this message into a DTMF tone). Figure 1 shows the main IEs of
the message.
Figure 1 START DTMF ACKNOWLEDGE message
Associated IEs
Information Element Description
(IE)
START DTMF ACKNOWLEDGE message, Protocol Discriminator
Protocol Discriminator takes the value 3, indicating that the message belongs to the call
controller (CC) protocol.

Message Type
Indicates the type of the message. For a START DTMF

ACKNOWLEDGE message, the message type is START DTMF
ACKNOWLEDGE.
Reference Standards
For details, see 9.3.25 "Start DTMF Acknowledge" in 3rd Generation Partnership Project
(3GPP) TS24008-830.
STOP DTMF
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the MS/UE to request the network to stop sending the dual tone
multiple frequency (DTMF) tone towards the remote user. Figure 1 shows the main IEs of
the message.
Figure 1 STOP DTMF message
Associated IEs
Information Element
Description
(IE)
STOP DTMF message, Protocol Discriminator takes the value 3,

Protocol Discriminator indicating that the message belongs to the call controller (CC)
protocol.

Message Type
Indicates the type of the message. For a STOP DTMF message,

the message type is STOP DTMF.
Reference Standards
For details, see 9.3.29 "Stop DTMF" in 3rd Generation Partnership Project (3GPP)
TS24008-830.

Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the network to notify the MS/UE that the sending of the dual tone
multiple frequency (DTMF) tone has been stopped. Figure 1 shows the main IEs of the
message.
Figure 1 STOP DTMF ACKNOWLEDGE message
Associated IEs
Information Element
Description
(IE)

STOP DTMF ACKNOWLEDGE message, Protocol Discriminator
Protocol Discriminator takes the value 3, indicating that the message belongs to the call
controller (CC) protocol.

Message Type
Indicates the type of the message. For a STOP DTMF

ACKNOWLEDGE message, the message type is STOP DTMF
ACKNOWLEDGE.
Reference Standards
For details, see 9.3.30 "Stop DTMF acknowledge" in 3rd Generation Partnership Project
(3GPP) TS24008-830.

Message Type
Skip indicator
Priority Level
Mobile Identity
Spare Half Octet
Authentication parameter RAND
Authentication Parameter AUTN (UMTS authentication challenge only)
CM service type
Identity type
Reject cause
Cause
Connected number
Facility
Progress indicator
Repeat indicator
Bearer capability
Calling party BCD number

Description of the IE
Reference Standards
Information Element (IE) Description
Bits 1 to 4 of the first octet of a standard L3 message contain
the Protocol Discriminator IE. This IE identifies the L3 protocol
to which a standard L3 message belongs. The correspondence
between L3 protocols and protocol discriminators is one-to-one.
The following are typical values of Protocol Discriminator:
0101: The message belongs to the mobility
An international mobile subscriber identity (IMSI)
DETACH INDICATION message is considered as an
example here. In this example, Protocol Discriminator
is 0101. Therefore, mm-layer-message is present in
layer-3-information.
0011: The message belongs to the call controller (CC)

protocol.
A SETUP message is considered as an example here.
In this example, Protocol Discriminator is 0011.
Therefore, cm-layer-message is present in layer-3information.
1011: The message belongs to the supplementary

service (SS) protocol.
A FACILITY message is considered as an example
here. In this example, Protocol Discriminator is 1011.
Therefore, ss-layer-message is present in layer-3information.
1001: The message belongs to the short message

service (SMS) protocol.
A CP DATA message is considered as an example
here. In this example, Protocol Discriminator is 1001.
Therefore, sms-layer-message is present in layer-3information.
Reference Standards
For details, see 10.2 "Protocol Discriminator" in 3rd Generation Partnership Project (3GPP)
TS24008-830.
Parent topic: Description of Associated IEs
Message Type
Reference Standards
Description
Indicates the type of the message.
The following are message types used for mobility
management:
international mobile subscriber identity (IMSI)
DETACH INDICATION
IDENTITY REQUEST
IDENTITY RESPONSE
temporary mobile subscriber identifier (TMSI)
REALLOCATION COMMAND
TMSI REALLOCATION COMPLETE
connection management (CM) SERVICE ACCEPT
CM SERVICE REJECT
CM SERVICE ABORT
CM SERVICE REQUEST
CM SERVICE PROMPT
CM RE-ESTABLISHMENT REQUEST
mobility management (MM) NULL
MM STATUS
MM INFORMATION
The following are the message types used for call control
and supplementary service control.
ALERTING
Message Type
CALL CONFIRMED
CALL PROCEEDING
CONNECT
CONNECT ACKNOWLEDGE
EMERGENCY SETUP
PROGRESS
CC-ESTABLISHMENT
CC-ESTABLISHMENT CONFIRMED
RECALL
START call controller (CC)
SETUP
MODIFY
MODIFY COMPLETE
MODIFY REJECT
USER INFORMATION
HOLD
HOLD ACKNOWLEDGE
HOLD REJECT
RETRIEVE
RETRIEVE REJECT
DISCONNECT
RELEASE
RELEASE COMPLETE
CONGESTION CONTROL
NOTIFY
STATUS
STATUS ENQUIRY
START dual tone multiple frequency (DTMF)
STOP DTMF
START DTMF REJECT
FACILITY
An IMSI DETACH INDICATION message is considered as

an example here. In this example, mm-msg-type is 1,
indicating that the message type is IMSI DETACH
INDICATION.
Reference Standards
For details, see 10.4 "Message Type" in 3rd Generation Partnership Project (3GPP)
TS24008-830.
Skip indicator
Reference Standards
Description
ignored.
A message received with skip indicator
different from 0000 should be ignored. A
message received with skip indicator encoded
as 0000 should not be ignored, unless it is
ignored for other reasons.
Skip indicator
An international mobile subscriber identity

(IMSI) DETACH INDICATION message is
considered as an example here. In this
example, Skip indicator is 0, indicating that the
message will not be ignored.
Reference Standards
For details, see 10.3.1 "Skip indicator" in 3rd Generation Partnership Project (3GPP)
TS24008-830.
Reference Standards
Information Element
(IE)
Description
Distinguishes a few message flows for a given protocol
discriminator and a given session announcement protocol (SAP).
Such a message flow is called a transaction. This IE consists of
the following fields:
transaction-value: indicates the transaction identifier (TI)

value, which can be set to 6 at most.
transaction-flag: identifies whether the message sender
or receiver has assigned the TI value to this transaction.
A message has transaction-flag set to 0 when it belongs
to a transaction initiated by its sender, and to 1
otherwise.
A SETUP message is considered as an example here. In this

example, transaction-value is 0 indicating that the TI value is 0,
and transaction-flag is 0 indicating that the message is sent from
the side that originates the TI.
Reference Standards
For details, see 11.2.3.1.3 "Transaction identifier" in 3rd Generation Partnership Project
(3GPP) TS24007-700.
Priority Level
Reference Standards
Provides information defining the priority level requested or
applied.
The Priority Level IE is optional and may be included in
CM_SERVICE_REQUEST, CALL_PROCEEDING, and SETUP
messages. Calls with higher priority are set up more quickly.
This IE takes the following values:
Priority Level
0:
1:
2:
3:
4:
5:
6:
7:
no priority applied
call priority level 4
call priority level B
call priority level A
A CM_SERVICE_REQUEST is considered as an example

here. In this example, Priority Level is 1, indicating that call
priority level 4 is applied.
Reference Standards
For details, see 10.5.1.11 "Priority Level" in 3rd Generation Partnership Project (3GPP)
TS24008-830.

Reference Standards
Ciphering Key Sequence

Number
Makes it possible for the network to identify the ciphering key,

which is stored in the MS/UE, without invoking the
authentication procedure.
In a location update, the access side passes Ciphering Key
Sequence Number to the network side. By using Ciphering Key
Sequence Number, the network side identifies the ciphering key
Kc (in GSM authentication challenge) or ciphering key ciphering
key (CK) and integrity key IK (in UMTS authentication
challenge) without invoking the authentication procedure. In the
GSM network, if the Ciphering Key Sequence Number received
from the MS is the same as that held by the network side,
authentication challenge is bypassed.
A LOCATION UPDATING REQUEST message is considered

as an example here. In this example, the Ciphering Key
Sequence Number stored in the MS/UE is 7.
An AUTHENTICATION REQUEST message is considered as

an example here. In this example, the Ciphering Key Sequence
Number allocated by the network is 6.
Reference Standards
For details, see 10.5.1.2 "Ciphering Key Sequence Number" in 3rd Generation Partnership

Reference Standards
Provides unambiguous identification of location areas where the
MS/UE is staying.
This IE is five octets long and coded in the format:
MCC+MNC+LAC.
Location Area
Identification
A LOCATION UPDATING ACCEPT message is considered as

an example here. In this example, location-area-identity
(equivalent of Location Area Identification), which is stored in the
subscriber identity module (SIM)/user service identity module
(USIM), is 46073f0001.
Reference Standards
For details, see 10.5.1.3 "Location Area Identification" in 3rd Generation Partnership
Mobile Identity
Reference Standards
Provides one of the following MS/UE identity information:
International mobile Subscriber Identity (IMSI)
Temporary Mobile Subscriber Identity (TMSI or PTMSI)
International Mobile Equipment Identity (IMEI)
International Mobile Equipment Identity Together with
the Software Version Number (IMEISV)
Temporary Mobile Group Identity (TMGI)
Associated Multimedia Broadcast Multicast Service
(MBMS) Session Identity
Mobile Identity
A LOCATION UPDATING REQUEST message is considered as

an example here. In this example, the Mobile Identity IE is coded
as follows:
type-of-identity is IMSI, indicating that IMSI is selected
to identify the MS/UE.
odd-or-even-ind is 1, indicating that the selected mobile
identity type consists of an odd number of digits. If
there are an even number of digits, odd-or-even-ind
should be set to 0.
imsi is 460880001000111.
Reference Standards
For details, see 10.5.1.4 "Mobile Identity" in 3rd Generation Partnership Project (3GPP)
TS24008-830.

Reference Standards
Information
Element (IE)
Description
Provides the network with information concerning aspects of high
priority of the MS/UE. This IE affects the manner in which the network
handles the operation of the MS/UE. It consists of the following fields:
rf-power-capability: indicates the radio frequency (RF) power
capability of the frequency band used. It is dimensioned into
five classes.
a51-alrorithm-indicator: indicates whether the MS/UE supports
encryption algorithm A5/1. The MS/UE should set this
indicator to 0 if A5/1 algorithm is supported, and to 1
otherwise.
early-classmark-send: indicates whether "Controlled Early
Classmark Sending" option is implemented in the MS/UE. The
MS/UE should set this indicator to 1 if "Controlled Early
Classmark Sending" option is supported, and to 0 otherwise.
revision-level-indicator: indicates the protocol version
supported by the MS/UE. This IE takes a few values, for
example, value 0 for GSM phase 1, and value 2 for GSM
phase 2 mobile stations.
Mobile Station
Classmark 1
A LOCATION UPDATING REQUEST message is considered as an

example here. In this example, rf-power-capability is 3 indicating that
RF power capability class 4 is applied, a51-alrorithm-indicator is 0
indicating that the MS/UE supports the A5/1 algorithm, and earlyclassmark-send is 1 indicating that "Controlled Early Classmark
Sending" option is implemented in the MS/UE.
Reference Standards
For details, see 10.5.1.5 "Mobile Station Classmark 1" in 3rd Generation Partnership

Reference Standards
Information
Element (IE)
Description
Provides the network with information concerning aspects of both high and
low priority of the MS/UE.
This IE is conveyed in a connection management (CM) SERVICE
REQUEST or UE-originated LOCATION UPDATING REQUEST message.
It contains a few fields, including:
voice-group-call-service: indicates MS/UE support for Voice
Group Call Service (VGCS) notification reception.
voice-broadcast-service: indicates MS/UE support for Voice
Broadcast Service (VBS) notification reception.
short-message-capability: indicates MS/UE support for mobile
terminated point-to-point short message service (SMS).
supplement-service-screen: indicates MS/UE support for
supplementary service screening.
cm-service-prompt: indicates MS/UE support for CM Service
Prompt (also called CCBS).
universal-character-set-2: indicates MS/UE support for Universal
Character Set 2 (UCS2).
location-service-capability: indicates MS/UE support for location
request notification.
classmark3-indicator: indicates MS/UE support for options
indicated in Mobile Station Classmark 3.
Mobile Station
Classmark 2
A CM SERVICE REQUEST message is considered as an example here. In

this example, voice-group-call-service is 0 indicating that no VGCS
capability or no notifications are wanted, and voice-broadcast-service is 0
indicating that no VBS capability or no notifications are wanted.
Reference Standards
Spare Half Octet

Reference Standards
Description
Reserved for future use.
This IE is half-octet long and filled with spare bits set to
zero.
Spare Half Octet

An AUTHENTICATION REQUEST message is
considered as an example here. In this example, spare
is 0, indicating that a spare bit equal to zero is added.
Reference Standards
For details, see 10.5.1.8 "Spare Half Octet" in 3rd Generation Partnership Project (3GPP)
TS24008-830.
Authentication parameter RAND

Reference Standards
Provides the MS/UE with a non-predictable number to be used
to calculate the authentication response signature SRES and the
ciphering key Kc (for GSM authentication challenge), or the
response RES and both the ciphering key CK and integrity key
IK (for UMTS authentication challenge). The non-predictable
number is called RAND.
Authentication parameter
random number (RAND)
An AUTHENTICATION REQUEST message is considered as an

example here. In this example, the RAND value (indicated by
auth-rand) is 1F 8E ED E0 C8 FC 99 F6 B3 32 AE CF 48 DD
71 E0.
Reference Standards
For details, see 10.5.3.1 "Authentication parameter RAND" in 3rd Generation Partnership
Authentication Parameter AUTN (UMTS authentication

challenge only)
Reference Standards
Information Element
Description
(IE)
Provides the UE with a means of authenticating the network.
This IE is sent from the network to the UE only when Universal
Mobile Telecommunications System (UMTS) authentication challenge
is used.
Authentication
Parameter
authentication token
(AUTN)
An AUTHENTICATION REQUEST message is considered as an
example here. In this example, the AUTN value (indicated by autn) is
5E FB DE ED 57 43 72 4C AF 9C AE 5E 8B F3 25 7B.
Reference Standards
For details, see 10.5.3.1.1 "Authentication Parameter AUTN (UMTS authentication
challenge only)" in 3rd Generation Partnership Project (3GPP) TS24008-830.

Reference Standards
Information
Element (IE)
Description
Provides the network with the authentication response calculated in the
subscriber identity module (SIM)/user service identity module (USIM).
In GSM authentication challenge, SRES (response calculated in the
SIM/USIM) is 4 bytes in length and is placed in the Authentication
Response Parameter IE. In Universal Mobile Telecommunications
System (UMTS) authentication challenge, RES (response calculated in
the USIM) may be up to 16 octets in length. The Authentication
Response Parameter IE consists of the following fields:
auth-sres: conveys SRES or four most significant octets of
RES.
auth-res-ext: conveys the remaining part of RES. This field is
included if RES (UMTS only) is longer than 4 octets and
therefore does not fit in the auth-sres field.
Authentication
Response
parameter
An AUTHENTICATION RESPONSE message is considered as an

example here. In this example, auth-sres is FB 19 FC 2C, and authres-ext is EF 9B 0F 05. So, the complete RES is FB 19 FC 2C EF 9B
0F 05.
Reference Standards
For details, see 10.5.3.2 "Authentication Response parameter" in 3rd Generation
Partnership Project (3GPP) TS24008-830.
CM service type
Reference Standards
Information Element
Description
(IE)
Specifies which service is requested from the network.
connection
management (CM)
service type
1: mobile originating call establishment or packet mode

connection establishment
2: emergency call establishment
4: short message service
8: supplementary service activation
9: voice group call establishment
10: voice broadcast call establishment
11: location services
A CM SERVICE REQUEST message is considered as an example

here. In this example, cm-service-type is 1, indicating that the
mobile originating call establishment or packet mode connection
establishment is being requested by the MS/UE.
Reference Standards
For details, see 10.5.3.3 "CM service type" in 3rd Generation Partnership Project (3GPP)
TS24008-830.
Identity type
Reference Standards
Specifies which identity is requested from the MS/UE.
Identity type
1: international mobile subscriber identity (IMSI)

2: international mobile equipment identity (IMEI)
3: international mobile station equipment identity and
software version (IMEISV)
4: temporary mobile subscriber identifier (TMSI)
An IDENTITY REQUEST message is considered as an example

here. In this example, mobile-identity-type is 2, indicating that
IMEI is being requested from the MS/UE.
Reference Standards
For details, see 10.5.3.4 "Identity type" in 3rd Generation Partnership Project (3GPP)
TS24008-830.

Reference Standards
Information Element
Description
(IE)
Indicates whether a generic updating, a periodic updating, or an
international mobile subscriber identity (IMSI) attach is wanted. This
IE may also indicate that a follow-on request has been received from
the connection management (CM) entity of the MS/UE. It consists of
the following fields:
location-update-type: indicates the type of location update.
0: generic location update
9: periodic location update
2: IMSI attach
follow-on-request-bit: indicates whether a follow-on request
is pending. The presence of follow-on indicator implies that
the current service is followed by CM services and CM
services may be established on existing radio resource
(RR) and mobility management (MM) connections.
Location updating
type

example here. In this example, location-update-type is 0 indicating
that generic location update is wanted, and follow-on-request-bit is 0
indicating that no follow-on request is pending.
Reference Standards
For details, see 10.5.3.5 "Location updating type" in 3rd Generation Partnership Project
(3GPP) TS24008-830.
Reject cause
Reference Standards
Information Element
(IE)
Description
Indicates the reason why a request from the MS/UE is rejected by
the network.
Reject cause
2: international mobile subscriber identity (IMSI) unknown

in HLR
3: Illegal MS
4: IMSI unknown in VLR
5: international mobile equipment identity (IMEI) not
accepted
6: Illegal mobile equipment (ME)
11: public land mobile network (PLMN) not allowed
12: Location Area not allowed
13: Roaming not allowed in this location area
15: No Suitable Cells In Location Area
17: Network failure
20: mobile access code (MAC) failure
21: Synch failure
22: Congestion
23: GSM authentication unacceptable
A LOCATION UPDATING REJECT message is considered as an

example here. In this example, reject-cause is 11, indicating that
the location update request is denied because the MS/UE is not
authorized to enter the PLMN.
Reference Standards
For details, see 10.5.3.6 "Reject cause" in 3rd Generation Partnership Project (3GPP)
TS24008-830.
Cause
Reference Standards
Information Element
(IE)
Description
Describes the reason for generating certain messages, to provide
diagnostic information in the event of procedural errors and to
indicate the location of the cause originator.
Cause
A DISCONNECT message is considered as an example here. In

this example, cause-value is 44, indicating that the call is released
because the requested circuit/channel is not available.
Reference Standards
For details, see 10.5.4.11 "Cause" in 3rd Generation Partnership Project (3GPP) TS24008830.
Connected number
Reference Standards
Information
Element (IE)
Description
Identifies the connected party of a call.
This IE is sent from the network to the calling MS/UE. It consists of the
following fields:
number-plan-identification: indicates the numbering plan in use.
0: Unknown
1: integrated services digital network
(ISDN)/telephony numbering plan
2: generic numbering plan
3: data numbering plan
4: telex numbering plan
5: Maritime mobile numbering plan
6: Land mobile numbering plan
7: ISDN/mobile numbering plan
Connected
number
type-of-number: indicates the type of connected number. For

example, subscriber number, unknown number, national
number, and international number.
screening-indicator: indicates whether the connected number
should be hidden from the calling party.
presentation-indicator: indicates whether the connected number
should be presented to the calling party. This field is set to 0 if
presentation is allowed, and to 1 otherwise.
number: indicates the directory number for which the call is
destined.
A CONNECT message is considered as an example here. In this

example, number-plan-identification is 1 indicating that the
ISDN/telephony numbering plan is applied, type-of-number is 2 indicating
that the connected number is an national number, screening-indicator is 0
indicating that the connected number is not screened, and presentationindicator is 0 indicating that presentation of the connected number is
allowed.
Reference Standards
For details, see 10.5.4.13 "Connected number" in 3rd Generation Partnership Project
(3GPP) TS24008-830.
Facility
Reference Standards
Description
Conveys supplementary service related information.
This IE is included only when a supplementary service,
identified by the operation-code field within the Facility IE, is
required.
The operation-code field takes the following values:
Facility
10: registerSS
11: eraseSS
12: activateSS
13: deactivateSS
14: interrogateSS
16: notifySS
17: registerPassword
18: getPassword
19: processUnstructuredSS-Data
38: forwardCheckSS-Indication
59: processUnstructuredSS-Request
60: unstructuredSS-Request
61: unstructuredSS-Notify
77: eraseCCEntry
110: activatePSS
115: lcs-MOLR
116: lcs-LocationNotification
117: callDeflection
118: userUserService
119: accessRegisterCCEntry
120: forwardCUG-Info
121: splitMPTY
122: retrieveMPTY
123: holdMPTY
124: buildMPTY
125: forwardChargeAdvice
126: explicitCT
A FACILITY message is considered as an example here. In

this example, operation-code is 61, indicating that invocation
or operation of unstructured supplementary service data
(USSD) supplementary service is in progress.
Reference Standards
For details, see 10.5.4.15 "Facility" in 3rd Generation Partnership Project (3GPP)
TS24008-830 and 4.2.2 "Operations description" in 3GPP TS24080-740.

Reference Standards
Description
Provides a means for the addressed entity to perform
compatibility check.

example, lower-layer-compatibility-1 is 00 01, indicating that
the call originating entity has sent compatibility check method
00 01 to the addressed entity.
Reference Standards
For details, see 10.5.4.18 "Low layer compatibility" in 3rd Generation Partnership Project
(3GPP) TS24008-830.
Progress indicator
Reference Standards
Information Element
Description
(IE)
Describes an event that has occurred during the life of a call.
Progress indicator
A DISCONNECT message is considered as an example here. In this
example, Progress description is 1, indicating that the call is not
end-to-end public land mobile network (PLMN)/integrated services
digital network (ISDN) and further call progress information may be
available in-band.
Reference Standards
For details, see 10.5.4.21 "Progress indicator" in 3rd Generation Partnership Project
(3GPP) TS24008-830.
Repeat indicator
Reference Standards
Information
Element (IE)
Description
Indicates how the associated repeated information elements should
be interpreted when included in a message.
The Repeat indicator IE is included immediately before the first
occurrence of the associated information element that will be
repeated in a message.
Repeat indicator

example, bc-repeat-indicator is 1, indicating that a circular for
successive circuit selection.
Reference Standards
For details, see 10.5.4.22 "Repeat indicator" in 3rd Generation Partnership Project (3GPP)
TS24008-830.
Bearer capability
Reference Standards
Information
Element (IE)
Description
Describes a bearer service.
The purpose of this IE is to let access side and network side notify each
other of the locally supported codecs so that both sides can reach an
agreement on the codec that will be used. This IE contains a few fields,
including:
information-transfer-capability: indicates the type of information
that can be transferred during the lifetime of the call. This field has
a few values, for example, 010 (3.1 kHz audio, ex PLMN), 001
(unrestricted digital information), 011 (facsimile group 3), and 000
(speech).
default-speech-supported-ind: indicates the speech version
supported.
Bearer
capability
A SETUP message from the calling MS/UE is considered as an example

here. In this example, information-transfer-capability is 0 indicating that the
calling MS/UE requests speech bearer capability (BC), and default-speechsupported-ind is 1 indicating that the access side supports full rate speech
version 1.
Reference Standards
For details, see 10.5.4.5 "Bearer capability" in 3rd Generation Partnership Project (3GPP)
TS24008-830.


Reference Standards
Information
Element (IE)
Description
Identifies the called party. This IE contains the following fields,
including:
number-plan-identification: indicates the numbering plan in
use.
0: Unknown
1: integrated services digital network
(ISDN)/telephony numbering plan
Called party binarycoded data (BCD)

number
type-of-number: indicates the type of called number, for

example, subscriber number, unknown number, national
number, and international number.
number: indicates the called number.
A SETUP message from the calling MS/UE is considered as an

example here. In this example, number-plan-identification is 1 indicating
that the ISDN/telephony numbering plan is applied, type-of-number is 2
indicating that the called number is a national number, and called
number is 13107559917.
Reference Standards
For details, see 10.5.4.7 "Called party BCD number" in 3rd Generation Partnership Project
(3GPP) TS24008-830.

Reference Standards
Information Element
Description
(IE)
Identifies the origin of a call. This IE contains the following fields,
including:
number-plan-identification: indicates the numbering plan in use.
Calling party binarycoded data (BCD)

number
0: Unknown
1: integrated services digital network (ISDN)/telephony
numbering plan
type-of-number: indicates the type of calling number, for example,
subscriber number, unknown number, national number, and
international number.
number: indicates the calling number.
A SETUP message from the called MS/UE is considered as an

example here. In this example, number-plan-identification is 1
indicating that the ISDN/telephony numbering plan is applied, typeof-number is 2 indicating that the calling number is an national
number, and calling number is 13620016111.
Reference Standards
For details, see 10.5.4.9 "Calling party BCD number" in 3rd Generation Partnership Project
(3GPP) TS24008-830.

A Interface Protocol
Description of the A Interface Protocol
Description of Assignment Messages
Description of Cipher Mode Control Messages
Description of Paging Messages
Description of Handover Management Messages
Description of Resource Release Messages
Description of the A Interface Protocol

Protocol Stack
Message List
The MSC server/VLR communicates with the base station subsystem (BSS) through BSS
Application Part (BSSAP). Figure 1 shows the application of the A interface protocol
BSSAP.
Figure 1 Application of the A interface protocol
Protocol Stack
Figure 2 shows the protocol stack for time division multiplexing (TDM) transport over the A
interface. Figure 3 shows the protocol stack for IP transport over the A interface.
Figure 2 Protocol stack for TDM transport over the A interface
Figure 3 Protocol stack for IP transport over the A interface
NOTE:
When interfacing the IP-capable BSC, the A interface supports a few adaptation protocols,
including MTP3-User Adaptation Layer (M3UA) and Signaling Connection and Control Part User Adaptation Layer (SUA) protocols. Figure 3 takes M3UA as an example.
BSSAP is split into two sub application parts: BSS Management Application Part
(BSSMAP) and Direct Transfer Application Part (DTAP).
DTAP is used to realize direct transfer of call control and mobility management messages
between the MSC and the MS, with no interpretation of layer 3 information at the BSS.
BSSMAP supports all of the MSC-BSC procedures that require interpretation and
processing of information related to single calls, and resource management. BSSMAP
messages are not distributed to the MS.
As shown in Figure 4, BSSAP messages are encapsulated into payload of Signaling
Connection Control Part (SCCP) messages.
Figure 4 Encapsulation of BSSAP messages
Message List
Table 1 List of common A interface messages
Message
ASSIGNMENT
REQUEST
ASSIGNMENT
COMPLETE
ASSIGNMENT
Direction Function
This message is sent from the MSC server to the BSS
MSC
via the relevant SCCP connection in order to request the
server ->
BSS to assign radio resource(s), the attributes of which
BSC
are defined within the message.
BSC -> This message is sent from the BSS to the MSC server
MSC
and indicates that the requested assignment has been
server
completed correctly.
This message is sent from the BSS to the MSC server
BSC -> via the relevant SCCP connection. It indicates that there
MSC
FAILURE
server
CIPHER MODE
COMMAND
MSC
server ->
BSC
CIPHER MODE
COMPLETE
BSC ->
MSC
server
PAGING
MSC
server ->
BSC
HANDOVER
REQUEST
MSC
server ->
BSC
HANDOVER
REQUIRED
BSC ->
MSC
server
HANDOVER
REQUEST
ACKNOWLEDGE
BSC ->
MSC
server
HANDOVER
COMMAND
MSC
server ->
BSC
HANDOVER
COMPLETE
BSC ->
MSC
server
BSC ->
HANDOVER DETECT MSC
server
CLEAR COMMAND
MSC
server ->
BSC
has been a failure in the assignment process at the BSS

and that the assignment procedure has been aborted.
via the relevant SCCP connection associated with that
MS transaction. It updates the encryption parameters for
the concerned MS.
This message is sent from the BSS to the MSC server
via the relevant SCCP connection. It indicates that a
successful cipher synchronization has been achieved
across the radio interface.
and contains sufficient information to allow the paging
message to be transmitted by the correct cells at the
correct time.
This message is sent from the MSC server to the target
BSS via the relevant SCCP connection to indicate that
the MS will be handed over to that BSS.
This message is sent from the source BSS to the MSC
server to indicate that a handover is required for a given
MS that already has dedicated radio resource(s)
assigned.
This message is sent from the target BSS to the MSC
server to indicate that the handover request can be
supported by the target BSS, and also to convey
information about radio channel(s) the MS should be
directed to.
This message is sent from the MSC server to the source
BSS via the relevant SCCP connection and contains the
target channel to which the MS should return.
server via the relevant SCCP connection. It indicates that
the correct MS has successfully accessed the target
cell.
server via the relevant SCCP connection. It indicates that
the correct MS has successfully accessed the target
cell.
This message is sent from the MSC server to the BSS to
instruct the BSS to release the associated dedicated
resource(s). After reception of this message, the BSS
releases the radio interface and marks any assigned
terrestrial resources as idle.
BSC ->
CLEAR COMPLETE MSC
server
MSC
REROUTE COMMAND server ->
BSC
REROUTE
COMPLETE
This message is sent from the BSS to the MSC server to

inform the MSC that the associated dedicated
resource(s) has been successfully cleared.
instruct the BSS to select another core network. This
message applies only to the 2G MOCN flow.
MSC
notify the BSS that the core network selection is
server ->
complete. This message applies only to the 2G MOCN
BSC
flow.
Parent topic: A Interface Protocol


Table 1 IEs carried in the common part of messages
Information
Element (IE)
Description
Provides a brief description of the message sender and receiver.
Header
sender-mid: identifies the calling control unit (CCU) module

on the sender side.
sender-pid: identifies the internal processing module on the
sender side.
receiver-mid: identifies the CCU module on the receiver side.
receiver-pid: identifies the internal processing module on the
receiver side.

example here. In this example, the message is originated from CCU
module 23 via the Signaling Connection Control Part (SCCP) module
and interpreted by CCU module 23 before reaching the AIM module.
Provides SCCP connection information and signaling point code (SPC)
of the BSC.
sccp-connect-id: identifies the SCCP connection in use.
spc-of-14-bit: conveys the 14-bit SPC of the BSC.
SCCP information

example here. In this example, sccp-connect-id is 130 indicating that
SCCP connection 130 is used to transport the message, and spc-of-
14-bit is 0x2771 indicating that the BSC is assigned the SPC 0x2771.
Description of Assignment Messages

ASSIGNMENT REQUEST
ASSIGNMENT COMPLETE
ASSIGNMENT FAILURE
ASSIGNMENT REQUEST
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent from the MSC to the base station subsystem (BSS) via the relevant
Signaling Connection Control Part (SCCP) connection in order to request the BSS to assign
radio resource(s), the attributes of which are defined within the message. Figure 1 shows
Figure 1 ASSIGNMENT REQUEST message
Associated IEs
Description
Message Type
Identifies the message being sent. It is a

single-octet IE and mandatory in all
messages. In an ASSIGNMENT REQUEST
message, Message Type takes the fixed
value 1.
Channel Type
Contains all of the information that the BSS

requires to determine the required radio
resource(s). This IE has a minimum length of
5 octets and a maximum length of 13 octets.

For details, see Channel Type.
Layer 3 Header Information
Provides the BSS with information that must

be included in the header of layer 3
messages over the radio interface.
For details, see Layer 3 Header Information.
Priority
Indicates the priority of the request. This IE is

three octets long.
For details, see Priority.
Circuit Identity Code
Defines the terrestrial channel over which the

call will pass.
For details, see Circuit Identity Code.
Reference Standards
For details, see 3.2.1.1 "ASSIGNMENT REQUEST" in 3rd Generation Partnership Project
(3GPP) TS48008-840.
Parent topic: Description of Assignment Messages
ASSIGNMENT COMPLETE
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent from the base station subsystem (BSS) to the MSC and indicates that
the requested assignment has been completed correctly. Figure 1 shows the main IEs of
the message.
Figure 1 ASSIGNMENT COMPLETE message
Associated IEs
Description
Message Type

messages. In an ASSIGNMENT COMPLETE
value 2.
radio resource (RR) Cause
Indicates the reason passed from the radio

interface to the MSC transparently.
For details, see RR Cause.
Defines the terrestrial channel over which the

call will pass.
Indicates the speech version being used by
Speech Version
the BSS.
For details, see Speech Version.
Reference Standards
For details, see 3.2.1.2 "ASSIGNMENT COMPLETE" in 3rd Generation Partnership Project
(3GPP) TS48008-840.
ASSIGNMENT FAILURE
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent from the base station subsystem (BSS) to the MSC via the relevant
Signaling Connection Control Part (SCCP) connection. It indicates that there has been a
failure in the assignment process at the BSS and that the assignment procedure has been
aborted. Figure 1 shows the main IEs of the message.
Figure 1 ASSIGNMENT FAILURE message
Associated IEs
Description
Message Type

messages. In an ASSIGNMENT FAILURE
Message, Message Type takes the fixed
value 3.
Cause
Indicates the reason why an assignment

failure was encountered.
radio resource (RR) Cause
Indicates the reason passed from the radio

interface to the MSC transparently.
Reference Standards
For details, see 3.2.1.3 "ASSIGNMENT FAILURE" in 3rd Generation Partnership Project
(3GPP) TS48008-840.
Description of Cipher Mode Control Messages

CIPHER MODE COMMAND
CIPHER MODE COMPLETE
CIPHER MODE COMMAND

Message Function
Associated IEs
Reference Standards
Message Function
This message is sent from the MSC to the base station subsystem (BSS) via the relevant
Signaling Connection Control Part (SCCP) connection associated with that MS transaction.
It updates the encryption parameters for the concerned MS. Figure 1 shows the main IEs
of the message.
Figure 1 CIPHER MODE COMMAND message
Associated IEs
Description
Message Type

messages. In a CIPHER MODE COMMAND
value 83.
Provides the BSS with information that must

be included in the header of layer 3
messages over the radio interface.
Contains the user data encryption information
used to control any encryption equipment at
Encryption Information
the BSS.
For details, see Encryption Information.
Reference Standards
For details, see 3.2.1.30 "CIPHER MODE COMMAND" in 3rd Generation Partnership
Parent topic: Description of Cipher Mode Control Messages
CIPHER MODE COMPLETE

Message Function
Associated IEs
Reference Standards
Message Function
This message is sent from the base station subsystem (BSS) to the MSC via the relevant
Signaling Connection Control Part (SCCP) connection. It indicates that a successful cipher
synchronization has been achieved across the radio interface. Figure 1 shows the main IEs
of the message.
Figure 1 CIPHER MODE COMPLETE message
Associated IEs
Description
Message Type

messages. In a CIPHER MODE COMPLETE
value 85.
Chosen Encryption Algorithm
Indicates the encryption algorithm being used

by the BSS.
For details, see Chosen Encryption Algorithm.
Reference Standards
For details, see 3.2.1.31 "CIPHER MODE COMPLETE" in 3rd Generation Partnership
Parent topic: Description of Cipher Mode Control Messages

Description of Paging Messages

PAGING
PAGING RESPONSE
PAGING
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent from the MSC to the base station subsystem (BSS) and contains
sufficient information to allow the paging message to be transmitted by the correct cells at
the correct time. Figure 1 shows the main IEs of the message.
Figure 1 PAGING message

Associated IEs
Message Type
Description
messages. In a PAGING message, Message
Type takes the fixed value 82.

international mobile subscriber identity
(IMSI)
Provides IMSI of the called party.

For details, see IMSI.
temporary mobile subscriber identifier

(TMSI)
Provides TMSI of the called party.

For details, see TMSI.
Cell Identifier List
Identifies the cells on the called side.

For details, see Cell Identifier List.
enhanced multi-level precedence and

preemption (eMLPP) Priority
Contains the eMLPP priority of the call.

For details, see eMLPP Priority.
Reference Standards
For details, see 3.2.1.19 "PAGING" in 3rd Generation Partnership Project (3GPP)
TS48008-840.
Parent topic: Description of Paging Messages
PAGING RESPONSE
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent from the base station subsystem (BSS) to the MSC server as a
response to the PAGING message. Figure 1 shows the PAGING RESPONSE message.
Figure 1 PAGING RESPONSE message
Associated IEs
Description

message belongs.
Skip Indicator

Message Type

messages. In a PAGING RESPONSE
value 39.

ciphering key.
Number.
Spare Half Octet


For details, see Classmark Information Type
2.
Mobile Identity
Provides identity information of the MS.

Reference Standards
For details, see section 9.1.25 "Paging response" in 3GPP TS44018-840.
Parent topic: Description of Paging Messages


HANDOVER REQUEST
HANDOVER REQUIRED
HANDOVER REQUEST ACKNOWLEDGE
HANDOVER COMMAND
HANDOVER COMPLETE
HANDOVER DETECT
HANDOVER REQUEST
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent from the MSC to the target base station subsystem (BSS) via the
relevant Signaling Connection Control Part (SCCP) connection to indicate that the MS will
be handed over to that BSS. Figure 1 shows the main IEs of the message.
Figure 1 HANDOVER REQUEST message
Associated IEs
Description
Message Type

messages. In a HANDOVER REQUEST
value 16.
Channel Type
Provides information such as channel rate,

channel type, and permitted speech version.
For details, see Channel Type.
Contains the user data encryption information

used to control any encryption equipment at
the BSS. The encryption information includes
the permitted A5 algorithm(s).
Classmark Information 1 or Classmark

Information 2
Indicates general capability of the MS.

For details about Classmark Information Type
1, see Classmark Information Type 1.
For details about Classmark Information Type
2, see Classmark Information Type 2.
Cell Identifier (Serving)
Identifies the source cell.

For details, see Cell Identifier.
Priority
Indicates subscriber priority.

For details, see Priority.
Identifies a circuit between SPCs.

Cell Identifier (Target)
Identifies the target cell.

Cause
Indicates the reason for a handover to have

occurred.
Speech Version (Used)

the BSS.
Chosen Encryption Algorithm (Serving)

by the BSS.
Reference Standards
For details, see 3.2.1.8 "HANDOVER REQUEST" in 3rd Generation Partnership Project
(3GPP) TS48008-840.
Parent topic: Description of Handover Management Messages
HANDOVER REQUIRED
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent from the source base station subsystem (BSS) to the MSC to indicate
that a handover is required for a given MS that already has dedicated radio resource(s)
assigned. Figure 1 shows the main IEs of the message.
Figure 1 HANDOVER REQUIRED message
Associated IEs
Description
Message Type

messages. In a HANDOVER REQUIRED
value 17.
Cause
Indicates the reason for a handover to have

occurred.
Identifies a list of preferred target cells.
Cell Identifier List (Preferred)
For details, see Cell Identifier List.

Current Channel Type 1
Contains a description of the channel

allocated to the MS.
For details, see Current Channel Type 1.
Speech Version (Used)

the BSS. This IE is included only when the
channel is used for speech service.
Reference Standards
For details, see 3.2.1.9 "HANDOVER REQUIRED" in 3rd Generation Partnership Project
(3GPP) TS48008-840.
HANDOVER REQUEST ACKNOWLEDGE

Message Function
Associated IEs
Reference Standards
Message Function
This message is sent from the target base station subsystem (BSS) to the MSC to indicate
that the handover request can be supported by the target BSS, and also to convey
information about radio channel(s) the MS should be directed to. Figure 1 shows the main
IEs of the message.
Figure 1 HANDOVER REQUEST ACKNOWLEDGE message
Associated IEs
Description
Message Type

messages. In a HANDOVER REQUEST
ACKNOWLEDGE message, Message Type
takes the fixed value 18.

Layer 3 Information
Provides information about the channel to

which the MS should retune.
For details, see Layer 3 Information.
Chosen Channel
Contains a description of the channel that the

target BSS allocated to the MS.
For details, see Chosen Channel.

by the target BSS.
Reference Standards
For details, see 3.2.1.10 "HANDOVER REQUEST ACKNOWLEDGE" in 3rd Generation
HANDOVER COMMAND
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent from the MSC to the source base station subsystem (BSS) via the
relevant Signaling Connection Control Part (SCCP) connection and contains the target
channel to which the MS should retune. Figure 1 shows the main IEs of the message.
Figure 1 HANDOVER COMMAND message
Associated IEs
Description
Message Type
Indicates the type of message. For a HANDOVER

COMMAND message, the message type is
bssmap-Handover-Command.
Layer 3 Information
Provides radio channel information.

For details, see Layer 3 Information.
Cell Identifier
Identifies a cell.
Reference Standards
For details, see 3.2.1.11 "HANDOVER COMMAND" in 3rd Generation Partnership Project
(3GPP) TS48008-840.
HANDOVER COMPLETE
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent from the target base station subsystem (BSS) to the MSC via the
relevant Signaling Connection Control Part (SCCP) connection. It indicates that the correct
MS has successfully accessed the target cell. Figure 1 shows the main IEs of the message.
Figure 1 HANDOVER COMPLETE message
Associated IEs
Description
Message Type
Indicates the type of message. For a HANDOVER

COMPLETE message, the message type is
bssmap-Handover-Complete.
Radio Resource (RR) Cause
Indicates the reason why a HANDOVER

COMPLETE message was sent. Generally,
sending of a HANDOVER COMPLETE message
is a normal event and does not result from errors.

Reference Standards
For details, see 3.2.1.12 "HANDOVER COMPLETE" in 3rd Generation Partnership Project
(3GPP) TS48008-840.
HANDOVER DETECT
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent from the target base station subsystem (BSS) to the MSC via the
relevant Signaling Connection Control Part (SCCP) connection. It indicates that the correct
MS has successfully accessed the target cell. Figure 1 shows the main IEs of the message.
Figure 1 HANDOVER DETECT message
Associated IEs
Description
Message Type
Indicates the type of message. For a

HANDOVER DETECT message, the message
type is bssmap-Handover-Detect.
Reference Standards
For details, see 3.2.1.40 "HANDOVER DETECT" in 3rd Generation Partnership Project
(3GPP) TS48008-840.

Description of Resource Release Messages

CLEAR COMMAND
CLEAR COMPLETE
CLEAR COMMAND
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent from the MSC to the base station subsystem (BSS) to instruct the
BSS to release the associated dedicated resource(s). After reception of this message, the
BSS releases the radio interface and marks any assigned terrestrial resources as idle.
Figure 1 CLEAR COMMAND message
Associated IEs
Description
Message Type
Indicates the type of message. For a CLEAR

COMMAND message, the message type is
bssmap-Clear-Command.
Provides the BSS with information that must be

included in the header of layer 3 messages over
the radio interface.
Cause
Indicates the reason why resources are

released. Generally, resource release is initiated
for call control purposes.
CSFB Indication
Indicates that the radio connection is established

in a circuit switched fallback (CSFB) procedure.
For details, see CSFB Indication.
Reference Standards
For details, see 3.2.1.21 "CLEAR COMMAND" in 3rd Generation Partnership Project
(3GPP) TS48008-a60.
Parent topic: Description of Resource Release Messages
CLEAR COMPLETE
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent from the base station subsystem (BSS) to the MSC to inform the
MSC that the associated dedicated resource(s) has been successfully cleared. Figure 1
Figure 1 CLEAR COMPLETE message
Associated IEs
Description
Message Type
Indicates the type of message. For a CLEAR

COMPLETE message, the message type is
bssmap-Clear-Complete.
Reference Standards
For details, see 3.2.1.22 "CLEAR COMPLETE" in 3rd Generation Partnership Project
(3GPP) TS48008-840.
Parent topic: Description of Resource Release Messages


Message Type
Channel Type
Cell Identifier
Priority
Classmark Information Type 2
RR Cause
Layer 3 Information
Chosen Channel
Cause
Speech Version
eMLPP Priority
IMSI
TMSI
CSFB Indication
Message Type
Reference Standards
Description
Identifies the message being sent.
The following are typical values of this IE:
Message Type
1: ASSIGNMENT REQUEST
2: ASSIGNMENT COMPLETE
3: ASSIGNMENT FAILUR
4: CHANNEL MODIFY REQUEST
16: HANDOVER REQUEST
17: HANDOVER REQUIRED
18: HANDOVER REQUEST
ACKNOWLEDGE
19: HANDOVER COMMAND
20: HANDOVER COMPLETE
21: HANDOVER SUCCEEDED
22: HANDOVER FAILURE
23: HANDOVER PERFORMED
27: HANDOVER DETECT
32: CLEAR COMMAND
33: CLEAR COMPLETE
82: PAGING
83: CIPHER MODE COMMAND
85: CIPHER MODE COMPLETE
An ASSIGNMENT REQUEST message is

considered as an example here. In this example,
bssmap-message-type is 1, indicating that the
message being sent is ASSIGNMENT REQUEST.
Reference Standards
For details, see 3.2.2.1 "Message Type" in 3rd Generation Partnership Project (3GPP)
TS48008-840.
Reference Standards
Description
Contains the user data encryption information used to
control any encryption equipment at the base station
subsystem (BSS). This IE contains a few fields,
including:
permitted-algorithms: indicates whether
encryption is applied, and if encryption is
applied, the A5 encryption algorithm(s) that
will be used. This field occupies eight bits.
The meaning of each bit is as follows:
Bit
Bit
Bit
Bit
Bit
Bit
Bit
Bit
0:
1:
2:
3:
4:
5:
6:
7:
no encryption.
GSM A5/1 algorithm
GSM A5/2 algorithm
GSM A5/3 algorithm
GSM A5/4 algorithm
GSM A5/5 algorithm
GSM A5/6 algorithm
GSM A5/7 algorithm
Bit 0 is encoded as 1 to indicate that

encryption will be applied, and as 0 to indicate
otherwise. Among bits 1-6, a bit encoded as
1 indicates that the BSS may use the option
represented by that bit; a bit encoded as 0
indicates that the BSS shall not use the option
represented by that bit.
key: identifies the ciphering key Kc. This field
must be present if at least one of the A5
encryption algorithms is permitted.
A CIPHER MODE COMMAND message is considered
as an example here. In this example, permittedalgorithms is FF indicating that the BSS may select the
GSM A5/1 algorithm, and the Kc sent to the BSS is B2
CA 7C 5B 95 C9 89 60.
Reference Standards
For details, see 3.2.2.10 "Encryption Information" in 3rd Generation Partnership Project
(3GPP) TS48008-840.
Channel Type
Reference Standards
Description
Contains all of the information that the base station
subsystem (BSS) requires to determine the required radio
resource(s).
This IE has a minimum length of 5 octets and a maximum
length of 13 octets. It consists of the following fields:
Channel Type
bsc-swithc: reserved for future use.

sp-data: indicates whether the channel is used for
speech or data service. The sp-data field is
encoded as 1 to indicate speech service, and as 2
to indicate data service.
rate: indicates channel rate.
permitted-speech-version-identifier-value-1:
indicates the permitted speech version.
An ASSIGNMENT REQUEST message is considered as an

example here. In this example, sp-data is 1 indicating that a
speech channel is required, rate is 8 indicating that the
required channel rate is full rate traffic channel (TCH)
channel Bm (ch-tyep-rate-bm), and permitted-speechversion-identifier-value-1 is 1 indicating that the permitted
speech version is GSM speech full rate version 1.
Reference Standards
For details, see 3.2.2.11 "Channel Type" in 3rd Generation Partnership Project (3GPP)
TS48008-840.

Cell Identifier
Reference Standards
Description
Identifies a cell covered by the base station
subsystem (BSS).
In handover procedures, two types of cell identifier
are introduced: cell-identifier-serving for the source
cell and cell-identifier-target for the target cell.
cell-identifier-serving consists of the following fields:
spare4: indicates whether the whole or a
part of Cell Global Identification (CGI) is
used for source cell identification.
0: The whole CGI is used to
identify the source cell.
1: The Location Area Identification
(LAI) is used to identify the source
cell.
2: The Cell Identity (CI) is used to
identify the source cell.
gci: provides source cell identification in the
selected form.
Cell Identifier
A HANDOVER REQUEST message is considered as

an example here. In this example, spare4 is 0
indicating that CGI is used to identify the source cell,
and gci (CGI of the source cell) is 4607100010001.
cell-identifier-target consists of the following fields:

spare4: indicates whether the whole or a
part of CGI is used for target cell
identification.
0: The whole CGI is used to
identify the target cell.
1: The LAI is used to identify the
target cell.
2: The CI is used to identify the
target cell.
gci: provides target cell identification in the
selected form.
A HANDOVER REQUEST message is considered as

an example here. In this example, spare4 is 0
indicating that CGI is used to identify the target cell,
and gci (CGI of the target cell) is 4607200010001.
Reference Standards
For details, see 3.2.2.17 "Cell Identifier" in 3rd Generation Partnership Project (3GPP)
TS48008-840.
Priority
Reference Standards
Description
Indicates the priority of the request. This IE contains a few
fields, including:
Priority
priority-level: indicates the priority level.

preemption-Capability-Indicator: indicates
whether this allocation request can preempt an
existing connection. This field is encoded as 1 to
allow preemption, and as 0 to disallow
preemption.
queuing: indicates whether this allocation request
can be queued.
preemption-Vulnerability-indicator: indicates
whether the connection used by this allocation
request can be preempted by another allocation
request. This field is encoded as 1 to indicate that
this allocation request can be the target of
preemption, and as 0 to indicate otherwise.
An ASSIGNMENT REQUEST message is considered as

an example here. In this example, preemption-Capabilityindicator is 0 indicating that this allocation request cannot
preempt an existing connection, priority-level is 12
indicating that this allocation request is assigned priority
level 12, queuing is 1 indicating that this allocation request
can be queued, and preemption-Vulnerability-indicator is 0
indicating that the connection used by this allocation
request cannot be preempted.
Reference Standards
For details, see 3.2.2.18 "Priority" in 3rd Generation Partnership Project (3GPP) TS48008840.

Reference Standards
Information
Element (IE)
Description
Provides the network with information concerning aspects of both high and
low priority of the MS.
This IE is conveyed in a connection management (CM) SERVICE
REQUEST or UE-originated LOCATION UPDATING REQUEST message.
It contains a few fields, including:
voice-group-call-service: indicates MS support for Voice Group
Call Service (VGCS) notification reception.
voice-broadcast-service: indicates MS support for Voice
Broadcast Service (VBS) notification reception.
short-message-capability: indicates MS support for mobile
terminated point-to-point short message service (SMS).
supplement-service-screen: indicates MS support for
supplementary service screening.
cm-service-prompt: indicates MS support for CM Service Prompt
(also called CCBS).
universal-character-set-2: indicates MS support for Universal
Character Set 2 (UCS2).
location-service-capability: indicates MS support for location
request notification.
classmark3-indicator: indicates MS support for options indicated
in Mobile Station Classmark 3.
Classmark
Information
Type 2
A CM SERVICE REQUEST message is considered as an example here.

In this example, voice-group-call-service is 0 indicating that no VGCS
capability or no notifications are wanted, and voice-broadcast-service is 0
indicating that no VBS capability or no notifications are wanted.
Reference Standards

Reference Standards
Description
Defines the terrestrial channel over which the call will pass.
Circuit identity code = pcm-multiplex-in-use x 32 + actualtimeslot-in-use, where:
pcm-multiplex-in-use: defines the pulse code
modulation (PCM) multiplex in use.
actual-timeslot-in-use: defines the number of the
timeslot assigned to the circuit.

example here. In this example, pcm-multiplex-in-use is 0
indicating that PCM multiplex 0 is in use, and actualtimeslot-in-use is 0x1 indicating that timeslot 1 within PCM
is activated. So, the circuit identity code is 1 (0x32 + 1 =
1).
Reference Standards
For details, see 3.2.2.2 "Circuit Identity Code" in 3rd Generation Partnership Project
(3GPP) TS48008-840.
RR Cause
Reference Standards
Description
Indicates the reason for a message to have been
sent.
Radio Resource (RR) Cause
An ASSIGNMENT COMPLETE message is

rr-cause is 0, indicating that sending of that
message is a normal event and does not result
from any errors.
Reference Standards
Layer 3 Information
Reference Standards
Description
Passes radio interface messages from one network entity to
another.
This IE conveys different messages, depending on
scenarios.
Layer 3 Information
In a GSM-to-UMTS inter-MSC handover, the Layer

3 Information IE conveys a HANDOVER TO
universal terrestrial radio access network (UTRAN)
COMMAND message.
In an intra-GSM-system inter-MSC handover, the
Layer 3 Information IE conveys a Radio Resource
(RR) HANDOVER COMMAND message.
In a GSM-to-cdma2000 inter-MSC handover, the
Layer 3 Information IE conveys a HANDOVER TO
CDMA2000 COMMAND message.
A HANDOVER COMMAND message in an intra-GSMsystem inter-MSC handover is considered as an example

here. In this example, L3info is 09 06 26 00 00 00 00 00 00
00, indicating that the Layer 3 Information IE conveys an RR
HANDOVER COMMAND message.
Reference Standards
For details, see 3.2.1.10 "Layer 3 Information" in 3rd Generation Partnership Project
(3GPP) TS48008-840.

Reference Standards
Information
Element (IE)
Description
Identifies a list of cells.
choice-by-cell-identification-discriminator: indicates whether the
whole or a part of Cell Global identification (CGI) is used for
cell identification of the cells in the list.
0: The whole CGI is used to identify the cells in the
list.
1: A combination of Location Area Code (LAC) and
Cell Identity (CI) is used to identify the cells in the list.
2: The CI is used to identify the cells in the list.
3: The Location Area Identification (LAI) is used to
identify all cells within a location area.
lai: identifies the location area where the MS is presently
located.
A PAGING message is considered as an example here. In this example,

choice-by-cell-identification-discriminator is 4 indicating that LAI is used
to identify all cells within the current location area, and lai is 460710001
indicating that the MS is presently located in location area 460710001.
Reference Standards
For details, see 3.2.2.27 "Cell Identifier List" in 3rd Generation Partnership Project (3GPP)
TS48008-840.


Reference Standards
Information Element
Description
(IE)
Provides the network with information concerning aspects of high
priority of the MS. This IE affects the manner in which the network
handles the operation of the MS. It contains a few fields, including:
Classmark Information
Type 1
rf-power-capability: indicates the radio frequency (RF)

power capability of the frequency band used. It is
dimensioned into five classes.
a51-alrorithm-indicator: indicates whether the MS supports
the encryption algorithm A5/1. The MS should set this
indicator to 0 if the A5/1 algorithm is supported, and to 1
otherwise.
early-classmark-send: indicates whether "Controlled Early
Classmark Sending" option is implemented in the MS. The
MS should set this indicator to 1 if "Controlled Early
Classmark Sending" option is supported, and to 0
otherwise.
revision-level-indicator: indicates the protocol version
supported by the MS. This IE takes a few values, for
example, value 0 for GSM phase 1, and value 2 for GSM
phase 2 mobile stations.

example here. In this example, rf-power-capability is 1 indicating
that RF power capability class 1 is applied, a51-alrorithm-indicator
is 0 indicating that the MS supports the A5/1 algorithm, earlyclassmark-send is 0 indicating that "Controlled Early Classmark
Sending" option is not implemented in the MS, and revision-levelindicator is 0 indicating that GSM phase 1 MS is used.
Reference Standards
Chosen Channel
Reference Standards
Information
Description
Element (IE)
Contains a description of the channel allocated to the MS.
This IE is included only when the base station subsystem (BSS) has
allocated a channel. It consists of the following fields:
channel-mode: indicates the mode of the allocated channel.
channel: indicates the data rate of the allocated channel.
Chosen
Channel
A HANDOVER REQUEST ACKNOWLEDGE message is considered as an

example here. In this example, channel-model is 13 indicating that channel
mode is data-36-kbits-radio-interface, and channel is 4 indicating that the
channel rate is eight-full-rate-tchs.
Reference Standards
For details, see 3.2.2.33 "Chosen Channel" in 3rd Generation Partnership Project (3GPP)
TS48008-840.

Reference Standards
Information Element
Description
(IE)
Indicates the encryption algorithm being used by the base station
subsystem (BSS).
This IE is included only when the BSS has chosen an encryption
algorithm.
Chosen Encryption
Algorithm
A CIPHER MODE COMPLETE message is considered as an
example here. In this example, chosen-encryption-algorithm is 2,
indicating that the BSS has chosen GSM A5/1 algorithm.
Reference Standards
For details, see 3.2.2.44 "Chosen Encryption Algorithm" in 3rd Generation Partnership

Reference Standards
Information
Element (IE)
Description
Contains a description of the channel allocated to the MS. This IE
consists of the following fields:
channel-mode: indicates the mode of the allocated channel.
channel: indicates the data rate of the allocated channel.
Current Channel
Type 1
A HANDOVER REQUIRED message is considered as an example
here. In this example, channel-mode is 1 indicating that a speech (full
rate or half rate) channel is allocated, and channel is 8 indicating that
the channel rate is one-full-rate-tch.
Reference Standards
For details, see 3.2.2.49 "Current Channel Type 1" in 3rd Generation Partnership Project
(3GPP) TS48008-840.
Cause
Reference Standards
Information
Description
Element (IE)
Indicates the reason for a particular event to have occurred. This IE contains
the cause-value field.
Cause
A HANDOVER COMPLETE message is considered as an example here. In
this example, cause-value is 11, indicating that the message is sent because
the handover is successful.
Reference Standards
Speech Version
Reference Standards
Information Element
Description
(IE)
Indicates the speech version being used by the base station
subsystem (BSS).
Speech Version
An ASSIGNMENT COMPLETE message is considered as an
example here. In this example, speech-version-identifier is 1,
indicating that the BSS is using GSM speech full rate version 1.
Reference Standards
For details, see 3.2.2.51 "Speech Version" in 3rd Generation Partnership Project (3GPP)
TS48008-840.
eMLPP Priority
Reference Standards
Information Element
(IE)
Description
Contains the eMLPP priority of the call. This IE contains the callpriority field.
enhanced multi-level
precedence and
preemption (eMLPP)
Priority
A PAGING message is considered as an example here. In this

example, call-priority is 4, indicating that eMLPP priority level 1 is
applied to the call.
Reference Standards
For details, see 3.2.2.56 "eMLPP Priority" in 3rd Generation Partnership Project (3GPP)
TS48008-840.
IMSI
Reference Standards
Information
Element
Description
(IE)
Provides the International Mobile Subscriber Identity (IMSI).
IMSI
type-of-identity: indicates which type of identity information is
selected to identify the MS.
odd-or-even-ind: indicate whether the selected mobile identity type
consists of an odd or even number of digits.
imsi: indicates IMSI.
A PAGING message is considered as an example here. In this example, typeof-identity is 1 indicating that IMSI is selected to identify the MS, odd-or-evenind is 1, indicating that IMSI contains an odd number of digits, and IMSI is
4600007550009082.
Reference Standards
For details, see 3.2.2.6 "IMSI" in 3rd Generation Partnership Project (3GPP) TS48008840.
TMSI
Reference Standards
Description
TMSI
Provides the Temporary Mobile Subscriber Identity

(TMSI).
This IE is included in a PAGING message if the
network uses TMSI to page the MS.
A PAGING message is considered as an example
here. In this example, TMSI is 0x60340039.
Reference Standards
For details, see 3.2.2.7 "TMSI" in 3rd Generation Partnership Project (3GPP) TS48008840.

Reference Standards
Information Element
(IE)
Description
Provides the base station subsystem (BSS) with information that
must be included in the header of layer 3 messages over the
radio interface.
This IE is not included, unless otherwise required. It contains the
following fields, including:
Layer 3 Header
Information
protocol-discriminator: identifies the L3 protocol to which

the L3 message belongs.
ti-value: indicates the value of transaction identifier.
ti-flag: identifies whether the message sender or
receiver has assigned the transaction identifier (TI) value
to this transaction.

example here. In this example, protocol-discriminator is 6
indicating that the message belongs to the radio resource (RR)
protocol, and ti-value is 0 indicating that the transaction identifier
is 0.
Reference Standards
For details, see 3.2.2.9 "Layer 3 Header Information" in 3rd Generation Partnership Project
(3GPP) TS48008-840.
CSFB Indication
Reference Standards
Information
Description
Element (IE)
Indicates that the radio connection is established in a circuit switched fallback
(CSFB) procedure.
Cause
CSFB Indication: Indicates the cause IE.
A CLEAR_COMMAND message is used as an example.
Reference Standards
For details, see 3.2.2.121 in 48008-a60.

IE Description
Reference Standards
IE Description
IE
Description
Indicates that the MSC server is required to initiate
a Multi-Operator Core Network (MOCN) flow for
the current call.
The example message in the preceding figure is

Location updating request. If this message
contains the redirect-attempt-flag IE, the BSS
supports the MOCN feature but the mobile terminal
does not support the MOCN feature. In this case,
the MSC server must initiate a MOCN flow.
Reference Standards
For details, see section 3.2.2.111 "Redirect Attempt Flag" in 3GPP TS 48008-b40.
Iu-CS Interface Protocol

Description of the Iu-CS Interface Protocol
Description of the User Identity Messages
Description of the Messages Used in the RAB Assignment Flow
Description of the Encryption Mode Messages
Description of the Paging Messages
Description of the Messages Used in the Relocation Flow
Description of the Release Messages
Description of the Iu-CS Interface Protocol

Protocol Stack
Message List
The MSC/VLR communicates with the Universal Mobile Telecommunications System
(UMTS) Terrestrial Radio Access Network (UTRAN) through the Radio Access Network
Application Part (RANAP). Figure 1 shows the application of the RANAP.
Figure 1 Application of the RANAP

Protocol Stack
Figure 2 and Figure 3 show the protocol stack of the Iu interface.
Figure 2 Protocol stack of the Iu interface (ATM)
Figure 3 Protocol stack of the Iu interface (IP)
RANAP is the Signaling System No. 7 (SS7) user layer signaling protocol for the Iu
interface, which is between the UTRAN and the Core Network (CN). The MSC, serving as a
functional entity in the Circuit-Switched (CS) domain, interconnects with the UTRAN by using
the RANAP through the control plane of the Iu-CS interface.
The Iu-CS interface protocol includes the following:
1. Control plane: the control plane signaling RANAP and signaling bearer
2. User plane: the user plane protocol IuUP and data bearer
3. Control plane of the transmission network: the data bearer and control signaling
Access Link Control Application Part (ALCAP) and signaling bearer
Message List
Table 1 List of common user-network interface messages
Message
Direction
RAB ASSIGNMENT REQUEST MSC->RNC
RAB ASSIGNMENT
RESPONSE
RNC->MSC
SECURITY MODE COMMAND MSC->RNC
SECURITY MODE COMPLETE RNC->MSC
Function
This message is sent by the MSC to
the RNC to request the
establishment, modification, or
release of one or more Radio
Access Bearer (RAB) for a
subscriber.
This message is sent by the RNC to
report the outcome of the request
from the RAB ASSIGNMENT
REQUEST message.
trigger the integrity and ciphering
functions over the radio interface.
This message is sent by the RNC as
a successful response to a
SECURITY MODE COMMAND
message.
PAGING
MSC->RNC
Relocation Required
RNC->MSC
RELOCATION COMMAND
MSC->RNC
RELOCATION REQUEST
MSC->RNC
RELOCATION REQUEST
ACKNOWLEDGE
RNC->MSC
RELOCATION DETECT
RNC->MSC
RELOCATION COMPLETE
RNC->MSC
COMMON ID
MSC->RNC
IU RELEASE COMMAND
MSC->RNC
IU RELEASE COMPLETE
RNC->MSC

request the RNC to page a User
Equipment (UE).
This message is sent by the source
RNC to inform the MSC that a
relocation is to be performed.
the source RNC to inform that
resources for the relocation are
allocated in the target RNC.
request the target RNC to allocate
necessary resources for a
relocation.
This message is sent by the target
RNC to inform the MSC of the result
of the resource allocation for the
requested relocation.
This message is sent by the RNC to
inform the MSC that the UE has
detected a new channel but has not
switched to the new channel.
This message is sent by the target
RNC to inform the MSC that the
relocation is complete.
inform the RNC of the permanent
NAS UE identity and additional
information of a subscriber.
instruct the RNC to release all
resources related to the Iu
connection.
This message is sent by the RNC as
a response to the IU RELEASE
COMMAND message.
Parent topic: Iu-CS Interface Protocol


Information
Element (IE)
Description
Indicates the sender and receiver of a message.
Header
sender-mid: Indicates the number of the calling control unit

(CCU) module from which the message is sent.
sender-pid: Indicates the number of the internal processing
module that sends the message.
receiver-mid: Indicates the number of the CCU module to
which the message is sent.
receiver: Indicates the number of the internal processing
module that receives the message.
The Location Updating Request message is considered as an
example here. In this example, sender-mid is 22, which indicates the
number of the CCU module from which the message is sent; senderpid is 179, which indicates that the message is sent by the sccp
module, receiver-mid is 22, which indicates the number of the CCU
module to which the message is sent; receiver-pid is 141, which
indicates that the message is sent to the Radio Access Network
Application Part (RANAP) module. The message is sent from the sccp
module to the RANAP module on CCU module 22.
Indicates the SCCP connection and signaling point of the RNC.
Signaling Connection
Control Part (SCCP)
message identifier
sccp-connect-id: Identifies an SCCP connection.

spc-of-14-bit: Indicates the 14-bit signaling point code (SPC)
of the RNC.
ssn: Indicates the subsystem number.
The Location Updating Request message is considered as an
example here. This message indicates that the SCCP connection
number is 103, the SPC of the RNC is 0x2773, and the subsystem
number of the RNC is 142 (which indicates that the subsystem is
ranap).
Description of the User Identity Messages

COMMON ID
COMMON ID
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the MSC to inform the RNC of the permanent NAS UE identity and
additional information of a subscriber. Figure 1 shows the main IEs of the message.
Figure 1 COMMON ID message

Associated IEs
Description
Message Type
Uniquely identifies the message being sent. In

a COMMON ID message, Message type is
COMMON ID.
Permanent NAS UE Identity
Contains the international mobile subscriber

identity (IMSI) of a subscriber.
For details, see Permanent NAS UE Identity.
SNA Access Information
Provides information about the area(s) in the

PLMN(s) that the UE is authorized to access.
For details, see SNA Access Information.
Reference Standards
For details, see 9.1.24 "COMMON ID" in 3rd Generation Partnership Project (3GPP)
25413-801.
Parent topic: Description of the User Identity Messages
Description of the Messages Used in the RAB Assignment

Flow
RAB ASSIGNMENT REQUEST
RAB ASSIGNMENT RESPONSE
RAB ASSIGNMENT REQUEST

Message Function
Associated IEs
Reference Standards
Message Function
This message is sent from the MSC to the RNC to request the establishment, modification,
or release of one or more RABs for a UE. Figure 1 and Figure 2 show the IEs contained in
the radio access bearer (RAB) ASSIGNMENT REQUEST message.
Figure 1 RAB ASSIGNMENT REQUEST (carrying RABs To Be Setup Or Modified List)
Figure 2 RAB ASSIGNMENT REQUEST (carrying RABs To Be Released List)
Associated IEs
Description
RABs To Be Setup Or Modified List
Provides a list of the RABs to be set up or

modified.
For details, see RABs To Be Setup Or
Modified List.
RABs To Be Setup Or Modified Item IEs
Provides the detailed information about the

RABs to be set up or modified.
For details, see RABs To Be Setup Or
Modified Item IEs.
First Setup Or Modify Item
Indicates the first RAB to be set up or

modified.
For details, see First Setup Or Modify Item.
RAB ID
Indicates the ID of a RAB.

For details, see RAB ID.
NAS Synchronisation Indicator
Contains the transparent NAS information that

is transferred without interpretation in the
RNC.
For details, see NAS Synchronisation

Indicator.
RAB Parameters
Specifies the attributes of a RAB.

For details, see RAB Parameters.
User Plane Information
Contains the information about the user plane.

For details, see User Plane Information.
User Plane Mode
Indicates the mode of operation of the user

plane.
For details, see User Plane Mode.
UP Mode Versions
Indicates the versions of the selected user

plane modes that are required and supported
by the CN.
For details, see UP Mode Versions.
Transport Layer Information
Contains the information about the transport

layer.
For details, see Transport Layer Information.
Transport Layer Address
Indicates the IP address to be used for the

user plane transport.
For details, see Transport Layer Address.
Iu Transport Association
Indicates the association between a RAB and

the corresponding transport bearer.
For details, see Iu Transport Association.
RABs To Be Released List
Provides a list of the RABs to be released.

For details, see RABs To Be Released List.
RABs To Be Released Item IEs

RABs to be released.
For details, see RABs To Be Released Item
IEs.
Cause
Contains the cause of the release of a RAB.

Reference Standards
For details, see 9.1.3 "RAB ASSIGNMENT REQUEST" in 3rd Generation Partnership
Project (3GPP) 25413-801.
Parent topic: Description of the Messages Used in the RAB Assignment Flow

RAB ASSIGNMENT RESPONSE

Message Function
Associated IEs
Reference Standards
Message Function
This message is sent from the RNC to the MSC, carrying the outcome of the request from
the radio access bearer (RAB) ASSIGNMENT REQUEST message. Figure 1, Figure 2, and
Figure 3 show the IEs contained in the RAB ASSIGNMENT RESPONSE message.
Figure 1 RAB ASSIGNMENT RESPONSE (carrying RABs Setup Or Modified List)
Figure 2 RAB ASSIGNMENT RESPONSE (carrying RABs Released List)
Figure 3 RAB ASSIGNMENT RESPONSE (carrying RABs Failed To Release List)
Associated IEs
RABs Setup Or Modified List
Description
Provides a list of the established or modified
RABs.
For details, see RABs Setup Or Modified
List.
RABs Setup Or Modified Item IEs

established or modified RABs.
For details, see RABs Setup Or Modified
Item IEs.
RAB ID
Indicates the ID of a RAB.

RABs Released List
Provides a list of the released RABs.

For details, see RABs Released List.
RABs Released Item IEs

released RABs.
For details, see RABs Released Item IEs.
RABs Failed To Release List
Provides a list of the RABs that are not

successfully released.
For details, see RABs Failed To Release List.
RABs Failed To Release Item IEs

RABs that are not successfully released.
For details, see RABs Failed To Release Item
IEs.
Cause
Indicates the cause of the failure to release a

RAB.
Reference Standards
For details, see 9.1.4 "RAB ASSIGNMENT RESPONSE" in 3rd Generation Partnership
Parent topic: Description of the Messages Used in the RAB Assignment Flow
Description of the Encryption Mode Messages

SECURITY MODE COMPLETE

Message Function
Associated IEs
Reference Standards
Message Function
This message is sent from the MSC to the RNC to trigger the integrity and ciphering
functions over the radio interface. Figure 1 shows the main IEs of the message.
Figure 1 SECURITY MODE COMMAND message
Associated IEs
Description
Message Type

a SECURITY MODE COMMAND message,
Message type is SECURITY MODE
COMMAND.
Integrity Protection Information
Contains the integrity protection information,

including the key and available algorithms.
For details, see Integrity Protection
Information.
Contains the user data encryption information,

including the key and available algorithms.
Key Status
Indicates whether the key contained in a

SECURITY MODE COMMAND message is
new or used. The key status can be NEW or
OLD.
For details, see Key Status.
Reference Standards
For details, see 9.1.26 "SECURITY MODE COMMAND" in 3rd Generation Partnership
Parent topic: Description of the Encryption Mode Messages
SECURITY MODE COMPLETE

Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the RNC as a successful response to a SECURITY MODE
COMMAND message. Figure 1 shows the main IEs of the message.
Figure 1 SECURITY MODE COMPLETE message
Associated IEs
Description
Message Type

a SECURITY MODE COMPLETE message,
Message type is SECURITY MODE
COMPLETE.
Chosen Integrity Protection Algorithm
Indicates the integrity protection algorithm

being used by the RNC.
For details, see Chosen Integrity Protection
Algorithm.

by the RNC.
Reference Standards
For details, see 9.1.27 "SECURITY MODE COMPLETE" in 3rd Generation Partnership
Parent topic: Description of the Encryption Mode Messages
Description of the Paging Messages

PAGING
Paging response
PAGING
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the MSC to request the RNC to page a UE. Figure 1 shows the
Figure 1 PAGING message

Associated IEs
Information Element
(IE)
Description
Message Type
Uniquely identifies the message being sent. In a PAGING

message, Message type is PAGING.
CN Domain Indicator
Indicates the CN domain from which the message is sent or to

which the message is sent. The CN domain consists of the CS
domain and the Packet-Switched domain (PS domain).
For details, see CN Domain Indicator.
Permanent NAS UE
Identity
Indicates the permanent identity of a UE in the universal

terrestrial radio access network (UTRAN) and the CN.
Temporary UE Identity
Indicates a temporary identity of a UE in the UTRAN and the CN.

This IE is carried in the PAGING message only when the UE is
paged based on the temporary mobile subscriber identifier
(TMSI).
For details, see Temporary UE Identity.
Paging Area ID
Identifies the area where a PAGING message is to be

broadcast.
For details, see Paging Area ID.
Paging Cause
Indicates the cause for paging a UE.

For details, see Paging Cause.
Global CN-ID
Globally identify a CN.

For details, see Global CN-ID.
Reference Standards
For details, see 9.1.23 "PAGING" in 3rd Generation Partnership Project (3GPP) 25413801.
Parent topic: Description of the Paging Messages
Paging response
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the RNC to the MSC as a response to the paging request
message. Figure 1 shows the main IEs of the message.
Figure 1 Paging response message
Associated IEs
Description
Indicates the Layer 3 protocol to which the

Layer 3 messages belong.
Skip Indicator
Indicates whether the message is valid. If

Skip Indicator is 0, it indicates that the
message is valid. The invalid messages are
not processed.
Message Type
Uniquely identifies a message. Message Type

occupies one byte. In a PAGING RESPONSE
message, Message Type is 39.

ciphering key.
Number.
Spare Half Octet
Indicates the reserved half Octet.

Indicates Classmark2 of the UE.

For details, see Classmark Information Type
2.
Mobile Identity
Identifies a UE.
Reference Standards
For details, see 9.1.25 "Paging response" in 3rd Generation Partnership Project (3GPP)
44018-840.
Parent topic: Description of the Paging Messages
Description of the Messages Used in the Relocation Flow

RELOCATION REQUIRED
RELOCATION COMMAND
RELOCATION REQUEST
RELOCATION REQUEST ACKNOWLEDGE
RELOCATION DETECT
RELOCATION COMPLETE
RELOCATION REQUIRED
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the source RNC to inform the MSC that a relocation is to be
performed. Figure 1 shows the main IEs of the message.
Figure 1 RELOCATION REQUIRED message
Associated IEs
Description
a RELOCATION REQUIRED message,
Message Type
Message type is RELOCATION REQUIRED.

Relocation Type
Indicates whether the relocation of the

Serving Radio Network Subsystem (SRNS) is
to be executed with or without involvement of
the UE.
For details, see Relocation Type.
Cause
Indicates the cause of the relocation.

Source ID
Identifies the source for the relocation of the

SRNS.
For details, see Source ID.
Target ID
Identifies the target for the relocation of the

SRNS.
For details, see Target ID.
Source RNC To Target RNC Transparent

Container
Contains the information sent from the source

RNC to the target RNC.
For details, see Source RNC To Target RNC
Transparent Container.
Reference Standards
For details, see 9.1.9 "RELOCATION REQUIRED" in 3rd Generation Partnership Project
(3GPP) 25413-801.
Parent topic: Description of the Messages Used in the Relocation Flow
RELOCATION COMMAND
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the MSC to the source RNC to inform that resources for the
relocation are allocated in the target RNC. Figure 1 shows the main IEs of the message.
Figure 1 RELOCATION COMMAND message
Associated IEs
Description
Message Type

a RELOCATION COMMAND message,
Message type is RELOCATION COMMAND.
Target RNC To Source RNC Transparent

Container
Indicates the message that is transparently

sent from the target RNC to the source RNC.
For details, see Target RNC To Source RNC
L3 Information
Contains the radio interface message.

For details, see L3 Information.

For details, see RABs To Be Released List.

RABs to be released.
For details, see RABs To Be Released Item
IEs.
radio access bearer (RAB) ID
uniquely identifies a radio access bearer for a

UE. At present, RAB ID is set to 1.
Reference Standards
For details, see 9.1.12 "RELOCATION COMMAND" in 3rd Generation Partnership Project
(3GPP) 25413-801.
RELOCATION REQUEST
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the MSC to request the target RNC to allocate necessary
resources for a relocation. Figure 1 shows the main IEs of the message.
Figure 1 RELOCATION REQUEST message
Associated IEs
Description
Message Type

a RELOCATION REQUEST message,
Message type is RELOCATION REQUEST.
Identifies a UE in the universal terrestrial

radio access network (UTRAN) and the CN.
Cause
Indicates the cause of the relocation.

CN Domain Indicator
Indicates the CN domain from which the

message is sent or to which the message is
sent. The CN domain consists of the CS
domain and the PS domain.
For details, see CN Domain Indicator.
Source RNC To Target RNC Transparent

Container
Indicates an information element that is

produced by the source RNC and is
transmitted to the target RNC.
For details, see Source RNC To Target RNC
RABs To Be Setup List
Provides a list of the RABs to be established.

For details, see RABs To Be Setup List.
RABs To Be Setup Item IEs

RABs to be established.
For details, see RABs To Be Setup Item IEs.
Indicates the address of the transport layer.

Indicates the association between a radio

access bearer (RAB) and the corresponding
transport bearer.
Contains the integrity protection information.

Information.
Contains the data encryption information.

Iu Signalling Connection Identifier
Identifies an Iu connection between the CN

and the RNC.
For details, see Iu Signalling Connection
Identifier.
Reference Standards
For details, see 9.1.10 "RELOCATION REQUEST" in 3rd Generation Partnership Project
(3GPP) 25413-801.

RELOCATION REQUEST ACKNOWLEDGE

Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the target RNC to inform the MSC of the result of the resource
allocation for the requested relocation. Figure 1 shows the main IEs of the message.
Figure 1 RELOCATION REQUEST ACKNOWLEDGE message
Associated IEs
Description
Message Type

a RELOCATION REQUEST
ACKNOWLEDGE message, Message type is
RELOCATION REQUEST ACKNOWLEDGE.
Target RNC To Source RNC Transparent

Container
Indicates the message that is transparently

sent from the target RNC to the source RNC.
For details, see Target RNC To Source RNC
RABs Setup List
Provides a list of the established RABs.

For details, see RABs Setup List.
RABs Setup Item IEs

established RABs.
For details, see RABs Setup Item IEs.
RABs Failed To Setup List

RABs that are not successfully established.
For details, see RABs Failed To Setup List.

For details, see RABs To Be Setup List.

RABs to be established.
For details, see RABs To Be Setup Item IEs.
Indicates the address of the transport layer.

Indicates the association between a radio

access bearer (RAB) and the corresponding
transport bearer.
Contains the integrity protection information.

Information.
Contains the data encryption information.

Identifies an Iu connection between the CN
and the RNC.

For details, see Iu Signalling Connection
Identifier.
Reference Standards
For details, see 9.1.11 "RELOCATION REQUEST ACKNOWLEDGE" in 3rd Generation
Partnership Project (3GPP) 25413-801.
RELOCATION DETECT
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the target RNC to inform the MSC that the UE has detected a new
channel but has not switched to the new channel. Figure 1 shows the main IEs of the
message.
Figure 1 RELOCATION DETECT message

Associated IEs
Description
Message Type

a RELOCATION DETECT message,
Message type is RELOCATION DETECT.
Reference Standards
For details, see 9.1.13 "RELOCATION DETECT" in 3rd Generation Partnership Project
(3GPP) 25413-801.
RELOCATION COMPLETE
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the target RNC to inform the MSC that the relocation is complete.
Figure 1 RELOCATION COMPLETE message

Associated IEs
Description
Message Type

a RELOCATION COMPLETE message,
Message type is RELOCATION COMPLETE.
Reference Standards
For details, see 9.1.14 "RELOCATION COMPLETE" in 3rd Generation Partnership Project
(3GPP) 25413-801.
Description of the Release Messages

IU RELEASE COMMAND
IU RELEASE COMPLETE
IU RELEASE COMMAND
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the MSC to instruct the RNC to release all resources related to the
Iu connection. Figure 1 shows the IEs of the message.
Figure 1 IU RELEASE COMMAND message
Associated IEs
Description
Message Type
Uniquely identifies the message being sent. In a IU RELEASE

COMMAND message, Message type is IU RELEASE
COMMAND.
Cause
Indicates the cause of the release.

End Of CSFB
Indicates that the radio connection is established in a circuit

switched fallback (CSFB) procedure.
For details, see End Of CSFB.
Reference Standards
For details, see 9.1.7 "IU RELEASE COMMAND" in 3rd Generation Partnership Project
(3GPP) 25413-a70.
Parent topic: Description of the Release Messages
IU RELEASE COMPLETE
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by the RNC to inform the MSC that all the resources related to the Iu
connection are released. Figure 1 shows the IEs of the message.
Figure 1 IU RELEASE COMPLETE message

Associated IEs
Description
Message Type
Uniquely identifies the message being sent. In a IU

RELEASE COMPLETE message, Message type is IU
RELEASE COMPLETE.
Uniquely identifies a RAB for a UE. At present, RAB ID is

radio access bearer (RAB) ID set to 1.

RABs Released List
Provides a list of released RABs.

For details, see RABs Released List.
Provides the detailed information about the released RABs.

For details, see RABs Released Item IEs.
Reference Standards
For details, see 9.1.8 "IU RELEASE COMPLETE" in 3rd Generation Partnership Project
(3GPP) 25413-801.
Parent topic: Description of the Release Messages

Cause
CN Domain Indicator
Global CN-ID
Key Status
L3 Information
Message Type
MS Classmark 2
MS Classmark 3
Paging Area ID
Paging Cause
RAB ID
RAB Parameters
RABs Failed To Setup Item IEs
RABs Released List
RABs Setup Item IEs

RABs Setup List
Relocation Type
Source ID
Source RNC To Target RNC Transparent Container
Target ID
Target RNC To Source RNC Transparent Container
UP Mode Versions
User Plane Mode
End Of CSFB
Cause
Reference Standards
Information
Element
Description
(IE)
Indicates the reason for a particular event for the Radio Access Network
Application Part (RANAP) protocol.
Cause
cause: Indicates the cause IE.
radioNetwork: Indicates the specific reason.
The RELOCATION REQUIRED message is considered as an example here. In
this example, radioNetwork is 2, which indicates that the reason for the current
relocation is trelocoverall-expiry.
Reference Standards

Reference Standards
Information Element
Description
(IE)
Indicates the encryption algorithm being used by the RNC.
Chosen Encryption
Algorithm
chosenEncryptionAlgorithm: Indicates the encryption algorithm being

used by the RNC.
The SECURITY MODE COMPLETE message is considered as an
example here. In this example, chosenEncryptionAlgorithm is 1,
which indicates that the encryption algorithm used by the RNC is
standard-UMTS-encryption-algorithm-UEA1.
Reference Standards
For details, see 9.2.1.14 "Chosen Encryption Algorithm" in 3rd Generation Partnership

Reference Standards
Description
Indicates the integrity protection algorithm being used by the
RNC.
Chosen Integrity Protection

Algorithm
chosenIntegrityProtectionAlgorithm: Indicates the integrity

protection algorithm being used by the RNC.
The SECURITY MODE COMPLETE message is considered
as an example here. In this example,
chosenIntegrityProtectionAlgorithm is 0, which indicates that
the integrity protection algorithm being used by the RNC is
standard-UMTS-integrity-algorithm-UIA1.
Reference Standards
For details, see 9.2.1.13 "Chosen Integrity Protection Algorithm" in 3rd Generation
CN Domain Indicator
Reference Standards
Information
Element (IE)
Description
Indicates the CN domain from which the message is sent or to which
the message is sent.
The CN domain consists of the CS domain and the PS domain.
CN Domain
Indicator
cN-DomainIndicator: Indicates the CN domain.

The PAGING message is considered as an example here. In this
example, cN-DomainIndicator indicates that the PAGING message is
sent to the CS domain.
Reference Standards
For details, see 9.2.1.5 "CN Domain Indicator" in 3rd Generation Partnership Project
(3GPP) TS25413-801.
Reference Standards
Information
Element
Description
(IE)
Indicates the user data encryption information (key and available algorithms)
used to control any encryption equipment at the RNC.
Encryption
Information
permittedAlgorithms: Indicates the algorithm list.

EncryptionAlgorithm: Indicates the algorithm used for user data
encryption.
key: Indicates the key used for user data encryption.
The SECURITY MODE COMMAN message is considered as an example
here. The message indicates that the RNC uses the standard-UMTSencryption-algorith-UEA1 algorithm and the key contained in the message for
user data encryption.
Reference Standards
For details, see 9.2.1.12 "Encryption Information" in 3rd Generation Partnership Project
(3GPP) TS25413-801.


Reference Standards
Information Element
Description
(IE)
Indicates the first radio access bearer (RAB) to be established or
modified.
rAB-ID: Uniquely identifies a RAB for a UE. At present, it is

set to 1.
nAS-SynchronisationIndicator: Indicates the nAS
information transferred without interpretation in the RNC.
rAB-Parameters: Indicates the radio access bearer (rAB)
parameters.
userPlaneInformation: Provides the information about the
user plane.
transportLayerInformation: Provides the information about
the transport layer.
First Setup Or Modify

Item
The RAB ASSIGNMENT REQUEST message is considered as an

example here. In this example, rAB-ID is 1, which indicates that RAB
1 is the first RAB to be established or modified for the UE.
Reference Standards
Global CN-ID
Reference Standards
Information
Element (IE)
Description
Indicates the ID of the CN.
Global CN-ID contains the public land mobile network (PLMN) identity
and the CN ID.
Global CN-ID
pLMNidentity: Identifies a PLMN.
cN-ID: Identifies a CN. It is used to identify a CN in POOL
networking.
The PAGING message is considered as an example here. This
message indicates that the PLMN identity is 64 F0 37 and CN ID is 0.
Reference Standards
For details, see 9.2.1.46 "Global CN-ID" in 3rd Generation Partnership Project (3GPP)
TS25413-801.

Reference Standards
Information Element
Description
(IE)
Indicates the integrity protection information (key and available
algorithms).
Integrity Protection
Information
IntegrityProtectionInformation: Indicates the Integrity

Protection Information IE.
IntegrityProtectionAlgorithm: Indicates the available
algorithms.
key: Indicates the key used for integrity protection.
The SECURITY MODE COMMAND message is considered as an
example here. This message indicates that the standard-UMTSintergrity-alorithm-UIA1 algorithm and the key contained in the
message are used for data integrity protection.
Reference Standards
For details, see 9.2.1.11 "Integrity Protection Information" in 3rd Generation Partnership

Reference Standards
Description
Indicates the association between a radio access bearer
(RAB) and the corresponding transport bearer.
bindingID: Identifies the association between a RAB and the

corresponding transport bearer.
The RELOCATION REQUEST message is considered as an
example here. The message indicates that the ID of the
association between the RAB and the transport bearer is 01
1E 00 12.
Reference Standards
For details, see 9.2.2.2 "Iu Transport Association" in 3rd Generation Partnership Project
(3GPP) TS25413-801.
Key Status
Reference Standards
Information
Description
Element (IE)
Indicates whether the keys contained in a SECURITY MODE COMMAND
message are new or have been used.
Key Status
keyStatus: Indicates the status of the key.
The SECURITY MODE COMMAN message is considered as an example
here. In this message, keyStatus is 1, which indicates that the key contained
in message is new.
Reference Standards
For details, see 9.2.1.36 "Key Status" in 3rd Generation Partnership Project (3GPP)
TS25413-801.
L3 Information
Reference Standards
Description
Contains the information about the radio interface.
The contents of L3 Information vary according to the type of
the relocation.
In the case of 2G-to-3G inter-office relocation, L3
Information carries the HANDOVER TO universal
terrestrial radio access network (UTRAN)
COMMAND message.
In the case of 2G inter-office relocation or 3G-to-2G
relocation, L3 Information carries the radio resource
(RR) HANDOVER COMMAND message.
In the case of 2G-to-cdma2000 inter-office
relocation, L3 Information carries the HANDOVER
TO CDMA2000 COMMAND message.
L3 Information
The RELOCATION COMMAND message used in 3G-to-2G

intra-office relocation is considered as an example here. In this
example, l3-Information is 06 2B 00 2F 0D 00 2F 08 05 D8 63
21 93, which indicates the RR HANDOVER COMMAND
message.
Reference Standards
For details, see 9.2.1.31 "L3 Information" in 3rd Generation Partnership Project (3GPP)
TS25413-801.

Message Type
Reference Standards
Information
Element (IE)
Description
Uniquely identifies the message being sent.
It is mandatory for all messages.
Message Type
initiatingMessage: Indicate the type of message.
commonID: Indicates the specific message.
The COMMON ID message is considered as an example here. This
message indicates that the COMMON ID message is one of
initiatingMessage messages.
Reference Standards
For details, see 9.2.1.1 "Message Type" in 3rd Generation Partnership Project (3GPP)
TS25413-801.
MS Classmark 2
Reference Standards
Information
Element (IE)
Description
Indicates the access priority of a UE.
The CN implements the access of a UE based on the value of Classmark2.
MS Classmark
2
voice-group-call-service: Indicates whether the UE supports the

voice group call service.
voice-broadcast-service: Indicates whether the UE supports the
voice broadcast service.
short-message-capability: Indicates whether the UE supports the
short message service.
supplement-service-screen: Indicates whether the UE supports
supplementary services.
cm-service-prompt: Indicates whether the UE supports the
completion of calls to busy subscriber (CCBS) service.
universal-character-set-2: Indicates whether the UE supports ucs2
characters.
location-service-capability: Indicates whether the UE supports the
location service.
classmark3-indicator: Indicates whether the UE supports the

Classmark3 indicator.
The Relocation Required message is considered as an example here. In
this example, voice-group-call-service and voice-broadcast-service are 0,
which indicates that the UE does not support the voice group call service or
voice broadcast service.
Reference Standards
For details, see 9.2.1.26 "MS Classmark 2" in 3rd Generation Partnership Project (3GPP)
TS25413-801.
MS Classmark 3
Reference Standards
Description
Indicates the general features (for example, single mode or
dual mode) of a UE. The network operations vary according to
the value of MS Classmark 3.
MS Classmark 3
classmakr-information-type3:Classmark3
The Classmark Update message is considered as an example
here. In this example, classmakr-information-type3 is 60 14 54
00 00. The network obtains the information about the features
of the UE after analyzing this code stream, and then perform
the related operation.
Reference Standards
For details, see 9.2.1.27 "MS Classmark 3" in 3rd Generation Partnership Project (3GPP)
TS25413-801.

Reference Standards
Information
Element (IE)
Description
Contains the transparent NAS information that is transferred without
interpretation in the RNC.
NAS
Synchronisation
Indicator
nAS-SynchronisationIndicator: Indicates the transparent NAS

information that is transferred without interpretation in the RNC.
The radio access bearer (RAB) ASSIGNMENT REQUEST message is
considered as an example here. In this example, nASSynchronisationIndicator is 60, which indicates that the content of the
NAS message that is transferred without interpretation in the RNC is
60.
Reference Standards
For details, see 9.2.3.18 "NAS Synchronisation Indicator" in 3rd Generation Partnership
Paging Area ID
Reference Standards
Information
Element (IE)
Description
Indicates the area where a PAGING message is to be broadcast.
Paging Area ID can be a Location Area ID (LAI) or a Routing Area ID
(RAC).
Paging Area ID
LAI: Indicates that the PAGING message is to be broadcast in a location
area (LA).
The PAGING message is considered as an example here. In this example,
pLMNidentity is 64 F0 44 and location area code (lAC) is 00 44, which
indicate that the PAGING message is to be broadcast in LA 460440044.
Reference Standards
For details, see 9.2.1.21 "Paging Area ID" in 3rd Generation Partnership Project (3GPP)
TS25413-801.
Paging Cause
Reference Standards
Information Element
(IE)
Description
Indicates the cause for paging a UE.
Paging Cause
pagingCause: Indicates the reason for the paging.

example, pagingCause is 0, which indicates that the UE is paged
because an ordinary call is to be terminated.
Reference Standards
For details, see 9.2.3.3 "Paging Cause" in 3rd Generation Partnership Project (3GPP)
TS25413-801.

Reference Standards
Identifies a UE used in the universal terrestrial radio access
network (UTRAN) and the CN. The RNC uses this IE to find
other existing signaling connections of the same UE.
Permanent NAS UE
Identity
imsi: Indicates the international mobile subscriber

identity (IMSI).
imsi-content: Indicates the contents of the IMSI.
The COMMON ID message is considered as an example here.
In this example, imsi-content is 460881104008832, which
indicates that the IMSI of the subscriber is 460881104008832.
Reference Standards
For details, see 9.2.3.1 "Permanent NAS UE Identity" in 3rd Generation Partnership Project
(3GPP) TS25413-801.
RAB ID
Reference Standards
Information Element
(IE)
Description
Uniquely identifies a RAB for a UE. At present, RAB ID is set to 1.
Identifies a radio
access bearer (RAB).
rAB-ID: Indicates the ID of the RAB.
The IU RELEASE COMPLETE message is considered as an
example here. This message indicates that the UE uses RAB 1.
Reference Standards
For details, see 9.2.1.2 "RAB ID" in 3rd Generation Partnership Project (3GPP) TS25413801.
RAB Parameters
Reference Standards
Information Element
Description
(IE)
Indicate all RAB attributes.
radio access bearer

(RAB) Parameters
trafficClass: Indicates the type of application for which the
RAB service is optimized.
rAB-AsymmetryIndicator: Indicates asymmetry or
symmetry of the RAB and traffic direction.
The RAB ASSIGNMENT REQUEST message is considered as an
example here. In this example, trafficClass is 0, which indicates the
RAB is used for voice calls, and rAB-AsymmetryIndicator is 0, which
indicates that the RAB is symmetric and the traffic direction is
bidirectional.
Reference Standards
For details, see 9.2.1.3 "RAB Parameters" in 3rd Generation Partnership Project (3GPP)
TS25413-801.

Reference Standards
Information Element
(IE)
Description
Provides the detailed information about the RABs that are not
RABs Failed To
Release Item IEs
rAB-ID: Indicates the ID of the radio access bearer

(RAB).
cause: Indicates the reason for the release failure.
The RAB ASSIGNMENT RESPONSE message is considered as
an example here. In this example, rAB-ID is 1, which indicates the
ID of the RAB.
Reference Standards

Reference Standards
Information Element
Description
(IE)
Provides a list of the RABs that are not successfully released.
RABs Failed To
Release List
rAB-FailedItem: Indicates the specific RABs that are not
The radio access bearer (RAB) ASSIGNMENT RESPONSE
message is considered as an example here. The message
indicates that the RABs Failed To Release List contains only one
rAB-FailedItem.
Reference Standards
RABs Failed To Setup Item IEs

Reference Standards
Provides the detailed information about the RABs that are not
successfully established.
RABs Failed To Setup Item

IEs
rAB-ID: Indicates the ID of the radio access bearer

(RAB).
radioNetwork: Indicates the reason for the failure.
The RELOCATION REQUEST ACKNOWLEDGE message is
considered as an example here. In this message, rAB-ID is 3,
which indicates RAB 3 is not successfully established, and
radioNetwork is 30, which indicates that RAB 3 is not
established because the RAB ID is invalid.
Reference Standards

Reference Standards
Information Element
Description
(IE)
Provides a list of the RABs that are not successfully established.
RABs Failed To Setup

List
RAB-FailedList: Indicates the RABs Failed To Setup List IE.

rAB-FailedItem: Indicates the specific RABs that are not
successfully established.
considered as an example here. The message indicates that the
RABs Failed To Setup List contains only one rAB-FailedItem.
Reference Standards

Reference Standards
information element
(IE)
Description
Provides the detailed information about the released RABs.
RABs Released Item

IEs
rAB-ID: Indicates the radio access bearer (RAB) ID,

which is 1.
dL-GTP-PDU-SequenceNumber: Indicates the GTP-PDU
sequence number to be sent to the UE.
uL-GTP-PDU-SequenceNumber:: Indicates the GTP-PDU
sequence number to be sent to the SGSN.
example here. In this example, rAB-ID is 1, which indicates that the
ID of the current RAB is 1, and dL-GTP-PDU-SequenceNumber is
1, which indicates that the GTP-PDU sequence number to be sent
to the UE.
Reference Standards
For details, see 9.2.2.3 "DL GTP-PDU Sequence Number" in 3rd Generation Partnership
RABs Released List

Reference Standards
Information Element
(IE)
Description
Provides a list of the released RABs.
RABs Released List

rAB-ReleasedList-IuRelComp: Indicates the RABs
Released List IE.
rAB-ReleasedItem-IuRelComp: Indicates the specific
RABs that are released.
example here. The message indicates that the RABs Released
List contains only one rAB-ReleasedItem.
Reference Standards
RABs Setup Item IEs

Reference Standards
Information Element
(IE)
Description
Provides the detailed information about the established RABs.
RABs Setup Item IEs
rAB-ID: RABID. For details, see RAB ID.

considered as an example here. In this example, rAB-ID is 1,
which indicates that the ID of the radio access bearer (RAB) for
the UE is 1.
Reference Standards
RABs Setup List

Reference Standards
Information Element
Description
(IE)
Provides a list of the established RABs.
RABs Setup List

rAB-SetupList-RelocReqAck: Indicates the list of the
established RABs.
rAB-SetupItem-RelocReqAck: Indicates the specific RABs
that are successfully established.
RABs Setup List contains only one rAB-SetupItem.
Reference Standards

Reference Standards
Information Element
Description
(IE)
Provides the detailed information about the RABs that are
established or modified.
RABs Setup Or
Modified Item IEs
rAB-ID: Indicates the ID of the radio access bearer (RAB).

The RAB ASSIGNMENT RESPONSE message is considered as an
ID of the RAB for the UE is 1.
Reference Standards

Reference Standards
Information Element
Description
(IE)
Provides a list of the RABs that are established or modified.
RABs Setup Or
Modified List
rAB-SetupOrModifiedList: Indicates the list of the RABs
that are established or modified.
rAB-SetupOrModifiedItem: Indicates the specific RABs
that are established or modified.
The radio access bearer (RAB) ASSIGNMENT RESPONSE
message is considered as an example here. The message indicates
that the RABs Setup Or Modified List contains only one rABSetupOrModifiedItem.
Reference Standards

Reference Standards
Information Element
(IE)
Description
Provides the detailed information about the RABs to be released.
RABs To Be Released
Item IEs
rAB-ReleaseItem: Indicates the radio access bearer

(RAB) to be released.
rAB-ID: Indicates the ID of the RAB.
cause: Indicates the reason for the release.
The RAB ASSIGNMENT REQUEST message is considered as
an example here. In this example, rAB-ID is 1, which indicates the
Reference Standards

Reference Standards
Information Element
Description
(IE)
RABs To Be Released
List
rAB-ReleaseList: Indicates the list of the RABs to be
released.
rAB-ReleaseItem: Indicates the specific RABs to be
released.
The radio access bearer (RAB) ASSIGNMENT REQUEST
message is considered as an example here. The message
indicates that the RABs To Be Released List contains only one rABReleaseItem.
Reference Standards

Reference Standards
Information Element
Description
(IE)
Provides the detailed information about the RABs to be established.
RABs To Be Setup
Item IEs
rAB-ID: Indicates the ID of the radio access bearer (RAB).

nAS-SynchronisationIndication: Indicates the transparent
non-access stratum (NAS) information that is transferred
without interpretation in the RNC. For details, see NAS
Synchronisation Indicator.
rAB-Parameters: Indicates the radio access bearer (rAB)
parameters.
userPlaneInformation: Provides the information about the
user plane. For details, see User Plane Information.
Reference Standards
(3GPP) TS25413-801.

Reference Standards
Information
Element (IE)
Description
RABs To Be Setup
List
rAB-SetupList-RelocReq: Indicates the list of the RABs to be
established.
rAB-SetupItem-RelocReq: Indicates the specific RABs to be
established.
The RELOCATION REQUEST message is considered as an example
here. The message indicates that the RABs To Be Setup List contains
only one rAB-SetupItem.
Reference Standards
(3GPP) TS25413-801.

Reference Standards
Description
Provides the detailed information about the RABs to be
RABs To Be Setup Or
Modified Item IEs
The radio access bearer (RAB) ASSIGNMENT REQUEST

message is considered as an example here.
Reference Standards

Reference Standards
Information Element
Description
(IE)
Indicates the list of the RABs to be established or modified.
RABs To Be Setup Or
Modified List
rAB-SetupOrModifyList: Indicates the list of the RABs to
be established or modified.
rAB-SetupOrModifyItemFirst: Indicates the RABs to be
The radio access bearer (RAB) ASSIGNMENT REQUEST message
is considered as an example here. The message indicates that only
one RAB is contained in the list of the RABs to be established or
modified.
Reference Standards
Relocation Type
Reference Standards
Information
Element (IE)
Description
Indicates whether the relocation of the serving radio network system
(SRNS) is to be executed with or without involvement of the UE.
If Relocation Type is ue-involved, the RNC sends a handover
command to the UE to trigger the relocation. If Relocation Type is uenot-involved, the relocation is triggered through the Iur interface.
Relocation Type
relocationType: Indicates the type of the relocation.

The RELOCATION REQUIRED message is considered as an
example here. In this example, relocationType is 0, which indicates
that UE is not involved in the relocation, that is, the relocation is
triggered through the Iur interface.
Reference Standards
For details, see 9.2.1.23 "Relocation Type" in 3rd Generation Partnership Project (3GPP)
TS25413-801.

Reference Standards
Information Element
(IE)
Description
Indicates the area(s) in the PLMN(s) that the UE is authorized to
access.
SNA Access
Information
sNA-Access-Information: Indicates the SNA Access

Information IE.
authorisedPLMNs: Indicates the PLMN(s) that the UE is
authorized to access.
The COMMON ID message is considered as an example here. In
this example, pLMNidentity is 00 00 01, which indicates that the UE
is authorized to access the PLMN identified by 00 00 01.
Reference Standards
For details, see 9.2.3.24 "SNA Access Information" in 3rd Generation Partnership Project
(3GPP) TS25413-801.
Source ID
Reference Standards
Information Element
Description
(IE)
Indicates the ID of the source for the relocation of the serving radio
network system (SRNS). The source ID contains the information
about the public land mobile network (PLMN) and ID of the RNC.
Source ID

rNC_ID: Indicates the ID of the RNC.
example here. In this example, pLMNidentity is 64 F0 37, which
indicates that the ID of the PLMN is 46073, and rNC-ID is 73, which
indicates that the ID of the RNC on the access side is 73.
Reference Standards
For details, see 9.2.1.24 "Source ID" in 3rd Generation Partnership Project (3GPP)
TS25413-801.
Source RNC To Target RNC Transparent Container

Reference Standards
Information Element
(IE)
Description
Indicates an information element that is produced by the source
RNC and is transmitted to the target RNC.
Source RNC To Target

RNC Transparent
Container
relocationType: Indicates the type of the relocation.
example here. In this example, relocationType is 0, which
indicates that UE is not involved in the relocation, that is, the
relocation is triggered through the Iur interface.
Reference Standards
For details, see 9.2.1.28 "Source RNC To Target RNC Transparent Container" in 3rd
Generation Partnership Project (3GPP) TS25413-801.

Reference Standards
Description
Identifies an Iu connection between the CN and the RNC.
The value of Iu Signalling Connection Identifier is a string of a
maximum of 24 bits. The most significant bit of this IE
indicates the node that allocates resources for this connection.
Value:
Iu Signalling Connection
Identifier
1: Indicates that the resources for the Iu connection

are allocated by the CN.
0: Indicates that the resources for the Iu connection
are allocated by the RNC.
iuSignallingConnectionIdentifier: Indicates an Iu connection

between the CN and the RNC.
example here. The message indicates that the resources for
Iu connection FC 00 01 are allocated by the CN.
Reference Standards
For details, see 9.2.1.38 "Iu Signalling Connection Identifier" in 3rd Generation Partnership
Target ID
Reference Standards
Information
Element (IE)
Description
Identifies the target for the relocation of the serving radio network
system (SRNS).
The target ID can be the target RNC-ID (for 3G-3G relocation) or the
Cell Global ID (GCI) of the relocation target (in case of 3G-to-2G
relocation).
Target ID
targetID: Identifies the target for the relocation of the SRNS.
targetRNC-ID: Indicates that the target ID is the target RNCID.
lAI: Indicates the location area identity.
rNC-ID: Indicates the ID of the RNC.
The RELOCATION REQUIRED message for 3G-3G relocation is
target RNC is RNC 74 located in lAI 460740001.
Reference Standards
For details, see 9.2.1.25 "Target ID" in 3rd Generation Partnership Project (3GPP)
TS25413-801.
Target RNC To Source RNC Transparent Container

Reference Standards
Description
Indicates that the IE is an IE for information.

This IE is produced by the target RNC and transmitted to the
Target RNC To Source RNC source RNC.
Transparent Container
The RELOCATION COMMAND message is considered as an
example here.
Reference Standards
For details, see 9.2.1.30 "Target RNC To Source RNC Transparent Container" in 3rd
Reference Standards
Information
Element (IE)
Description
Indicates the temporary identity of a UE.
Temporary UE
Identity
tMSI: Indicates the temporary mobile subscriber identifier (TMSI) of

a UE.
example, tMSI is 60 34 00 69, which indicates that the TMSI of the
UE is 60 34 00 69.
Reference Standards
For details, see 9.2.3.2 "Temporary UE Identity" in 3rd Generation Partnership Project
(3GPP) TS25413-801.

Reference Standards
Information Element
(IE)
Description
Indicates the address to be used for Transport Network Control
Plane signaling to establish the transport bearer in the case of
transport bearer establishment with Access Link Control
Application Part (ALCAP).

transportLayerAddress: Indicates the address to be used in the
transport layer.
example here.
Reference Standards
For details, see 9.2.2.1 "Transport Layer Address" in 3rd Generation Partnership Project
(3GPP) TS25413-801.

Reference Standards
Contains the information about the transport layer.
Transport Layer
Information
transportLayInformation: Indicates the

transportLayInformation IE.
transportLayerAddress: Indicates the address to be
used in the transport layer.
bindlingID: Identifies the association between the radio
access bearer (RAB) and the corresponding transport
bearer.
The RAB ASSIGNMENT REQUEST message is considered as
an example here. The message contains the address to be
used in the transport layer and the ID of the association
between the RAB and the corresponding transport bearer.
Reference Standards
UP Mode Versions
Reference Standards
Information
Element (IE)
Description
Indicates the versions for the selected Iu user plane mode that are
required and supported by the CN.
UP Mode
Versions
uP-ModeVersions: Indicates the versions of the Iu user plane mode that

are required and supported by the CN.
The RELOCATION REQUEST message is considered as an example
here. This message indicates that the version of the Iu user plane mode
is 00 03.
Reference Standards
For details, see 9.2.1.19 "UP Mode Versions" in 3rd Generation Partnership Project
(3GPP) TS25413-801.

Reference Standards
Information Element
Description
(IE)
Contains the required user plane mode and user plane node
versions.
userPlaneInformation: Indicates the User Plane Information IE,

which contains the following information:
User Plane
Information
1. User Plane Mode: Indicates the user plane mode. For

details, see User Plane Mode.
2. UP Mode Versions: Indicates the versions for the selected
Iu user plane mode that are required and supported by
the CN. For details, see UP Mode Versions.
example here. In this example, userPlaneMode is 1, which indicates
that the user plane mode is support-mode-for-predefined-SDUsizes, and uP-ModeVersions is 00 03, which indicates the user plane
node version supported by the CN is 00 03.
Reference Standards
User Plane Mode

Reference Standards
Information
Element (IE)
Description
Indicates the mode of the requested operation of the Iu user plane.
User Plane
Mode
userPlaneMode: Indicates the mode of the requested operation of the Iu

user plane.
The RELOCATION REQUEST message is considered as an example here.
In this example, userPlaneMode is 1, which indicates that the mode of the
requested operation of the Iu user plane is support-mode-for-predefinedSDE-size.
Reference Standards
For details, see 9.2.1.18 "User Plane Mode" in 3rd Generation Partnership Project (3GPP)
TS25413-801.
End Of CSFB
Reference Standards
Information
Description
Element (IE)
Indicates that the radio connection is established in a circuit switched fallback
(CSFB) procedure.
End Of
CSFB
End Of CSFB: Indicates that a CSFB procedure is complete.

An IU_RELEASE_COMMAND message is used as an example.
Reference Standards
For details, see 9.2.1.111 in 25413-a70.
C/D Interface Protocol

Description of C/D Interface Protocol
Description of MSRN Management Messages
Description of Location Management Messages
Description of Subscriber Data Management Messages
Description of Authentication Messages
Description of SMS Management Messages
Description of SS Management Messages
Description of C/D Interface Protocol

Protocol Stack
Message List
The MSC interworks with the HLR. In this networking, the MSC/VLR communicates with the
HLR through Mobile Application Part (MAP). Figure 1 shows the application of the C/D
interface protocol.
Figure 1 Application of the C/D interface protocol

Protocol Stack
Figure 2 through Figure 4 show the protocol stack of the C/D interface.
Figure 2 Protocol stack of the C/D interface (non-peer-to-peer M3UA networking)
Figure 3 Protocol stack of the C/D interface (peer-to-peer M3UA networking)
Figure 4 Protocol stack of the C/D interface (M2UA networking)
The MAP messages are encoded in the ASN.1 format and encapsulated in the user data of
Transaction Capability Application Part (TCAP) messages. Figure 5 shows the message
structure.
Figure 5 MAP message structure
Message List
Table 1 List of common C/D interface messages
Message
MAP_SEND_ROUTING_INFORMATION_REQ
MAP_SEND_ROUTING_INFORMATION_CNF
MAP_PROVIDE_ROAMING_NUMBER_IND
MAP_PROVIDE_ROAMING_NUMBER_RSP
MAP_UPDATE_LOCATION_REQ
MAP_UPDATE_LOCATION_CNF
MAP_CANCEL_LOCATION_IND
MAP_CANCEL_LOCATION_RSP
Direction Function
MSC/VLR- This message is sent

>HLR
routing information of
This message is sent
HLRacknowledge the
>MSC/VLR
MAP_SEND_ROUTIN
HLRstation roaming numb
>MSC/VLR
MSC/VLR.
MSC/VLRacknowledge the
>HLR
MAP_PROVIDE_ROA
>HLR
request the location u
HLRacknowledge the MAP
>MSC/VLR
message.
HLRThis message is sent
>MSC/VLR cancel a location upda
MSC/VLR- acknowledge the MAP
>HLR
message.

>MSC/VLR insert the subscriber d
MSC/VLRMAP_INSERT_SUBSCRIBER_DATA_RSP
acknowledge the
>HLR
MAP_INSERT_SUBS
MSC/VLRMAP_PURGE_MS_REQ
location information of
>HLR
deletes the subscribe
MAP_PURGE_MS_CNF
>MSC/VLR acknowledge the MAP
MAP_SEND_AUTHENTICATION_INFO_REQ
>HLR
authentication set from
HLRMAP_SEND_AUTHENTICATION_INFO_CNF
acknowledge the
>MSC/VLR
MAP_SEND_AUTHEN
MAP_AUTHENTICATION_FAILURE_REPORT_REQ
>HLR
report the authenticat
HLRacknowledge the
MAP_AUTHENTICATION_FAILURE_REPORT_CNF
>MSC/VLR MAP_AUTHENTICATI
message.
MAP_READY_FOR_SHORT_MESSAGE_REQ
>HLR
of the subscriber reac
HLRMAP_READY_FOR_SHORT_MESSAGE_CNF
acknowledge the
>MSC/VLR
MAP_READY_FOR_S
MAP_PROVIDE_SUBSCRIBER_INFO_IND
>MSC/VLR information of the sub
MSC/VLRMAP_PROVIDE_SUBSCRIBER_INFO_RSP
acknowledge the
>HLR
MAP_PROVIDE_SUB
MSC/VLRMAP_PROCESS_UNSTRUCTURED_SS_REQUEST_REQ
unstructured supplem
>HLR
operation from the HL
HLRacknowledge the
MAP_PROCESS_UNSTRUCTURED_SS_REQUEST_CNF
>MSC/VLR MAP_PROCESS_UN
message.
MAP_UNSTRUCTURED_SS_REQUEST_IND
MAP_INSERT_SUBSCRIBER_DATA_IND
MAP_UNSTRUCTURED_SS_REQUEST_RSP
MAP_UNSTRUCTURED_SS_NOTIFY_IND
MAP_REGISTER_SS_REQ
MAP_REGISTER_SS_CNF
MAP_ACTIVATE_SS_REQ
MAP_ACTIVATE_SS_CNF
MAP_DEACTIVATE_SS_REQ
MAP_DEACTIVATE_SS_CNF
MAP_INTERROGATE_SS_REQ
MAP_INTERROGATE_SS_CNF
MAP_ERASE_SS_REQ
MAP_ERASE_SS_CNF
>MSC/VLR the HLR) to request th

acknowledge the
>HLR
MAP_UNSTRUCTURE

HLRthe HLR) to request a
>MSC/VLR
subscriber, in connect
>HLR
register data related t
>HLR
activate a supplement
>HLR
deactivate a suppleme
>HLR
interrogate a supplem
HLRacknowledge the MAP
>MSC/VLR
message.
>HLR
supplementary service
Parent topic: C/D Interface Protocol


Reference Standards
Information Element
Description
(IE)
Identifies a Mobile Application Part (MAP) dialog.
Dialogue ID
The MAP_SEND_ROUTING_INFORMATION_REQ message is

considered as an example here. In this example, ie-dialogue-id is
0x40a.
Identifies the functions of messages. It corresponds to the
operation code in the Transaction Capability Application Part
(TCAP) component.
Operation code
considered as an example here. In this example, ie-mapoperation-code is send-routing-information.
Reference Standards
For details, see 3rd Generation Partnership Project (3GPP) TS29002-870.
Description of MSRN Management Messages

Message Function
Associated IEs
Reference Standards
Message Function
The MAP_SEND_ROUTING_INFORMATION_REQ message is sent by the GMSC to
request the routing information of the callee from the HLR. Figure 1 shows the main IEs of
the message.
Figure 1 MAP_SEND_ROUTING_INFORMATION_REQ message
Associated IEs
Information Element
(IE)
Invoke Id
Description
Uniquely identifies an operation in a Mobile Application Part
(MAP) dialogue.
For details, see Invoke Id.

Interrogation Type
Indicate the interrogation type.

For details, see Interrogation Type.
GMSC or GSM service

control function
(gsmSCF) Address
Indicates the address of the GMSC or the gsmSCF.

For details, see GMSC or gsmSCF Address.
Mobile Station
International integrated Indicates the MSISDN of the subscriber.
services digital network
For details, see MSISDN.
(ISDN) Number
(MSISDN)
Network Signal Info
Indicates the network signal information.

For details, see Network Signal Info.
Supported Customized
Applications for Mobile Indicates which phases of CAMEL are supported in the VLR.
network Enhanced Logic For details, see Supported CAMEL Phases.
(CAMEL) Phases
Suppress terminating
CAMEL subscription
information (T-CSI)
Indicates whether to suppress the T-CSI information.

For details, see Suppress T-CSI.
Suppression of
Announcement
Indicates whether to suppress the announcements.

For details, see Suppression of Announcement.
Call Reference Number
Indicates the call reference number.

For details, see Call Reference Number.
Forwarding Reason
Indicates the reason for which the call is to be forwarded

For details, see Forwarding Reason.
Number of Forwarding
Indicates the number of times a call is forwarded.

For details, see Number of Forwarding.
Reference Standards
For details, see 10.1 "MAP_SEND_ROUTING_INFORMATION service" in 3rd Generation
Parent topic: Description of MSRN Management Messages
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_SEND_ROUTING_INFORMATION_CNF message is sent by the HLR to the
GMSC to acknowledge the MAP_SEND_ROUTING_INFORMATION_REQ message.
Figure 1 MAP_SEND_ROUTING_INFORMATION_CNF message
Associated IEs
Information Element
(IE)
Description
Invoke Id

(MAP) dialogue.
Mobile Station
International ISDN
Number (MSISDN)
Indicates the MSISDN of the subscriber.

(CAMEL) Phases
mobile station roaming
number (MSRN)
Indicates the roaming number.

For details, see MSRN.
Forwarding Data
Indicates the call forwarding data.

For details, see Forwarding Data.
visited mobile switching Indicates the address of the VMSC.

center (VMSC) address For details, see address of the VMSC.
Location Information
Indicates the location information.

For details, see Location Information.
Subscriber State
Indicates the status of the subscriber.

For details, see Subscriber State.
Reference Standards
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_PROVIDE_ROAMING_NUMBER_IND message is sent by the HLR to obtain the
mobile station roaming number (MSRN) from the terminating MSC. Figure 1 shows the main
IEs of the message.
Figure 1 MAP_PROVIDE_ROAMING_NUMBER_IND message
Associated IEs
Information Element
(IE)
Description
Invoke Id

(MAP) dialogue.
Indicates the IMSI of the subscriber.

international mobile
subscriber identity (IMSI) For details, see IMSI.
Mobile Station
International ISDN
Number (MSISDN)

GSM Bearer Capability
Indicates the GSM bearer capability.

For details, see GSM Bearer Capability.
Network Signal Info
Indicates the network signal information.

For details, see Network Signal Info.
Suppression Of
Announcement
Indicates whether to suppress the announcements.

For details, see Suppression of Announcement.
Indicates the call reference number.

For details, see Call Reference Number.
GMSC Address
Indicates the address of the GMSC.

For details, see GMSC Address.
Reference Standards
For details, see 10.2 "MAP_PROVIDE_ROAMING_NUMBER service" in 3rd Generation
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_PROVIDE_ROAMING_NUMBER_RSP message is sent by the terminating VLR
to the HLR to acknowledge the MAP_PROVIDE_ROAMING_NUMBER_IND message.
Figure 1 MAP_PROVIDE_ROAMING_NUMBER_RSP message
Associated IEs
Description
Invoke Id

(MAP) dialogue.
Roaming Number
Indicates the roaming number.

For details, see Roaming Number.
Indicates that the MAP_RELEASE_RESOURCES service is

ReleaseResourcesSupported supported at the visited mobile switching center (VMSC).
For details, see ReleaseResourcesSupported.
User error
Indicator the user error.

For details, see User error.
Provider error
Indicates a protocol-related error.

For details, see Provider error.
Reference Standards
Description of Location Management Messages

Message Function
Associated IEs
Reference Standards
Message Function
The MAP_UPDATE_LOCATION_REQ message is sent by the MSC/VLR to update the
location information in the HLR. Figure 1 shows the main IEs of the message.
Figure 1 MAP_UPDATE_LOCATION_REQ message
Associated IEs
Information Element
(IE)
Invoke Id
Description
(MAP) dialogue.

MSC Address
Indicates the MSC number involved when the location information

of the subscriber is updated.
For details, see MSC Address.
VLR number
Indicates the VLR number involved when the location information

of the subscriber is updated.
For details, see VLR number.
(CAMEL) Phases
Reference Standards
For details, see 8.1.2 "MAP_UPDATE_LOCATION service" in 3rd Generation Partnership
Parent topic: Description of Location Management Messages
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_UPDATE_LOCATION_CNF message is sent by the HLR to the VLR to
acknowledge the MAP_UPDATE_LOCATION_REQ message. Figure 1 shows the main IEs
of the message.
Figure 1 MAP_UPDATE_LOCATION_CNF message
Associated IEs
Information Element
(IE)
Description
Invoke Id

(MAP) dialogue.
HLR number
Indicates the integrated services digital network (ISDN) number

of an HLR that processes the location update.
For details, see HLR number.
Reference Standards
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_CANCEL_LOCATION_IND message is sent by the HLR to instruct the VLR to
delete the specified subscriber data. Figure 1 shows the main IEs of the message.
Figure 1 MAP_CANCEL_LOCATION_IND message
Associated IEs
Information Element
(IE)
Description
Invoke Id
(MAP) dialogue.

Cancellation Type
Indicates the reason of location cancellation.

For details, see Cancellation Type.
Reference Standards
For details, see 8.1.3 "MAP_CANCEL_LOCATION service" in 3rd Generation Partnership
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_CANCEL_LOCATION_RSP message is sent by the VLR to the HLR to
acknowledge the MAP_CANCEL_LOCATION_IND message. Figure 1 shows the main IEs
of the message.
Figure 1 MAP_CANCEL_LOCATION_RSP message
Associated IEs
Information Element
(IE)
Description
Invoke Id

(MAP) dialogue.
Reference Standards

Description of Subscriber Data Management Messages

MAP_INSERT_SUBSCRIBER_DATA_RSP
MAP_PURGE_MS_REQ
MAP_PURGE_MS_CNF
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_INSERT_SUBSCRIBER_DATA_IND message is sent by HLR to insert the
subscriber data to the VLR. Figure 1 shows the main IEs of the message.
Figure 1 MAP_INSERT_SUBSCRIBER_DATA_IND message
Associated IEs
Description
Invoke Id

(MAP) dialogue.
subscriber identity (IMSI)

Mobile Station International Indicates the MSISDN of the subscriber.

ISDN Number (MSISDN)
Category
Indicates the subscriber category.

For details, see Category.
Subscriber Status
Indicates the status of the subscriber.

For details, see Subscriber Status.
Bearer service List
Indicates the bearer service capability.

For details, see Bearer service List.
Teleservice List
Indicates the teleservice capability.

For details, see Teleservice List.
Forwarding information List
Indicates the call forwarding data of the subscriber.

For details, see Forwarding information List.
Call barring information List
Indicates the call barring information.

For details, see Call barring information List.
Closed user group (CUG)

information List
Indicates the CUG information.

For details, see CUG information List.
SS-Data List
Indicates the SS-Data information.

For details, see SS-Data List.
enhanced multi-level
Indicates the eMLPP subscription data.
precedence and preemption
(eMLPP) Subscription Data For details, see eMLPP Subscription Data.
MC-Subscription Data
Indicates the multicard service (MC) subscription data.

For details, see MC-Subscription Data.
Operator Determined
Barring General data
Indicates all the Operator Determined Barring categories that

may be applied to a subscriber registered in any public land
mobile network (PLMN).
For details, see Operator Determined Barring General data.
Operator Determined
Barring home public land
mobile network (HPLMN)
data

may be applied only to a subscriber registered in the HPLMN.
For details, see Operator Determined Barring HPLMN data.
Indicates the roaming restriction for the features that are not
Roaming Restriction Due To supported.

Unsupported Feature
For details, see Roaming Restriction Due To Unsupported
Feature.
Regional Subscription Data
Indicates the regional subscription data.

For details, see Regional Subscription Data.
VLR Customized
Indicates the CAMEL subscription information.
Applications for Mobile
network Enhanced Logic
For details, see VLR CAMEL Subscription Info.
(CAMEL) Subscription Info
Reference Standards
For details, see 8.8.1 "MAP_INSERT_SUBSCRIBER_DATA service" in 3rd Generation
Parent topic: Description of Subscriber Data Management Messages
MAP_INSERT_SUBSCRIBER_DATA_RSP
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_INSERT_SUBSCRIBER_DATA_RSP message is sent by the VLR to the HLR to
acknowledge the MAP_INSERT_SUBSCRIBER_DATA_IND message. Figure 1 shows the
Figure 1 MAP_INSERT_SUBSCRIBER_DATA_RSP message
Associated IEs
Description
Invoke Id

(MAP) dialogue.
Bearer service List
Indicates the bearer service capability.

For details, see Bearer service List.
Teleservice List
Indicates the teleservice capability.

For details, see Teleservice List.
Operator Determined
Barring General data

may be applied to a subscriber registered in any public land
mobile network (PLMN).
For details, see Operator Determined Barring General data.

Regional Subscription
Response
Indicates the regional subscription response.

For details, see Regional Subscription Response.
network Enhanced Logic
(CAMEL) Phases
Indicates which phases of CAMEL are supported in the VLR.

For details, see Supported CAMEL Phases.
Reference Standards
MAP_PURGE_MS_REQ
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_PURGE_MS_REQ message is sent by the VLR to instruct the HLR to remove
the location information of the specified subscriber. This message contains the international
mobile subscriber identity (IMSI) of the subscriber. Figure 1 shows the main IEs of the
message.
Figure 1 MAP_PURGE_MS_REQ message
Associated IEs
Description
Invoke Id

(MAP) dialogue.
IMSI

VLR number
Indicates the VLR number of the subscriber.

Reference Standards
For details, see 8.1.6 "MAP_PURGE_MS service" in 3rd Generation Partnership Project
(3GPP) TS29002-870.
MAP_PURGE_MS_CNF
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_PURGE_MS_CNF is sent by the HLR to the VLR to acknowledge the
MAP_PURGE_MS_REQ message. Figure 1 shows the main IEs of the message.
Figure 1 MAP_PURGE_MS_CNF message

Associated IEs
Description
Invoke Id

(MAP) dialogue.
Reference Standards
For details, see 8.1.6 "MAP_PURGE_MS service" in 3rd Generation Partnership Project
(3GPP) TS29002-870.

Description of Authentication Messages

MAP_SEND_AUTHENTICATION_INFO_RSP
MAP_AUTHENTICATION_FAILURE_REPORT_RSP
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_SEND_AUTHENTICATION_INFO_REQ message is sent by the VLR to request
authentication sets from the HLR. Figure 1 shows the main IEs of the message.
Figure 1 MAP_SEND_AUTHENTICATION_INFO_REQ message
Associated IEs
Information
Element (IE)
Description
Invoke Id
Uniquely identifies an operation in a Mobile Application Part (MAP)

dialogue.
International mobile Indicates the IMSI number of the subscriber.

subscriber identity
(IMSI)
Number of
requested vectors
Indicates the number of authentication sets to be requested.

For details, see Number of requested vectors.
Requesting node
type
Indicates the type of requesting node.

For details, see Requesting node type.
Indicates if the VLR allows segmentation of the response at MAP

Segmentation
user level.
prohibited indicator
For details, see Segmentation prohibited indicator.
Reference Standards
For details, see 8.5.2 "MAP_SEND_AUTHENTICATION_INFO service" in 3rd Generation
Parent topic: Description of Authentication Messages
MAP_SEND_AUTHENTICATION_INFO_RSP
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_SEND_AUTHENTICATION_INFO_RSP message is sent by the HLR to the VLR
to acknowledge the MAP_SEND_AUTHENTICATION_INFO_REQ message. Figure 1
Figure 1 MAP_SEND_AUTHENTICATION_INFO_RSP message
Associated IEs
Information
Element (IE)
Description
Invoke Id

dialogue.
AuthenticationSetList
Indicates a list of authentication sets.

For details, see AuthenticationSetList.
Reference Standards
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_AUTHENTICATION_FAILURE_REPORT_REQ message is sent by the VLR to
inform the HLR of the authentication failure. Figure 1 shows the main IEs of the message.
Figure 1 MAP_AUTHENTICATION_FAILURE_REPORT_REQ message
Associated IEs
Information
Description
Element (IE)
Invoke Id
Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue.

international
mobile
subscriber
identity (IMSI)
Failure cause
Indicates the reason for which an authentication failure occurs.

For details, see Failure cause.
Re-attempt
Indicates whether a failure occurs in a normal authentication attempt or in

an authentication re-attempt.
For details, see Re-attempt.
Access Type
Indicates the access type.

For details, see Access Type.
Rand
Indicates the specific AV that fails authentication.

For details, see Rand.
VLR number
Indicates the VLR number of the subscriber.

Reference Standards
For details, see 8.5.3 "MAP_AUTHENTICATION_FAILURE_REPORT service" in 3rd
MAP_AUTHENTICATION_FAILURE_REPORT_RSP
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_AUTHENTICATION_FAILURE_REPORT_RSP message is sent by the HLR to
the VLR to acknowledge the MAP_AUTHENTICATION_FAILURE_REPORT_REQ
message. Figure 1 shows the main IEs of the message.
Figure 1 MAP_AUTHENTICATION_FAILURE_REPORT_RSP message
Associated IEs
Information
Description
Element (IE)
Invoke Id
Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue.

Reference Standards
Description of SMS Management Messages

MAP_READY_FOR_SHORT_MESSAGE_RSP
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_READY_FOR_SHORT_MESSAGE_REQ message is sent by the MSC/VLR to
inform the HLR that the MS is reachable or the MS memory is available. Figure 1 shows the
Figure 1 MAP_READY_FOR_SHORT_MESSAGE_REQ message
Associated IEs
Information
Element (IE)
Invoke Id
Description
dialogue.

International
mobile subscriber
identity (IMSI)
Temporary mobile Indicates the TMSI of the subscriber.
subscriber
identifier (TMSI) For details, see TMSI.
Alert Reason
Indicates the alerting reason.

For details, see Alert Reason.
Alert Reason
Indicator
Indicates the alerting reason indicator.

For details, see Alert Reason Indicator.
Reference Standards
For details, see 12.4 "MAP-READY-FOR-SM service" in 3rd Generation Partnership
Parent topic: Description of SMS Management Messages
MAP_READY_FOR_SHORT_MESSAGE_RSP
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_READY_FOR_SHORT_MESSAGE_RSP message sent by the MSC/VLR to the
HLR to acknowledge the MAP_READY_FOR_SHORT_MESSAGE_REQ message. Figure
Figure 1 MAP_READY_FOR_SHORT_MESSAGE_RSP message
Associated IEs
Information
Element (IE)
Description
Invoke Id

dialogue.
Reference Standards
Parent topic: Description of SMS Management Messages
Description of SS Management Messages

MAP_PROCESS_UNSTRUCTURED_SS_REQUEST_REQ
MAP_PROVIDE_SUBSCRIBER_INFO_RSP
MAP_REGISTER_SS_REQ
MAP_REGISTER_SS_RSP
MAP_ACTIVATE_SS_REQ
MAP_ACTIVATE_SS_RSP
MAP_DEACTIVATE_SS_RSP
MAP_INTERROGATE_SS_RSP
MAP_ERASE_SS_REQ
MAP_ERASE_SS_RSP
MAP_PROCESS_UNSTRUCTURED_SS_REQUEST_REQ
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent between the MSC and the VLR, between the VLR and the HLR,
between the HLR and GSM service control function (gsmSCF) and between the HLR and
HLR to relay information to allow unstructured supplementary service operation. Figure 1
Figure 1 MAP_PROCESS_UNSTRUCTURED_SS_REQUEST_REQ message
Associated IEs
Information
Element (IE)
Description
Invoke Id

dialogue.
Unstructured
supplementary
service data
(USSD) Data
Coding Scheme
Indicates the coding scheme of the USSD data.

For details, see USSD Data Coding Scheme.
USSD String
Indicates the USSD character string.

For details, see USSD String.
Mobile Station
International ISDN Indicates the MSISDN of the subscriber.
Number
(MSISDN)
Reference Standards
For details, see 11.9 "MAP_PROCESS_UNSTRUCTURED_SS_REQUEST service" in 3rd
Parent topic: Description of SS Management Messages
Message Function
Associated IEs
Message Function
The MAP_PROCESS_UNSTRUCTURED_SS_REQUEST_CNF message is sent to
acknowledge the MAP_PROCESS_UNSTRUCTURED_SS_REQUEST_REQ message and
contains the unstructured supplementary service data (USSD) operation result. Figure 1
Figure 1 MAP_PROCESS_UNSTRUCTURED_SS_REQUEST_CNF message
Associated IEs
Information
Element (IE)
Description
Invoke Id

dialogue.
USSD Data
Coding Scheme

USSD String


Message Function
Associated IEs
Reference Standards
Message Function
The MAP_PROVIDE_SUBSCRIBER_INFO_IND message (that is, the PSI message) is
sent by the HLR to request the current location information of the subscriber from the
MSC/VLR. Figure 1 shows the main IEs of the message.
Figure 1 MAP_PROVIDE_SUBSCRIBER_INFO_IND message
Associated IEs
Information
Element (IE)
Description
Invoke Id

dialogue.
International
mobile subscriber
identity (IMSI)
Requested
information
Indicates the information to be requested.

For details, see Requested information.
Reference Standards
For details, see 8.3.4 "Provide Subscriber Info" in 3rd Generation Partnership Project
(3GPP) TS23018-810.
MAP_PROVIDE_SUBSCRIBER_INFO_RSP
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_PROVIDE_SUBSCRIBER_INFO_RSP message is sent by the MSC to the HLR
to acknowledge the MAP_PROVIDE_SUBSCRIBER_INFO_REQ message. Figure 1 shows
Figure 1 MAP_PROVIDE_SUBSCRIBER_INFO_RSP message
Associated IEs
Information
Element (IE)
Invoke Id
Description
dialogue.

Location
information
Indicate the subscription location information.

For details, see Location Information.
Reference Standards
For details, see 8.3.5 "Provide Subscriber Info ack" in 3rd Generation Partnership Project
(3GPP) TS23018-810.
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_UNSTRUCTURED_SS_REQUEST_IND message is sent by the invoking entity
(for example, the HLR) to request the information from the mobile subscriber, in connection
with the unstructured supplementary service data (USSD) service. This message is sent
between the GSM service control function (gsmSCF) and the HLR, the HLR and the VLR,
and between the VLR and the MSC. Figure 1 shows the main IEs of the message.
Figure 1 MAP_UNSTRUCTURED_SS_REQUEST_IND message
Associated IEs
Information
Element (IE)
Description
Invoke Id

dialogue.
USSD Data
Coding Scheme

USSD String

Alerting Pattern
Indicates the alerting pattern.

For details, see Alerting Pattern.
Reference Standards
For details, see 11.10 "MAP_UNSTRUCTURED_SS_REQUEST service" in 3rd Generation
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_UNSTRUCTURED_SS_REQUEST_RSP message is sent to acknowledge the
MAP_UNSTRUCTURED_SS_REQUEST_IND message and contains the unstructured
supplementary service data (USSD) operation result. Figure 1 shows the main IEs of the
message.
Figure 1 MAP_UNSTRUCTURED_SS_REQUEST_RSP message
Associated IEs
Information
Element (IE)
Description
Invoke Id

dialogue.
USSD Data
Coding Scheme

USSD String

Reference Standards
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_UNSTRUCTURED_SS_NOTIFY_IND message is sent by the invoking entity (for
example, the HLR) to request a notification to be sent to the mobile subscriber, in
connection with the unstructured supplementary service data (USSD) service. This message
is sent between the GSM service control function (gsmSCF) and the HLR, the HLR and the
VLR, and between the VLR and the MSC. Figure 1 shows the main IEs of the message.
Figure 1 MAP_UNSTRUCTURED_SS_NOTIFY_IND message
Associated IEs
Information
Element (IE)
Description
Invoke Id
dialogue.
USSD Data
Coding Scheme

USSD String

Alerting Pattern

Reference Standards
For details, see 11.11 "MAP_UNSTRUCTURED_SS_NOTIFY service" in 3rd Generation
MAP_REGISTER_SS_REQ
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_REGISTER_SS_REQ message is sent by the MSC/VLR to the HLR to register
data related to a supplementary service. Figure 1 shows the main IEs of the message.
Figure 1 MAP_REGISTER_SS_REQ message
Associated IEs
Information
Element (IE)
Invoke Id
Description
dialogue.

SS-Code
Indicates the supplementary service code registered by the subscriber.

For details, see SS-Code.
Basic service
Indicates the basic service registered by the subscriber.

For details, see Basic service.
Forwarded-to
number with
subaddress
Indicates the forwarded-to number which optionally includes a

subaddress.
For details, see Forwarded-to number with subaddress.
No reply condition Indicates the duration at which the call is not answered.
time
For details, see No reply condition time.
EMLPP default
priority
Indicates the enhanced multi-level precedence and preemption (eMLPP)

default priority level.
For details, see EMLPP default priority.
Long FTN
Supported
Indicates that the mobile station supports long forwarded-to numbers.

For details, see Long FTN Supported.
Reference Standards
For details, see 11.1 "MAP_REGISTER_SS service" in 3rd Generation Partnership Project
(3GPP) TS29002-870.
MAP_REGISTER_SS_RSP
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_REGISTER_SS_RSP message is sent by the HLR to the VLR to acknowledge
the MAP_REGISTER_SS_REQ message. Figure 1 shows the main IEs of the message.
Figure 1 MAP_REGISTER_SS_RSP message
Associated IEs
Information
Element (IE)
Description
Invoke Id

dialogue.
Forwarding
information

For details, see Forwarding information.
EMLPP default
priority
Indicates the enhanced multi-level precedence and preemption (eMLPP)

default priority level.
For details, see EMLPP default priority.
Reference Standards
(3GPP) TS29002-870.
MAP_ACTIVATE_SS_REQ
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_ACTIVATE_SS_REQ message is sent by the MSC/VLR to the HLR to activate a
supplementary service. Figure 1 shows the main IEs of the message.
Figure 1 MAP_ACTIVATE_SS_REQ message

Associated IEs
Information
Element (IE)
Description
Invoke Id

dialogue.
SS-Code

Basic service

Long FTN
Supported

Reference Standards
For details, see 11.3 "MAP_ACTIVATE_SS service" in 3rd Generation Partnership Project
(3GPP) TS29002-870.
MAP_ACTIVATE_SS_RSP
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_ACTIVATE_SS_RSP message is sent by the HLR to the MSC/VLR to
acknowledge the MAP_ACTIVATE_SS_REQ message. Figure 1 shows the main IEs of the
message.
Figure 1 MAP_ACTIVATE_SS_RSP message
Associated IEs
Information
Element (IE)
Description
Invoke Id

dialogue.
Forwarding
information

Call barring
information
For details, see Call barring information.
SS-Data
Indicates the supplementary service data.

For details, see SS-Data.
Reference Standards
(3GPP) TS29002-870.
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_DEACTIVATE_SS_REQ message is sent by the MSC/VLR to the HLR to
deactivate a supplementary service. Figure 1 shows the main IEs of the message.
Figure 1 MAP_DEACTIVATE_SS_REQ message

Associated IEs
Information
Element (IE)
Description
Invoke Id

dialogue.
SS-Code
Indicates the supplementary service code to be registered by the

subscriber.
Basic service
Indicates the basic service to be registered by the subscriber.

Reference Standards
For details, see 11.4 "MAP_DEACTIVATE_SS service" in 3rd Generation Partnership
MAP_DEACTIVATE_SS_RSP
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_DEACTIVATE_SS_RSP message is sent by the HLR to acknowledge the
MAP_DEACTIVATE_SS_REQ message. Figure 1 shows the main IEs of the message.
Figure 1 MAP_DEACTIVATE_SS_RSP message
Associated IEs
Information
Element (IE)
Description
Invoke Id

dialogue.
Forwarding
information

Call barring
information

For details, see Call barring information.
SS-Data
Indicates the supplementary service data.

For details, see SS-Data.
Reference Standards
For details, see 11.4 "MAP_DEACTIVATE_SS service" in 3rd Generation Partnership
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_INTERROGATE_SS_REQ message is sent by the MSC/VLR to the HLR to
interrogate the supplementary service. Figure 1 shows the main IEs of the message.
Figure 1 MAP_INTERROGATE_SS_REQ message
Associated IEs
Information
Element (IE)
Description
Invoke Id

dialogue.
SS-Code

Long FTN
Supported

Basic service

Reference Standards
For details, see 11.5 "MAP_INTERROGATE_SS service" in 3rd Generation Partnership
MAP_INTERROGATE_SS_RSP
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_INTERROGATE_SS_RSP message is sent by the HLR to acknowledge the
MAP_INTERROGATE_SS_REQ message. It carries the interrogateSS operation result.
Figure 1 MAP_INTERROGATE_SS_RSP message

Associated IEs
Information
Element (IE)
Description
Invoke Id

dialogue.
SS-Status
Indicates the status of the supplementary service.

For details, see SS-Status.
Basic service
Group LIST
Indicates a list of basic service groups.

For details, see Basic service Group LIST.
Forwarding feature Indicates a list of call forwarding features.

LIST
For details, see Forwarding feature LIST.
Calling line
Indicate the CLI restriction information.
identification (CLI)
For details, see CLI restriction Info.
restriction Info
Enhanced multilevel precedence
and preemption
(EMLPP) Info
Indicates the EMLPP information.

For details, see EMLPP Info.
Reference Standards
MAP_ERASE_SS_REQ
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_ERASE_SS_REQ message is sent by the MSC/VLR to delete the supplementary
service data from the HLR. Figure 1 shows the main IEs of the message.
Figure 1 MAP_ERASE_SS_REQ message

Associated IEs
Information
Element (IE)
Description
Invoke Id

dialogue.
SS-Code

Basic service

Reference Standards
For details, see 11.2 "MAP_ERASE_SS service" in 3rd Generation Partnership Project
(3GPP) TS29002-870.
MAP_ERASE_SS_RSP
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_ERASE_SS_RSP message is sent by the HLR to acknowledge the
MAP_ERASE_SS_REQ message. Figure 1 shows the main IEs of the message.
Figure 1 MAP_ERASE_SS_RSP message
Associated IEs
Information
Element (IE)
Description
Invoke Id

dialogue.
Forwarding
information
Reference Standards
For details, see 11.2 "MAP_ERASE_SS service" in 3rd Generation Partnership Project
(3GPP) TS29002-870.

Access Type
Alert Reason
Alert Reason Indicator
Alerting Pattern
Basic service
Basic service Group LIST
Bearer service List
Call barring information
Cancellation Type
Category
CLI restriction Info
CUG information List
EMLPP default priority
EMLPP Info
eMLPP Subscription Data
Failure cause
Forwarded-to number with subaddress
Forwarding Data
Forwarding feature LIST
Forwarding information
Forwarding Reason
GMSC Address
GMSC or gsmSCF Address

HLR number
IMSI
Interrogation Type
Invoke Id
Long FTN Supported
MSC Address
MSC Number
MSISDN
MSRN
Network Signal Info
No reply condition time
Number of requested vectors
Operator Determined Barring General data
Operator Determined Barring HPLMN data
Provider error
Rand
Re-attempt
Regional Subscription Response
ReleaseResourcesSupported
Requested information
Requesting node type
Roaming Number
Roaming Restriction Due To Unsupported Feature

Segmentation prohibited indicator
SS-Code
SS-Data
SS-Data List
SS-Status
Subscriber State
Subscriber Status
Supported CAMEL Phases
Suppress T-CSI
Suppression of Announcement
Teleservice List
TMSI
User error
USSD Data Coding Scheme
USSD String
VLR CAMEL Subscription Info
VLR number
address of the VMSC
Access Type
Reference Standards
Information
Element (IE)
Description
Indicates the access type.
Values:
call: Indicates basic calls.
emergency call: Indicates emergency calls.
location updating: Indicates the location update.
supplementary service procedure: Indicates supplementary
services.
short message transfer: Indicates short messages.
Access Type
The MAP_AUTHENTICATION_FAILURE_REPORT_REQ message is

considered as an example here. In this example, accessType is
locationUpdating.
Reference Standards
Alert Reason
Reference Standards
Information
Element (IE)
Description
Indicates the reason why the short message service center is alerted.
Values:
ms Present: Indicates that the MS is present or reachable.
memoryAvaliable: Indicates that the MS has the available
memory.
Alert Reason
The MAP_READY_FOR_SHORT_MESSAGE_REQ message is

considered as an example here. In this example, alertReason is ms
Present, which indicates the MS is present or reachable.
Reference Standards
Alert Reason Indicator

Reference Standards
Information
Element (IE)
Description
Indicates that the alerting reason is sent to the HLR due to general
packet radio service (GPRS) activation.
Alert Reason
Indicator

considered as an example here. As long as the Alert Reason
Indicator IE is contained, the alerting reason is sent to the HLR at the
time of GPRS activation, regardless of the value of the Alert Reason
Indicator IE.
Reference Standards
Alerting Pattern
Reference Standards
Information
Element (IE)
Description
Indicates an alerting level or alerting category.
The meanings of the bits of the Alerting Pattern IE are as follows:
Bits 8-5: reserved
Bits 4 -3: Indicate the alerting level by 00 and the alerting
range by 01 or 10.
Bits 2-1: Indicate the alerting category.
Alerting Pattern
The MAP_UNSTRUCTURED_SS_REQUEST_IND message is

considered as an example here. In this example, alertPattern is 00,
which indicates the alerting level is 0.
Reference Standards
Reference Standards
Information Element
(IE)
Description
Indicates a list of authentication sets. Values:
TripletList (for GSM authentication): The triplet list
contains all the triplet authentication sets required by the
VLR.
QuintupletList (for Universal Mobile Telecommunications
System (UMTS) authentication): The quintuplet list
contains all the quintuplet authentication sets required by
the VLR.
SEQUENCE consists of the following parts:

rand: Indicates a random number used for authentication.
It is used as an input field for the other fields of the
authentication algorithm.
sres: Indicates the response to an authentication request.

It is used by the network side to authenticate the
subscriber.
kc: Indicates the key used for ciphering data during the
communication procedure.
The MAP_SEND_AUTHENTICATION_INFO_RSP message is
considered as an example here. In this example, rand is 27 E4 0A
15 AD 98 45 6A C3 41 70 4A D8 BA 86 2D; sres is 16 D3 87 07;
kc is 00 04 5C CC DD AF 6A FD.
Reference Standards
Basic service
Reference Standards
Information
Element (IE)
Description
Indicates the basic services registered by the subscriber.
Basic service
bearerService
teleservice
The MAP_REGISTER_SS_REQ message is considered as an example
here. In this example, bearerService is allBearerServices, which
indicates all the bearer services; teleservice is allTeleservices, which
indicates all the teleservices.
Reference Standards
(3GPP) TS29002-870.
Basic service Group LIST

Reference Standards
Information Element
Description
(IE)
Indicates a list of basic service groups.
Basic service Group

LIST
The MAP_REGISTER_SS_RSP message is considered as an
example here. In this example, bearerService is
allBearerServices, which indicates all the bearer services.
Reference Standards
Bearer service List

Reference Standards
Information
Element (IE)
Description
Indicates a list of extensible bearer services.
Bearer service List
BEARER-SERVICE-04: Indicates a type of bearer service.

The MAP_INSERT_SUBSCRIBER_DATA_IND message is considered
as an example here. In this example, BEARER-SERVICE-04 is
allAlternateSpeech-DataCDA, which indicates the allAlternateSpeechDataCDA is supported.
Reference Standards


Reference Standards
Information Element
Description
(IE)
Indicates the call barring information of the subscriber.
Call barring
information
SEQUENCE: Indicates a list of call barring information.

bearerService
The MAP_ACTIVATE_SS_RSP message is considered as an
example here. In this example, bearerService is allBearerServices,
which indicates all the bearer services.
Reference Standards
(3GPP) TS29002-870.

Reference Standards
Information Element
(IE)
Description
Indicates a list of extensible call barring information. It consists of
the following subordinate IEs:
ss-Code
callBarringFeatureList

List
ss-Code: Indicates the supplementary service code.

SEQUENCE: Indicates a list of call barring information.
The MAP-INSERT-SUBSCRIBER-DATA_IND message is
considered as an example here. In this example, ss-Code is
allSS, which indicates all the supplementary service codes.
Reference Standards

Reference Standards
Information Element
(IE)
Description
Indicates a reference number allocated by the GMSC during a call.
Call Reference Number The MAP_SEND_ROUTING_INFORMATION_REQ message is

callReferenceNumber is 17 10 5A 13 A0 74, which indicates that
the call reference number is allocated by the GMSC.
Reference Standards
Cancellation Type
Reference Standards
Information
Element (IE)
Description
Indicates the reason of location cancellation.
Cancellation Type
The MAP_CANCEL_LOCATION_REQ message is considered as an

example here. In this example, cancellationType is
subscriptionWithdraw, which indicates that the reason of location
cancellation is that the related subscriber data is deleted.
Reference Standards
Category
Reference Standards
Information
Element (IE)
Category
Description
Indicates the subscriber categories.
Invalid values include UNKNOWN, FRENCH, ENGLISH, GERMAN,
RUSSIAN, SPANISH, SPECIAL1SPECIAL2, SPECIAL3, RESERVE,
COMMON, SUPERIOR, DATACALL, TESTCALL, SPARE, PAYPHONE,
16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, COIN, 33,
and 34 through 254. Category is generally set to COMMON and the
meaning of each value can be determined by carriers.
The MAP-INSERT-SUBSCRIBER-DATA_IND message is considered as
an example here. In this example, category is 0A.
Reference Standards
CLI restriction Info

Reference Standards
Information
Element (IE)
Description
Indicates the CLI restriction information.
calling line
identification (CLI)
restriction Info
The MAP_INTERROGATE_SS_RSP message is considered as an

example here. In this example, cliRestrictionOption is permanent,
which indicates permanent restriction.
Reference Standards
CUG information List

Reference Standards
Information
Element (IE)
Description
Indicates a list of CUG information.
It includes:
CUG-SubscriptionList
CUG-FeatureList
Closed user group

(CUG) information
List
cug-SubscriptionList: Indicates the CUG subscription

information list.
cug-index: Indicates the CUG index.
cug-Interlock: Indicates the CUG interlock.
intraCUG-Options: Indicates the internal CUG options.
CUG-FeatureList: Indicates a list of CUG features.
interCUG-Restrictions: Indicates the inter-CUG restrictions.
The MAP-INSERT-SUBSCRIBER-DATA_IND message is considered

as an example here. In this example, cug-index is 0, which indicates
that the CUG index is 0; cug-Interlock is 00 00 00 00, which
indicates the CUG interlock information; intraCUG-Options is
noCUG-Restriction, which indicates no CUG restriction; interCUGRestrictions is cug-only-facilities, which indicates that only the CUG
device is used.
Reference Standards
EMLPP default priority

Reference Standards
Information
Element (IE)
Enhanced multi-level
precedence and
preemption
(EMLPP) default
priority
Description
Indicates the default EMLPP priority level.
The MAP_REGISTER_SS_REQ message is considered as an
example here. In this example, defaultPriority is 0, which indicates
the default priority level is 0.
Reference Standards
(3GPP) TS29002-870.
EMLPP Info
Reference Standards
Information
Element (IE)
Description
Indicates the EMLPP information.
precedence and
preemption
(EMLPP) Info
maximumentitledPriority
defaultPriority
example here. In this example, maximumentitledPriority is 0, which
indicates the maximum priority level is 0; defaultPriority is 0, which
indicates the default priority level is 0.
Reference Standards
eMLPP Subscription Data

Reference Standards
Information Element
Description
(IE)
Indicates the eMLPP subscription data, including:
precedence and
preemption (eMLPP)
Subscription Data
maximumentitledPriority
defaultPriority
The MAP-INSERT-SUBSCRIBER-DATA_RSP message is
maximumentitledPriority is 0, which indicates the maximum
priority level is 0; defaultPriority is 0, which indicates the default
priority level is 0.
Reference Standards
Failure cause
Reference Standards
Information
Element (IE)
Description
Indicates the reason for which an authentication failure occurs.
Values:
Wrong user response
Wrong network signature
Failure cause

example here. In this example, failureCause is
wrongUserResponse.
Reference Standards
Forwarded-to number with subaddress

Reference Standards
Information
Element (IE)
Description
Indicates the forwarded-to number.
Forwarded-to
number with
subaddress
nature-of-address-indicator
number
example here. In this example, nature-of-address-indicator is
international-number, which indicates that the number address
nature is international; number is 13907556789, which indicates the
forwarded-to number is 13907556789.
Reference Standards
(3GPP) TS29002-870.
Forwarding Data
Reference Standards
Information
Element (IE)
Description
Indicates the call forwarding data, including:
Forwarding Data
forwardedToNumber
content
forwardingOptions
forwarding-reason
The MAP_SEND_ROUTING_INFORMATION_CNF message is
considered as an example here. In this example, nature-of-addressindicator is international-number, which indicates that the number
address nature is international; content is 8613912340030, which
indicates the forwarded-to number is 13912340030; forwardingreason is ms-not-reachable, which indicates that the call is forwarded
at the reason of subscriber unreachable.
Reference Standards

Forwarding feature LIST

Reference Standards
Information
Element (IE)
Description
Indicates a list of call forwarding features.
A list of one or more forwarding features is returned by the responder
when the interrogation request applied to the call forwarding
supplementary service.
Forwarding feature
LIST
bearerService
forwardedToNumber
content
which indicates all the bearer services; nature-of-address-indicator
is international-number, which indicates that the number address
nature is international; content is 8613912340030, which indicates
the forwarded-to number is 8613912340030.
Reference Standards
Reference Standards
Information
Element (IE)
Description
Indicates the call forwarding information returned by the HLR after the
subscriber successfully registers the call forwarding service.
Forwarding
information
forwardindFeatureList
bearerService
forwardedToNumber
content
forwardingOptions
forwarding-reason
The MAP_REGISTER_SS_RSP message is considered as an
which indicates all the bearer services; nature-of-address-indicator
is international-number, which indicates that the number address
nature is international; content is 8613912340030, which indicates
the forwarded-to number is 8613912340030; forwarding-reason is
ms-not-reachable, which indicates that the call is forwarded at the
reason of subscriber unreachable.
Reference Standards
(3GPP) TS29002-870.

Reference Standards
Information Element
(IE)
Description
Indicates a list of call forwarding information.
List
forwardindFeatureList
bearerService
forwardedToNumber
content
forwardingOptions
forwarding-reason
The MAP_INSERT_SUBSCRIBER_DATA_RSP message is
considered as an example here. In this example, bearerService is
allBearerServices, which indicates all the bearer services;
nature-of-address-indicator is international-number, which
indicates that the number address nature is international; content
is 8613912340030, which indicates the forwarded-to number is
8613912340030; forwarding-reason is ms-not-reachable, which
indicates that the call is forwarded at the reason of subscriber
unreachable.
Reference Standards
Forwarding Reason
Reference Standards
Information Element
(IE)
Description
Indicates the reason for which the call is to be forwarded.
Values:
Forwarding Reason
Busy subscriber
Mobile subscriber not reachable
No subscriber reply
Call forwarded unconditionally
forwardingReason is notReachable, which indicates that the call
is forwarded because the subscriber is not reachable.
Reference Standards
GMSC Address
Reference Standards
Information
Element (IE)
Description
Indicates the address of the GMSC.
nature-of-address-indicator: Indicates the number address

nature.
content: Indicates the GMSC address.
GMSC Address
The MAP_PROVIDE_ROAMING_NUMBER_IND message is

address nature is international; content is 86139025, which indicates
that the GMSC address is 86139025.
Reference Standards
GMSC or gsmSCF Address

Reference Standards
Information
Element (IE)
Description
Indicates E.164 address of the GMSC or the gsmSCF. This
parameter contains the gsmSCF address if the Customized
Applications for Mobile network Enhanced Logic (CAMEL) service is
invoked; otherwise, it is the GMSC address.
GMSC or GSM
service control
function (gsmSCF)
Address
content
that the GMSC address is 86139025.
Reference Standards

Reference Standards
Information
Element (IE)
Description
Indicates the GSM bearer capability.
GSM Bearer
Capability
protocolId
signalInfo
considered as an example here. In this example, protocolId is gsm0408 and signalInfo is 04 09 A1 B8 19 88 20 15 6B 00 88.
Reference Standards
HLR number
Reference Standards
Information
Element (IE)
Description
Indicates the HLR number that is used for location update. The
updated location information of the subscriber is stored in the HLR.
HLR number
content
The MAP_UPDATE_LOCATION_CNF message is considered as an
nature is international; content is 861310751099, which indicates the
HLR number is 861310751099.
Reference Standards
IMSI
Reference Standards
Information
Element (IE)
Description
Indicates the IMSI number of the subscriber.
International mobile
content
subscriber identity
(IMSI)
considered as an example here. In this example, content is
460000000030183, which indicates the IMSI is 460000000030183.
Reference Standards
Interrogation Type
Reference Standards
Information
Element (IE)
Description
Indicates the interrogation type.
Values:
Basic call
Forwarding
Interrogation Type

considered as an example here. In this example, interrogationType
is basicCall, indicates that the interrogation type is basic call.
Reference Standards
Invoke Id
Reference Standards
Information
Element (IE)
Description
dialogue.
Invoke Id

considered as an example here. In this example, invoke-ID is 0x4e,
which indicates the invoking identifier of the MAP dialogue.
Reference Standards
Reference Standards
Information
Element (IE)
Description
Indicates the location information of the subscriber.
Location
Information
ageOfLocaltionInformation: Indicates the useful life of the

location information.
geographicalInformation: Indicates the geographical location
information.
vlr-number: Indicates the VLR number information.
nature.
content: Inidcates the VLR number.
ageOfLocaltionInformation is 0x0, which indicates that the useful life
of the location information is 0; geographicalInformation is 10 00 00
00 00 00 00 00 00; nature-of-address-indicator is internationalnumber, which indicates that the number address nature is
international; content is 861310751315.
Reference Standards
Long FTN Supported

Reference Standards
Information
Element (IE)
Description
Indicates whether to support the long forwarded-to number.

Long FTN Supported example here. In this example, longFTN-Supported is NULL. As
long as the Long FTN Supported IE is contained, the long forwardedto number is supported regardless of the value of the Long FTN
Supported IE.
Reference Standards
(3GPP) TS29002-870.
Reference Standards
Information
Element (IE)
Description
Indicates the subscription data related to the multicard service (MC)
service, including:
MC-Subscription
Data
nbrSB: Indicates the maximum number of parallel bearers

that may be used as defined by the user's subscription.
nbrUser: Indicates the maximum number of parallel bearers
that may be used as defined by the user at registration of
the MC supplementary service (SS).
considered as an example here. In this example, nbrSB is 0x2 and
nbrUser is 0x01.
Reference Standards

MSC Address
Reference Standards
Information
Element (IE)
Description
Indicates the MSC address.
content
MSC Address
The MAP_UPDATE_LOCATION_REQ message is considered as an

nature is international; content is 861310751315, which indicates that
the MSC address is 861310751315.
Reference Standards
MSC Number
Reference Standards
Information
Element (IE)
Description
Indicates the number of the MSC at which the subscriber resides.
content
MSC Number

that the MSC number is 86139025.
Reference Standards
MSISDN
Reference Standards
Information
Element (IE)
Description
Mobile Station
International ISDN
Number (MSISDN)
content
considered as an example here. In this example, nature-of-addressindicator is international-number. content is 8613912340183,
which indicates the MSISDN is 8613912340183.
Reference Standards
MSRN
Reference Standards
Information
Element (IE)
Description
Indicates the MSRN allocated by the MSC serving the callee.
mobile station
roaming number
(MSRN)
content
86139025399, which indicates the newly allocated MSRN. Generally,
this MSRN is in the same number segment as the MSC/VLR number.
Reference Standards
Network Signal Info

Reference Standards
Information
Element (IE)
Description
Indicates the network signal information, including the bearer
capability.
Network Signal Info

protocolId: Indicates the protocol type.
signalInfo: Indicates the bearer information.
considered as an example here. In this example, protocolid is ets300102-1, which indicates the ETS-300102-1 protocol; signalInfo is
04 03 88 90 A6, which indicates the bearer information.
Reference Standards
No reply condition time

Reference Standards
Information
Element (IE)
No reply condition
time
Description
Indicates the time at which the call is not answered. This parameter is
included if the registration applies to the Call Forwarding on No Reply
supplementary service.
example here. In this example, noReplyConditionTime is 0x05.
Reference Standards
(3GPP) TS29002-870.
Reference Standards
Information
Element (IE)
Number of
Forwarding
Description
Indicates the number of times the incoming calls are forwarded. This
parameter is present only when the callee has registered the call
forwarding supplementary service.
numberOfForwarding is 0x01.
Reference Standards

Reference Standards
Information Element
(IE)
Description
Indicates the number of authentication sets the new VLR is
prepared to receive from the HLR.
Number of requested
vectors
The MAP_SEND_AUTHENTICATION_INFO_REQ message is

numberOfRequestedVectors is 0x05.
Reference Standards
Operator Determined Barring General data

Reference Standards
Description
Indicates the Operator Determined Barring data that may be
applied to a subscriber registered in any public land mobile
network (PLMN).
Operator Determined Barring

General data
The MAP_INSERT_SUBSCRIBER_DATA_IND message is

considered as an example here.
Reference Standards

Operator Determined Barring HPLMN data

Reference Standards
Description
Indicates the Operator Determined Barring data that may be
applied only to a subscriber registered in the HPLMN.
Operator Determined Barring

home public land mobile
network (HPLMN) data
Reference Standards
Provider error
Reference Standards
Information
Element (IE)
Description
Indicates a protocol-related error.
Provider error

considered as an example here. In this example, ie-provider-error is
duplicated-invoke-id, which indicates the repeated invoking IDs
exist.
Reference Standards
Rand
Reference Standards
Information
Element (IE)
Description
Indicates the random number used for authentication.
Rand

considered as an example here. In this example, rand is 27 E4 0A 15
AD 98 45 6A C3 41 70 4A D8 BA 86 2D.
Reference Standards
Re-attempt
Reference Standards
Information
Element (IE)
Description
Indicates whether the failure occurs in a normal authentication attempt
or in an authentication re-attempt.
Re-attempt

considered as an example here. In this example, re-attempt is
FALSE, which indicates that the failure occurs in a normal
authentication attempt.
Reference Standards

Reference Standards
Information Element
Description
(IE)
Indicates the regional subscription area in which the subscriber is
allowed to roam.
Data
regionalSubscriptionData is 00 00.
Reference Standards
Regional Subscription Response

Reference Standards
Information Element
(IE)
Description
Indicates the response to the regional subscription data. Values:
Network Restriction, Too Many Zone Codes, Regional
Subscription Not Supported by the VLR or the SGSN, Zone
Codes Conflict
Response

regionalSubscriptionResponse is networkNodeAreaRestricted, indicates the reason for inserting the regional
subscription data.
Reference Standards
ReleaseResourcesSupported
Reference Standards
Description
Indicates that the MAP_RELEASE_RESOURCES service is
supported at the visited mobile switching center (VMSC).
ReleaseResourcesSupported The MAP_PROVIDE_ROAMING_NUMBER_RSP message is

releaseResourcesSupported is NULL, which indicates that
the VMSC supports the MAP_RELEASE_RESOURCES
service.
Reference Standards
Requested information
Reference Standards
Information
Element (IE)
Description
Indicates the subscription information requested by the HLR, including
one or more of the following:
Location information
Subscriber state
international mobile equipment identity (IMEI)
MS classmark
Requested
information
locationInformation: Indicates the location information.
subscriberState: Indicates the subscriber state.
The MAP_PROVIDE_SUBSCRIBER_INFO_IND message is considered
as an example here. In this example, locationInformation is NULL,
which indicates that the location information is requested by the HLR;
subscriberState is NULL, which indicates that the subscriber state is
requested by the HLR.
Reference Standards
For details, see 8.3.4 "Provide Subscriber Info" in 3rd Generation Partnership Project
(3GPP) TS23018-810.

Reference Standards
Information Element
(IE)
Description
Indicates the type of the requesting node, include VLR and SGSN.

requestingNodeType is vlr, which indicates the VLR at the CS
domain requests the authentication set.
Reference Standards
Roaming Number
Reference Standards
Information
Element (IE)
Description
Indicates the mobile station roaming number (MSRN) allocated by the
MSC serving the callee.
Roaming Number
The MAP_PROVIDE_ROAMING_NUMBER_RSP message is
86139025553, which indicates the MSRN allocated by the MSC
serving the callee is 86139025553.
Reference Standards
Roaming Restriction Due To Unsupported Feature

Reference Standards
Information
Element (IE)
Description
Indicates that the MSC/VLR performs roaming restriction because of
unsupported features.
Roaming Restriction
Due To Unsupported
Feature
roamingRestrictionDueToUnsupportedFeature is NULL.
Reference Standards

Reference Standards
Information Element
(IE)
Description
Indicates whether the new VLR allows segmentation of the
response at Mobile Application Part (MAP) user level.
Segmentation

segmentationProhibited is NULL, which indicates the new VLR
allows segmentation of the response at MAP user level.
Reference Standards
SS-Code
Reference Standards
Information
Element (IE)
Description
Indicates the supplementary service code registered by the mobile
subscriber.
SS-Code
example here. In this example ss-Code is allSS.
Reference Standards
(3GPP) TS29002-870.
SS-Data
Reference Standards
Information
Element (IE)
Description
Indicates the necessary set of information required to characterize the
supplementary service, for example, call hold, at the period of service
activation.
SS-Data
ss-Status: Indicates the supplementary service status.
a-bit: Indicates whether the supplementary service is activated.
ss-SubscriptionOption: Indicates the supplementary service
subscription option.
cliRestrictionOption: Indicates the command-line interface (CLI)
restriction option.
basicServiceGroupList: Indicates a list of basic service groups.
bearerService: Indicates bearer services.
teleservice: Indicates teleservices.
defaultPriority: Indicates the default priority.
nbrUser: Indicates the maximum number of parallel bearers that
may be used as defined by the user at registration of the
multicard service (MC) service.
The MAP_REGISTER_SS_REQ message is considered as an example
here. In this example, ss-Code is allSS; a-bit is not-active;
cliRestrictionOption is permanent; bearerService is
allBearerServices; teleservice is allTeleservices; defaultPriority is
0x0; nbrUser is 0x1.
Reference Standards
(3GPP) TS29002-870.
SS-Data List
Reference Standards
Information
Element (IE)
Description
Indicates a list of extensible SS-Data parameters.
SS-Data List
ss-Status: Indicates the supplementary service status.
a-bit: Indicates whether the supplementary service is
activated.
as an example here. In this example, ss-Code is allSS and a-bit is notactive.
Reference Standards
SS-Status
Reference Standards
Information
Element (IE)
Description
Indicates the status of the supplementary service.
SS-Status
a-bit: Indicates whether the supplementary service is
activated.
example here. In this example, a-bit is not-active.
Reference Standards
Subscriber State
Reference Standards
Information
Element (IE)
Description
Indicate the status of the subscriber.
Values:
Busy
Unreachable
Idle
Unknown
Subscriber State
assumedIdle: Indicates that the subscriber is in the idle

state.
considered as an example here. In this example, assumedIdle is
NULL, which indicates that the subscriber is in the idle state.
Reference Standards
Subscriber Status
Reference Standards
Information
Element (IE)
Subscriber Status
Description
Indicates whether the subscriber registers the Operator Determined
Barring service.
If not, the value of this IE is service granted; if yes, the value of this IE is
operatorDeterminedBarring.
considered as an example here. In this example, subscriberStatus is
service granted.
Reference Standards
Supported CAMEL Phases

Reference Standards
Information
Element (IE)
Description
Indicates which phases of CAMEL are supported
Supported
Customized
Applications for
Mobile network
Enhanced Logic
(CAMEL) Phases
phase4
considered as an example here. In this example, phase4 is 0x01,
which indicate the CAMEL phase 4 is supported.
Reference Standards
Suppress T-CSI
Reference Standards
Information
Element (IE)
Description
Indicates that the invocation of terminating Customized Applications
for Mobile network Enhanced Logic (CAMEL) services is suppressed,
that is, the HLR does not includes the T-CSI information in the SRIACK message.
Suppress
terminating CAMEL
subscription
information (T-CSI)
suppress-T-CSI
considered as an example here. In this example, suppress-T-CSI is
NULL, which indicates that the T-CSI information is suppressed.
Reference Standards
Suppression of Announcement
Reference Standards
Information Element
(IE)
Description
Indicates that the call failure announcement is suppressed.
Suppression of
Announcement

suppressionOfAnnouncement is NULL, which indicates the call
failure announcement is suppressed as long as the Suppression of
Announcement IE is contained.
Reference Standards
Teleservice List
Reference Standards
Information
Element (IE)
Description
Indicates a list of teleservices.
Teleservice List
TELE-SERVICE-04: Indicates a type of teleservice.

as an example here. In this example, TELE-SERVICE-04 is
emergencyCalls, which indicates the emergency call service is
supported.
Reference Standards
TMSI
Reference Standards
Information
Element (IE)
Description
Indicates the TMSI of the subscriber.

temporary mobile
subscriber identifier
(TMSI)
considered as an example here. In this example, tmsi is 60 38 00 07.
Reference Standards
User error
Reference Standards
Information
Element (IE)
Description
Indicates the user errors.
Values:
Unknown subscriber
Call restriction
Absent subscriber
Busy
No reply
System error
User error
The MAP_PROVIDE_ROAMING_NUMBER_RSP message is

considered as an example here. In this example, ie-user-error is
absent-subscriber, which indicates that the MS is powered off.
Reference Standards
USSD Data Coding Scheme

Reference Standards
Information
Element (IE)
Description

Unstructured
Supplementary
Service Data
The MAP_PROCESS_UNSTRUCTURED_SS_REQUEST_REQ
(USSD) Data Coding message is considered as an example here. In this example, ussdScheme
DataCodingScheme is 0F.
Reference Standards
USSD String
Reference Standards
Information
Element (IE)
Unstructured
Supplementary
Service Data
(USSD) String
Description
The MAP_PROCESS_UNSTRUCTURED_SS_REQUEST_REQ
message is considered as an example here. In this example, ussdString is AA 11 0E 37 02.
Reference Standards
VLR CAMEL Subscription Info

Reference Standards
Information Element
(IE)
Description
Indicates that the subscriber has registered the CAMEL service.
The contents of this IE vary according to the CAMEL phases.
In CAMEL phase 1, this IE contains only the originating
CAMEL subscription information (O-CSI).
In CAMEL phase 2, this IE may contain O-CSI,
supplementary service notification CAMEL subscription
information (SS-CSI) and translation information flag
CAMEL subscription information (TIF-CSI).
In CAMEL phase 3, this IE may contain O-CSI, dialed
services CAMEL subscription information (D-CSI), SSCSI, visited mobile switching center (VMSC) terminating
CAMEL subscription information (VT-CSI), mobile
origination short message service (MO-SMS-CSI),
mobility management event notification CAMEL
subscription information (M-CSI) and TIF-CSI.
In CAMEL phase 4, this IE may contain O-CSI, D-CSI,
SS-CSI, VT-CSI, MO-SMS-CSI, mobile termination short
message service camel subscription information (MTSMS-CSI), M-CSI and TIF-CSI.
VLR Customized
network Enhanced
Logic (CAMEL)
Subscription Info
originating camel subscription information (o-CSI):

Indicates the O-CSI information.
gsmSCF-Address: Indicates the address of the GSM
service control function (gsmSCF).
nature-of-address-indicator: Indicates the number
address nature.
content: Indicates the specific gsmSCF address.
considered as an example here. In this example, nature-ofaddress-indicator is international-number, which indicates that
the number address nature is international; content is 000000,
which indicates that the specific gsmSCF address is 000000.
Reference Standards
VLR number
Reference Standards
Information
Element (IE)
Description
Indicates the number of the VLR at which the subscriber resides.
content
VLR number
The MAP_UPDATE_LOCATION_REQ message is considered as an

nature is international; content is 861310751315, which indicates that
the specific VLR number is 861310751315.
Reference Standards
address of the VMSC

Reference Standards
Information
Element (IE)
Description
Indicates the number of the VMSC at which the subscriber resides.
visited mobile
switching center
(VMSC) address

nature.
content: Indicates the specific VMSC number.
address nature is international; content is 139000, which indicates that
the VMSC address is 139000.
Reference Standards
E/Nc Interface Protocol (Handover Management of MAP)

Description of the E/Nc Interface Protocol
Description of the E/Nc Interface Protocol

Protocol Stack
Message List
The MSC interworks with another MSC. In this networking, the MSC communicates with
another MSC through Mobile Application Part (MAP). Figure 1 shows the application of the
E/Nc interface protocol.
Figure 1 Application of the E/Nc interface protocol

Protocol Stack
Figure 2 through Figure 4 show the protocol stack of the E/Nc interface.
Figure 2 Protocol stack of the E/Nc interface (non-peer-to-peer M3UA networking)
Figure 3 Protocol stack of the E/Nc interface (peer-to-peer M3UA networking)
Figure 4 Protocol stack of the E/Nc interface (M2UA networking)
structure.
Message List
Table 1 List of common E/Nc interface messages
Message
Direction Function
MSC-A- This message is sent to hand

>MSC-B source MSC (MSC-A) to the
This message is sent by MSC
MSC-BMAP_PREPARE_HANDOVER_RSP
acknowledge the
>MSC-A
MAP_PREPARE_HANDOVER
MSC-B- transmit the received Relocat
MAP_PROCESS_ACCESS_SIGNALLING
>MSC-A Element (IE) (in the case of 2
indicating that the MS has det
MSC-B- transmit the received Relocat
MAP_SEND_END_SIGNAL_REQ
>MSC-A case of 2G network) to MSCinter-MSC handover is comple
MSC-B- This message is sent by MSC
MAP_SEND_END_SIGNAL_RSP
>MSC-A MSC MAP resources and rele
MSC-BMAP_PREPARE_SUBSEQUENT_HANDOVER_REQ
that a handover or relocation
>MSC-A
third MSC is required.
MSC-A- MAP_PREPARE_SUBSEQUE
MAP_PREPARE_SUBSEQUENT_HANDOVER_RSP
>MSC-B message and inform MSC-B o
MAP_PREPARE_HANDOVER_REQ
subsequent handback and res

Parent topic: E/Nc Interface Protocol (Handover Management of MAP)

Reference Standards
Information Element
Description
(IE)
Identifies a Mobile Application Part (MAP) dialogue.
Dialogue ID
The MAP_PREPARE_HANDOVER_REQ message is considered

as an example here. In this example, ie-dialogue-id is 0x40a.
(TCAP) component.
Operation code
as an example here. In this example, ie-map-operation-code is
prepare-handover.
Reference Standards

MAP_PREPARE_HANDOVER_RSP
MAP_PREPARE_SUBSEQUENT_HANDOVER_REQ
MAP_U_ABORT_REQ
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_PREPARE_HANDOVER_REQ message is sent when a call is to be handed over
or relocated from the source MSC (MSC-A) to the target MSC (MSC-B). Figure 1 shows
Figure 1 MAP_PREPARE_HANDOVER_REQ message
Associated IEs
Information Element
Description
(IE)
Invoke Id

dialogue.

Target Cell Id
Indicates the location area or cell into which the subscriber intends
to roam.
For details, see Target Cell Id.
Target RNC Id
Indicates the identity of the RNC to which a call has to be relocated.

For details, see Target RNC Id.
Indicates that no handover number is required.

HONumberNotRequired For details, see HO-NumberNotRequired.
subscriber identity
(IMSI)

Information
Indicates the integrity protection information used by the source

MSC.
For details, see Integrity Protection Information.
Encryption
Information
Indicates the encryption information used by the source MSC.

Radio Resource
Information
Indicates the radio resource information.

For details, see Radio Resource Information.
AN-APDU
Indicates the application protocol data unit of the access network.

For details, see AN-APDU.
Allowed GSM
Algorithms
Indicates the GSM encryption algorithm supported by the source

MSC.
For details, see Allowed GSM Algorithms.
Allowed Universal
Mobile
Telecommunications
System (UMTS)
Algorithms
Indicates the UMTS encryption algorithm supported by the source

MSC.
For details, see Allowed UMTS Algorithms.
Radio Resource List
Indicates a list of radio resources.

For details, see Radio Resource List.
radio access bearer

(RAB) ID
Indicates the radio access identifier.

Iu-Currently Used
Codec
Indicates the codec used at the Iu interface before handover.

For details, see Iu-Currently Used Codec.
Iu-Supported Codecs Indicates the codecs supported by the Iu interface.
List
For details, see Iu-Supported Codecs List.
Reference Standards
For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation
MAP_PREPARE_HANDOVER_RSP
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by MSC_B to inform MSC_A that handover preparation is completed.
(Assume that an MS/UE is handed over from MSC_A to MSC_B.) Figure 1 shows the main
information element of the message.
Figure 1 MAP_PREPARE_HANDOVER_RSP message
Associated IEs
Information Element
(IE)
Description
Invoke Id

dialogue.
AN-APDU
Indicates an application protocol data unit of the access network.

Handover Number
Indicates a handover number.

For details, see Handover Number.
Relocation Number
List
Indicates a handover number list.

For details, see Relocation Number List.
Selected Universal
Mobile
Telecommunications
System (UMTS)
Algorithms
Indicates a selected UMTS algorithm.

For details, see Selected UMTS Algorithms.
Indicates the selected radio resource information.

Chosen Radio
Resource Information For details, see Chosen Radio Resource Information.
Iu-Selected Codec
Indicates a codec selected for the Iu interface.

For details, see Iu-Selected Codec.
Iu-Available Codecs
List
Indicates a codec list available for the Iu interface.

For details, see Iu-Available Codecs List
User error
Indicates a user error.

Provider error
Indicates a provider error.

Reference Standards
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_PROCESS_ACCESS_SIGNALLING message is sent by MSC-B to transparently
transmit the received Relocation Detect IE (in the case of 2G network) to MSC-A, indicating
that the MS has detects a new channel. Figure 1 shows the main IEs of the message.
Figure 1 MAP_PROCESS_ACCESS_SIGNALLING message
Associated IEs
Information Element
Description
(IE)
Invoke Id

dialogue.
AN-APDU

Selected GSM
Algorithm
Indicates the GSM encryption algorithm selected.

For details, see Selected GSM Algorithm.
Selected radio
Indicates the radio access identifier selected.
access bearer (RAB)
For details, see Selected RAB ID.
id
Selected Universal
Mobile
Telecommunications
System (UMTS)
Algorithms
Indicates the UMTS encryption algorithm selected.

For details, see Selected UMTS Algorithms.
Indicates the radio resource information selected.

Chosen Radio
Resource Information For details, see Chosen Radio Resource Information.
Iu-Selected Codec
Indicates the codecs selected by the Iu interface.

For details, see Iu-Selected Codec.
Iu-Available Codecs
List
Indicates the codecs available for the Iu interface.

For details, see Iu-Available Codecs List.
Reference Standards
For details, see 8.4.3 "MAP_PROCESS_ACCESS_SIGNALLING service" in 3rd
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_SEND_END_SIGNAL_REQ message is sent by MSC-B to transparently transmit
the received Relocation Complete IE (in the case of 2G network) to MSC-A, indicating that
the handover of MSC-A is complete. Figure 1 shows the main IEs of the message.
Figure 1 MAP_SEND_END_SIGNAL_REQ message
Associated IEs
Information Element
Description
(IE)
Invoke Id

dialogue.
AN-APDU

Reference Standards
For details, see 8.4.2 "MAP_SEND_END_SIGNAL service" in 3rd Generation Partnership
MAP_PREPARE_SUBSEQUENT_HANDOVER_REQ
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_PREPARE_SUBSEQUENT_HANDOVER_REQ message is sent to inform MSC-A
that a handover or relocation to either MSC-A or a third MSC is required. Figure 1 shows
Figure 1 MAP_PREPARE_SUBSEQUENT_HANDOVER_REQ message
Associated IEs
Information Element
(IE)
Description
Invoke Id

dialogue.
Target Cell Id
Indicates the location area or cell into which the subscriber intends
to roam.
For details, see Target Cell Id.
Target RNC Id
Indicates the identity of the RNC to which a call has to be relocated.

For details, see Target RNC Id.
AN-APDU

Selected radio
Indicates the radio access identifier selected.
access bearer (RAB)
For details, see Selected RAB ID.
id
Indicates the integrated services digital network (ISDN) number of
Target MSC Number an MSC to which a call has to be handed over.
For details, see Target MSC Number.
Reference Standards
For details, see 8.4.5 "MAP_PREPARE_SUBSEQUENT_HANDOVER service" in 3rd
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by MSC_A to MSC_B to acknowledge the
MAP_PREPARE_SUBSEQUENT_HANDOVER_REQ message. It is used to notify MSC_B
whether subsequent handover is allowed and how resources are allocated. Figure 1 shows
the main information elements (IEs) of the message.
Figure 1 MAP_PREPARE_SUBSEQUENT_HANDOVER_RSP message
Associated IEs
Information Element
Description
(IE)
Invoke Id

dialogue.
Indicates an application protocol data unit of the access network.
AN-APDU
User error

Provider error

Reference Standards
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_SEND_END_SIGNAL_RSP message is sent to release the Mobile Application
Part (MAP) resources between MSCs and to release the inter-MSC call. Figure 1 shows
Figure 1 MAP_SEND_END_SIGNAL_RSP message

Associated IEs
Information Element
Description
(IE)
Invoke Id
Uniquely identifies an operation in a MAP dialogue.

Reference Standards
For details, see 8.4.2 "MAP_SEND_END_SIGNAL service" in 3rd Generation Partnership
MAP_U_ABORT_REQ
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent when the upper-layer user becomes abnormal during a Mobile
Application Part (MAP) dialog. Figure 1 shows the main information element of the
message.
Figure 1 MAP_U_ABORT_REQ message
Associated IEs
Information Element
Description
(IE)
User reason
Indicates a user reason.

For details, see User reason.
Diagnostic information
Indicates the diagnostic information.

For details, see Diagnostic information.
Reference Standards
For details, see 7.3.4 "MAP_U_ABORT service" in 3rd Generation Partnership Project
(3GPP) TS29002-870.


Allowed GSM Algorithms
Allowed UMTS Algorithms
AN-APDU
Chosen Radio Resource Information
Handover Number
HO-NumberNotRequired
Iu-Available Codecs List
Iu-Currently Used Codec
Iu-Selected Codec
Iu-Supported Codecs List
RAB ID
Radio Resource Information
Radio Resource List
Relocation Number List
Selected GSM Algorithm
Selected RAB ID
Selected UMTS Algorithms
Target Cell Id
Target MSC Number
Target RNC Id
User error
Provider error
User reason
User error
Allowed GSM Algorithms

Reference Standards
Information Element
Description
(IE)
Indicates the GSM encryption algorithms that are supported. Values:
no-encryption
gsm-a5-1
gsm-a5-2
gsm-a5-3
gsm-a5-4
gsm-a5-5
gsm-a5-6
gsm-a5-7
Allowed GSM
Algorithms
The MAP_PREPARE_HANDOVER_REQ message is considered as

an example here. In this example, no-encryption is allowed, which
indicates the 2G encryption algorithm is not supported; gsm-a5-1 is
not-allowed, which indicates the a5-1 algorithm is not supported;
gsm-a5-2 is not-allowed, which indicates the a5-2 algorithm is not
supported; gsm-a5-3 is not-allowed, which indicates the a5-3
algorithm is not supported; gsm-a5-4 is not-allowed, which indicates
the a5-4 algorithm is not supported; gsm-a5-5 is not-allowed, which
indicates the a5-5 algorithm is not supported; gsm-a5-6 is notallowed, which indicates the a5-6 algorithm is not supported; and
gsm-a5-7 is not-allowed, which indicates the a5-7 algorithm is not
supported.
Reference Standards

Allowed UMTS Algorithms

Reference Standards
Information Element
Description
(IE)
Indicates the UMTS encryption algorithms that are supported.
Values:
Allowed Universal
Mobile
Telecommunications
System (UMTS)
Algorithms
INTEGRITY-PROTECTION-ALGORITHM
ENCRYPTION-ALGORITHM
an example here. In this example, INTEGRITY-PROTECTIONALGORITHM is standard-UIA1, which indicates that the standardUIA1 integrity protection algorithm is supported; ENCRYPTIONALGORITHM is standard-UEA1, which indicates the standard-UEA1
encryption algorithm is supported.
Reference Standards
AN-APDU
Reference Standards
Information Element
Description
(IE)
Indicates the application protocol data unit of the access network. It
includes the complete Relocation Request (or Handover Request)
message and is sent by the MSC to the target RNC or BSC without
being parsed.
AN-APDU
accessNetworkProtocolId: Indicates the access network

protocol ID.
signalInfo: Indicates the signal information.
an example here. In this example, accessNetworkProtocolId is
ts3G-48006, which indicates that the access network protocol is
ts3G-48006.
Reference Standards

Chosen Radio Resource Information

Reference Standards
Information Element
Description
(IE)
Indicates the radio resource information used by the target MSC
involved in handover.
Chosen Radio
Resource Information
chosenChannelInfo: Indicates the channel information used.

chosenSpeechVersion: Indicates the speech version used.
The MAP_PREPARE_HANDOVER_RSP message is considered as
an example here. In this example, chosenChannelInfo is 03, which
indicates that the used channel is 3; chosenSpeechVersion is 01,
which indicates that the used speech version is 1.
Reference Standards
Reference Standards
Information Element
Description
(IE)
Indicates the encryption information.
Encryption
Information

an example here. In this example, encryptionInfo is 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00.
Reference Standards
Handover Number
Reference Standards
Information Element
Description
(IE)
Indicates the number allocated by the target MSC and used for
routing a call between MSCs during handover.
Handover Number
content
an example here. In this example, nature-of-address-indicator is
nature is international; content is 13907558888, which indicates the
handover number is 13907558888.
Reference Standards
HO-NumberNotRequired
Reference Standards
Information Element
Description
(IE)
Indicates that no handover number is required.
HONumberNotRequired an example here. In this example, ho-NumberNotRequired is
NULL. As long as the HO-NumberNotRequired IE is contained, no
handover number is required regardless of the value of the HONumberNotRequired IE.
Reference Standards

Reference Standards
Information Element
Description
(IE)
Indicates the integrity protection information used by the source
MSC.
Information

an example here. In this example, integrityProtectionInfo is 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00.
Reference Standards
Iu-Available Codecs List

Reference Standards
Information Element
Description
(IE)
Indicates the codecs available for the Iu interface.
Iu-Available Codecs
List

an example here. In this example, iuAvailableCodecsList is codec1,
codec2, codec3, codec4, which indicates the codecs available for
the Iu interface are codec1, codec2, codec3, and codec4.
Reference Standards
Iu-Currently Used Codec

Reference Standards
Information Element
Description
(IE)
Indicates the codecs that currently used by the Iu interface.
Iu-Currently Used
Codec

an example here. In this example, iuCurrentlyUsedCodec is 00,
indicates that the codec currently used by the Iu interface is 00.
Reference Standards
Iu-Selected Codec
Reference Standards
Information Element
Description
(IE)
Indicates the codecs that are selected the Iu interface.
Iu-Selected Codec

an example here. In this example, iuSelectedCodec is 01, indicates
that the codec selected by the Iu interface is 01.
Reference Standards
Iu-Supported Codecs List

Reference Standards
Information Element
Description
(IE)
Indicates a list of codecs supported by the Iu interface.
Iu-Supported Codecs
List
iuSupportedCodecsList
codec1
an example here. In this example, codec1 is 00, indicates that the
codec supported by the Iu interface is 00.
Reference Standards
RAB ID
Reference Standards
Information Element
Description
(IE)
Indicates the radio access identifier.
Radio Access Bearer
(RAB) ID
an example here. In this example, rab-Id is 0x01.
Reference Standards
Radio Resource Information

Reference Standards
Information Element
(IE)
Radio Resource
Information
Description
Indicates the radio resource information. If the Radio Resource
List IE is included in the handover request message, the Radio
Resource Information IE will not be included in the handover
request message.
as an example here. In this example, radioResourceInformation
is 00 00 00.
Reference Standards
Radio Resource List

Reference Standards
Information Element
Description
(IE)
Indicates a list of radio resources, include radioResourceInformation
and rab-Id. If the Radio Resource Information IE is included in the
handover request message, the Radio Resource List IE will not
included in the handover request message.
Radio Resource List

an example here. In this example, radioResourceInformation is 00
00 00, which indicates the radio resource list; rab-Id is 0x01, which
indicates the radio access identifier.
Reference Standards
Relocation Number List

Reference Standards
Information Element
Description
(IE)
Indicates a list of handover numbers that are allocated by the target
MSC and used for routing a call between MSCs during handover. If
the Relocation Number List IE is returned, the Handover Number IE
will not be returned.
Relocation Number
List

an example here. In this example, content is 8613907554567, which
indicates that the handover number allocated by the target MSC is
8613907554567.
Reference Standards
Selected GSM Algorithm

Reference Standards
Information Element
Description
(IE)
Indicates the GSM algorithm selected by GSM BSC controlled by the
target MSC.
Selected GSM
Algorithm
The MAP_PROCESS_ACCESS_SIGNALLING_REQ message is

considered as an example here. In this example, selectedGSMAlgorithm is no-encryption-used, which indicates that the GSM
algorithm is not selected.
Reference Standards
Selected RAB ID
Reference Standards
Information Element
Description
(IE)
Indicates the radio access identifier selected by GSM BSC controlled
by the target MSC.
Selected Radio
Access Bearer (RAB)
The MAP_PROCESS_ACCESS_SIGNALLING_REQ message is
ID
considered as an example here. In this example, selectedRab-Id is
0x01.
Reference Standards
Selected UMTS Algorithms

Reference Standards
Information Element
Description
(IE)
Indicates the UMTS algorithm selected by GSM BSC controlled by
the target MSC.
Selected Universal
Mobile
Telecommunications
System (UMTS)
Algorithms
integrityProtectionAlgorithm
encryptionAlgorithm
an example here. In this example, integrityProtectionAlgorithm is
standard-UIA1, which indicates that the standard-UIA1 integrity
protection algorithm is selected; encryptionAlgorithm is noencryption, which indicates that the no encryption algorithm is
selected.
Reference Standards
Target Cell Id
Reference Standards
Information Element
Description
(IE)
Indicates the identity of the cell to which a call has to be handed
over. This IE is used for a 2G network.
Target Cell Id
an example here. In this example, targetCellId is 46 00 00 77 55.
Reference Standards
Target MSC Number

Reference Standards
Information Element
Description
(IE)
Indicates the number of the MSC to which a call has to be handed
over.
Target MSC Number
content
The MAP_PREPARE_SUBSEQUENT_HANDOVER_REQ message
is considered as an example here. In this example, nature-ofaddress-indicator is international-number, which indicates that the
number address nature is international; content is 861310751201,
which indicates that the specific MSC number is 861310751201.
Reference Standards
Target RNC Id
Reference Standards
Information Element
Description
(IE)
Indicates the identity of the RNC to which a call has to be handed
over. This IE is used for a 3G network.
Target RNC Id

an example here. In this example, targetRNCId is 46 00 00 77 55 00
44.
Reference Standards
User error
Reference Standards
Information
Element (IE)
Description
User error
The MAP_PREPARE_HANDOVER_RSP message is considered as an

example here. In this example, ie-user-error is system-failure.
Reference Standards
Provider error
Reference Standards
Information
Element (IE)
Description
Provider error
The MAP_PREPARE_HANDOVER_RSP message is considered as an

example here. In this example, ie-provider-error is service-completefailure.
Reference Standards
User reason
Reference Standards
Information
Element (IE)
Description
Indicates a user reason.
User reason
The MAP_U_ABORT_REQ is considered as an example here. In this

example, ie-abort-user-reason is mpa-application-procedurecancellation, which indicates that user reason is that the application is
cancelled.
Reference Standards
(3GPP) TS29002-870.
Reference Standards
Information
Element (IE)
Description
Indicates the diagnostic information.
Diagnostic
information
The MAP_U_ABORT_REQ is considered as an example here. In this

example, ie-abort-diagnostic-info is mpa-associated-procedurefailure, which indicates that associated procedures fail.
Reference Standards
(3GPP) TS29002-870.
User error
Reference Standards
Information
Element (IE)
Description
User error
The MAP_PREPARE_SUBSEQUENT_HANDOVER_RSP message is

considered as an example here. In this example, ie-user-error is
system-failure, indicating that the system fails.
Reference Standards
G Interface Protocol
Description of the G Interface Protocol
Description of Associated Messages
Description of the G Interface Protocol

Protocol Stack
Message List
The MSC interworks with the VLR. In this networking, it also functions as the VLR and
communicates with the VLR through Mobile Application Part (MAP). Figure 1 shows the
application of the G interface protocol.
Figure 1 Application of the G interface protocol

Protocol Stack
Figure 2 through Figure 4 show the protocol stack of the G interface.
Figure 2 Protocol stack of the G interface (non-peer-to-peer M3UA networking)
Figure 3 Protocol stack of the G interface (peer-to-peer M3UA networking)
Figure 4 Protocol stack of the G interface (M2UA networking)
structure.
Message List
Table 1 List of common G interface messages
Message
Direction
MAP_SEND_IDENTIFICATION_REQ
VLR-A>VLR-B
MAP_SEND_IDENTIFICATION_RSP
VLR-B>VLR-A
Function
This message sent by VLR-A to request
the International mobile subscriber
identity (IMSI) and authentication data
from VLR-B.
This message sent by VLR-B to VLR-A
to acknowledge the
message.
Parent topic: G Interface Protocol


Reference Standards
Information Element
Description
(IE)
Dialogue ID
The MAP_SEND_IDENTIFICATION_REQ message is considered

as an example here. In this example, ie-dialogue-id is 0x40a.
(TCAP) component.
Operation code
as an example here. In this example, ie-map-operation-code is
send-identification.
Reference Standards

Message Function
Associated IEs
Reference Standards
Message Function
The MAP_SEND_IDENTIFICATION_REQ message is sent by the serving VLR to request
the International mobile subscriber identity (IMSI) and authentication data from the previous
VLR (PVLR). Figure 1 shows the main IEs of the message.
Figure 1 MAP_SEND_IDENTIFICATION_REQ message
Associated IEs
Information Element
(IE)
Invoke Id
Description
(MAP) dialogue.
For details, see Invoke id.

temporary mobile
subscriber identifier
(TMSI)

For details, see TMSI.
Number of requested
vectors
Indicates the number of requested authentication sets.

For details, see Number of requested vectors.
Indicates if the VLR allows segmentation of the response at MAP

Segmentation prohibited user level.
indicator
For details, see Segmentation prohibited indicator.
MSC Number
Indicates the MSC number of the subscriber.

For details, see MSC Number.
Previous Location Area

Id
Indicates the ID of the previous location area.

For details, see Previous Location Area Id.
Reference Standards
For details, see 8.1.4 "MAP_SEND_IDENTIFICATION service" in 3rd Generation
Parent topic: Description of Associated Messages
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_SEND_IDENTIFICATION_RSP message is sent by previous VLR (PVLR) to the
serving VLR to acknowledge the MAP_SEND_IDENTIFICATION_REQ message. Figure 1
Figure 1 MAP_SEND_IDENTIFICATION_RSP message
Associated IEs
Information Element
(IE)
Invoke Id
Description
(MAP) dialogue.
For details, see Invoke id.

Indicates the IMSI number of the subscriber.
Authentication set
Indicates the authentication set of the subscriber.

For details, see Authentication set.
Current Security Context
Indicates the security context.

For details, see Current Security Context.
Reference Standards

Authentication set
IMSI
Invoke id
MSC Number
Previous Location Area Id
TMSI
Authentication set
Reference Standards
Information Element
(IE)
Description
Indicates a list of authentication sets. TripletList (for GSM
authentication): The triplet list contains all the triplet authentication
sets required by the VLR. QuintupletList (for Universal Mobile
Telecommunications System (UMTS) authentication): The
quintuplet list contains all the quintuplet authentication sets required
by the VLR.
Authentication set
The MAP_SEND_IDENTIFICATION_CNF message is considered

as an example here. In this example, rand is 27 E4 0A 15 AD 98
45 6A C3 41 70 4A D8 BA 86 2D, which indicates a set of random
numbers; sres is 16 D3 87 07, which indicates the subscriber
response; kc is 00 04 5C CC DD AF 6A FD, which indicates the
encryption key used for authentication.
Reference Standards

Reference Standards
Information Element
Description
(IE)
Indicates a list of security context parameters. This list either
contains GSM Security Context data (Kc and Cksn) or Universal
Mobile Telecommunications System (UMTS) Security Context Data
(Ck, Ik, and Ksi).
Current Security
Context
The MAP_SEND_IDENTIFICATION_CNF message is considered as

an example here. In this example, ck is B2 E9 5C BC 03 14 C9 40
7B 7B BB 69 E0 AF C7 69, which indicates the ciphering key; ik is
40 56 94 D7 D5 76 64 03 DD C5 CA D0 C5 D9 1B 33, which
indicates the integrity key; ksi is 06; which indicates the key set
identifier.
Reference Standards
IMSI
Reference Standards
Information
Element (IE)
Description
International mobile Indicates the IMSI number of the subscriber.

subscriber identity
(IMSI)
Reference Standards
Invoke id
Reference Standards
Information
Element (IE)
Description
dialogue.
Invoke Id
The MAP_SEND_IDENTIFICATION_REQ message is considered as

an example here. In this example, invoke-ID is 0x4e, which indicates
the invoking identifier of the MAP dialogue.
Reference Standards
MSC Number
Reference Standards
Information
Element (IE)
Description
Indicates the number of the MSC at which the subscriber resides.
MSC Number
The MAP_OPEN_REQ message is considered as an example here.
In this example, content is 86139025, which indicates the MSC
number of the subscriber is 86139025.
Reference Standards

Reference Standards
Information Element
(IE)
Description
Indicates the number of authentication sets the new VLR is
prepared to receive from the previous VLR (PVLR).
Number of requested
vectors

numberOfRequestedVectors is 0x5, which indicates the serving
VLR can receive a maximum of five authentication sets from the
PVLR..
Reference Standards
Previous Location Area Id

Reference Standards
Information Element
Description
(IE)
Indicates the ID of the previous location area.
Previous Location
Area Id

as an example here. In this example, previous-LAI is 4600007788,
which indicates the previous location area ID is 4600007788.
Reference Standards

Reference Standards
Information Element
(IE)
Description
Indicates whether the new VLR allows segmentation of the
response at Mobile Application Part (MAP) user level.
Segmentation

as an example here. In this example, segmentationProhibited is
NULL, which indicates the segmentation of the response at MAP
user level is allowed.
Reference Standards
TMSI
Reference Standards
Information
Element (IE)
Description
Temporary mobile
subscriber identifier The MAP_SEND_IDENTIFICATION_REQ message is considered as
(TMSI)
an example here. In this example, tmsi is 60 38 00 07, which
indicates TMSI allocated by previous VLR (PVLR) is 60 38 00 07.
Reference Standards
E Interface Protocol
Description of the E Interface Protocol
Description of the E Interface Protocol

Protocol Stack
Message List
The MSC interworks with the SMC. In this networking, the MSC communicates with the
SMC through Mobile Application Part (MAP). Figure 1 shows the application of the E
interface protocol.
Figure 1 Application of the E interface protocol

Protocol Stack
Figure 2 through Figure 4 show the protocol stack of the E interface.
Figure 2 Protocol stack of the E interface (non-peer-to-peer M3UA networking)
Figure 3 Protocol stack of the E interface (peer-to-peer M3UA networking)
Figure 4 Protocol stack of the E interface (M2UA networking)
structure.
Message List
Table 1 List of common E interface messages
Message
Direction Function
MAP_MO_FORWARD_SHORT_MESSAGE_REQ
MSC>SMC
MAP_MO_FORWARD_SHORT_MESSAGE_CNF
SMC>MSC
MAP_MT_FORWARD_SHORT_MESSAGE_IND
SMC>MSC
MAP_MT_FORWARD_SHORT_MESSAGE_RSP
MSC>SMC
This message is sent by the MS

short message to the SMC.
This message is sent by the SM
acknowledge the
MAP_MO_FORWARD_SHORT
message.
This message is sent by the SM
terminate a short message.
This message is sent by the MS
acknowledge the
MAP_MT_FORWARD_SHORT_
message.
Parent topic: E Interface Protocol


Reference Standards
Information Element
Description
(IE)
Dialogue ID
The MAP_MO_FORWARD_SHORT_MESSAGE_REQ message is

considered as an example here. In this example, ie-dialogue-id is
0x40a.
(TCAP) component.
Operation code
considered as an example here. In this example, ie-mapoperation-code is mo-forward-sm.
Reference Standards

MAP_P_ABORT_IND
Cp data
Cp ACK
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_MO_FORWARD_SHORT_MESSAGE_REQ message is sent by the mobile
switching center (MSC) server to forward a short message to the short message center
(SMC). Figure 1 shows the main information elements (IEs) in the message.
Figure 1 MAP_MO_FORWARD_SHORT_MESSAGE_REQ message
Associated IEs
IE
Description
Invoke Id

(MAP) dialogue.
Short Message (SM) RP Indicates the destination address used by the short message
service relay sub-layer protocol.
Destination Address
(DA)
For details, see SM RP DA.
SM RP Origination
Address (OA)
Indicates the originating address used by the short message

service relay sub-layer protocol, for example, Mobile Station
International ISDN Number (MSISDN).
For details, see SM RP OA.
SM RP UI
Represents the user data field carried by the short message

For details, see SM RP UI.
Reference Standards
For details, see section 12.2 "MAP-MO-FORWARD-SHORT-MESSAGE service" in 3rd
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_MO_FORWARD_SHORT_MESSAGE_CNF message is sent by the short
message center (SMC) to the mobile switching center (MSC) server to acknowledge the
MAP_MO_FORWARD_SHORT_MESSAGE_REQ message. If an error occurs when the
SMC processes the received short message, the SMC includes the corresponding cause
value in the MAP_MO_FORWARD_SHORT_MESSAGE_CNF message. Figure 1 shows
the main information elements (IEs) in the message.
Figure 1 MAP_MO_FORWARD_SHORT_MESSAGE_CNF message
Associated IEs
IE
Description
Invoke Id

(MAP) dialogue.
Reference Standards
For details, see section 12.2 "MAP-MO-FORWARD-SHORT-MESSAGE service" in 3rd
MAP_P_ABORT_IND
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_P_ABORT_IND message is sent when a short message cannot arrive at the
SMC. Figure 1 shows the main IEs of the message.
Figure 1 MAP_P_ABORT_IND message

Associated IEs
Information Element
(IE)
Description
Indicates the reason for aborting the Mobile Application Part
(MAP) dialogue.
Values:
Provider reason
1.
2.
3.
4.
5.
6.
Provider malfunction
Supporting dialogue/transaction released
Resource limitation
Maintenance activity
Version incompatibility
Abnormal MAP dialogue
Indicates the source of the abort.

Values:
Source
1. MAP problem
2. Transmission convergence (TC) problem
3. Network service problem
Reference Standards
For details, see 7.3.5 "MAP-P-ABORT service" in 3rd Generation Partnership Project
(3GPP) TS29002-870.
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_MT_FORWARD_SHORT_MESSAGE_IND message is sent by the short
message center (SMC) to instruct the mobile switching center (MSC) server to send a short
message to the destination subscriber. Figure 1 shows the main information elements (IEs)
in the message.
Figure 1 MAP_MT_FORWARD_SHORT_MESSAGE_IND message
Associated IEs
IE
Description
Invoke Id

(MAP) dialogue.
Indicates the destination address used by the short message

Short Message (SM) RP service relay sub-layer protocol, that is, the international mobile
subscriber identity (IMSI) number in the mobile terminated (MT)
Destination Address
short message.
(DA)
For details, see SM RP DA.
SM RP Origination
Address (OA)
Indicates the originating address used by the short message

service relay sub-layer protocol, for example, that is, the SMC
address in the MT short message.
For details, see SM RP OA.
SM RP UI
Represents the user data field carried by the short message

For details, see SM RP UI.
Reference Standards
For details, see section 12.9 "MAP-MT-FORWARD-SHORT-MESSAGE service" in 3rd
Message Function
Associated IEs
Reference Standards
Message Function
The MAP_MT_FORWARD_SHORT_MESSAGE_RSP message is sent by the mobile
switching center (MSC) server to notify the short message center (SMC) of the result of
sending a short message to the destination subscriber. If the MSC server fails to send the
short message to the destination subscriber, the MSC server includes a failure cause value
in the MAP_MT_FORWARD_SHORT_MESSAGE_RSP message. Figure 1 shows the
associated information elements (IEs) in the message.
Figure 1 MAP_MT_FORWARD_SHORT_MESSAGE_RSP message
Associated IEs
IE
Description
Invoke Id

(MAP) dialogue.
User error
(Optional IE) Indicates the reason for the failure of sending short
messages.
Reference Standards
For details, see section 12.9 "MAP-MT-FORWARD-SHORT-MESSAGE service" in 3rd

Cp data
Message Function
Associated IEs
Reference Standards
Message Function
The CP data message is sent between MSCs to deliver the routing performer (RP) data.
Figure 1 CP data message
Associated IEs
Information Element
(IE)
Description
sms msg type
Indicates the short message type.

For details, see Message type.
Reference Standards
For details, see 9.3.2 "Protocol element repertoire at Short Message (SM) Relay Layer
(RL)" in 3rd Generation Partnership Project (3GPP) TS23040-830.
Cp ACK
Message Function
Associated IEs
Reference Standards
Message Function
The CP ACK message is sent to acknowledge the CP data message. Figure 1 shows the
Figure 1 CP ACK message
Associated IEs
Information Element
(IE)
Description
sms msg type
Indicates the short message type.

Reference Standards

IMSI
Invoke Id
SM RP DA
SM RP OA
User error
Message type
SM RP UI
IMSI
Reference Standards
Information
Element (IE)
Description
Indicates the IMSI of the subscriber who receives the multicast tunnel
(MT) short messages.
subscriber identity
(IMSI)
460000240946695, which indicates that the MT short message is
received by the subscriber with the IMSI of 460000240946695.
Reference Standards
For details, see 12.9 "MAP-MT-FORWARD-SHORT-MESSAGE service" in 3rd Generation
Invoke Id
Reference Standards
Information
Element (IE)
Description
dialogue.
Invoke Id

considered as an example here. In this example, invoke-ID is 0x4e,
which indicates the invoking identifier of the MAP dialogue.
Reference Standards
For details, see 12.2 "MAP-MO-FORWARD-SHORT-MESSAGE service" or 12.9 "MAPMT-FORWARD-SHORT-MESSAGE service" in 3rd Generation Partnership Project (3GPP)
TS29002-870.
SM RP DA
Reference Standards
Information
Element (IE)
Description
Indicates the destination address used by the short message service
relay sub-layer protocol, that is, the SMC address in an multiplex
option (MO) short message or the subscriber address in an multicast
tunnel (MT) short message.
Short Message (SM)

RP Destination
Address (DA)

considered as an example here. In this example, number is
86139075555, which indicates that the SMC number is 86139075555.
Reference Standards
TS29002-870.
SM RP OA
Reference Standards
Information
Element (IE)
Description
Indicates the source address used by the short message service
relay sub-layer protocol, that is, the message sender address in an
multiplex option (MO) short message or the SMC address in an
multicast tunnel (MT) short message.
Short Message (SM)

RP Origination
Address (OA)

8613907551605, which indicates the number of the subscriber who
sends the short message.
Reference Standards
TS29002-870.
User error
Reference Standards
Information
Element (IE)
Description
Indicates the reason why a short message cannot be sent
successfully.
Values:
User error
1. Unidentified subscriber: Indicates that the network side

does not store any information of the subscriber.
2. Absent Subscriber_SM: Indicates the MS power-off or
roaming restriction.
3. Subscriber busy for mobile terminating (MT) short message
service (SMS): Indicates that the MS cannot receive two
short messages at the same time.
4. Facility Not Supported: Indicates the MS does not support
the SMS.
5. Illegal Subscriber: Indicates that delivery of the MT short
message failed because the MS fails authentication.
6. Illegal equipment: Indicates that delivery of the MT short
message failed because an international mobile equipment
identity (IMEI) check fails.
7. System Failure
8. Short Message (SM) Delivery Failure, including: memory
capacity exceeded in the mobile equipment, protocol error,
and mobile equipment does not support the mobile
terminated short message service
9. Unexpected Data Value
10. Data Missing
The MAP_MO_FORWARD_SHORT_MESSAGE_CNF message is
considered as an example here. In this example, ie-user-error is smdelivery-failure(32).
Reference Standards
For details, see 12.9 "MAP-MT-FORWARD-SHORT-MESSAGE service" in 3rd Generation
Message type
Reference Standards
Information
Element (IE)
Description
Indicate the type of short message. It can be included in different
types of messages.
1. CP_DATA: This message is sent between the MS and the
network side and contains the subscriber data or the other
related information.
2. CP_ACK: This message is sent between the MS and the
network side to acknowledge the CP_DATA message.
3. CP_ERROR: This message is sent between the MS and
the network side to transmit the error information.
sms msg type
The CP_data message is considered as an example here. In this

example, sms-msg-type is cp-data, which indicates the MS sends a
short message to the network side.
Reference Standards
SM RP UI
Reference Standards
Information
Element (IE)
Description
Short Message (SM) Represents the user data field carried by the short message service
RP UI
relay sub-layer protocol.
Reference Standards
For details, see section 7.6.8 "Short message parameters" in 3rd Generation Partnership
Sv Interface Protocol
Description of the Sv Interface Protocol
Description of the Sv Interface Protocol

Protocol Stack
Message List
At the initial phase of Voice over Long Term Evolution (VoLTE) network deployment,
carriers' networks are upgraded from the GSM/Enhanced Data rates for GSM Evolution
(EDGE) radio access network (GERAN) or Universal Mobile Telecommunications System
(UMTS) Terrestrial Radio Access Network (UTRAN) to the Evolved Universal Terrestrial
Radio Access Network (E-UTRAN). The Long Term Evolution (LTE) network usually covers
only hot spots and provides services only in certain areas. When a subscriber roams from
an E-UTRAN to a GERAN/UTRAN, the subscriber have to be handed over from E-UTRAN
to the GERAN/UTRAN.
When a subscriber roams from an E-UTRAN to a UTRAN/GERAN during a call, the EUTRAN determines whether the subscriber needs to be handed over based on the
information about neighboring networks (including signaling availability and signal strength)
received from user equipment (UE). If a handover is required, the E-UTRAN sends a
handover request to the mobility management entity (MME) or the serving GPRS Support
node (SGSN). The MME/SGSN then sends a Single Radio Voice Call Continuity (SRVCC)
handover request to the mobile switching center (MSC) server over the Sv interface. In this
way, subscribers can continue ongoing calls when roaming from an E-UTRAN to a
UTRAN/GERAN.
The MME/SGSN interworks with the SRVCC Interworking Function (SRVCC IWF), which is
the MSC server equipped with the SRVCC IWF function, using General Packet Radio
Service (GPRS) Tunneling Protocol (GTP) version 2, control plane (GTPv2-C). Figure 1
shows the application of the GTPv2-C protocol.
Figure 1 Application of the GTPv2-C protocol

Protocol Stack
The Sv interface uses GTPv2-C protocol stack. Figure 2 shows the protocol stack for the
Sv interface.
Figure 2 Protocol stack of the Sv interface
NOTE:
Based on User Datagram Protocol (UDP), the GTPv2-C is the control part of the GTP.
L1: Layer 1 of the GTPv2-C protocol stack. Carriers can adopt an appropriate protocol
based on their requirements.
L2: Layer 2 of the GTPv2-C protocol stack. Typically Ethernet is used at a Layer 2, but
carriers may use other protocols.
Message List
Table 1 List of common Sv interface messages
Message
Direction
GTP_MSG_SRVCC_PS_TO_CS_REQ
This message is sent from th

MME/SGSN- MME/SGSN to the target MS
>MSC server Sv interface, instructing the M
initiate an SRVCC handover.
GTP_MSG_SRVCC_PS_TO_CS_RSP
This message is sent by the

source MME/SGSN over the
MSC server- response to the
>MME/SGSN GTP_MSG_SRVCC_PS_TO
message during the SRVCC
procedure.
GTP_MSG_SRVCC_PS_TO_CS_COMP_NTF

MSC server- the Sv interface to notify the
>MME/SGSN that the SRVCC handover wi
successful.
GTP_MSG_SRVCC_PS_TO_CS_COMP_ACK
Function

MME/SGSN to the MSC serv
MME/SGSN- interface in response to the
>MSC server GTP_MSG_SRVCC_PS_TO

procedure.

MME/SGSN- MME/SGSN to the target MS
GTP_MSG_SRVCC_PS_TO_CS_CANCEL_NTF
>MSC server Sv interface, requesting the c
ongoing SRVCC handover.

source MME/SGSN over the
MSC server- response to the
GTP_MSG_SRVCC_PS_TO_CS_CANCEL_ACK
>MME/SGSN GTP_MSG_SRVCC_PS_TO
procedure.
Parent topic: Sv Interface Protocol

Table 1 describes the information elements (IEs) carried in the common part of messages.
Information
Element (IE)
Description
Indicates the sender and receiver of a message.
senderMID: identifies the BSG process which sends the

message.
senderPid: identifies the internal processing module which
sends the message.
receiverMid: identifies the BSG process which receives the
message.
recvrPid: identifies the internal processing module which
receives the message.
Header
The GTP_MSG_SRVCC_PS_TO_CS_REQ message is used as an

example here.
In this example, meanings of each parameter are as follows:
senderMID is set to 1400: indicating that the BSG process
whose process identification (PID) is 1400 sends the
message.
senderPid is set to sx-PID-IPD(204): indicating that an
internal integrated product development (IPD) module sends
the message.
receiverMid is set to 1400: indicating that the BSG process
whose PID is 1400 receives the message.
recvrPid is set to sx-PID-GTP(356): indicating that the
internal GPRS tunneling protocol (GTP) module receives the
message.
Describes the GTP message.
pathID: identifies the GTP path.

entityID: identifies the GTP peer (GTPPE) entity,
corresponding to the local mobile management entity (MME).
fromIP: identifies the source IP address of the message,
corresponding to the IP address of the MME.
toIP: identifies the target IP address of the message,
corresponding to the IP address of the mobile switching
center (MSC) server.
fromPort: identifies the port through which the message is
sent.
toPort: identifies the port through which the message is
received.
msgType: indicates the message type.
spare: indicates that the field is not used.
teid-present: indicates whether the message contains tunnel
endpoint identifier (TEID) IE.
Value:
1: The message contains TEID IE.
0: The message does not contain TEID IE.
Body
piggyback: indicates whether the PIGGYBACK feature is

supported.
Value:
0: The PIGGYBACK feature is not supported.
1: The PIGGYBACK feature is supported
version: identifies the supported GTP versions.
The GTP_MSG_SRVCC_PS_TO_CS_REQ message is used as an
example here.
In the example, meanings of each parameter are as follows:

pathID is set to 0: indicating that the sequence number of
the GTP path is 0.
entityID is set to 0: indicating that the sequence number of
the local MME is 0.
fromIP is set to 09 01 42 a1, which is a hexadecimal
number. After the value is reversed to "a1 42 01 09" and
converted to a decimal equivalent, the sending IP address
"161.66.1.9" is obtained.
toIP is set to 52 01 42 a1, which is a hexadecimal number.
After the value is reversed to "a1 42 01 52" and converted to
a decimal equivalent, the receiving IP address "161.66.1.81"
is obtained.
fromPort is set to 2124: indicating that the message is sent
through the port whose port number is 2124.
toPort is set to 2123: indicating that the message is
received through the port whose port number is 2123.
msgType is set to 25: indicating that the message type is
PS to CS Request.
spare is set to 0: indicating that the field is idle.
teid-present is set to 1: indicating that the message
contains TEID IE.
piggyback is set to 0: indicating that the PIGGYBACK
feature is not supported.
version is set to 2: indicating that the supported GTP
version number is version 2.
ie-common field
It is an example of the GTP_MSG_SRVCC_PS_TO_CS_REQ

message.
In the stn-sr IE of this example, ie-common is the common field of the
IEs in the Sv interface messages. The ie-common field is used with
the IE type field to identify an IE. In this message, the ie-common is
not added, therefore, spare and instance are set to 0.


Message Function
Associated IEs
Reference Standards
Message Function
A GTP_MSG_SRVCC_PS_TO_CS_REQ message is sent from the source mobility
management entity (MME) or the serving general packet radio service (GPRS) Support
node (SGSN) to the target mobile switching center (MSC) server over the Sv interface,
instructing the MSC server to initiate a Single Radio Voice Call Continuity (SRVCC)
handover. Figure 1 shows the main information elements (IEs) in the message.
Figure 1 GTP_MSG_SRVCC_PS_TO_CS_REQ message sent during an intra-MSC 3G
handover
Associated IEs
Description
IP-Address
This IE specifies the control plane message's

address which is determined by the source
MME/SGSN. It is mandatory.
For details, see IP Address.
TEID-C
This IE specifies the control plane message

tunnel which is determined by the source
MME/SGSN. It is mandatory.
The target MME can include this tunnel
endpoint identifier (TEID) in the GPRS
tunneling protocol (GTP) header of all related
control plane messages which are related to
the requested bearer.
For details, see TEID-C.
Target GCI
This IE identifies the target access for an

SRVCC to GSM/Enhanced Data rates for
GSM Evolution (EDGE) radio access network
(GERAN) handover. It is optional.
If the target side of a handover is a 2G
network, the Target global cell identity (GCI)
IE will be included in the
GTP_MSG_SRVCC_PS_CS_REQ message.
For details, see Target GCI.
This IE identifies the international mobile
subscriber identity (IMSI) of the subscriber. It
is optional. It is included in the
GTP_MSG_SRVCC_PS_CS_REQ message
sent from the MME/SGSN except for the
following cases:
IMSI
The user equipment (UE) is

emergency attached and it is
UICCless (UICC refers to universal
integrated circuit card).
The UE is emergency attached and
the IMSI is not authenticated.
Mobile Station International ISDN Number

(MSISDN)
This IE identifies the mobile station

international integrated services digital
network (ISDN) number (MSISDN) of the
subscriber. It is optional. It is included in the
GTP_MSG_SRVCC_PS_CS_REQ message
sent from the MME/SGSN except for the
following cases:
it is UICCless.
The MSISDN is defined in 3rd Generation
Partnership Project (3GPP) TS 23.003 [4].
STN-SR
This IE is included in the

message if this session is not for an
emergency call. It is optional.
For details, see STN-SR.
Mobility management (MM) Context for EUTRAN SRVCC
The MME includes mobile station classmarks,

supported codecs, and CS Security key in
MM Context for SRVCC for Evolved Universal
Terrestrial Radio Access Network (E-UTRAN)
SRVCC. This IE is optional. The derivation of
the CS security keys shall follow the
procedures defined 3GPP TS 33.401[7].
For details, see MM Context for E-UTRAN
SRVCC.
Source to Target Transparent Container
This MME or SGSN includes Source to Target

Transparent Container IE. This IE is
mandatory.
For details, see Source to Target Transparent
Container.
Target RNC ID
This IE identifies the target access for

SRVCC handover to Universal Mobile
Telecommunications System (UMTS)
Terrestrial Radio Access Network (UTRAN). It
is optional.
If the target side of a handover is a 3G
network, the Target RNC ID IE is included in
the GTP_MSG_SRVCC_PS_CS_REQ
message.
For details, see Target RNC ID.
Reference Standards
For details, see 5.2.2 "SRVCC PS to CS Request" in 3GPP 29.280 V9.3.0.

Message Function
Associated IEs
Reference Standards
Message Function
A GTP_MSG_SRVCC_PS_TO_CS_RSP message is sent by the mobile switching center
(MSC) server to the source mobility management entity (MME) or the serving general
packet radio service (GPRS) Support node (SGSN) over the Sv interface in response to the
GTP_MSG_SRVCC_PS_TO_CS_REQ message during the Single Radio Voice Call
Continuity (SRVCC) handover procedure. Figure 1 shows the main information elements
(IEs) in the message.
Figure 1 GTP_MSG_SRVCC_PS_TO_CS_RSP message sent during an intra-MSC 3G
handover
Associated IEs
Description
Cause
This IE specifies whether the

message is accepted. If Cause is not
Request accepted, the
message is rejected. It is mandatory.
SRVCC Cause
This IE specifies why the

message is rejected if Cause is not Request
accepted. It is optional.
For details, see SRVCC Cause.
TEID-C
This IE is included in the

message by the target MSC server if Cause
is Request accepted.
The source MME/SGSN includes this TEID-C
in the GPRS Tunneling Protocol-Control plane
(GTP-C) header of all subsequent uplink
control plane messages from the source
MME/SGSN to the target MSC servers. This
IE is optional.
For details, see TEID-C.
Target to Source Transparent Container
This IE is included to carry the Handover

command from the target access network if
Cause is Request accepted. It is optional.
For details, see Target to Source Transparent
Container.
Reference Standards
For details, see 5.2.3 "SRVCC PS to CS Response" in 3rd Generation Partnership Project
(3GPP) 29.280 V9.3.0.
Message Function
Associated IEs
Reference Standards
Message Function
A GTP_MSG_SRVCC_PS_TO_CS_COMP_NTF message is sent over the Sv interface to
notify the source mobility management entity (MME) or the serving general packet radio
service (GPRS) Support node (SGSN) that the Single Radio Voice Call Continuity (SRVCC)
handover with the CS domain is successful. The SRVCC procedure is stipulated in 3GPP
TS 23.216 [2]. Figure 1 shows the main information elements (IEs) in the message.
Figure 1 GTP_MSG_SRVCC_PS_TO_CS_COMP_NTF message sent during an intra-MSC
3G handover
Associated IEs
Description
This IE indicates the international mobile
subscriber identity (IMSI) of the subscriber. It
is optional. It is included in the
message except for the following cases:
IMSI
The user equipment (UE) is

emergency attached and it is
UICCless (UICC refers to universal
integrated circuit card).

Reference Standards
For details, see 5.2.4 "SRVCC PS to CS Complete Notification" in 3GPP 29.280 V9.3.0.
Message Function
Associated IEs
Reference Standards
Message Function
A GTP_MSG_SRVCC_PS_TO_CS_COMP_ACK message is sent from the source mobility
management entity (MME) or the serving general packet radio service (GPRS) Support
node (SGSN) to the mobile switching center (MSC) server over the Sv interface in response
to the GTP_MSG_SRVCC_PS_TO_CS_COMP_NTF message during the Single Radio
Voice Call Continuity (SRVCC) handover procedure. Figure 1 shows the main information
elements (IEs) in the message.
Figure 1 GTP_MSG_SRVCC_PS_TO_CS_COMP_ACK message sent during an intra-
MSC 3G handover
Associated IEs
Cause
Description
message is accepted. If Cause is not
Request accepted, the

Reference Standards
For details, see 5.2.5 "SRVCC PS to CS Complete Acknowledge" in 3rd Generation
Partnership Project (3GPP) 29.280 V9.3.0.
Message Function
Associated IEs
Reference Standards
Message Function
A GTP_MSG_SRVCC_PS_TO_CS_CANCEL_NTF message is sent from the source
mobility management entity (MME) or the serving general packet radio service (GPRS)
Support node (SGSN) to the target mobile switching center (MSC) server over the Sv
interface, requesting the cancelation of an ongoing Single Radio Voice Call Continuity
(SRVCC) handover. Figure 1 shows the main information elements (IEs) in the message.
Figure 1 GTP_MSG_SRVCC_PS_TO_CS_CANCEL_NTF message sent during an intra-
MSC 3G handover
Associated IEs
Description
SRVCC Cause
This IE specifies the reason for the handover

cancelation or rejection. It is mandatory.
For details, see SRVCC Cause.
This IE identifies the international mobile
subscriber identity (IMSI) of the subscriber. It is
optional. It is included in the

message except for the following cases:
IMSI
The user equipment (UE) is emergency

attached and it is UICCless (UICC
refers to universal integrated circuit
card).
The UE is emergency attached and the
IMSI is not authenticated.
Reference Standards
For details, see 5.2.6 "SRVCC PS to CS Cancel Notification" in 3rd Generation Partnership
Project (3GPP) 29.280 V9.3.0.
Message Function
Associated IEs
Reference Standards
Message Function
A GTP_MSG_SRVCC_PS_TO_CS_COMP_ACK message is sent from the mobile
switching center (MSC) server to the source mobility management entity (MME) or the
serving general packet radio service (GPRS) Support node (SGSN) over the Sv interface in
response to the GTP_MSG_SRVCC_PS_TO_CS_CANCEL_NTF message during the
Single Radio Voice Call Continuity (SRVCC) handover procedure. Figure 1 shows the main
information elements (IEs) in the message.
Figure 1 GTP_MSG_SRVCC_PS_TO_CS_CANCEL_ACK message sent during an intra-
MSC 3G handover
Associated IEs
Description
Cause

message is accepted. If Cause is not Request
accepted, the
Sv Flags
The Service trigger information (STI) flag in this

IE is included if the MSC server triggers the IP
multimedia subsystem (IMS) session transfer
procedure. This IE is optional.
For details, see Sv Flags.
Reference Standards
For details, see 5.2.7 "SRVCC PS to CS Cancel Acknowledge" in 3rd Generation
Partnership Project (3GPP) 29.280 V9.3.0.

STN-SR
MM Context for E-UTRAN SRVCC
SRVCC Cause
Target RNC ID
Target GCI
TEID-C
Sv Flags
IMSI
MSISDN
IP Address
Cause
STN-SR
Reference Standards
STN-SR
Description
Is used for re-establishing remote session
connected to the IP multimedia subsystem (IMS)
domain. It is transferred through General Packet
Radio Service (GPRS) Tunneling Protocol (GTP)
tunnels. The sending entity copies the value part of
the STN-SR into the Value field of the STN-SR IE.
Session Transfer Number (STN) is public
telecommunication number defined in the E.164
encoding scheme and recommended by the
International Telecommunication UnionTelecommunication Standardization Sector (ITU-T).
It is used in the Single Radio Voice Call Continuity
(SRVCC) PS to CS Request session. Session
Transfer Number for SRVCC (STN-SR) is the STN
allocated during the SRVCC.
The STN-SR IE in the

GTP_MSG_SRVCC_PS_TO_CS_REQ message
is used as an example here.
In this example, stn-sr is set to 21 43 65 12 34.
After the sequence of the two numbers of each
byte is reversed, the STN-SR "12 34 56 21 43" is
obtained.
Reference Standards
For details, see 3rd Generation Partnership Project (3GPP) 23.003 [4].


Reference Standards
Description
Includes radio access network (RAN) or base
station subsystem (BSS) parameters that are
necessary for the target RAN to set up radio
bearers.
When the target network is
GSM/Enhanced Data rates for GSM
Evolution (EDGE) radio access network
(GERAN), this container carries the Old
BSS to New BSS Information defined in
3rd Generation Partnership Project
(3GPP) TS 48.008 [8].
When the target network is Universal
Terrestrial Radio Access Network
(UTRAN), this container carries the
Source Radio Network Controller (RNC)
to Target RNC Transparent Container IE
defined in 3GPP TS 25.413 [9].

length-of-transparent-container:
specifies the length of transparent
container.
transparent-container: specifies the
value of Source to Target Transparent
Container IE.
The Source to Target Transparent Container IE in
the GTP_MSG_SRVCC_PS_TO_CS_REQ
message is used as an example here.

In this example, meanings of each parameter are
as follows:
length-of-transparent-container is set
to 6: indicating that the length of the
transparent container is 6.
transparent-container is set to 01 00 01
01 80 01: indicating that the value of the
IE is 01 00 01 01 80 01.
Reference Standards
For details, see 6.3 "Source to Target Transparent Container" in 3GPP 29.280 V9.3.0.

Reference Standards
Information
Element
Description
(IE)
Contains the bearer information that is necessary for the user equipment (UE)
to access the target radio access network (RAN).
When the target network is GSM/Enhanced Data rates for GSM
Evolution (EDGE) radio access network (GERAN), this container
carries the New business support system (BSS) to Old BSS
Information defined in 3rd Generation Partnership Project (3GPP) TS
48.008 [8].
When the target network is Universal Terrestrial Radio Access
Network (UTRAN), this container carries the Target RNC to Source
RNC Transparent Container IE defined in 3GPP TS 25.413 [9].
Target to
Source
Transparent
Container
length-of-transparent-container: specifies the length of transparent

container.
transparent-container: specifies the value of Target to Source
Transparent Container IE.
The Target to Source Transparent Container IE in the
GTP_MSG_SRVCC_PS_TO_CS_RSP message is used as an example here.
In this example, meanings of each parameter are as follows:
length-of-transparent-container is set to 46: indicating that the
length of the transparent container is 46.
transparent-container is set to 84 B7 E4 00 00 56 A8 00 A3 0C 7C
5E 84 80 23 57 9A 88 08 0C 90 00 99 88 A9 D8 8E 47 47 04 52 FB
66 7C E0 08 64 54 26 02 00 60 01 02 04 00: indicating that the value
for the Target to Source Transparent Container IE is 84 B7 E4 00 00
56 A8 00 A3 0C 7C 5E 84 80 23 57 9A 88 08 0C 90 00 99 88 A9 D8
8E 47 47 04 52 FB 66 7C E0 08 64 54 26 02 00 60 01 02 04 00.
Reference Standards
For details, see 6.4 "Target to Source Transparent Container" in 3GPP 29.280 V9.3.0.
MM Context for E-UTRAN SRVCC

Reference Standards
Description
Contains Mobile Station Classmarks, supported
codec list, and the security parameters that are
necessary for the mobile switching center (MSC)
server to set up the ciphering connection (and
integrity protection for 3G) with the target access
for Single Radio Voice Call Continuity (SRVCC). In
addition, it carries CS ciphering keys parameters:
CKSRVCC, IKSRVCC, and eKSI for Evolved
Universal Terrestrial Radio Access Network (EUTRAN) SRVCC which are defined in 3rd
Generation Partnership Project (3GPP) TS 33.401
[6].
Mobile Station Classmark 2, Mobile Station
Classmark 3, and supported codec list IEs indicate
the supported encryption algorithm for
GSM/Enhanced Data rates for GSM Evolution
(EDGE) radio access network (GERAN) access
and CS supported codec. The coding of Mobile
Station Classmarks and supported codec list fields
include the IE value part as it is specified in 3GPP
TS 24.008 [7].
Mobility management (MM) Context for

E-UTRAN SRVCC
eksi: integrity mode information. It

indicates whether the mobility
management entity (MME) transfers a
valid security context to the MSC server.
If the value for eksi is between 0 and 6,
ck and ik are valid. Otherwise, ck and ik
are invalid.
ck (Cipher Key): 3G encryption
parameter.
ik (Integrity Key): 3G encryption
parameter.
length-of-classmark2: specifies the
length of Mobile Station Classmark 2.
mobile-station-classmark2: specifies
the Mobile Station Classmark type.
length-of-classmark3: specifies the
length of Mobile Station Classmark 3.
mobile-station-classmark3: specifies
the Mobile Station Classmark type.
length-of-codec-list: specifies the length
of codec list.
supported-codec-list: specifies the
supported codec list.
The MM Context for E-UTRAN SRVCC IE in the
as follows:
eksi is set to 6: indicating that ck and ik
are valid.
ck is set to 76 DB 58 56 F9 76 2C D7
EC 20 79 EB 52 B3 8D BE: indicating
that the 3G encryption information is 76
DB 58 56 F9 76 2C D7 EC 20 79 EB 52
B3 8D BE.
ik is set to 05 A5 24 2D 5E D2 38 16 B0
C9 E4 46 65 9C 56 EA: indicating that the
3G encryption information is 05 A5 24 2D
5E D2 38 16 B0 C9 E4 46 65 9C 56 EA.
length-of-classmark2 is set to 3:
indicating that the length of Mobile Station
Classmark 2 is 3.
mobile-station-classmark2 is set to 01
00 81: indicating that the value for Mobile
Station Classmark 2 is 01 00 81.
length-of-classmark3 is set to 12:
indicating that the length of Mobile Station
Classmark 3 is 12.
mobile-station-classmark3 is set to 12
11 11 11 11 11 11 11 11 11 11 11:
indicating that the value for Mobile Station
Classmark 3 is 12 11 11 11 11 11 11 11 11
11 11 11.
length-of-codec-list is set to 8:
indicating that the length of codec list is 8.
supported-codec-list is set to 00 02 1F
00 04 02 60 04: indicating that the
supported codec list is 00 02 1F 00 04 02
60 04.
Reference Standards
For details, see 3GPP 33.401 [6].
SRVCC Cause
Reference Standards
Description
Specifies the reason for canceling or denying the
GTP_MSG_SRVCC_PS_TO_CS_REQ message.
SRVCC Cause
The Single Radio Voice Call Continuity (SRVCC)
Cause IE in the
In this example, srvcc-cause-value is set to 5,
indicating an unknown target ID 5.
Table 1 shows the meanings of SRVCC Cause values.
Table 1 SRVCC Cause values
Cause Value
Meaning
(decimal)
0
Reserved. Shall not be sent and if received the Cause shall be treated as an
invalid IE.
Unspecified.
Handover/Relocation canceled by source system.
Handover /Relocation Failure with Target system.
Handover/Relocation Target not allowed.
Unknown Target ID.
Target Cell not available.
No Radio Resources Available in Target Cell.
Failure in Radio Interface Procedure.
9-255
Spare. This value range is reserved for SRVCC Cause values.
Reference Standards
For details, see 6.7 "SRVCC Cause" in 3rd Generation Partnership Project (3GPP) 29.280
V9.3.0.
Target RNC ID
Reference Standards
IE
Description
If the target side of a handover is a 3G network,
message will include this information element (IE)
containing the identity of the target RNC. The
encoding of this IE is defined in 3rd Generation
Partnership Project (3GPP) TS 29.002 [11] TS
29.002 [11].
Target RNC ID
The Target RNC ID IE in the

For the encoding of rnc-id as shown in the previous
diagram, see Target ID. Where, LAI is 64 F0 00
01 73 and RNC ID is 00 59.
Reference Standards
For details, see 6.8 "Target RNC ID" in 3GPP 29.280 V9.3.0.
Target GCI
Reference Standards
IE
Description
If the target side of a handover is a 2G network,
message will include the Target Global Cell ID
(GCI) information element (IE) containing the
identity of the target Global System for Mobile
Communications (GSM) Cell ID. The encoding of
this IE is defined in 3rd Generation Partnership
Project (3GPP) TS 29.002 [11].
Target GCI
The Target GCI IE in the

when the target side is a 3G network is used as an
example here.
In this example, cell-id is set to 00, indicating that
the Target GCI ID is invalid.
Reference Standards
For details, see 3GPP 29.002 [11].
TEID-C
Reference Standards
Description
Identifies the Tunnel Endpoint Identifier for Control
Plane (TEID-C).
TEID-C
The GTP_MSG_SRVCC_PS_TO_CS_REQ
In this example, teid is set to 10000003.
Reference Standards
For details, see 6.10 "Tunnel Endpoint Identifier for Control Plane (TEID-C)" in 3rd
Generation Partnership Project (3GPP) 29.280 V9.3.0.
Sv Flags
Reference Standards
IE
Description
This information element (IE) is optional.
Sv Flags
EmInd (Emergency Indicator): indicates

the IP multimedia subsystem (IMS)
emergency session.
ICS (IMS Centralized Service): is used to
request IMS Centralized Service (ICS)
support.
STI (Session Transfer Indicator):
indicates whether the IMS session
transfer has been invoked.
The Sv Flags IE in the
as follows:
emind is set to 0: indicating that the IMS
emergency session is not supported.
ics is set to 0: indicating that requesting
ICS is not supported.
sti is set to 1: indicating that the IMS
session transfer has been invoked.
Reference Standards
For details, see 6.11 "Sv Flags" in 3rd Generation Partnership Project (3GPP) 29.280
V9.3.0.
IMSI
Reference Standards
Description
Identifies the international mobile subscriber
identity (IMSI) of the subscriber.
IMSI
The IMSI IE in the

In this example, imsi is set to 64 00 20 00 10 88
14 F9. After the sequence of the two numbers of
each byte is reversed, the IMSI "46 00 02 00 01
88 41 9" of the subscriber is obtained. In this
value, F is invalid and should not be considered.
Reference Standards
MSISDN
Reference Standards
Description
Identifies the mobile station international ISDN
number (MSISDN) of the subscriber.
MSISDN
The MSISDN IE in the

In this example, msisdn is set to 68 31 83 29 85
14 F9. After the sequence of the two numbers of
each byte is reversed,, the MSISDN "86 13 38 92
58 41 9" of the subscriber is obtained. In this
value, F is invalid and should not be considered.
Reference Standards
IP Address
Reference Standards
Description
Specifies the control plane message's address
which is determined by the source mobility
management entity (MME) or the serving GPRS
Support node (SGSN).
IP Address
The IP Address IE in the
In this example, ipaddr is set to A1 42 01 9F,
which is a hexadecimal number. After the value is
converted to a decimal equivalent, the IP address
"161.66.1.159" for control plane message is
obtained.
Reference Standards
For details, see 5.2.2 "SRVCC PS to CS Request" in 3rd Generation Partnership Project
(3GPP) 29.280 V9.3.0.
Cause
Reference Standards
Description
Specifies whether the
is accepted.
cause: specifies whether the

message is accepted.
cs (Cause Source): specifies whether the
local mobile switching center (MSC)
server or the peer MSC server generates
the cause value. Value:
1: The incorrect cause value is
generated by peer network
elements (NEs).
0: The incorrect cause value is
generated by local NEs.
bce (Bearer Context IE Error): specifies
whether the Single Radio Voice Call
Continuity (SRVCC) PS to CS handover
rejection is caused by Bearer Context IE
error. Value:
Cause
1: The SRVCC PS to CS
handover rejection is caused by
Bearer Context IE error.
handover rejection is not caused
by Bearer Context IE error.
pce (PDN Connection IE Error): specifies
whether the SRVCC PS to CS handover
rejection is caused by packet data
network (PDN) Connection IE Error.
Value:
handover rejection is caused by
PDN Connection IE Error.
handover rejection is not caused
by PDN Connection IE Error.
The Cause IE in the
GTP_MSG_SRVCC_PS_TO_CS_RSP message
as follows:
cause is set to 6: indicating that the
SRVCC PS to CS Request is accepted.
cs is set to 0: indicating that the incorrect
cause value is generated by local NEs.
bce is set to 0: indicating that the SRVCC
PS to CS handover rejection is not
caused by Bearer Context IE error.
pce is set to 0: indicating that the SRVCC
PS to CS handover rejection is not
caused by PDN Connection IE Error.
Reference Standards

H.248 Protocol
Description of the H.248 Protocol
Extended 3GPP-based H.248 Protocol
Description of the H.248 Protocol

Protocol Stack
Message Structure
IE Structure
Message List
Reference Standards
In the 3rd Generation Partnership Project (3GPP) R4 core network, the control plane is
separated from the bearer plane. The H.248 protocol is applied to the Mc interface
between the control plane and the bearer plane. Using the H.248 protocol, the MGC
controls the bearer resources on the MGW and the MGW notifies the MGC of the bearer
status.
Major scenarios of interaction between the MGC and the MGW are as follows:
1. The MGC notifies the MGW to allocate the bearer resource.
2. The MGC notifies the MGW to modify the attributes of the bearer resource.
3. The MGC notifies the MGW to release the bearer resource.
4. The MGW notifies the MGC of the status change of the MGW.
5. The MGW notifies the MGW of the occurrence of the bearer-specific events.
6. The MGC audits the bearer resource status of the MGW.
Protocol Stack
The H.248 protocol can be carried over either IP or asynchronous transfer mode (ATM).
The IP networking mode is generally used. Figure 1 shows the protocol stack of the H.248
protocol carried over IP.
Figure 1 Protocol stack of the H.248 protocol carried over IP

Message Structure
The H.248 messages are encoded in a binary format or in a text format. When the binary
format is used, the H.248 messages comply with the International Telecommunication
Union-Telecommunication Standardization Sector (ITU-T) X.680 (ASN.1) specification and
are encoded in accordance with X.690-specified basic encoding rule (BER) rules. When the
text format is used, the H.248 messages comply with the RFC 2234 ABNF specification.
An H.248 message contains one or more transactions, a transaction contains one or more
actions, and an action contains one or more commands. A command contains one or more
parameters that are defined and described by descriptors and packets. Figure 2 shows the
hierarchical structure of the H.248 message.
Figure 2 Hierarchical structure of the H.248 message
IE Structure
Figure 3 shows the IE Structure of the H.248 message.
Figure 3 IE Structure
Message List
Table 1 describes seven pairs of H.248 messages.
Table 1 List of H.248 messages
Message
Direction Function
ADD REQ
MGC>MGW
Requests the MGW to add a termination to a context.
ADD REPLY
MGW>MGC
Responds to the ADD REQ message.
NTFY REQ
MGW>MGC
Notifies the occurrence of events in the MGW.
NTFY REPLY
MGC>MGW
Responds to the NTFY REQ message.
MOD REQ
MGC>MGW
Requests the MGW to modify the properties, events, or

signals of a termination.
MOD REPLY
MGW>MGC
Responds to the MOD REQ message.
SUB REQ
MGC>MGW
Requests the MGW to remove a termination from a

context.
SUB REPLY
MGW>MGC
Responds to the SUB REQ message.
MOV REQ
MGC>MGW
Requests the MGW to move a termination from one

context to another context.
MOV REPLY
MGW>MGC
Responds to the MOV REQ message.
AUDIT VAL REQ
MGC>MGW
Requests the MGW to return the current state of

properties, events, signals and statistics of terminations.
AUDIT VAL REPLY
MGW>MGC
Responds to the AUDIT VAL REQ message.
ServiceChange
REQ
MGC<>MGW
Instructs the MGW to take a termination or group of

terminations in or out of service.
Notifies the MGC that a termination or group of
terminations is about to be taken out of service or has just
returned to service.
ServiceChange
REPLY
MGC<>MGW
Responds to the ServiceChange REQ message.
Reference Standards
For details about the H.248 protocol, see ITU-T H.248 versions.
Parent topic: H.248 Protocol
Extended 3GPP-based H.248 Protocol

Application Scenarios
Interaction with Other Protocols
Packages of the Extended 3GPP-based Protocol feature
Protocol Reference
The Extended 3GPP-based H.248 Protocol feature enables the medial gateway controller
(MGC) to control bearer resources on the media gateway (MGW) and enables the MGW
to notify the MGC of the bearer status. It is designed based on the H.248/MEGACO
protocol defined by the ITU-T/IETF. It applies to the Mc interface between control and
bearer planes on the 3rd Generation Partnership Project (3GPP) R4 network for which
control and bearer are separated.
Application Scenarios
This feature applies to the following H.248supported scenarios:
The MGC instructs the MGW to allocate bearer resources.
The MGC instructs the MGW to modify bearer resources.
The MGC instructs the MGW moves a termination from one context to another
context.
The MGC instructs the MGW to release bearer resources.
The MGW notifies the MGC of its status change.
The MGW notifies the MGC of an bearer event.
The MGC audits the status of MGW bearer resources.
The MGC audits attributes information of MGW terminations.
Interaction with Other Protocols
This feature adds multiple applications to the application layer of the H.248 protocol by
expanding protocol packages described in Packages of the Extended 3GPP-based
Protocol feature. Multiple 3GPP protocols and Q.1950 are involved in implementing this
feature. For example, Iu and Nb interfaces comply with the 3GPP TS 25.415 protocol. For
details about the new applications and their application scenarios, see the reference list in
the 3GPP TS 29.232 protocol.
Packages of the Extended 3GPP-based Protocol feature
Table 1 describes the packages of the Extended 3GPP-based Protocol feature.

Table 1 Packages of the Extended 3GPP-based Protocol feature
Package Name
Description
3GUP package:threegup (0x002f)
Specifies the operation mode on

the user plane (Iu and Nb
interfaces).
Circuit Switched Data package:threegcsd (0x0030)
Negotiates circuit switched (CS)

data services on the GSM or
UMTS network.
TFO package:threegtfoc (0x0031)
Implements the tandem free

operation (TFO) function to reduce
the number of encoding and
decoding times in the voice stream.
Trace package:calltrace (0x0097)
Activates or deactivates MGW

tracing tasks.
Protocol Reference
For details about the Extended 3GPP-based H.248 Protocol feature, see 3GPP 29.232
protocols.

Table 1 describes the IEs carried in the common part of messages.
Table 1 the Common Part of Messages
Information
Element (IE)
Description
Indicates the version of the H.248 protocol used by the message sender.
Version
Represents the message identifier.
mid
For details about the common part of messages, see H.248 Message
Header.

ADD REQ
ADD REPLY
NTFY REQ
NTFY REPLY
MOD REQ
MOD REPLY
SUB REQ
SUB REPLY
MOV REQ
MOV REPLY
AUDIT VAL REQ
AUDIT VAL REPLY
ServiceChange REQ
ServiceChange REPLY
ADD REQ
Message Function
Associated IEs
Message Function
The ADD REQ message is used to add a termination to a context. If the MGC does not
specify an existing context by setting contextId to 0xfffffffe, the MGW creates a context.
Figure 1 shows important IEs in the ADD REQ message.
Figure 1 ADD REQ message

Associated IEs
Description
Every H.248 message contains a header.
H.248 message header
For details, see H.248 Message Header.

transactions
One or more transactions constitute an H.248 message.

For details, see transactions.
actions
One or more actions constitute a transaction.

For details, see actions.
context
One context maps to only one action.

For details, see context.
command
One or more commands constitute an action.

For details, see command.
termination
A termination receives or sends streams.

For details, see termination.
descriptor
A descriptor describes the parameters in commands.

For details, see descriptor.

ADD REPLY
Message Function
Associated IEs
Message Function
The ADD REPLY message is used to respond to the ADD REQ message. If the ADD
command fails, the MGW includes error information in the ADD REPLY message. If the
ADD command is successful, the MGW includes the context and termination information in
the ADD REPLY message. Figure 1 shows important IEs in the ADD REPLY message.
Figure 1 ADD REPLY message

Associated IEs
Description

transactions

actions

context

command

termination

descriptor


NTFY REQ
Message Function
Associated IEs
Message Function
The NTFY REQ message is used to inform the MGC of the occurrence of events in the
MGW. Common events are as follows:
g-Cause: indicates the asynchronous transfer mode (ATM) or IP termination state
and the bearer state.
g-SignalComplet: completion of signals
tonedet-std: detection of dual tone multiple frequency (DTMF) signals
gB-BNCChange: bearer change
bT-TunnelInd: tunnel indication
Figure 1 shows important IEs in the NTFY REQ message.
Figure 1 NTFY REQ message

Associated IEs
Description

transactions

actions

context

command

termination

descriptor


NTFY REPLY
Message Function
Associated IEs
Message Function
The NTFY REPLY is used to respond to the NTFY REQ message. Figure 1 shows
important IEs in the NTFY REPLY message.
Figure 1 NTFY REPLY message

Associated IEs
Description

transactions

actions

context

command

termination


MOD REQ
Message Function
Associated IEs
Message Function
The MOD REQ message is used to modify the properties, events, or signals (tones for
example) of a termination. As the MOD REQ message is used only for existing
terminations, wildcards are not allowed to represent a termination ID. Figure 1 shows
important IEs in the MOD REQ message.
Figure 1 MOD REQ message
Associated IEs
Description

transactions

actions

context

command

termination

descriptor


MOD REPLY
Message Function
Associated IEs
Message Function
The MOD REPLY message is used to respond to the MOD REQ message. If the MOD
command fails, the MGW includes error information in the MOD REPLY message. Figure 1
shows important IEs in the MOD REPLY message.
Figure 1 MOD REPLY message

Associated IEs
Description

transactions

actions

context

command

termination


SUB REQ
Message Function
Associated IEs
Message Function
The SUB REQ message is used to remove a termination from a context. After the last
termination is removed from the context, the MGW releases the context. Figure 1 shows
important IEs in the SUB REQ message.
Figure 1 SUB REQ message

Associated IEs
Description

transactions

actions

context

command

termination


SUB REPLY
Message Function
Associated IEs
Message Function
The SUB REPLY message is used to respond to the SUB REQ message. If the SUB
command fails, the MGW includes error information in the SUB REPLY message. Figure 1
shows important IEs in the SUB REPLY message.
Figure 1 SUB REPLY message

Associated IEs
Description

transactions

actions

context

command

termination

descriptor


MOV REQ
Message Function
Associated IEs
Message Function
The MOV REQ message is used to request the MGW to move a termination from one
context to another context. The contextId identifies the context to which the termination is
moved. Its value 0xfffffffe indicates that the MGW is required to create a new context.
Figure 1 shows important IEs in the MOV REQ message.
Figure 1 MOV REQ message

Associated IEs
Description

transactions
actions

context

command

termination

descriptor
It describes the parameters in commands.


MOV REPLY
Message Function
Associated IEs
Message Function
The MOV REPLY message is used by the MGW to respond to the MOD REQ message. If
the MOV command fails, the MGW includes error information in the MOV REPLY message.
If the MOV command is successful, the MGW includes the context and termination
information in the MOV REPLY message. Figure 1 shows important IEs in the MOV REPLY
message.
Figure 1 MOV REPLY message

Associated IEs
Description
transactions

actions

context

command

termination

descriptor


AUDIT VAL REQ

Message Function
Associated IEs
Message Function
The AUDIT VAL REQ message is used to return the current state of properties, events,
signals and statistics of terminations or request the contents of a descriptor or of a single
property, event, signal or statistic. Figure 1 shows important IEs in the AUDIT VAL REQ
message.
Figure 1 AUDIT VAL REQ message

Associated IEs
Description

transactions

actions

context

command

termination

descriptor


AUDIT VAL REPLY

Message Function
Associated IEs
Message Function
The AUDIT VAL REPLY message is used to respond to the AUDIT VAL REQ message.
Figure 1 and Figure 2 shows important IEs in the AUDIT VAL REPLY message.
Figure 1 AUDIT VAL REPLY message

Figure 2 AUDIT VAL REPLY message
Associated IEs
Description

transactions

actions

context

command

termination
descriptor


ServiceChange REQ
Message Function
Associated IEs
Message Function
The ServiceChange REQ message is used by:
MGW to notify the MGC that a termination or a group of terminations is about to
be taken out of service or has just returned to service.
MGW to announce its availability to the MGC (registration) and notify the MGC of
impending or completed restart of the MGW.
MGC to announce a handover to the MGW.
MGC to instruct the MGW to take a termination or a group of terminations in or
out of service.
Figure 1 shows important IEs in the ServiceChange REQ message.
Figure 1 ServiceChange REQ message

Associated IEs
Description

transactions

actions

context

command

termination

descriptor


ServiceChange REPLY
Message Function
Associated IEs
Message Function
The ServiceChange REPLY message is used by the MGW or MGC to respond to the
ServerChange REQ message. Figure 1 shows important IEs in the ServiceChange REPLY
message.
Figure 1 ServiceChange REPLY message

Associated IEs
Description
transactions

actions

context

command

termination

descriptor



H.248 Message Header
transactions
actions
context
command
termination
descriptor
termStateDescr
localControlDescriptor
localDescriptor
remoteDescriptor
signalsDescriptor
eventsDescriptor
observedEventsDescriptor
auditDescriptor
serviceChange
statisticsDescriptor
errorDescriptor
H.248 Message Header

Reference Standards
The H.248 protocol named by International Telecommunication Union-Telecommunication
Standardization Sector (ITU-T) is also known as media gateway controller (MeGaCo)
named by Internet Engineering Task Force (IETF). It is a combination of the H.323 protocol
defined by ITU-T and the Media Gateway Control Protocol (MGCP) protocol defined by
IETF.
The H.248 message header consists of the protocol version and message identifier (mid).
When the MGC interworks with the MGW, the H.248 entity, either MGC or MGW, uses the
same mid for all messages it sends out. The mid can be an IP address, domain name, or
device name; the IP address is generally used as the mid.
Information
Element
Description
(IE)
ADD REQ
H.248
message
header
unitemessagetpye: The value standardmessage indicates a
standard message type.
version: The value 1 indicates the H.248 version number.
Presently, the MGW supports versions 1 and 2, but not version 3.

address: The value 50 01 01 2D indicates that the Internet Protocol
version 4 (IPv4) address is 80.1.1.45 in decimal notation.
portNumber: The value 0xbd0 indicates that the port number is 3024
in decimal notation.
The mid of the message sender MGC is the destination IP address used in the
man-machine language (MML) command ADD H248LNK for configuring the
H.248 link on the MGW.
ADD
REPLY
H.248
message
header
unitemessagetype: The value standardmessage indicates a

standard message type.
version: The value 1 indicates the H.248 version number.
address: The value 50 3C 19 0A indicates that the IPv4 address is
80.60.25.10 in decimal notation.
portNumber: The value 0xbd0 indicates that the port number is 3024
in decimal notation.
The mid of the message sender MGW is Virtual media gateway id
preset in the SET VMGW command.
It is recommended that Virtual media gateway id be set in the

format of "IP address + port number" as used in ADD H248LNK.
This IP address, which is used for signaling forwarding, is configured
on the operation and maintenance center (OMC) interface of the
MPU board in the service frame when three SSM-32 frames are
cascaded.
Reference Standards
For details about contexts, see section 8.3 "Contexts" in ITU-T H.248.1.
transactions
Reference Standards
An H.248 message consists of one or more transactions, each of which is identified by a
transactionid. Transactions consist of one or more actions. Commands in a transaction are
executed in sequence. If a command in a transaction fails, the following commands in the
same transaction are no longer executed.
Transactions are presented as TransactionRequests. Corresponding responses to a
TransactionRequest are received in a single reply (transactionReply).
Information
Element (IE)
Description
ADD REQ
transactions
transactionRequest: It is used in the ADD REQ message to
initiate a new transaction.
transactionid: The value 0x80000075 indicates that the
transactionid is 2147483765.
ADD REPLY
transactions
transactionReply: It responds to the transactionRequest in
the ADD REQ message.

transactionid: It is the same as the transactionid in the ADD
REQ message, 2147483765.
transactionResult: indicates the transaction result.
NTFY REQ
transactions
transactionRequest: It is used in the NTFY REQ message to
initiate a new transaction.
transactionid: The value 0x9e40055e indicates that the
transactionid is 2654995806.
NTFY REPLY
transactions
transactionReply: It responds to the transactionRequest in
the NTFY REQ message.
transactionid: It is the same as the transactionid in the NTFY
REQ message, 2654995806.
transactionResult: indicates the transaction result.
Reference Standards
For details about transactions, see section 8 "Transactions" in International
Telecommunication Union-Telecommunication Standardization Sector (ITU-T) H.248.1.

actions
Reference Standards
One or more actions constitute a transaction. Each action typically specifies a contextId and
consists of a series of commands. Commands in an action are executed in sequence.
An action is initiated by an ActionRequest, which is responded with an ActionReply.
Information
Element (IE)
Description
ADD REQ
actions
ActionRequest: The ActionRequest in the ADD REQ

message initiates an action.
contextId: The value 0xfffffffe indicates creation of a context.
CommandRequest: The CommandRequest in an action
initiates a command.
ADD REPLY
actions
ActionReply: It responds to the ActionRequest in the ADD

REQ message.
contextId: The value 0x1e012e indicates that the contextId
assigned by the MGW is 1966382. For details, see context.
CommandReply: It responds to the CommandRequest.
NTFY REQ
actions
ActionRequest: The ActionRequest in the NTFY REQ
message initiates an action.
contextId: The value 0x1e012e indicates the contextId
1966382. For details, see context.
CommandRequest: The CommandRequest in an action
initiates a command.
Reference Standards
For details about actions, see section 8 "Transactions" in International Telecommunication
Union-Telecommunication Standardization Sector (ITU-T) H.248.1.
context
Reference Standards
A context maps to an action and is identified by a contextId.
A context is an association between a number of terminations. It describes the topology
(who hears/sees whom) as well as the media mixing and switching parameters if more than
two terminations are involved in the association.
Information
Element (IE)
Description
contextId: The value 0xfffffffe (4294967294 in decimal

notation) is a CHOOSE wildcard, indicating that the MGC
requests the MGW to create a context.
contextId, 32-bit identifier, is unique within the scope of the
MGW. The other values are as follows:
0xffffffff: The ALL wildcard identifies all contexts on
the MGW.
0: The NULL value indicates the NULL context
containing all terminations that are not added to any
specific context.
Specific values: Identify the contexts that have been
created by the MGW.
ADD REQ
context
contextRequest: Contains context properties.

priority: The value 0 indicates priority level 0.
The value ranges from 0 to 15; a smaller value indicates a
higher priority level.
NOTE:
If a termination is to be added to an existing context, the ADD REQ

message must contain a specific contextId. Otherwise, the contextId is
0xfffffffe.
ADD REPLY
context
contextId: The value 0x1e012e indicates that the contextId assigned
by the MGW is 1966382.
Reference Standards
For details about contexts, see section 6.1 "Contexts" in International Telecommunication
command
Reference Standards
The command consists of the termination ID field and the descriptor field. The descriptor
field contains various parameters in the command.
Commands are usually executed in pairs. The CommandRequest in an action initiates a
command and the CommandReply responds to the CommandRequest.
Information
Element (IE)
Description
ADD REQ
command
addReq: It is used to add a termination to a context. For

details on more commands, see Description of the H.248
Protocol.
terminationID: For details, see termination.
descriptors: For details, see descriptor.
ADD REPLY
command
addReply: It is used to respond to the ADD REQ message.

For details on more commands, see Description of the H.248
Protocol.
terminationAudit: It is used to return the terminal audit
information. For details, see descriptor.
NTFY REQ
command
notifyReq: It is used to notify the MGC of the occurrence of
events in the MGW. For details on more commands, see
Description of the H.248 Protocol.
observedEventsDescriptor: It is used to inform the MGC of
which events were detected. For details, see
observedEventsDescriptor.
NTFY REPLY
command
notifyReply: It is used to respond to the NTFY REQ

message. For details on more commands, see Description of
the H.248 Protocol.
AUDIT VAL REQ

command
auditValueRequest: It is used to return the current state of
properties, events, signals, and statistics of terminations. For
details on more commands, see Description of the H.248
Protocol.
auditDescriptor: For details, see auditDescriptor.
AUDIT VAL REPLY

command
auditValueReply: It is used to respond to the AUDIT VAL

REQ message. For details on more commands, see
Description of the H.248 Protocol.
errorDescriptor: For details, see errorDescriptor.

termStateDescr: For details, see termStateDescr.
localControlDescriptor: For details, see
localControlDescriptor.
Reference Standards
For details about the command, see section 7 "Commands" in International
termination
Reference Standards
A termination is a logical entity on the MGW that receives and sends media streams and
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 identities (terminationID), assigned by the MGW at the time of their creation.
Information
Element (IE)
Description
ADD REQ
termination
wildcard: indicates whether wildcards can be used as
termination IDs.
WildcardField: The value 7F indicates the ALL wildcard.
id: The value of all 0s indicates that the MGW is required to
assign an ephemeral termination.
ADD REPLY
termination
wildcard: No wildcard indicates a specified termination.

id: The value 00 00 00 00 20 1E 00 7F indicates an assigned
termination ID.
The rules for assigning termination IDs between the
MSOFTX3000 and the UMG8900 are as follows:

00 00 00 00 2X XX XX XX: indicates asynchronous
transfer mode (ATM) terminations.
00 00 00 00 3X XX XX XX: indicates IP
terminations.
00 00 00 00 4X XX XX XX: indicates time division
multiplexing (TDM) terminations.
00 00 00 00 5F XX XX XX: indicates Dummy
terminations for audio playback.
ADD REPLY (IP

termination)
termination
wildcard: No wildcard indicates a specified termination.
id: The value 00 00 00 00 30 00 04 1F indicates an assigned
termination ID.
contextId: The value is 0xffffffff.

id: The value 00 00 00 00 40 00 00 5F indicates the nonNULL context to which the to-be-audited termination is
AUDIT VAL REQ

termination
added.
contextId: The value is 0.

id: The value 00 00 00 00 40 00 00 5F indicates the to-beaudited terminations that do not belong to any specific
contexts.
ServiceChange
REQ
termination
contextId: The value is 0.

id: The value FF FF FF FF FF FF FF FF indicates a root
termination; the ServiceChange command is effective on the
entire MGW.
Reference Standards
For details about terminations, see section 6.2 "Terminations" in International
descriptor
Reference Standards
A descriptor is a syntactic element of the protocol that groups related properties. A
descriptor has a name and contains a list of parameters. Figure 1 shows the structure of
descriptors.
Figure 1 Descriptors
Information
Element (IE)
Description
ADD REQ
descriptor
mediaDescriptor: Lists media stream specifications.

streams: Lists Remote/Local/LocalControl Descriptors for
streams.
localDescriptor: For details, see localDescriptor.
eventsDescriptor: For details, see eventsDescriptor.
ADD REPLY
descriptor
terminationAudit: Returns termination information.

NTFY REQ
descriptor
observedEventsDescriptor: For details, see

observedEventsDescriptor.
ADD REPLY (IP

termination)
descriptor

streams.
MOD REQ
descriptor

streams.
remoteDescriptor: For details, see remoteDescriptor.
signalsDescriptor: For details, see signalsDescriptor.
SUB REPLY
descriptor
terminationAudit: Returns termination information.
statisticsDescriptor: For details, see statisticsDescriptor.
AUDIT VAL REQ

descriptor
auditDescriptor: For details, see auditDescriptor.
errorDescriptor: For details, see errorDescriptor.
AUDIT VAL REPLY

descriptor

ServiceChange
REQ
descriptor
serviceChangeParms: For details, see serviceChange.

Reference Standards
For details about contexts, see section 7.1 "Contexts" in International Telecommunication
termStateDescr
Reference Standards
The termStateDescr contains the termination properties that are defined in packages and
are not stream specific.
Information
Element (IE)
Description
name: The name emp-ip-interface indicates a logical

interface corresponding to an IP address.
value: The value 0 indicates that the logical interface is
numbered 0.
IP-interface is defined in the Middlebox Package.
ADD REQ (IP

termination)
termStateDescr
traceid: indicates the trace ID.

traceinfo: Provides user information.
cmode: indicates the communication mode.
muxlv: indicates the highest multiplexing level.
traceid and traceinfo are defined in the Trace Package.
cmode and muxlv are defined in the H324 Package
AUDIT VAL RLY

termStateDescr
serviceState: The value inSvc indicates that the termination is inservice and functioning normally.
The other values are as follows:
outOfSvc: The termination is out-of-service and not available

for traffic.
test: The termination is undergoing testing.
Reference Standards
For details about the termStateDescr, see section 7.1.5 "TerminationState Descriptor" in
International Telecommunication Union-Telecommunication Standardization Sector (ITU-T)
H.248.1.
For details about the Middlebox Package, see section 4 in European Telecommunications
Standards Institute (ETSI) TS101332.
The Trace Package is used for fullflow call trace between the MGW and the MGC.
For details about the H324 Package, see section 4 in ITU-T H.248.12.
Reference Standards
The localControl Descriptor contains the streamMode, reserveValue, and reserveGroup
properties and properties of a termination (defined in packages) that are stream specific.
The streamMode indicates the current service state of the termination. The reserveValue
and reserveGroup indicate how the MGW behaves after receiving the localDescriptor or
remoteDescriptor.
Information Element
Description
(IE)
streamMode: The value sendRecv indicates that the media

stream can be received and sent.
reserveValue: The value FALSE indicates that the MGW is
to reserve a single set of property values from those
indicated in the selected media group.
reservGroup: The value FALSE indicates that the MGW is
to reserve a single media group from each of the
localDescriptor and the remoteDescriptor.
name: The name bCP-BNCChar indicates the

characteristics of the added termination, that is, bearer
type of the media stream.
value: The value aal2 indicates that ATM transport is used
because the added termination is an ATM termination.
BNCChar: Backbone Network Connection Characteristics, which is
defined in the Bearer Characteristics Package.
The other value can be IP/RTP, indicating that IP transport is used
because the added termination is an IP termination.
name: The name p3gUP-mode indicates the up mode.

value: The value supp indicates the support mode.
mode: It is defined in the 3G UP Package (UP refers to User Plane).
The values are as follows:
trans: indicates the Transparent mode.
supp: indicates the Support mode for predefined service
distribution unit (SDU) sizes.
ADD
REQ(asynchronous
transfer mode (ATM)
termination)
name: The name p3gUP-DelErrSDU indicates how

erroneous SDUs are handled.
value: The value yes indicates performing error check and
setting frame quality classification.
DelErrSD: delivery of erroneous SDUs, which is defined in the 3G

UP Package.
The other value no indicates performing error check and discarding
the corrupted frame detected.
name: The name p3gUP-interface indicates the type of the

interface to which the termination is applied.
value: The value ran indicates that the termination is
applied to the RAN (Iu interface).
interface: It is defined in the 3G UP Package.
The other value cn indicates that the termination is applied to the CN
(Nb interface).
name: The name p3gUP-initDir indicates the UP

initialization direction.
value: The value in indicates that the termination receives
UP initialization initiated by the peer end.
initDir: initialization direction, which is defined in the 3G UP Package.
The other value out indicates that the termination initiates UP
initialization.
name: The name version indicates the version number of

the supported UP protocol.
value: The values are version1 (support the trans mode)
and version2 (support the supp mode).
version is defined in the 3G UP Package.
For details about the UP protocol, see Description of the
IU_UP/NB_UP Protocol.
streamMode: The value sendRecv indicates that the media

stream can be received and sent.
reserveValue: The value FALSE indicates that the MGW is
to reserve a single set of property values from those
indicated in the selected media group.
reservGroup: The value FALSE indicates that the MGW is
to reserve a single media group from each of the
localDescriptor and the remoteDescriptor.
ADD REQ (IP

termination applied
to the A interface)
name: The name net-MaxJitBuf indicates the maximum

jitter buffer.
value: The value 40 indicates that the maximum jitter buffer
is 40(ms).
MaxJitBuf: maximum jitter buffer, which is defined in the Network
Package.
name: The name bCP-BNCChar indicates the

characteristics of the added termination, that is, bearer
type of the media stream.
value: The value ip-rtp indicates that IP transport is used
because the added termination is an IP termination.
name: The name p3giptra-ipv4trans indicates the Internet

Protocol version 4 (IPv4) transport address.
value: The empty value indicates that the IP address is
contained in the returned ADD REPLY message.
ADD REQ (IP

termination applied ipv4trans: IPv4 transport address, which is defined in the IP
to the Iu interface) Transport Package.
name: The name p3giptra-UDport indicates the User

Datagram Protocol (UDP) port number.
value: The empty value indicates that the UDP port number
is contained in the returned ADD REPLY message.
UDport: UDP port, which is defined in the IP Transport Package.
ADD REPLY (IP

termination applied
to the Iu interface)
name: The name p3giptra-ipv4trans indicates the IPv4

transport address.
value: In the value 35 00 01 50 3C 3C D0 00 00 00 00 00
00 00 00 00 00 00 00 00, 50 3C 3C D0 indicates that the
transport address on the user plane is 80.60.60.208.
name: The name p3giptra-UDport indicates the UDP port

number.
value: The value 436 indicates that the port number is 436.
ADD REQ (IP

termination applied
to the Nb interface)
name: The name bT-TunOpt indicates when the MGW

reports tunneling related messages to the MGC.
value: The value any-time indicates that the MGW can
report tunneling related messages to the MGC at any time.
TunOpt: tunneling options, which is defined in the Bearer Control
Tunneling Package.
Reference Standards
For details about the localControlDescriptor, see section 7.1.7 "LocalControl Descriptor"in
H.248.1.
For details about the Bearer Characteristics Package, see Annex A in ITU-T Q.1950.
For details about the 3G UP Package, see section 15 in 3rd Generation Partnership Project
(3GPP) TS 29.232.
For details about the Network Package, see Annex E "Basic packages" in ITU-T H.248.1.
For details about the IP Transport Package, see section 15 in 3GPP TS 29.232.
For details about the Bearer Control Tunneling Package, see Annex A in ITU-T Q.1950.
localDescriptor
Reference Standards
The localDescriptor describes the media stream received by the MGW. If the
localDescriptor is present in the message delivered by the MGC, the MGW is required to
reserve media encoding and decoding resources for the termination. The localDescriptor
present in the message returned by the MGW indicates the resources supported by the
MGW. Text encoding of the localDescriptor complies with the Session Description Protocol
(SDP).
The localDescriptor consists of media groups (propGrps) and related properties
(LRPropertyParm).
Information
Element (IE)
Description
name: The name sdp-v indicates the version of the SDP

protocol.
sdpString: The value 0 indicates that the version number is 0.
name: The name sdp-c indicates the connection set up for a

media session.
sdpString: The value ATM NSAP $ indicates an ATM
connection without knowing the network service access point

(NSAP) address.
name: The name sdp-m indicates the media type, that is,
media name and transport address.
sdpString: The value audio- - - indicates audio media; indicates that port information is not required for media
streams using the ATM connection.
ADD REQ
(asynchronous
transfer mode
(ATM) termination)
localDescriptor
name: The name sdp-a indicates zero or more session

attribute lines.
sdpString: The value eecid:$ indicates that the end-to-end
connection identifier (cid) of the ATM user plane is unknown
and the MGW is requested to assign the cid.

attribute lines.
sdpString: The value vsel:UMTS-AMR indicates that the
codec used is UMTS-AMR.

attribute lines.
sdpString: The value codecconfig:02053F3F06 indicates the
codec configuration.
02, which indicates the codec organization identifier,
represents 3rd Generation Partnership Project
(3GPP).
05, which indicates the codec identification,
represents Universal Mobile Telecommunications
System (UMTS) automatic meter reading system
(AMR).
3F indicates the active codec set (ACS); that is, the
active rates are 4.75 kbit/s, 5.15 kbit/s, 5.9 kbit/s,
6.7 kbit/s, 7.4 kbit/s, and 7.95 kbit/s.
3F indicates the supported codec set (SCS); that is,
the supported rates are 4.75 kbit/s, 5.15 kbit/s, 5.9
kbit/s, 6.7 kbit/s, 7.4 kbit/s, and 7.95 kbit/s.
06 indicates that the optimization mode (OM) is 0
(the given ACS will not be changed) and the
maximal number of codec modes (MACS) is 6.

media session.
sdpString: The value ATM NSAP
4700.0000.0000.0000.0000.0000.0000.0000.0000.0C28
indicates the returned NSAP address.
This address is the NSAP address configured on the MGW for adding
a Q.AAL2 node.
ADD REPLY (ATM

termination)
localDescriptor
attribute lines.
sdpString: The value eecid:981e007f indicates the returned
cid of the ATM user plane.
The least significant 7 bits (0011000) in the first byte 98 indicates that
the virtual MGW ID is 24.
The last 3 bytes (1e007f) are the last 3 bytes in the ATM termination
ID.
1E is the board number of the CMU (30); 00 7F is the termination

index ID.
media session.
sdpString: The value IN IP4 $ indicates an INTERNET
connection without knowing the Internet Protocol version 4
(IPv4) address.
sdpString: The value audio $ RTP/AVP 112 indicates audio
media, unknown port, Real-Time Transport Protocol
(RTP)/attribute-value pair (AVP) as the transport protocol,
and 112 as the payload type (PT).

attribute lines.
sdpString: The value rtpmap:112 AMR/8000/1 indicates that
the PT 112 corresponds to the codec AMR, with the sampling
frequency at 8000 Hz and the number of channels at 1.
ADD REPLY (IP

termination)
localDescriptor

attribute lines.
sdpString: The value ptime:20 indicates 20 ms of packet

time.

attribute lines.
sdpString: The value fmtp:112mode-set=0,1,2,3,4,5;modechange-period=2 indicates that the bit rates of the used
codecs are 4.75 kbit/s, 5.15 kbit/s, 5.9 kbit/s, 6.7 kbit/s, 7.4
kbit/s, and 7.95 kbit/s.
The mapping between codec numbers and bit rates is as
follows:
0:
1:
2:
3:
4:
5:
6:
7:
4.75 kbit/s
5.15 kbit/s
5.9 kbit/s
6.7 kbit/s
7.4 kbit/s
7.95 kbit/s
10.2 kbit/s
12.2 kbit/s

attribute lines.
sdpString: The value maxPTime:20 indicates that the
maximum packet time is 20 ms.

media session.
sdpString: The value IN IP4 80.60.60.208 indicates the IP
address 80.60.60.208; this IP address is configured for the
HRB on the MGW.
ADD REPLY (IP

termination)
localDescriptor
sdpString: The value audio 128 RTP/AVP 112 indicates
audio media, port number 128, RTP/AVP as the transport
protocol, and 112 as the PT.

attribute lines.
sdpString: The value rtpmap:112 AMR/8000 indicates that
the PT 112 corresponds to the codec AMR, with the sampling
frequency at 8000 Hz.
Reference Standards
For details about the localDescriptor, see section 7.1.8 "Local and Remote Descriptors" in
H.248.1.
For details about the SDP, see Internet Engineering Task Force (IETF) RFC 2327.
For details about the audio codec protocol, see 3GPP TS 26103.
remoteDescriptor
Reference Standards
The remoteDescriptor describes the media stream sent by the MGW. If the
remoteDescriptor is present in the message delivered by the MGC, the MGW is required to
reserve media encoding and decoding resources for the termination. Text encoding of the
remoteDescriptor complies with the Session Description Protocol (SDP).
The remoteDescriptor consists of media groups (propGrps) and related properties
(LRPropertyParm).
Information
Element (IE)
MOD REQ (IP

termination
applied to the A
interface)
remoteDescriptor
Description

media session.
sdpString: The value IN IP4 80.1.2.145 indicates an Internet
connection with the IP address 80.1.2.145. This IP address
is the user's IP address on the bearer plane of the BSC.
sdpString: The value audio 96 RTP/AVP 112 indicates audio
media, port number 96, Real-Time Transport Protocol

(RTP)/attribute-value pair (AVP) as the transport protocol,
and 112 as the payload type (PT).
Reference Standards
For details about the remotelDescriptor, see section 7.1.8 "Local and Remote Descriptors"
in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T)
H.248.1.
For details about the SDP, see Internet Engineering Task Force (IETF) RFC 2327.
signalsDescriptor
Reference Standards
The signalsDescriptor contains a set of signals that the MGW is requested to apply to a
termination.
Information
Element (IE)
MOD REQ
signalsDescriptor
Description
signalName: The name tonegen-RingTone indicates a

ringing tone.
sigType: The type timeOut indicates that the signal lasts until
it is turned off or a specific period of time elapses.
The other signal types are as follows:
brief: The signal will stop on its own unless a new
signalsDescriptor is applied that causes it to stop;
no timeout value is needed.
onOff: The signal lasts until it is turned off.
duration: The value 0xffff indicates the time that the signal
lasts.
notifyCompletion: The value 1001 indicates that the MGC
wishes to be notified when the signal finishes play out.
RingTone is defined in tonegen.
Reference Standards
For details about descriptors, see section 7.1.11 "Signals Descriptor" in International
For details about tonegen, see Annex E "Basic packages" in ITU-T H.248.1.
eventsDescriptor
Reference Standards
The eventsDescriptor contains a requestID and a list of events that the MGW is requested
to detect and report. The requestID is used to correlate the request with the notifications
that it may trigger.
Information
Element (IE)
Description
requestID: The value is 0.

pkgdName: The value g-Cause indicates that the MGC
requests the MGW to report the Cause event.
The Cause event is defined in the Generic package.
The meanings of Cause values are as follows:
NR: Normal Release
UR: Unavailable Resources
FT: Failure, Temporary
FP: Failure, Permanent
IW: Interworking Error
UN: Unsupported
ADD REQ
eventsDescriptor
eventParameterName: The value gB-BNCChange:Ox1(1)

indicates that the MGC requests the MGW to report the
BNCChange event.
tag: The value stag indicates an encoding format.
gB-BNCChange: The value bearer-Established(1) indicates
that the MGC requests the MGW to report the result of
bearer-Established in the BNCChange event.
The BNCChange event is defined in the Generic Bearer Connection
Package.

BNCChange event with the ID of 1.

gB-BNCChange: The value bearer-ModificationFailure(1)
result of bearer-ModificationFailure in the BNCChange event.

BNCChange event with the ID of 1.
gB-BNCChange: The value bearer-Modified(2) indicates that
the MGC requests the MGW to report the result of bearerModified in the BNCChange event.
Reference Standards
For details about the eventsDescriptor, see section 7.1.9 "Events Descriptor" in
H.248.1.
For details about the Generic package, see Annex E "Generic package" in ITU-T H.248.1.
For details about the Generic Bearer Connection Package, see Annex A in ITU-T Q.1950.
Reference Standards
The observedEventsDescriptor consists of the requestID and the parameters of the events
detected by the MGW. The requestID is used to associate the event request with the Notify
command.
requestID: The requestID is 0, which is the same as
NTFY REQ
that in the eventsDescriptor.

eventParameterName: The value gBBNCChange:Ox1(1) indicates that the MGW reports
the BNCChange event.
gB-BNCChange: The value bearer-Established(1)
indicates that the MGW reports the result of bearerEstablished in the BNCChange event.
date: The value 20101110 indicates that the event
occurred on November 10, 2010.
time: The value 14480688 indicates that the event
occurred at 14:48:06.
eventParameterName: The value g-Cause:cause(1)

indicates that the MGW reports the Cause event.
gCause: The value normal-release(1) indicates that
bearer resources are released normally.
For information about IEs in the BNCChange and Cause events,
see eventsDescriptor.
Reference Standards
For details about the observedEventsDescriptor, see section 7.1.17 "ObservedEvents
Descriptor" in International Telecommunication Union-Telecommunication Standardization
Sector (ITU-T) H.248.1.
For details about the Generic Bearer Connection Package, see Annex A in ITU-T Q.1950.
auditDescriptor
Reference Standards
The auditDescriptor specifies what information about a termination is to be audited. It
consists of the list of descriptors and individual properties to be returned. Audit may be
used in any command to force the return of any descriptor containing the current values of
its properties, events, signals and statistics.
Information
Element (IE)
Description
auditToken: The value 0010000000 indicates that the mediaDescriptor

is to be audited.
The meanings of auditToken values are as follows:
AUDIT VAL REQ
auditDescriptor
Bit
Bit
Bit
Bit
Bit
Bit
Bit
Bit
Bit
Bit
0: muxToken
1:modemToken
2: mediaToken
3: eventsToken
4: signalsToken
5: digitMapToken
6: statsToken
7: observedEventsToken
8: packagesToken
9: eventBufferToken
Reference Standards
For details about the auditDescriptor, see section 7.1.12 "Audit Descriptor" in International

serviceChange
Reference Standards
The serviceChange includes the serviceChangeMethod field and the reason field.
Information
Element (IE)
Description
When running a command to deactivate the MGW, the MGC sends the
ServiceChange REQ message to notify the MGW that it shall terminate
services running on all terminations.
serviceChangeMethod: The value forced indicates that the
specified terminations were taken abruptly out of service and all
established connections associated with them will be lost.
The other service change methods specified in the H.248.1
protocol are as follows:
Failover: It is sent from the MGW to the MGC,
indicating that the primary MGW is out of service and a
secondary MGW is taking over.
Graceful: It indicates that the specified terminations will
be taken out of service after the specified
ServiceChangeDelay; established connections are not
yet affected. However, the MGC should refrain from
establishing new connections and should attempt to
gracefully tear down existing connections on the
terminations affected by the serviceChange command.
Restart: When sent by the MGW to the MGC, it
announces that the MGW has restarted and wishes to
ServiceChange
REQ
serviceChange
renegotiate the protocol version, profile, or is

announcing a capability change. The
ServiceChangeReason indicates what actions may
need to be taken by the MGC. When sent by the MGC,
the MGW shall restart itself using the indicated
ServiceChangeReason.
Disconnect: It is always applied with the Root
TerminationID, indicating that the MGW lost
communication with the MGC, but it was subsequently
restored to the same MGC. Since MGW state may
have changed, the MGC may wish to use the Audit
command to resynchronize its state with the MGW's.
Handoff: When sent from the MGC to the MGW, this
method indicates that the MGC is going out of service
and a new MGC association must be established.
When sent from the MGW to the MGC, this indicates
that the MGW is attempting to establish a new
association in accordance with a Handoff received from
the MGC with which it was previously associated.
Another value whose meaning is mutually understood
between the MGW and the MGC.
reason: The value 03 8D indicates that the cause is MGC
Impending Failure.
The MGW sends the ServiceChange REQ message to register itself with
an MGC and inform the MGC to perform parameter negotiations.
serviceChangeMethod: The value restart indicates that the
MGW registers with an MGC after it is restarted.
serviceChangeVersion: The value 1 indicates that the message
sender supports H.248 version 1.

reason: The value 03 86 indicates that the reason for service
change is Warm Boot.
Reference Standards
For details about the serviceChange, see section 7.1.13 "ServiceChange Descriptor" in
H.248.1.
For details about the serviceChange, see section 5.2 in ITU-T H.248.8.
Reference Standards
The statisticsDescriptor provides information describing the status and usage of a
termination during its existence (ephemeral) or while it is outside the NULL context
(physical).
The statisticsDescriptor consists of statistics parameters.
Information
Element (IE)
Description
statName: The value net-Duration indicates the duration of a

termination's existence in a context.
OCTET-STRING: The value 00 00 00 00 00 00 50 82
indicates that a termination has existed for 20610 ms.
Duration is defined in the Network Package.
SUB REPLY
statName: The value net-OctetsReceived indicates the
number of bytes received by a termination.
OCTET-STRING: The value 00 00 00 00 00 00 3F EC
indicates that a termination has received 16364 bytes.
OctetsReceived is defined in the Network Package.
statName: The value rtp-PacketsSent indicates the number

of packets sent by a termination.
OCTET-STRING: The value 00 00 00 00 00 00 03 A0
indicates that a termination has sent 928 packets.
PacketsSent is defined in the Real-Time Transport Protocol (RTP)
Package.
Reference Standards
For details about the statisticsDescriptor, see section 7.1.15 "Statistics Descriptor" in
H.248.1.
errorDescriptor
Reference Standards
If a responder encounters an error when processing a transaction request, it must include
an errorDescriptor in its response.
An errorDescriptor consists of an IANA-registered error code, optionally accompanied by
an error text. (Internet Assigned Numbers Authority (IANA) is short for Internet Assigned
Numbers Authority.)
Information
Element (IE)
Description
AUDIT_VAL_RLY
errorDescriptor
errorCode: The value errTermNotInSpecCtx indicates that

the error cause is "Termination ID is not in Specified Context."
errorText: The value Termination ID is not in Specified
Context indicates that a termination to be audited does not
exist in the specified context.
Reference Standards
For details about the errorDescriptor, see section 7.1.20 "Error Descriptor" in International
Q.AAL2 Protocol
Description of the Q.AAL2 Protocol
Description of the Q.AAL2 Protocol

Protocol Stack
Message Structure
IE Structure
Message List
Reference Standards
As the AAL2 signaling protocol, the Q.AAL2 protocol is used to perform signaling
negotiations to establish, release, and maintain the asynchronous transfer mode (ATM)
Adaption Layer type 2 (AAL type 2) connections between two AAL2 signaling nodes. The
AAL2 protocol is a transport layer protocol that is dedicated to transporting low-speed,
real-time, and multirate connection services, for example, voice compression. The Q.AAL2
protocol is a control plane protocol used in the transport layer. It is dedicated to controlling
AAL2 connections.
The Q.AAL2 protocol allows AAL2 signaling nodes (such as RNC and MGW) to exchange
signaling messages with each other when ATM transport is used on the Iu interface in 3G
services. It can be used in any of the following scenarios:
1. An AAL2 connection is established.
2. An AAL2 connection is released.
Protocol Stack
Figure 1 shows the Q.AAL2 protocol stack.
Figure 1 Q.AAL2 protocol stack

Message Structure
The Q.AAL2 message consists of the message compatibility field and the parameters field.
A parameters field contains one or multiple parameters. Each parameter consists of the
parameter compatibility field and the parameter value field. Figure 2 shows the hierarchical
structure of the Q.AAL2 message.
Figure 2 Hierarchical structure of the Q.AAL2 message
IE Structure
Figure 3 shows the Information Element (IE) Structure of the Q.AAL2 message.
Message List
Table 1 lists the common Q.AAL2 messages.
Table 1 List of Q.AAL2 messages
Message
Direction
Function
ERQ
RNC>MGW
Requests the MGW to establish an AAL2 connection.
ECF
MGW>RNC
Responds to the establish request (ERQ) message.
REL
RNC>MGW
Requests the MGW to release an AAL2 connection.
RLC
MGW>RNC
Responds to the release (REL) message.
Reference Standards
For details about the Q.AAL2 protocol, see the International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.2630.1.
Parent topic: Q.AAL2 Protocol

Table 1describes the IEs carried in the common part of messages.
Table 1 the Common Part of Messages
Information
Element (IE)
Description
Identifies the signaling association of the receiver.
destination signaling
association identifier
For details about the common part of messages, see Q.AAL2

Message Header.


ERQ
ECF
REL
RLC
ERQ
Message Function
Associated IEs
Message Function
The establish request (ERQ) message is used by the RNC to request the MGW to
establish an ATM Adaptation Layer Type 2 (AAL2) connection. Figure 1 shows important
IEs in the ERQ message.
Figure 1 ERQ message

Associated IEs
Description
Q.AAL2 message header
Indicates the header information of the Q.AAL2 message.

Every Q.AAL2 message contains a header.
For details, see Q.AAL2 Message Header.
message
Identifies a Q.AAL2 message.

For details, see message.
message_compatibility
Indicates the compatibility information about the message.

For details, see message_compatibility.
establishRequest-Param
Indicates the parameter carried in the ERQ message.

For details, see establishRequestParam.

ECF
Message Function
Associated IEs
Message Function
The establish confirm (ECF) message is used by the MGW to respond to the establish
request (ERQ) message sent by the RNC. Figure 1 shows important IEs in the ECF
message.
Figure 1 ECF message

Associated IEs
Description

Q.ATM Adaptation Layer Type Every Q.AAL2 message contains a header.
2 (AAL2) message header
message


establishConfirm-Param
Indicates the parameter carried in the ECF message.

For details, see establishConfirm-Param.

REL
Message Function
Associated IEs
Message Function
The release (REL) message is used by the RNC to request the MGW to release an ATM
Adaptation Layer Type 2 (AAL2) connection. Figure 1 shows important IEs in the REL
message.
Figure 1 REL message

Associated IEs
Description

message


releaseRequest-Param
Indicates the parameter carried in the REL message.

For details, see releaseRequest-Param.

RLC
Message Function
Associated IEs
Message Function
The Release Confirm (RLC) message is used by the MGW to respond to the release (REL)
message sent by the RNC. Figure 1 shows important IEs in the RLC message.
Figure 1 RLC message

Associated IEs
Description

message


releaseCofirm-Param
Indicates the parameter carried in the RLC message.

For details, see releaseConfirm-param.


Q.AAL2 Message Header
message
establishRequestParam
releaseConfirm-param
connection-element-identifier
originating-signaling-association-identifier
aal2-service-endpoint-address
link-characteristics
served-user-generated-reference
cause
Q.AAL2 Message Header

Reference Standards
The Q.AAL2 message header consists only of the destination signaling association identifier
field.
A signaling association indicates a signaling capability that exists between two adjacent
AAL2 nodes. It controls the AAL2 connections that may exist in one or more AAL2 paths.
Information
Element (IE)
Description
establish request
(ERQ)
dsaid: The value 0 indicates that the destination signaling association
Q.AAL2 message identifier is unknown. A specific value of this field indicates the
header
signaling association identifier of the receiver.
Establish Confirm
(ECF)
Q.AAL2 message dsaid: The value 40 indicates the signaling association identifier on the
RNC. For details, see originating-signaling-association-identifier.
header
Release (REL)
Q.AAL2 message
header
dsaid: The value 83886091 indicates the signaling association identifier

on the MGW. For details, see originating-signaling-associationidentifier.
The ASU uses the four-byte said to identify the asynchronous transfer
mode (ATM) termination. The most significant byte identifies its board
number.
Reference Standards
For details about the destination signaling association identifier, see section 7.4.2 "Signaling
association identifier" in International Telecommunication Union-Telecommunication
Standardization Sector (ITU-T) Q.2630.1.

message
Reference Standards
The message consists of the message compatibility field and the parameters field.
Information
Element (IE)
Description
establish request
(ERQ)
message
establishrequest: It is used by the RNC to request the MGW to
establish an ATM Adaptation Layer Type 2 (AAL2) connection.
message-compatibility: For details, see message_compatibility.
establishRequest-param: For details, see establishRequestParam.
Establish
Confirm(ECF)
message
Release (REL)
message
establishconfirm: It is used by the MGW to respond to the ERQ

message sent by the RNC.
establishConfirm-param: For details, see establishConfirm-Param.
releaserequest: It is used by the RNC to request the MGW to release

an AAL2 connection.
releaseRequest-param: For details, see releaseRequest-Param.
Release
Confirm(RLC)
message
releaseconfirm: It is used to respond to the REL message sent by the

RNC.
releaseCofirm-param: For details, see releaseConfirm-param.
Reference Standards
For details about the message, see section 7.2 "Format and coding of the ATM Adaptation
Layer (AAL) type 2 signaling protocol messages" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.2630.1.
Reference Standards
The message_compatibility is used by an ATM Adaptation Layer Type 2 (AAL2) node to
process the unrecognized signaling information. It allows the protocol of an earlier version
to process the messages coded using the protocol of a later version.
Information Element
Description
(IE)
ERQ
pass-on-impossible-reserved: The value 0 indicates that

the unrecognized parameter is reserved.
pass-on-impossible-sendNotif: The value do-not-sendnotification indicates that the notification is not sent if the
unrecognized message or parameter cannot be forwarded.
send-notification: Sends the notification.
pass-on-impossible-instruction: The value pass-onmessage-or-parameter indicates that the unrecognized
message or parameter is forwarded.
Other values are as follows:
discard-parameter: Discards parameters.
discard-message: Discards the message.
general-action-reserved: The value 0 indicates that the
unrecognized parameter is reserved.
general-action-sendNotificaion: The value sendnotification indicates that the notification is sent when
general actions are performed.
general-action-instruction: The value discard-message
indicates that the unrecognized message is discarded
when general actions are performed.
Reference Standards
For details about the message_compatibility, see section 8.1 "Compatibility" in International
Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q.2630.1.
establishRequestParam
Reference Standards
The establishRequestParam contains parameters carried in the ERQ message.
Information Element
(IE)
Description
ERQ
establishRequestParam connection-element-identifier: For details, see connection-elementidentifier.
originating-signaling-association-identifier: For details, see
originating-signaling-association-identifier.
aal2service-endpoint-address: For details, see aal2-serviceendpoint-address.
link-characteristics: For details, see link-characteristics.
served-user-generated-reference: For details, see served-usergenerated-reference.
Reference Standards
For details about the establishRequestParam, see section 7.3 "Parameter specification of
the ATM Adaptation Layer (AAL) type 2 signaling protocol messages" in International
Reference Standards
The establishConfirm-Param contains parameters carried in the ECF message.
Information
Element (IE)
ECF
establishConfirmParam
Description
osaid: For details, see originating-signaling-association-identifier.
Reference Standards
For details about the establishConfirm-Param, see section 7.3 "Parameter specification of
Reference Standards
The releaseRequest-Param contains parameters carried in the REL message.
Information
Element (IE)
REL
releaseRequestParam
Description
cause: For details, see cause.
Reference Standards
For details about the releaseRequest-Param, see section 7.3 "Parameter specification of
releaseConfirm-param
Reference Standards
The releaseConfirm-param contains parameters carried in the RLC message.
Information
Element (IE)
RLC
releaseConfirmparam
Description
ceid: For details, see connection-element-identifier.
Reference Standards
For details about the releaseConfirm-param, see section 7.3 "Parameter specification of
connection-element-identifier
Reference Standards
The connection-element-identifier identifies all ATM Adaptation Layer Type 2 (AAL2) paths
between two adjacent AAL2 nodes associated with a signaling association, a particular
AAL2 path, or a particular channel on a particular AAL2 path.
Information
Element (IE)
Description
compatibility: The parameter compatibility is similar with

message compatibility. For details, see
message_compatibility.
Establish request
(ERQ)
connection-elementidentifier
pass-on-impossible-reserved: The value 0 indicates

that the unrecognized parameter is reserved.
pass-on-impossible-sendNotif: The value do-notsend-notification indicates that the notification is
not sent if the unrecognized message or parameter
cannot be forwarded.
pass-on-impossible-instruction: The value pass-onmessage-or-parameter indicates that the
unrecognized message or parameter is forwarded.
general-action-reserved: The value 0 indicates that
general-action-sendNotificaion: The value sendnotification indicates that the notification is sent
general-action-instruction: The value discard-
message indicates that the unrecognized message

is discarded when general actions are performed.
ceid: indicates the connection element identifier.
path-identifier: The value 13 indicates that the
identifier of the AAL2 path is 13.
channel-identifier: The value 236 indicates that the
channel identifier is 236.
The asynchronous transfer mode (ATM) transport is
connection-oriented and a virtual circuit (VC) must be
established before data transfer. In addition, each VC maps
to an AAL2 path. Every VC is identified by a Virtual Path
Identifier (VPI) and a Virtual Channel Identifier (VCI).
NOTE:
You can run LST AAL2PATH to query AAL2 connections on the MGW
side.
Reference Standards
For details about the connection-element-identifier, see section 7.3.2 "Connection element
identifier" in International Telecommunication Union-Telecommunication Standardization
Sector (ITU-T) Q.2630.1.
originating-signaling-association-identifier
Reference Standards
The originating-signaling-association-identifier indicates the signaling association identifier of
the originating ATM Adaptation Layer Type 2 (AAL2) node.
Information
Element (IE)
Description

establish request
(ERQ)
originating-signalingassociationidentifier

general-action-instruction: The value discardparameter indicates that unrecognized parameter is
discarded when general actions are performed.
osaid: The value 40 indicates that the signaling association

identifier (SAID) of the originating AAL2 node is 40.
Event charging
function (ECF)
osaid
osaid: The value 83886091 indicates that the SAID of the originating
AAL2 node on the MGW side is 83886091.
The ASU uses the four-byte SAID that is allocated by the Q.AAL2
module on each ASU, to identify the asynchronous transfer mode
(ATM) termination. The most significant byte identifies its board
number.
Reference Standards
For details about the originating-signaling-association-identifier, see section 7.3.6
"Originating signaling association identifier" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.2630.1.
aal2-service-endpoint-address
Reference Standards
The aal2-service-endpoint-address can be the destination Network Service Access Point
(NSAP) service endpoint address that is configured on the MGW. The RNC can obtain the
address from the radio access bearer (RAB) ASSIGNMENT REQUEST message sent by
the MGC.
Information
Element (IE)
Description

Establish request
(ERQ)
originating-signalingassociationidentifier

general-action-sendNotificaion: The value do-notsend-notification indicates that the notification is
not sent when general actions are performed.
general-action-instruction: The value pass-onmessage-or-parameter indicates that the

unrecognized information or parameter is forwarded
nsap: The value
4700.0000.0000.0000.0000.0000.0000.0000.0000.0C28
indicates the NSAP service endpoint address on the MGW
side. For details, see localDescriptor.
Reference Standards
For details about the aal2-service-endpoint-address, see section 7.3.4 "Destination NSAP
service endpoint address" in International Telecommunication Union-Telecommunication
Reference Standards
The link-characteristics contains attributes related to ATM Adaptation Layer Type 2 (AAL2)
links.
Information
Element (IE)
Description

Establish request
(ERQ)

maxBitRate: indicates the maximum CPS-SDU bit rate
available to the AAL2 served user.
forwardBitRate: The value 191 indicates that the
maximum CPS-SDU bit rate in the forward direction
is 191 kbit/s.
backwardBitRate: The value 191 indicates that the
maximum CPS-SDU bit rate in the backward
direction is 191 kbit/s.
averageBitRate: indicates the average CPS-SDU bit rate
available to the AAL2 served user.
forwardBitRate: The value 191 indicates that the
average CPS-SDU bit rate in the forward direction
is 191 kbit/s.
backwardBitRate: The value 191 indicates that the
average CPS-SDU bit rate in the backward direction
is 191 kbit/s.
maxSize: indicates the maximum AAL2 CPS-SDU size, in
bytes, allowed to be sent.
forwardSize: The value 45 indicates that the
maximum CPS-SDU size in the forward direction is
45 bytes.
backwardSize: The value 45 indicates that the
maximum CPS-SDU size in the backward direction
is 45 bytes.
averageSize: indicates the average AAL2 CPS-SDU size, in
bytes, allowed to be sent.
forwardSize: The value 45 indicates that the
average CPS-SDU size in the forward direction is
45 bytes.
backwardSize: The value 45 indicates that the
average CPS-SDU size in the backward direction is
45 bytes.
Reference Standards
For details about the link-characteristics, see section 7.3.5 "Link characteristics" in
Q.2630.1.
served-user-generated-reference
Reference Standards
The served-user-generated-reference uniquely identifies the radio access bearer (RAB)
management and control module on the MGW side.
Information
Element (IE)
Description

Establish request
(ERQ)
served-usergeneratedreference

sugr: The value 0x981e007f indicates that the served user

generated reference is 2552103039, which can be obtained
by the RNC from the RAB ASSIGNMENT REQUEST
message sent by the MGC. For details, see localDescriptor.
Reference Standards
For details about the served-user-generated-reference, see section 7.3.7 "Served user
generated reference" in International Telecommunication Union-Telecommunication
cause
Reference Standards
The cause describes why an ATM Adaptation Layer Type 2 (AAL2) connection is released
or fails to be established.
Information
Element (IE)
Description

Release (REL)
cause


general-action-instruction: The value discardparameter indicates that unrecognized parameter is
discarded when general actions are performed.
cause-value: indicates the cause value.
reserved1: The value 0 indicates the unrecognized
parameter is reserved.
coding-standard: The value itu-t-standardized
indicates that International Telecommunication
Union-Telecommunication Standardization Sector
(ITU-T) standardized codes are used.
reserved2: The value 0 indicates the unrecognized
parameter is reserved.
cause: The value normal-unspecified indicates that
it is a normal connection release.
diagnostics: indicates the diagnostics information.
Reference Standards
For details about the cause, see section 7.3.1 "Cause" in ITU-T Q.2630.1.
IU_UP/NB_UP Protocol
Description of the IU_UP/NB_UP Protocol
Description of the IU_UP/NB_UP Protocol

Protocol Stack
Message Structure
IE Structure
Message List
Reference Standards
The user plane (UP) protocol is used to convey user data associated to Radio Access
Bearers (RABs).
The UP protocol can be classified into the IU_UP protocol and the NB_UP protocol based
on the interface over which it is used. The control procedures of the two protocols,
however, are the same.
IU_UP: The Iu interface is used to transfer user data and user plane signaling
between an RNC and an MGW. The IU_UP protocol is used for UP operations
performed between an RNC and an MGW.
NB_UP: The Nb interface is used to transfer user data and user plane signaling
between two MGWs. The NB_UP protocol is used for UP operations performed
between two MGWs.
Modes of operation of the IU_UP/NB_UP protocol are defined as follows:
Transparent mode: This mode is intended for those RABs that do not require any
particular feature from the IU_UP/NB_UP protocol other than transfer of user data.
In this mode, no UP frame is sent. The typical services in this mode are H.324M
video phone (VP) services and transparent data services.
Support mode for predefined service distribution unit (SDU) size: This mode is
intended for those RABs that require some procedure control functions and some
data streams specific functions while the sizes of the user data being transferred
can vary in a predefined manner. The typical services in this mode are voice
services and non-transparent data services.
The IU_UP/NB_UP protocol is used during the negotiation in the user plane of the Iu or Nb
interface. The protocol in support mode for pre-defined SDU sizes can be used in any of the
following scenarios:
1. UP initialization and exchange of bearer path information between an RNC and an

MGW or between two MGWs.
2. Time alignment between an RNC and an MGW or between two MGWs.
3. Rate control between an RNC and an MGW or between two MGWs. This
procedure controls the allowed rate sets between transmission entities.
4. Handling of error events between an RNC and an MGW or between two MGWs.
This procedure controls fault monitoring information.
5. Transfer of user data between an RNC and an MGW or between two MGWs.
Protocol Stack
Figure 1 shows the protocol stack of the IU_UP protocol carried over asynchronous transfer
mode (ATM).
Figure 1 Protocol stack of the IU_UP protocol carried over ATM

Figure 2 shows the protocol stack of the IU_UP/NB_UP protocol carried over IP.
Figure 2 Protocol stack of the IU_UP/NB_UP protocol carried over IP
Message Structure
An IU_UP/NB_UP message consists of a message header, the Frame Control part, the
Frame Checksum part, and the Frame Payload part. Figure 3 shows the hierarchical
structure of the IU_UP/NB_UP message.
Figure 3 Hierarchical structure of the IU_UP/NB_UP message
IE Structure
Figure 4 shows the Information Element (IE) Structure of the IU_UP/NB_UP message.
Message List
Table 1 lists common IU_UP/NB_UP messages.
Table 1 List of common IU_UP/NB_UP messages
Message
Direction Function
TRC_IU/NB_UP_INIT (Sent
by RNC)
RNC>MGW
Sends an IU_UP initialization frame transported

over ATM.
TRC_IU/NB_UP_INIT (Sent
by MGW)
MGW>RNC
Responds to the IU_UP initialization frame

transported over ATM.
TRC_IU/NB_UP_INIT_TOIP
RNC>MGW
MGW>MGW
Sends an IU_UP initialization frame transported

over IP.
Sends an NB_UP initialization frame.
MGW-
>RNC
MGW>MGW
Responds to the IU_UP initialization frame

transported over IP.
Responds to the NB_UP initialization frame.
TRC_IU/NB_UP_TA
(Received)
RNC>MGW
MGW>MGW
Sends an IU_UP time alignment frame.

Sends an NB_UP time alignment frame.
TRC_IU/NB_UP_TA (Sent)
MGW>RNC
MGW>MGW
Responds to the UP time alignment frame.
TRC_IU/NB_UP_ACK_FRMIP
Reference Standards
For details about the IU_UP protocol, see 3rd Generation Partnership Project (3GPP) TS
25.415 versions.
For details about the NB_UP protocol, see 3GPP TS 29.415 versions.
Parent topic: IU_UP/NB_UP Protocol

There is no common part in IU_UP/NB_UP messages.

TRC_IU/NB_UP_INIT (Sent by RNC)
TRC_IU/NB_UP_INIT (Sent by MGW)
TRC_IU/NB_UP_TA (Received)
TRC_IU/NB_UP_INIT (Sent by RNC)

Message Function
Associated IEs
Message Function
The TRC_IU/NB_UP_INIT message (sent by RNC) is used by the RNC to send an UP
initialization frame to the MGW, controlling the exchange of initialization information such as
the radio access bearer (RAB) sub-Flow Combination Indicator (RFCI). Figure 1 shows
important IEs in the TRC_IU/NB_UP_INIT message (sent by RNC).
Figure 1 TRC_IU/NB_UP_INIT message

Associated IEs
Description
IU_UP/NB_UP message
header
Indicates the header information of IU_UP/NB_UP

messages.
For details, see IU_UP/NB_UP Message Header.
frameControlPart
Indicates the frame control information of IU_UP/NB_UP

messages.
For details, see frameControlPart.
frameChecksumPart
Indicates the frame checksum information of IU_UP/NB_UP

messages.
For details, see frameChecksumPart.
framePayloadPart
Indicates the frame payload information of IU_UP/NB_UP

messages.
For details, see framePayloadPart.

TRC_IU/NB_UP_INIT (Sent by MGW)

Message Function
Associated IEs
Message Function
The TRC_IU/NB_UP_INIT message (sent by MGW) is used by the MGW to respond to the
UP initialization frame. Figure 1 shows important IEs in the TRC_IU/NB_UP_INIT message
(sent by MGW).
Figure 1 TRC_IU/NB_UP_INIT message

Associated IEs
Description
IU_UP/NB_UP message
header

messages.
frameControlPart

messages.
frameChecksumPart

messages.
framePayloadPart

messages.

Message Function
Associated IEs
Message Function
The TRC_IU/NB_UP_INIT_TOIP message is used to control the exchange of initialization
information, for example, the exchange of radio access bearer (RAB) sub-Flow
Combination Indicator (RFCI). This message can be used by the radio network controller
(RNC) to instruct the media gateway (MGW) to start the initialization procedure over IPbased Iu interfaces, or by an MGW to instruct another MGW to start the initialization
procedure over Nb interfaces. Figure 1 shows important IEs in the
TRC_IU/NB_UP_INIT_TOIP message.
Figure 1 TRC_IU/NB_UP_INIT_TOIP message

Associated IEs
Description
IU_UP/NB_UP message
header

messages.
frameControlPart

messages.
frameChecksumPart

messages.
framePayLoadPart
Indicates the frame payload part of IU_UP/NB_UP

messages.

Message Function
Associated IEs
Message Function
The TRC_IU/NB_UP_ACK_FRMIP message is used by a media gateway (MGW) to reply
to the radio network controller (RNC) over IP-based Iu interfaces during the initialization
procedure, or reply to another MGW over Nb interfaces. Figure 1 shows important IEs in
the TRC_IU/NB_UP_ACK_FRMIP message.
Figure 1 TRC_IU/NB_UP_ACK_FRMIP message

Associated IEs
Description
IU_UP/NB_UP message
header

messages.
frameControlPart

messages.
frameChecksumPart
Indicates the frame check information of IU_UP/NB_UP

messages.
framePayLoadPart

messages.

TRC_IU/NB_UP_TA (Received)
Message Function
Associated IEs
Message Function
The TRC_IU/NB_UP_INIT (received) message is used by the radio network controller
(RNC) to instruct the media gateway (MGW) to start the time alignment procedure over Iu
interfaces, or by an MGW to instruct another MGW to start the time alignment produce
over Nb interfaces. During the time alignment procedure, the RNC or MGW indicates the
receiver (MGW) the necessary amount of the delay or advance adjustment. Figure 1 shows
important IEs in the TRC_IU/NB_UP_TA message.
Figure 1 TRC_IU/NB_UP_TA message

Associated IEs
Description
frameControlPart

messages.
frameChecksumPart
Indicates the frame check information of IU_UP/NB_UP

messages.
framePayLoadPart

messages.

Message Function
Associated IEs
Message Function
The TRC_IU/NB_UP_INIT (sent) message is used by a media gateway (MGW) to reply to
the radio network controller (RNC) or another MGW during the time alignment procedure.
Figure 1 shows important IEs in the TRC_IU/NB_UP_TA message.
Figure 1 TRC_IU/NB_UP_TA message

Associated IEs
Description
frameControlPart

messages.
frameChecksumPart

messages.
framePayLoadPart

messages.


IU_UP/NB_UP Message Header
frameControlPart
frameChecksumPart
framePayloadPart
RFC (RAB sub-Flow Combination Indicator)
IU_UP/NB_UP Message Header

The IU_UP/NB_UP message header consists of information about contexts, terminations,
and channels.
TRC_IU/NB_UP_INIT (sent
by RNC)
IU_UP/NB_UP message
header
TRC_IU/NB_UP_INIT_FRMIP
IU_UP/NB_UP message
header
Description
contextID: The value 1966382 indicates the context

of the termination receiving the initialization
message.
terminationID: The value 00 00 00 00 20 1E 00 7F
indicates the identifier of the termination receiving
the initialization message.
channelID: The value 236 indicates the ATM
Adaptation Layer Type 2 (AAL2) channel identifier.
said: The value 10 indicates the UP instance
number.
contextID: The value 1972295 indicates the context

of the termination receiving the initialization
message.
terminationID: The value 0x46c indicates that the
identifier of the termination receiving the initialization
message is 00 00 00 00 30 00 04 6C.
srcIpAddr: The value 0x503c3cd0 indicates that
the source IP address is 80.60.60.208.
srcUdp: The value 436 indicates the port number.
rsv: The value 0 indicates that the parameter field is
reserved.

frameControlPart
Reference Standards
The Frame Control part consists of the protocol data unit (PDU) Type field, the ackNack
field, and the Frame Number field.
Information Element
Description
(IE)
pduType: The value frame-14 indicates PDU type 14.

The PDU types are as follows:
PDU type 0 is defined to transfer user data over
the IU_UP/NB_UP in support mode for pre-defined
service distribution unit (SDU) sizes. Error
detection scheme is provided over the
IU_UP/NB_UP for the payload part.
SDU sizes when no payload error detection
scheme is necessary over IU_UP/NB_UP (for
example, no payload cyclic redundancy code
(CRC)).
PDU type 14 is defined to perform control
procedures over the IU_UP/NB_UP in support
mode for pre-defined SDU sizes. The control
procedure is identified by the procedure indicator.
The Frame Payload part contains the data
information related to the control procedure.
ackNack: The value procedure indicates that the frame is a
control procedure frame.
ack: indicates that the frame is a positive
acknowledgement of a control procedure frame.

Nack: indicates that the frame is a negative
TRC_IU/NB_UP_INIT
(sent by RNC)
frameControlPart
frmNum: The value 0 indicates the frame number.

The purpose of the PDU type 14 Frame Number is to
provide the receiving entity with a mechanism to keep track
of lost UP frames. It is also used to relate the
acknowledgment frame to the frame being acknowledged.
That is, the same PDU type 14 Frame Number is used in
the acknowledgement frame as the one used in the frame
being acknowledged.
modeVer: indicates the IU_UP/NB_UP mode version.
0: Mode version 1 is supported in transparent
mode.
1: Mode version 2 is supported in support mode
for pre-defined SDU sizes.
The only difference between services in transparent mode
and those in support mode for pre-defined SDU sizes is that
no UP initialization procedure is available in transparent
mode.
procInd: indicates the control procedure in the current
frame.
0: initialization.
1: rate control.
2: time alignment.
3: error event.
4-15: reserved.
NOTE:
The transcoder free operation (TrFO) function can be supported only
in support mode for pre-defined SDU sizes.
TRC_IU/NB_UP_INIT ackNack: The value ack indicates that the frame is a positive
(sent by MGW)
acknowledgement of a control procedure frame (that is, a positive
acknowledgement of an initialization frame).
frameControlPart
procedure: indicates that the frame is a control procedure
frame.
Nack: indicates that the frame is a negative
TRC_IU/NB_UP_TA
(receive)
frameControlPart
procInd: The value timeAlignment indicates a time alignment

procedure.
TRC_IU/NB_UP_TA
(send)
frameControlPart
ackNack: The value ack indicates that the frame is a positive
acknowledgement of a control procedure frame (that is, a positive
acknowledgement of a time alignment frame).
Reference Standards
For details about the frameControlPart, see section 6.6 "Elements for Iu UP communication
in Support mode" in 3rd Generation Partnership Project (3GPP) TS 25.415.
frameChecksumPart
Reference Standards
The Frame Checksum part consists of the Header cyclic redundancy code (CRC) field and
the Payload CRC field.
Information Element
Description
(IE)
TRC_IU/NB_UP_INIT
(sent by RNC)
frameChecksumPart
TRC_IU/NB_UP_INIT
(sent by MGW)
frameChecksumPart
headerCRC: The value 3 indicates the header CRC.

This field contains the CRC of all fields in the Frame Control
part. With this CRC error bursts can be detected.
payloadCRC: The value 484 indicates the payload CRC.
This field contains the CRC of all the fields of the Frame
Payload part. With this CRC error bursts can be detected.
headerCRC: The value 61 indicates the header CRC.

spare10: idle.
Reference Standards
For details about the frameChecksumPart, see section 6.6.3 "Coding of information
elements in frames" in 3rd Generation Partnership Project (3GPP) TS 25.415.
framePayloadPart
Reference Standards
The Frame Payload part consists of radio access bearer (RAB) sub Flow Combination
(RFC) information and related control information.
Information Element
Description
(IE)
spare3: The value 0 indicates that the spare field is set to 0

by the sender and should not be interpreted by the receiver.
ti: The value iptiPresent indicates that Timing Information is
included in the control procedure frame.
numberOfSubflowsPerRfci: The value 3 indicates that each
RFC consists of three sub-flows.
chainInd: indicates whether the control procedure frame is
the last frame related to the control procedure.
TRC_IU/NB_UP_INIT
(sent by RNC)
framePayloadPart
0: indicates that this frame is the last frame for the

procedure.
1: indicates that additional frames will be sent for
the procedure.
firstRFC: For details, see RFC (RAB sub-Flow Combination
Indicator).
modeVerSupp: The value 3 indicates that the sender of the
initialization frame supports UP mode versions 1 and 2.
dataPDUtype: The value 0 indicates that protocol data unit
(PDU) type 0 is used for transferring user data.
The PDU types are as follows:

service distribution unit (SDU) sizes. Error
detection scheme is provided over the
IU_UP/NB_UP for the payload part.
SDU sizes when no payload error detection
scheme is necessary over IU_UP/NB_UP (for
example, no payload cyclic redundancy code
(CRC)).
spare4: idle.
TRC_IU/NB_UP_INIT
(sent by MGW)
framePayloadPart
framePayloadPart: NULL.
dataTimeAlign: indicates the amount the sending time should be

TRC_IU/NB_UP_TA advanced or delayed.
(receive)
The values ranging from 0 to 255 are as follows:
framePayloadPart
1n80: indicates that the sending time is n500 s
delayed.
129n208: indicates that the sending time is (n-128)500
s advanced.
Other values: reserved.
TRC_IU/NB_UP_TA
(send)
framePayloadPart: NULL.
framePayloadPart
spareExtension: indicates the spare extension field.
Reference Standards
For details about the framePayloadPart, see section 6.6.3 "Coding of information elements
in frames" in 3rd Generation Partnership Project (3GPP) TS 25.415.

RFC (RAB sub-Flow Combination Indicator)

Reference Standards
RAB sub-Flow Combination (RFC) is a combination of the Radio Access Bearer (RAB) subflows.
Information
Element (IE)
Description
Last RFCI Indicator (LRI): The value notLast indicates that

the current initialization frame is not the last RFC.
Length Indicator (LI): The value oneByte indicates that the
length of the sub-flow is 1 byte.
RAB sub-flow combination indicator (RFCI): The value 0
indicates that the identifier assigned to this RFC is 0.
lengthOfSubflow1 Byte: The value 42 indicates that the length
of sub-flow 1 is 42 bits.
The Adaptive Multi-Rate (AMR) codec mode for the corresponding
RFC is 4.75 kbit/s. The calculation formula is as follows:
(42 + 53 + 0) bits/AMR codec packet time 20 ms = 4.75 kbit/s
LRI: The value notLast indicates that the current initialization

frame is not the last RFC.
LI: The value oneByte indicates that the length of the subflow is 1 bit.
RFCI: The value 1 indicates that the identifier assigned to this
RFC is 1.
The AMR codec mode for the corresponding RFC is 5.15 kbit/s. The
calculation formula is as follows:

LI: The value oneByte indicates that the length of the subflow is 1 byte.
RFC is 2.

RFC is 3.
TRC_IU/NB_UP_TA
(Sent by RNC)
RAB sub-Flow
Combination (RFC)

RFC is 4.

RFC is 5.

RFC is 8.
The total length of the sub-flow is 39 bits for the corresponding RFC,
indicating that the silence voice (comfort noise) is transmitted.
LRI: The value isLast indicates that the current initialization

frame is the last RFC.
RFC is 9.
The total length of the sub-flow is 0 bits for the corresponding RFC,
indicating that no data is transmitted.
Inter PDU Timing Interval (IPTI): The value 8 indicates that the value of
the IPTI is eight (in the same order as the RFCIs occur in the
Initialization frame).
NOTE:
The LST RFCI can be used to query the RFCI set on the media
gateway (MGW).
Reference Standards
For details about the RFC, see section 6.6.3 "Coding of information elements in frames" in
3rd Generation Partnership Project (3GPP) TS 25.415.
IPBCP Protocol
Description of the IPBCP Protocol
Description of the IPBCP Protocol

Protocol Stack
Message Structure
IE Structure
Message List
Reference Standards
IP Bearer Control Protocol (IPBCP) is used for bearer attribute negotiation before the RealTime Transport Protocol (RTP) bearer is established for the NB-UP data transmitted over
the Nb interface. The negotiation is implemented over the Mc and Nc interfaces. Figure 1
shows the IPBCP application.
Figure 1 IPBCP application

The control plane protocol used on the Nb interface is defined in 3rd Generation Partnership
Project (3GPP) TS 29.232. When IP bearer is used, two MGWs negotiate service bearer
attributes over the connection established by the Mc-provided channel and Nb-defined
tunnel. The Mc interface specification and Nb interface specification defined by 3GPP must
both be met.
IPBCP is used for the exchange of media stream characteristics, port numbers, and IP
addresses of the receiver and sender of a media stream. IPBCP uses the Session
Description Protocol (SDP) to encode the exchanged information.
IPBCP is used for the exchange of information during Bearer Independent Call Control
(BICC) call establishment when IP bearer is used on the Nb interface.
Protocol Stack
Figure 2 shows the IPBCP protocol stack.
Figure 2 IPBCP protocol stack
The MSC server transparently transmits Bearer Control Tunneling Protocol (BCTP) and
IPBCP packets without processing them. BCTP and IPBCP packets originate from one
MGW and terminate on another MGW.
Message Structure
IPBCP messages are encoded in compliance with SDP and contain a group of attribute
names and attribute values. Figure 3 shows the hierarchical structure of the IPBCP
message.
Figure 3 IPBCP message structure
IE Structure
Figure 4 shows the Information Element (IE) Structure of the IPBCP message.
Message List
Table 1 lists four IPBCP messages.
Table 1 IPBCP messages
Messages
Direction
Function
Request
MGW>MGW
Requests to exchange information necessary for

establishing and modifying an IP bearer.
For details, see bT-TunnelInd-DATA.
Accepted
MGW>MGW
Responds to the Request message after the Request

message is accepted and processed.
Confused
MGW>MGW

message is received but not processed.
Rejected
MGW>MGW

message is received but rejected.
IPBCP messages are transferred by means of H.248 messages and BICC messages.
Table 2 lists the commands used for IPBCP messages.
Table 2 Commands used for IPBCP messages
Message
Direction Function
(Command)
ADD REQ (bT)
MGC>MGW
Notifies the MGW of the time to report the tunneled

information.
MOD REQ (bT)
MGC>MGW
Sends tunneled information to the MGW or instructs the

MGW to report tunneled information events.
NTFY REQ (bT)
MGW>MGC
Reports tunneled information events to the MGC.
IAM (APP)
MGC>MGC
Sends tunneling related information to the MGC.
APM (Initiating
bCI)
MGC>MGC
Sends tunneled information to the MGC.
APM (Receiving
bCI)
MGC>MGC
Receives tunneling negotiation results from the MGC.
Reference Standards
For details about IPBCP, see International Telecommunication Union-Telecommunication
Standardization Sector (ITU-T) Q.1970.

Parent topic: IPBCP Protocol

There is no common part in IP Bearer Control Protocol (IPBCP) messages.

ADD REQ (bT)
MOD REQ (bT)
NTFY REQ (bT)
IAM (APP)
APM (Initiating bCI)
APM (Receiving bCI)
ADD REQ (bT)

Message Function
Associated IEs
Message Function
If the ADD REQ (bT) message contains the localControlDescriptor that carries the bTTunOpt attribute, it is used to notify the MGW of the time to report the tunneled information.
If the ADD REQ (bT) message contains the signalsDescriptor that carries the bTBearInfoTrans attribute, it is used by the MGC to send the tunneled information to the
MGW. Figure 1 and Figure 2 shows important IEs in the ADD REQ (bT) message.
Figure 1 ADD REQ (bT) message

Figure 2 ADD REQ (bT) message
Associated IEs
Description
bT-TunOpt
Notifies the MGW of the time to report the tunneled

information.
For details, see bT-TunOpt.
bT-BearInfoTrans
Sends the tunneled information to the MGW.

For details, see bT-BearInfoTrans.

MOD REQ (bT)

Message Function
Associated IEs
Message Function
If the MOD REQ (bT) message contains the eventsDescriptor that carries the bT-TunnelInd
attribute, it is used to instruct the MGW to report a tunneled information event.
If the MOD REQ (bT) message contains the signalsDescriptor that carries the bTBearInfoTrans attribute, it is used by the MGC to send the tunneled information to the
MGW. Figure 1 and Figure 2 shows important IEs in the MOD REQ (bT) message.
Figure 1 MOD REQ (bT) message

Figure 2 MOD REQ (bT) message
Associated IEs
Description
bT-TunnelInd
Instructs the MGW to report a tunneled information event.

For details, see bT-TunnelInd.
bT-BearInfoTrans
Sends the tunneled information to the MGW.

For details, see bT-BearInfoTrans.

NTFY REQ (bT)

Message Function
Associated IEs
Message Function
The NTFY REQ (bT) message contains the observedEventsDescriptor that carries the bTTunnelInd attribute. It is used to report an event that the tunneled information is sent from
the MGW. Figure 1 shows important IEs in the NTFY REQ (bT) message.
Figure 1 NTFY REQ (bT) message

Associated IEs
Description
bT-TunnelInd
Indicates an event that the tunneled information is sent from

the MGW.
For details, see bT-TunnelInd.
bT-TunnelInd-DATA
Indicates the tunneled information.


IAM (APP)
Message Function
Associated IEs
Message Function
The IAM (APP) message indicates the bearer related information. If the IAM (APP)
message contains bearer-Control-Info, the fast bearer establishment is to be used; if
bearer-Control-Info is not included, the delayed bearer establishment is to be used. Figure
1 shows important IEs in the IAM (APP) message.
Figure 1 IAM (APP) message

Associated IEs
Description
action-indicator
Indicates the bearer establishment mode.

For details, see action-indicator.
bearer-Control-Info
Indicates the tunneled bearer control information.

For details, see bearer-Control-Info.
bearer-Control-Tunnel
Indicates the information related to bearer control tunneling.

For details, see bearer-Control-Tunnel.

APM (Initiating bCI)

Message Function
Associated IEs
Message Function
The APM (initiating bCI) message is used to send the tunneled bearer control information. If
the first bearer-Control-Info (bCI) is included in the APM (initiating bCI) message from the
calling party side, the forward bearer establishment is to be used; if the bCI is included in
the APM (initiating bCI) message from the called party side, the backward bearer
establishment is to be used. Figure 1 shows important IEs in the APM (initiating bCI)
message.
Figure 1 APM (initiating bCI) message

Associated IEs
Description
bearer-Control-Info


APM (Receiving bCI)

Message Function
Associated IEs
Message Function
The APM (receiving bCI) message is used to receive the tunneling negotiation results.
Figure 1 shows important IEs in the APM (receiving bCI) message.
Figure 1 APM (receiving bCI) message

Associated IEs
Description
bearer-Control-Info



bT-TunOpt
bT-TunnelInd
bT-BearInfoTrans
bT-TunnelInd-DATA
action-indicator
bearer-Control-Info
bT-TunOpt
Reference Standards
The TunOpt, representing tunneling options, indicates when the MGW sends the tunneled
information to an MGC.
Information
Element (IE)
Description
ADD REQ (bT)

bT-TunOpt
name: The value bT-TunOpt indicates when the MGW sends

the tunneled information to an MGC.
value: The value any-time indicates that the MGW can send
the tunneled information at any time and that the related
termination goes into the initial state to wait for subsequent
information. The other value as-rsp-cmd indicates that the
MGW initiates the tunneling negotiation.
TunOpt: tunneling options, which is defined in the Bearer Control
Tunneling Package.
Reference Standards
For details about the Bearer Control Tunneling Package, see Annex A in International
Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q.1950.
bT-TunnelInd
Reference Standards
The TunnelInd, representing tunnel indication, indicates the event that the MGW sends the
tunneled information.
Information
Element (IE)
Description
MOD REQ (bT)

bT-TunnelInd
name: The value TunnelInd indicates that the MGW sends the
tunneled information and the relevant termination goes into the
negotiation requesting state.
NTFY REQ (bT)

bT-TunnelInd
name: The value bit, representing bearer information

transport, indicates that the tunneled information is sent.
value: The value bT-TunnelInd-DATA indicates the tunneled
information.
TunnelInd: tunnel indication, which is defined in the Bearer Control

Tunneling Package.
Reference Standards
bT-BearInfoTrans
Reference Standards
The BearInfoTrans, representing bearer information transport, is used by the MGC to send
the tunneled information to the MGW.
Information
Element (IE)
Description
ADD REQ (bT)

(Receiver)
bT-BearInfoTrans

value: The value bT-bit-DATA indicates the tunneled
information. For details about the related parameters, see
bT-TunnelInd-DATA.
BearInfoTrans: bearer information transport, which is defined in the
Bearer Control Tunneling Package.
MOD REQ (bT)

(Receiver)
bT-BearInfoTrans

bT-TunnelInd-DATA.
MOD REQ (bT)

(Sender)
bT-BearInfoTrans

transport, indicates that the tunneled information is sent and
the related termination goes into the accepting negotiation
response state.
bT-TunnelInd-DATA.
Reference Standards
bT-TunnelInd-DATA
Reference Standards
The bT-TunnelInd-DATA indicates the tunneled information.
Information
Element (IE)
Description

hl: indicates the length of bT-TunnelInd-DATA with its header.
l: The value 129 indicates an encoding format.
v: The value 161 indicates that the length of bT-TunnelIndDATA is 161 bytes.
ht: The value 4 indicates that an encoding format other than
DoubleWrapping is used for encoding H.248 messages.
vl: indicates the length of bT-TunnelInd-DATA without its header.
l: The value 129 indicates an encoding format.
v: The value 158 indicates that the length of bT-TunnelInd-
DATA (bctp and ipbcp parts) is 158 bytes.

bctp: Bearer Control Tunneling Protocol, which is used to provide the
tunneling mechanism.
o1: The eighth bit of the first byte is permanently set to 0.
bvei: version error indicator. The value 0 indicates no version
error. The other value 1 indicates that the BCTP protocol
version is not supported.
i1: The sixth bit of the first byte is permanently set to 1.
bctp-ver: version indicator. The value 0 indicates BCTP
protocol version 1.
o2: The eighth bit of the first byte is permanently set to 0.
tpei: protocol error indicator. The value 0 indicates no
protocol error. The other value 1 indicates that the BCTP
protocol is not supported.
tpi: protocol indicator. The value 32 indicates that information
is transported using the IP Bearer Control Protocol (IPBCP)
message of text format.
ipbcp: indicates the IPBCP message entity.
NTFY REQ(bT)
(Sender)
bT-TunnelInd-DATA
v: version. The value 0 indicates the Session Description

Protocol (SDP) version number.
o: origin. The value 0 0 IN IP4 80.60.60.208 indicates the
address of the session initiator. In the value 0 0 IN IP4
80.60.60.208, intelligent network (IN) indicates that the
network type is Internet; IP4 indicates the Internet Protocol
version 4 (IPv4) address type; 80.60.60.208 indicates the IP
address used by the session initiator to send IPBCP
messages.
s: session name. The value - indicates null.
c: connection information. The value IN IP4 80.60.60.208
indicates the IP address used by the Nb interface to carry
media streams.
t: start time and stop time. The value 0 indicates that this
field is not in use.
a: session attribute. The value ipbcp:1 Request indicates
that IPBCP version 1 is used to initiate a request.
m: media announcement. The value audio 492 RTP/AVP 96
indicates that media session type is audio, port number is
492, transport protocol is Real-Time Transport Protocol
(RTP)/attribute-value pair (AVP), and payload type (PT) is
96.
a: media attributes. The value ptime:5 indicates that the
packetization time is 5 ms.
a: media attributes. The value rtpmap:96
VND.3GPP.IUFP/16000 indicates that PT is 96,
VND.3GPP.IUFP is a fixed field, and sampling frequency is
16000 Hz.
For details about termination information in IPBCP messages, see
localDescriptor.
NOTE:
The SET IPBCP command can be used to set IPBCP
negotiation parameters, such as Timeout(s) and PtimeFlag.
An UP negotiation fails if the packetization time is different on
the calling party and called party sides.
Codec is not negotiated in IPBCP messages.
The ADD MGC command can be used to set support
double wrapping.
NTFY REQ (bT)

(Receiver)
bT-TunnelInd-DATA
ipbcp: indicates the IPBCP message entity.

a: session attribute. The value ipbcp:1 Accepted indicates
that IPBCP version 1 is used to accept a request.
m: media announcement. The value audio 508 RTP/AVP 96
indicates that media session type is audio, port number is
508, transport protocol is RTP/AVP, and PT is 96.
NTFY REQ (bT)
(Message trace on Tunneled information is presented in binary format in the messages
the MGC)
traced on the MGC. For details about the related parameters, see the
bT-TunnelInd-DATA messages traced on the MGW.
Reference Standards
For details about BCTP, see International Telecommunication Union-Telecommunication
For details about SDP, see Internet Engineering Task Force (IETF) RFC 2327.
action-indicator
Reference Standards
The action-indicator indicates the bearer establishment mode.
Information
Element (IE)
IAM (APP)
action-indicator
Description
action-id-data: The value connect-forward indicates the forward

bearer establishment. The other value connect-backward indicates
the backward bearer establishment.
NOTE:
The ADD BICCTG command can be used to configure the bearer
establishment mode on the MGC.
Reference Standards
For details about Bearer Independent Call Control (BICC), see International
Reference Standards
The bearer-Control-Tunnel indicates the information related to bearer control tunneling.
Information
Element (IE)
IAM (APP)
bearer-ControlTunnel
Description
bearer-control-tunneling-indicator: The value 1 indicates that the

bearer establishment mode is tunneling.
Reference Standards
For details about Bearer Independent Call Control (BICC), see International
bearer-Control-Info
Reference Standards
The bearer-Control-Info indicates the tunneled bearer control information.
Information
Element (IE)
Description
IAM (APP)
bearer-Control-Info
bearer-Control-Info: The tunneled bearer control information is sent
between MGCs by means of Bearer Independent Call Control (BICC)
messages. For details about the related parameters, see bTTunnelInd-DATA.
APM (Initiating
bCI)
bearer-Control-Info
between MGCs by means of BICC messages. For details about the
related parameters, see bT-TunnelInd-DATA.
APM (Receiving
bCI)
bearer-Control-Info

between MGCs by means of BICC messages. For details about the
related parameters, see bT-TunnelInd-DATA.
Reference Standards
For details about BICC, see International Telecommunication Union-Telecommunication
RTP/RTCP Protocol
Description of the RTP/RTCP Protocol
Description of the RTP/RTCP Protocol

Protocol Stack
Message Structure
IE Structure
Message List
Reference Standards
Audio streams over IP are transmitted using the User Datagram Protocol (UDP). As a
protocol designed for data stream transmission, UDP does not address the specific needs
of real-time data traffic, such as synchronization of media streams. For the transmission of
real-time data, Internet Engineering Task Force (IETF) formulated the Real-time Transport
Protocol (RTP) as an extension to UDP.
RTP provides end-to-end delivery services for data with real-time characteristics, such as
interactive audio and video. Those services include payload type identification, sequence
numbering, timestamping, and delivery monitoring.
RTP consists of two closely-linked parts:
RTP: Carries data that has real-time properties.
RTP Control Protocol (RTCP): Monitors the quality of service and conveys
information about the participants in an on-going session.
RTP allows for real-time transmission of audio and video and their synchronization. RTCP is
used to monitor RTP packets and the quality of service (QoS). As RTP neither reserves
resources nor ensures QoS of real-time services, RTCP is responsible for enhancing data
transmission.
RTCP is based on periodic transmission of control packets to all participants in a session,
using the same transmission mechanism as data packets. RTCP performs the following
functions:
Provides feedback on the quality of data transmission. The feedback information
contained in RTCP packets helps to diagnose network problems and control the
transmission of RTP packets.
Carries a persistent transport-level identifier for an RTP source, called the
canonical name (CNAME). If a conflict is discovered or a program is restarted,
synchronization source (SSRC) may change. Therefore, receivers require the
CNAME to keep track of each participant.
RTP is used for audio stream transmission over the Nb interface, IP-enabled A or Iu
interface, and IP over E1 (IPoE1).
RTCP is used for monitoring RTP packets and QoS.
Protocol Stack
Figure 1 shows the RTP/RTCP protocol stack.
Figure 1 RTP/RTCP protocol stack

Message Structure
Figure 2 shows the hierarchical structure of the RTP/RTCP message.
Figure 2 Hierarchical structure of the RTP/RTCP message
IE Structure
Figure 3 shows the Information Element (IE) structure of the RTP message.
Figure 3 IE structure of the RTP message
Figure 4 shows the IE structure of the RTCP message.

Figure 4 IE structure of the RTCP message
Message List
Table 1 lists RTCP messages.
Table 1 RTCP messages
Message
Direction
Function
SR packet
The sender report (SR) packet provides statistics on

BSC/RNC/MGW<- data packets sent and received by the sender.
>MGW
For details, see rtcpSR.
extension report
(XR) packet
The extended report (XR) packet provides statistics

BSC/RNC/MGW<- on extended information of data packets.
>MGW
For details, see rtcpXRVoIP.
RR packet
The receiver report (RR) packet provides statistics

BSC/RNC/MGW<- on data packets received by the receiver.
>MGW
For details, see rtcpRR.
SDES packet
The source description (SDES) packet describes the

BSC/RNC/MGW<- source of RTCP packets.
>MGW
For details, see rtcpSDES.
BYE packet
BSC/RNC/MGW<- The BYE packet indicates the end of audio

>MGW
transmission.
asymmetric digital
The application-defined (APP) packet is intended for
subscriber line
experimental use as new applications and new
(ADSL) Port
BSC/RNC/MGW<- features are developed, for example, it can be used
information
>MGW
for the RTP multiplex feature.
Protocol (APP)
For details, see rtcpAPP.
packet
Table 2 shows the commands used for RTCP messages.
Table 2 Commands used for RTCP messages
Message
(Command)
Direction
RTCP_SEND_MSG
BSC/RNC/MGW<- Indicates the RTCP packet statistics sent by the

>MGW
local end.
RTCP_RCV_MSG
BSC/RNC/MGW<- Indicates the RTCP packet statistics received by

>MGW
the local end.
Function
Reference Standards
For details about RTP/RTCP, see IETF RFC 3550.
Parent topic: RTP/RTCP Protocol

There is no common part in Real-Time Transport Protocol (RTP)/Real-time Transport
Control Protocol (RTCP) messages.

RTCP_SEND_MSG
RTCP_RCV_MSG
RTCP_SEND_MSG
Message Function
Associated IEs
Message Function
The RTCP_SEND_MSG indicates the Real-time Transport Control Protocol (RTCP) packet
statistics sent by the local end. Figure 1 shows important IEs in the RTCP_SEND_MSG
message.
Figure 1 RTCP_SEND_MSG message

Associated IEs
Description
ip (ip header)
For details, see ip.
udp (udp header)
For details, see udp.
rtcp (rtcp packet)
For details, see rtcp.

RTCP_RCV_MSG
Message Function
Associated IEs
Message Function
The RTCP_RCV_MSG indicates the Real-time Transport Control Protocol (RTCP) packet
statistics received by the local end. Figure 1 shows important IEs in the RTCP_RCV_MSG
message.
Figure 1 RTCP_RCV_MSG message

Associated IEs
Description
ip (ip header)
For details, see ip.
udp (udp header)
For details, see udp.
rtcp (rtcp packet)
For details, see rtcp.


ip
udp
rtcp
rtcpSR
rtcpXRVoIP
rtcpSDES
rtcpRR
rtcpAPP
ip
Reference Standards
The ip header includes the IP version, IP packet length, and IP address.
Information
Element (IE)
Description
version: The value 4 indicates IP version 4.

headerlen: header length. The value 5 indicates that the IP
header length is 20 bytes (5 x 4).
tos: type of service.
If IPQoS attributes comply with the Differentiated Services
Codepoint (DSCP) protocol, the DSCP field is used, where
the most significant 6 bits represent a DSCP value and the
least significant 2 bits are reserved. If the DSCP field has a
value of 184, the most significant 3 bits, 101, indicate that the
TOS is Expedited Forward (EF), which is generally used for
low-delay services. The most significant 6 bits, 101110,
indicate that the DSCP value is EF53(46), which is a default
DSCP value.
If IPQoS attributes comply with the TOS protocol, the TOS
field is used. The most significant 3 bits indicate priority, the

following 4 bits indicate a TOS value, and the last bit must be
reserved and set to 0. Different TOS values indicate varied
forwarding strategies:
RTCP_SEND_MSG
ip (ip header)
1000:
0100:
0010:
0001:
0000:
Minimize delay
Maximize throughput
Maximize reliability
Minimize monetary cost
Provide normal services
totallen: total length. The value 156 indicates that the total IP
packet length is 156 bytes.
identification: The value 17310 identifies a datagram.
flags: The value 0 indicates the last fragment of a datagram
that allows fragmentation.
fragmentoffset: The value 0 indicates that the fragment offset
is zero bytes (0 x 8).
ttl: time to live. The value 128 indicates 128 seconds of
lifespan.
protocol: The value udp indicates that User Datagram
Protocol (UDP) is used for the data transport layer.
checksum: The value 15466 indicates the IP header
checksum.
source-address: The value 80 60 13 15 indicates the source
IP address.
dest-address: The value 80 60 12 10 indicates the
destination IP address.
NOTE:
The TOS byte is used in IP Diffserv, an IP quality of service
(QoS) feature.
The SET IPQOS command can be used to set IPQoS
attributes.
The SET PRITODSCP command can be used to set the
mapping between the context priority and the DSCP value.
RTCP_RCV_MSG
ip (ip header)
source-address: The value 80 60 12 10 indicates the source

IP address.
dest-address: The value 80 60 13 15 indicates the
destination IP address.
Reference Standards
For details about the ip header, see Internet Engineering Task Force (IETF) Requirement
For Comments (RFC) 791.
udp
Reference Standards
The udp header includes the User Datagram Protocol (UDP) port number and UDP packet
length.
Information
Element (IE)
Description
RTCP_SEND_MSG
udp (udp header)
RTCP_RCV_MSG
udp (udp header)
Reference Standards
source-port: The value 63385 indicates the UDP port number

used by the Real-time Transport Control Protocol (RTCP)
packet sending end. It equals the UDP port number used by
the local end to send Real-Time Transport Protocol (RTP)
packets plus one.
dest-port: The value 53369 indicates the UDP port number
used by the RTCP packet receiving end. It equals the UDP
port number used by the remote end to send RTP packets
plus one.
length: The value 136 indicates that the UDP packet length
(including the UDP header) is 136 bytes.
checksum: The value 0 indicates that checksum of the header
and data is not calculated (the calculation of UDP checksum
is optional).
source-port: The value 63385 indicates the UDP port number

used by the RTCP packet sending end.
dest-port: The value 53369 indicates the UDP port number
used by the RTCP packet receiving end.
For details about the udp header, see Internet Engineering Task Force (IETF) RFC 768.
rtcp
Reference Standards
The Real-time Transport Control Protocol (RTCP) packet includes the Real-Time Transport
Protocol (RTP) version, packet type, sender report (SR) packet, and receiver report (RR)
packet.
Information
Element (IE)
Description
ucbit2Version: The value 2 indicates RTP version 2.

ucbit1PadFlag: The value 0 indicates that no padding is
added after the payload.
ucbit5Count: reception report count. The value 1 indicates
that the RTCP packet contains one reception report.
pktType: packet type. The value rctpSR indicates that the
RTCP packet contains the sender report.
rtcpSR: For details, see rtcpSR.

ucbit5Count: The value 0 indicates that ucbit5Count is
reserved.
pktType: The value rtcpXRVoIP indicates that the RTCP
packet contains the voice over IP (VoIP) extended report.
rtcpXRVoIP: For details, see rtcpXRVoIP.
RTCP_SEND_MSG
rtcp (rtcp packet)

ucbit5Count: refers to source count. The value 1 indicates the
number of SSRCs and CSRCs contained in the source
description (SDES) packet.
pktType: The value rtcpSDES indicates that the RTCP
packet contains the source description.
rtcpSDES: For details, see rtcpSDES.

ucbit5Count: refers to reception report count. The value 1
indicates that the RTCP packet contains one reception
report.
pktType: The value rctpRR indicates that the RTCP packet
contains the receiver report.
rtcpRR: For details, see rtcpRR.

ucbit5Count: refers to the subtype. The value 1 indicates that

the subtype of the asymmetric digital subscriber line (ADSL)
Port information Protocol (APP) packet is RTP multiplex
negotiation packet.
pktType: The value rctpAPP indicates that the RTCP packet
is an APP packet.
rtcpAPP: For details, see rtcpAPP.
Reference Standards
For details about RTCP packets, see section 6.4 "Sender and Receiver Reports" in RFC
3550.
rtcpSR
Reference Standards
The rtcpSR report provides statistics about data packets sent and received by the sender.
Information
Element (IE)
Description
udwSsrc: synchronization source identifier. The value

3685259243 identifies the synchronization source of the
sender report (SR).
udwNtpSec: indicates the integer part (most significant) of
the NodeB template file (NTP) time.
udwNtpFrac: indicates the fractional part (least significant) of
the NTP time.
udwRtpTs: indicates the Real-Time Transport Protocol (RTP)
timestamp used for time synchronization of RTP packets.
udwPktSent: indicates the count of sent RTP packets.
udwOctSent: indicates the count of sent octets.
RtcpRcvrpt: indicates the reception of packets.
RTCP_SEND_MSG
rtcpSR
udwSsrc: The value 3685759387 identifies the

synchronization source of the received packets.
udwbit8Fraction: fraction lost, indicating the RTP
packet loss rate.
The calculation formula is (udwbit8Fraction/256) x
100%.
udwbit24Lost: indicates the number of lost RTP

packets.
udwExtSeq: extended highest sequence number
received, indicating the highest sequence number of
the received RTP packet with extended information.
udwJitter: indicates the interarrival jitter, measured
in milliseconds.
udwLsr: last SR timestamp, indicating the NTP time
of the last received SR. The value 0 indicates that
no SR is received.
udwDlsr: delay since last SR. The value 0 indicates
that no SR is received.
NOTE:
The SET RTCP command can be used to set Real-time
Transport Control Protocol (RTCP) parameters, such as
Switch to send RTCP packets or not and Alarm high
threshold of fraction lost.
If the local port detects that the packet loss rate of the RTP
packets sent by the remote end is greater than or equal to
Alarm high threshold of fraction lost during four
consecutive RTCP packet sending periods, ALM-1023
Packet loss rate sent by remote end is reported. This
alarm is cleared if the local port detects that the packet loss
rate of the RTP packets sent by the remote end is smaller
than that threshold during an RTCP packet sending period.
RTCP_RCV_MSG
rtcpSR
synchronization source of the SR sent by the remote end.

synchronization source of the received packets.
Reference Standards
For details about the rtcpSR report, see section 6.4.1 "Sender Report RTCP Packet" in
RFC 3550.
rtcpXRVoIP
Reference Standards
The rtcpXRVoIP report provides metrics for monitoring voice over IP (VoIP) calls.
Information
Element (IE)
Description

extension report (XR).
xrBlockType: The value voipMetrics indicates that the report
provides VoIP metrics.
ucRes0: The value 0 indicates that ucRes0 is reserved.
ucBlockLen: The value 8 indicates that the report block length
RTCP_SEND_MSG
rtcpXRVoIP
(including the header) is 40 bytes (8 x 4 + 8).

udwSrcSsrc: The value 3685759387 identifies the
synchronization source of the XR report block.
ucLossRate: The value 0 indicate that the Real-Time
Transport Protocol (RTP) packet loss rate is 0.
ucDiscardRate: The value 0 indicates that the RTP packet
discard rate is 0.
ucBurst Density: The value 0 indicates that the packet loss
and discard rate within burst periods is 0.
ucGap Density: The value 0 indicates that the packet loss
and discard rate within inter-burst gaps is 0.
ucBrustDruation: The value 0 indicates that the total duration
of the burst periods that have occurred since the beginning of
reception is 0.
ucGapDuration: The value 0 indicates that the total duration
of the gap periods that have occurred since the beginning of
reception is 0.
ucRoundDelay: The value 0 indicates that the round trip delay
between RTP interfaces is not available.
ucEndSysDelay: The value 0 indicates that the end system
delay is not available.
ucSignalLevel: The value 127 indicates that the signal level is
not available.
ucNoiseLevel: The value 127 indicates that the noise level is
not available.
ucRERL: residual echo return loss. The value 0 indicates that
this parameter is not available.
ucGmin: The value 16 indicates that the minimum gap
threshold is 16.
ucRfactor: refers to a voice quality metric. The value 127
indicates that this parameter is not available.
ucExtRfactor: The value 127 indicates that this parameter is
not available on the access side and the wireless side.
ucMOSLQ: The value 127 indicates that the mean opinion
score (MOS) for listening quality is not available.
ucMOSCQ: The value 127 indicates that the MOS for
conversational quality is not available.
rxConfig: indicates the receiver configuration byte.
bit2PLC: packet loss concealment. The value 3
indicates standard PLC.

2: enhanced
1: disabled
0: unspecified
bit2JBA: jitter buffer adaptive. The value 0 indicates
unknown.
3: adaptive
2: non-adaptive
1: reserved
bit4JBRate: jitter buffer rate. The value 0 indicates
that the adjustment time is unknown.
ucRes1: reserved.
uwJBNominal: The value 210 indicates that the nominal jitter
buffer delay is 210 ms.
ucJBMax: The value 320 indicates that the maximum jitter
buffer delay is 320 ms.
ucJBAbsMax: The value 4800 indicates that the absolute
maximum jitter buffer delay is 4800 ms.
NOTE:
The PLC field is used in the enhanced PLC feature.
The JBA field is used in the IP jitter buffer function.
The Metrics Block in the Real-time Transport Control
Protocol (RTCP) XR defines statistical information for
monitoring the IP voice quality. The voice quality monitoring
feature uses the collected statistics to calculate the MOS
value and monitor the end-to-end voice quality.
The SET TCPARA command can be used to set transmission
convergence (TC) parameters, such as Packet loss
compensation and Enable dynamic JB adaption.
The SET RTCP command can be used to set RTCP
parameters, such as RTCP XR support mode and Gmin of
RTCP XR.
Reference Standards
For details about the rtcpXRVoIP report, see section 4 "Extended Report Blocks" in RFC
3611.
rtcpSDES
Reference Standards
The rtcpSDES item describes the source of Real-time Transport Control Protocol (RTCP)
packets and must contain the canonical end-point identifier (CNAME).
Information
Element (IE)
Description
RTCP_SEND_MSG
rtcpSDES
RTCP_RCV_MSG
rtcpSDES

sender report (SR).
cname: The value 1344@80.60.13.15 indicates the CNAME
identifier.

synchronization source of the SR sent by the remote end.
cname: The value 7558@80.60.12.10 indicates the CNAME
identifier.
Reference Standards
For details about the rtcpSDES item, see section 6.5 "Source Description RTCP Packet" in
RFC 3550.

rtcpRR
Reference Standards
The rtcpRR report provides statistics only on the data packets received by the receiver
(such as MGW).
Information
Element (IE)
Description

receiver report (RR).
RTCP_SEND_MSG
rtcpRR
udwbit8Fraction: fraction lost, indicating the RealTime Transport Protocol (RTP) packet loss rate.
udwbit24Lost: indicates the number of lost RTP
packets.
udwExtSeq: extended highest sequence number
received, indicating the highest sequence number of
the received RTP packet with extended information.
udwJitter: indicates the interarrival jitter, measured
in milliseconds.
udwLsr: last sender report (SR) timestamp,
indicating the NodeB template file (NTP) time of the
last received SR. The value 0 indicates that no SR
is received.
udwDlsr: delay since last SR. The value 0 indicates
that no SR is received.
Reference Standards
For details about the rtcpRR report, see section 6.4.2 "Receiver Report Real-time
Transport Control Protocol (RTCP) Packet" in RFC 3550.
rtcpAPP
Reference Standards
The rtcpAPP packet is intended for experimental use as new applications and new features
are developed. This section describes its use for Real-Time Transport Protocol (RTP)
multiplex negotiation.
Information
Element (IE)
Description

ADSL Port information Protocol (APP).
name: The name is 3GPP constantly.
rtpmux: indicates RTP multiplex attributes.
RTCP_SEND_MSG
rtcpAPP
bit1Mux: The value 1 indicates support for the noncompressed RTP multiplex capability of the
receiver.
The other value 0 indicates no support.
bit1CP: The value 0 indicates no support for the
compressed RTP multiplex capability of the
receiver.
The other value 1 indicates support for the
compressed RTP multiplex capability of the
receiver.
bit2Selection: The value 1 indicates support for the
non-compressed RTP multiplex capability of the
sender.

0: not support non-compressed RTP
multiplex capability of the sender.
2: support compressed RTP multiplex
capability of the sender.
3: reserved.
bit15LocalPort: The value 512 indicates that the
number of the port receiving RTP multiplex packets
is 1024 (512 x 2).
NOTE:
The MOD IPIF command can be used to set the RTP multiplex
capability.
The SET RTPMUX command can be used to set the number of the
port receiving RTP multiplex packets.
RTCP_RECV_MSG
rtcpAPP
udwSsrc: The value 333759004 identifies the synchronization
source of the APP.
name: The name is 3GPP constantly.
Reference Standards
For details about the rtcpAPP packet, see section 6.7 "Application-Defined Real-time
Transport Control Protocol (RTCP) Packet" in RFC 3550.
CAP Protocol
Description of the CAP Protocol
Description of the CAP Protocol

Protocol Stack
Message Structure
Message List
The MSC serves as an MSC server or a GMSC server in the Universal Mobile
Telecommunications System (UMTS) R4 network, and is embedded with the SSP functional
entity. The Customized Applications for Mobile network Enhanced Logic (CAMEL)
Application Part (CAP) protocol is used over the CAP interface between the MSC and the
SCP, as shown in Figure 1.
Figure 1 Application of the CAP protocol

Protocol Stack
The MSC supports two modes for CAP protocol transmission:
TDM-based: The CAP protocol information is transferred using services provided
by the Message Transfer Part (MTP).
IP-based: The CAP protocol information is transferred using services provided by
the Signaling Transport (SIGTRAN) protocol.
Figure 2 shows the CAP protocol stack.
Figure 2 CAP protocol stack
Message Structure
Figure 3 shows the structure of a CAP message.
Figure 3 CAP message structure
In the Signaling System No.7 (SS7), the CAP messages are transferred as the components
of the Transaction Capability Application Part (TCAP) messages. The ASN.1 format is
adopted for the coding of the CAP messages. The CAP message types are in one-to-one
relationship with the operation codes in TCAP components. In the message transfer
process, each time an operation is initiated, an invoke ID is allocated. The invoke ID
identifies an operation in a certain direction in a CAP dialog. Based on the invoke ID, a
component can be "translated" into the corresponding CAP message. The message
translation between the CAP and the TCAP is implemented by the Functional Entity Access
Manager (FEAM).
Message List
Interaction between different functional entities of the Mobile Intelligent Network (MIN) is
implemented through various operations defined in the CAP protocol. The defined operation
set varies according to the phase of the CAP protocol. In CAMEL Phase 3, 32 CAP
operations are defined, wherein 24 operations are call specific and 8 operations are short
message specific.
Table 1 lists the common CAP messages.
Table 1 List of common CAP messages
Message
Direction
Function
Initial detection
point (DP)
MSC -> SCP
This message is used to activate the

intelligent network (IN) call flow.
Request Report
basic call state
model (BCSM)
Event
SCP-> MSC
This message is used to specify the BCSM

event to be reported in the current call.
SCP -> MSC
This message is used to change some

parameters, such as the called address and
calling number display, of the current call so
that the current call proceeds according to the
service requirements.
SCP -> MSC
This message is used to control the duration

of the current call. It contains the control
parameters, such as the maximum call
duration and the tariff switch interval. When
the actual call duration reaches the maximum
call duration or when the caller or callee
releases the call, the MSC sends an Apply
Charging Report message to notify the SCP.
MSC -> SCP
This message is used to report the actual

duration of the current call and other relevant
information. The MSC sends this message
when the actual call duration reaches the
maximum call duration or when the caller or
callee releases the call.
Connect
Apply Charging
Apply Charging
Report
This message is used to send the e

parameter to the MSC. It contains the Charge
Furnish Charging
Information
SCP -> MSC
Advice Information (CAI), which can be used

to replace the CAI generated by the MSC and
inhibit any further generation of the CAI by the
MSC.
SCP -> MSC
This message is used to request the MSC to

proceed with the processing of the suspended
call.
Event Report
BCSM
MSC -> SCP
This message is used to notify the SCP of a

call-related event previously requested by the
SCP.
Play
Announcement
SCP -> MSC

play an announcement to the subscriber.
SCP -> MSC

play an announcement to the subscriber. This
announcement notifies the subscriber to enter
relevant information, such as the account and
password.
MSC -> SCP
This message is used to notify the SCP that a

Play Announcement operation has been
completed.
Connect To
Resource
SCP -> MSC
This message is used to connect a call

segment from the GSM service switching
function (gsmSSF) to a specialized local
resource.
Any Time
Interrogation
SCP -> HLR
This message is used to query the location

and status information of a subscriber.
Continue
Prompt And
Collect User
Information
Specialized
Resource Report
Any Time
Interrogation
HLR -> SCP
ACKnowledgement
(ACK)
This message is used to return the requested

location and status information of a
subscriber.
Parent topic: CAP Protocol


The CAMEL Application Part (CAP) messages do not contain any common part.

Initial DP
Request Report BCSM Event
Connect
Apply Charging
Apply Charging Report
Furnish Charging Information
Continue
Event Report BCSM
Play Announcement
Prompt And Collect User Information
Specialized Resource Report
Connect To Resource
Any Time Interrogation Request
Any Time Interrogation ACK
Disconnect Forward Connection
Initial DP
Message Function
Associated IEs
Reference Standards
Message Function
The Initial Detection Point (DP) message is sent from the MSC to the SCP. The MSC
generates the Initial DP message when a trigger is detected at a DP in the basic call state
model (BCSM). The Initial DP message contains information required by the SCP, such as
the calling number, called number, caller location, callee location, and subscriber status. The
IDP message also contains key parameters such as the service key. Figure 1 shows the
Figure 1 Initial DP message
Associated IEs
Description
ServiceKey
Identifies a type of Customized Applications

for Mobile network Enhanced Logic (CAMEL)
service in the SCP service logic.
For details, see ServiceKey.
CalledPartyNumber
Indicates the called number. This IE is

mandatory in the Mobile Terminated Call
(MTC) flow and the Call Forwarding (CF)
flow, and is optional in the Mobile Originated
Call (MOC) flow.
For details, see CalledPartyNumber.
CallingPartyNumber
Indicates the Mobile Station International

ISDN Number (MSISDN) of the caller, for
example, 8613903000001.
For details, see CallingPartyNumber.
CallingPartys Category
Indicates the caller category. Caller are

categorized into operator, pay phone, and
ordinary subscriber.
For details, see CallingPartys Category.
CallReference Number
Identify a call. This IE provides the call

reference number allocated by the
GMSC/MSC for the call.
For details, see CallReference Number.
ipSSPCapabilities
Indicates which GSM specialized resource

function (gsmSRF) resources are available
within the visited mobile switching center
(VMSC)/GMSC where the GSM service
switching function (gsmSSF) resides. It
notifies the SCP of the available resources
configured on the VMSC/GMSC/gsmSSF.
For details, see ipSSPCapabilities.
LocationNumber
Indicates the area code of the location. When

the Calling Party Number does not contain
any caller location information, this IE
indicates the caller location. The format is
Country code + Area code, for example,
8610.
For details, see LocationNumber.
locationInformation

For details, see locationInformation.
Identifies a mobile subscriber.

SubscriberState
Indicates the current state of the subscriber.

The states are CAMEL Busy, Network
Determined Not Reachable, and Assumed
Idle.
For details, see SubscriberState.
MSCAddress

For details, see MSCAddress.
bearcapability
Indicates the bearer capability connection to

the subscriber.
For details, see bearcapability.
EventTypeBCSM
Indicates the configuration event detection

point (EDP) event that triggers the current
Initial DP event. Common EventTypeBCSMs
are collectedInfo,
termAttemptAuthorized(12),
analyzedInformation, routeSelectFailure,
oCalledPartyBusy, and oNoAnswer. DP2 is
the mobile originated (MO) CAMEL service,
and DP12 is the mobile terminated (MT)
CAMEL service.
For details, see eventTypeBCSM.
timeZone
Indicates the time that the CAMEL service is

triggered and the time zone where the MSC
that triggers the CAMEL service is located.
For details, see timeZone.
Reference Standards
For details, see 4.6.1.8 "Initial DP" in 3rd Generation Partnership Project (3GPP) 23.078.
Request Report BCSM Event

Message Function
Associated IEs
Reference Standards
Message Function
The Request Report basic call state model (BCSM) Event (RRBE) message is sent from
the SCP to the MSC. According to the service requirements, the SCP uses the RRBE
message to request the MSC to monitor the call-specific BCSM event. On receiving this
message, the MSC records the BCSM event for which the SCP requests a report, and then
notifies the SCP of the event through the Event Report BCSM message when this BCSM
event occurs. The RRBE message contains the event to be monitored. Figure 1 shows the
Figure 1 Request Report BCSM Event (RRBE) message
Associated IEs
Description
eventTypeBCSM
Indicates the event type, that is, the

detection point (DP) that the MSC is
requested to monitor. collectedInfo and
termAttemptAuthorized are invalid values of
the eventTypeBCSM.
Indicates the mode in which the event is
reported. The values are as follows:
Monitor Mode
interrupted: indicates that the event

is reported as a request. The MSC
performs the subsequent
processing only after the response
is received.
notifyandcontinue: indicates that the
event is reported as a notification.
The MSC performs the subsequent
processing without receiving any
response from the SCP.
transparent: indicates that the event
is not reported to the SCF.
For details, see Monitor Mode.
Indicates the party whose call events shall be
reported to the SCF. The SCF can use only
the option sendingSideID. If sendingSideID is
not available, the following default values of
legID are used:
legID
For the event types O-Abandon and

T-Abandon, the default value of
legID is 1.
For the event types
RouteSelectFailure, OCalledPartyBusy, O-NoAnswer, OAnswer, O-NotReachable, TCalledPartyBusy, T-NoAnswer, TAnswer, and T-NotReachable, the
default value of legID is 2.
For the event types O_Disconnect
and T_Disconnect, the value of

legID ID must be explicitly given.
For details, see legID.
Application Timer
Indicates the timer duration for No_Answer

event. If the answer message is not received
after this timer expires, the MSC reports the
No_Answer event. Note that this duration
must be shorter than the duration of the
network No_Answer timer.
For details, see Application Timer.
Reference Standards
For details, see 4.6.2.14 "Request Report BCSM Event" in 3rd Generation Partnership
Project (3GPP) 23.078.
Connect
Message Function
Associated IEs
Reference Standards
Message Function
The Connect message is sent from the SCP to the MSC. The SCP uses this message to
change some parameters, such as the called address and calling number display, of the
current call so that the current call proceeds according to the service requirements. Figure
Associated IEs
Description
Destination Routing Address
Indicates the number to which the call is

routed. It is a mandatory IE.
For details, see Destination Routing Address.
Original Called Party ID
Indicates the original called number. This IE

is present when the call is forwarded.
For details, see Original Called Party ID.
Redirecting Party ID
Indicates the redirecting number from which

the route is forwarded.
For details, see Redirecting Party ID.
Redirection Information
Indicates the redirecting information, such as

the forwarding times and forwarding reason.
For details, see Redirection Information.
Generic Number
Indicates the generic number. This generic

number is used to overwrite the calling line ID
presented to the callee and is filled in the
calling number field in the call detail record
(CDR).
For details, see Generic Number.
Alerting Pattern

Reference Standards
For details, see 4.6.2.6 "Connect" in 3rd Generation Partnership Project (3GPP) 23.078.
Apply Charging
Message Function
Associated IEs
Reference Standards
Message Function
The Apply Charging (AC) message is sent from the SCP to the MSC. This message is used
to control the duration of the current call. The AC message contains the control parameters,
such as the maximum call duration and the tariff switch interval. When the actual call
duration reaches the maximum call duration or when the caller or callee releases the call,
the MSC sends an Apply Charging Report message to notify the SCP. Figure 1 shows the
Figure 1 Apply Charging message

Associated IEs
Description
BillingCharging Characteristics
Indicates a list of parameters required for the

Customer Support Engineer (CSE) control of
call duration. It contains information, such as
maxCallPeriodDuration,
releaseIfdurationExceeded, and PlayTone.
For details, see BillingCharging
Characteristics.
Indicates the maximum call duration of the
current call. In the prepaid service (PPS)
service, the value of MaxCallPeriod Duration
is 15 minutes. If the duration of the last
segment of conversation is equal to or
shorter than one minute, the duration of the
MaxCallPeriod Duration
last but two segment of conversation must be

configured as the duration of the last
segment of conversation and set to a value
between 15 and 16. In this way, the
subscriber can still hear the announcement in
the last minute of the conversation.
For details, see MaxCallPeriod Duration.
releaseIfdurationExceeded
Indicates whether the call is released after

the maximum call duration is reached. In
normally cases, the value of this IE is FALSE.
The value of this IE is TRUE (indicating that
the call is released) in the last Apply
Charging (AC) message only when the
balance of the subscriber is sufficient only for
one AC operation.
For details, see releaseIfdurationExceeded.
Tariff Switch Interval
Indicates the tariff switch interval, that is, the

time interval at which the tariff is switched.
For details, see Tariff Switch Interval.
PartyToCharge
Indicates the party to be charged in a call.

This IE must be present in the Apply
Charging Report (ACR) message sent by the
MSC.
For details, see PartyToCharge.
sendCalculationToSCPIndication
Indicates that the MSC sends the Apply

Charging Report (ACR) message after the
maximum call duration specified in the Apply
Charging (AC) message is reached. This IE
is always set to TRUE.
For details, see
sendCalculationToSCPIndication.
PlayTone
Indicates that the MSC plays a warning tone

or an announcement when the balance of the
subscriber is insufficient. The MSC
determines whether the announcement is
played one minute or three minutes before
the balance of the subscriber is exhausted.
The IE PlayTone is present in the last Apply
Charging (AC) message only when the value
of the IE ReleaseIfDuration Exceeded is
TRUE.
For details, see PlayTone.

Reference Standards
For details, see 4.6.2.2 "Apply Charging" in 3rd Generation Partnership Project (3GPP)
23.078.
Apply Charging Report

Message Function
Associated IEs
Reference Standards
Message Function
The Apply Charging Report (ACR) message is sent from the MSC to the SCP. When the
actual call duration reaches the maximum call duration or when the caller or callee releases
the call, the MSC sends the ACR message to the SCP, notifying the SCP of the actual call
duration and other relevant information. Figure 1 shows the main IEs of the message.
Figure 1 Apply Charging Report message

Associated IEs
Description
CallResult
Indicates the charging information requested

by the SCF in the Apply Charging message.
For details, see CallResult.
timeIfNoTariffSwitch
This IE is present only when no tariff switch

has occurred. This IE is mutually exclusive
with the IE timeIfTariffSwitch.
For details, see timeIfNoTariffSwitch.
This IE is present only when tariff switch has
occurred. It indicates the conversation

duration before and after the tariff is
switched.
This IE contains the following information:
Time SinceTariff Switch: indicates
the conversation duration from the
time that tariff switch occurs in the
time that the ACR message is sent.
Tariff Switch Interval: indicates the
conversation duration from the time
that the Apply Charging (AC)
message is sent to the time that
tariff switch occurs.
timeIfTariffSwitch
For details, see timeIfTariffSwitch.
partyToCharge

leg1 refers to the caller and leg2 refers to
the callee.
CallActive
Indicates the call status (active or released)

when the ACR message is sent. It is one of
the criteria based on which the SCP
determines whether to send the next AC
message after receiving the ACR message.
For details, see CallActive.
Reference Standards
For details, see 4.6.1.2 "Apply Charging Report" in 3rd Generation Partnership Project
(3GPP) 23.078.
Furnish Charging Information

Message Function
Associated IEs
Reference Standards
Message Function
The Furnish Charging Information (FCI) message is sent from the SCP to the MSC. The
SCP uses this message to send the e parameter to the MSC. The FCI message contains
the Charge Advice Information (CAI), which can be used to replace the CAI generated by
the MSC and inhibit any further generation of the CAI by the MSC. Figure 1 shows the main
IEs of the message. Relevant IEs in the FCI message sent by the SCP are filled in the
CDRs to identify the CDRs and facilitate call detail record (CDR) sorting.
Figure 1 Furnish Charging Information message

Associated IEs
FreeFormatData
Description
Indicates the relevant charging information.
This IE contains the free-format billing and/or
charging characteristics. The MSC must
insert the contents contained by this IE to the
Customized Applications for Mobile network
Enhanced Logic (CAMEL) CDR.

For details, see FreeFormatData.
Indicates the party (caller or callee) to be
charged or the party for which the CDR is
generated.
PartyToCharge
Indicates how the MSC processes multiple

FCIs that are sent in a flow.
If the value is Append, it indicates
that the next FCI is appended to the
previous FCI.
If the value is Overwrite, it indicates
that the previous FCI is overwritten
by the next FCI.
AppendFreeFormat Data
For details, see AppendFreeFormat Data.

Reference Standards
For details, see 4.6.2.12 "Furnish Charging Information" in 3rd Generation Partnership
Continue
Message Function
Associated IEs
Reference Standards
Message Function
The Continue message is sent from the SCP to the MSC. The SCP uses this message to
request the MSC to proceed with the processing of the suspended call. The Continue
message does not contain any Information Element (IE), as shown in Figure 1.
Figure 1 Continue message

Associated IEs
IE
Description
None
None
Reference Standards
For details, see 4.6.2.8 "Continue" in 3rd Generation Partnership Project (3GPP) 23.078.

Event Report BCSM

Message Function
Associated IEs
Reference Standards
Message Function
The Event Report BCSM (ERB) message is sent from the MSC to the SCP. On receiving
the request report BCSM event (RRBE) message, the MSC records the event for which the
SCP requests a report. When this event occurs, the MSC notifies the SCP of the event
through the ERB message and the SCP determines the subsequent processing based on
the event type. An RRBE message can request monitoring of multiple events, but these
events are reported in different ERB messages. Figure 1 shows the main IEs of the Event
Report basic call state model (BCSM) message.
Figure 1 Event Report BCSM message

Associated IEs
Description
eventTypeBCSM
Indicates the type of the event to the

reported.
Indicates the call information related to the
specified event.
eventSpecificInformationBCSM
If the event is RouteSelectFailure,

the IE
contains the failure cause (if
available).
If the event is O-Busy or T-Busy, the
IE eventSpecificInformationBCSM
contains the busy cause (if
available).
If the event is O-NoAnswer or TNoAnswer, the IE
eventSpecificInformationBCSM is
empty.
If the event is O-Answer or TAnswer, the IE
empty.
If the event is O-Disconnect or TDisconnect, the IE
contains the release cause (if
available).
If the event type is O-NotReachable
or T-NotReachable, the IE
available).
For details, see
eventSpecificInformationBCSM.
legID

reported to the GSM service switching
function (gsmSSF). The gsmSSF can use
only the option receivingSideID. If the value
of legID is 1, it indicates that the call events
of the caller shall be reported to the gsmSSF.
If the value of legID is 2, it indicates that the
call events of the callee shall be reported to
the gsmSSF.
For details, see legID.
Reference Standards
For details, see 4.6.1.4 "Event Report BCSM" in 3rd Generation Partnership Project
(3GPP) 23.078.
Play Announcement
Message Function
Associated IEs
Reference Standards
Message Function
The Play Announcement message is sent from the SCP to the assistant MSC. When
subscribers interact with other in a Customized Applications for Mobile network Enhanced
Logic (CAMEL) call, the SCP sends this message to the MSC, requesting the MSC to play
an announcement to the subscriber. In this process, the MSC serves as a signaling relay.
On receiving the Play Announcement message, the MSC forwards this message to the
relevant MSC. Figure 1 shows the main IEs of the message.
Figure 1 Play Announcement message

Associated IEs
Description
informationToSend
Indicates the information to be sent.

For details, see informationToSend.
It contains the following IEs:
inbandInfo
Message ID: indicates the

message(s) to be sent.
Number Of Repetitions: indicates
the maximum number of times the
message shall be sent to the
subscriber. It is an optional IE.
Duration: indicates the maximum
duration that the message shall be
played or repeated. The value 0
indicates endless repetition. It is an
optional IE.
Interval: indicates the time interval
between successive messages. It is
an optional IE.
For details, see inbandInfo.
Indicates the tone information. It contains the
following information:
tone
ToneID: identifies a tone.

Duration: indicates the duration of
the tone. It is an optional IE.
For details, see tone.
Indicates whether to release the connection
between the special resource and the
subscriber after the announcement is
complete.
disconnectFromIPForbidden
If the value is TRUE, it indicates that

disconnecting the subscriber from
the special resource is prohibited.
If the value is FALSE, it indicates
that disconnecting the subscriber
from the special resource is
permitted.
For details, see disconnectFromIPForbidden.
requestAnnouncementComplete
Indicates whether to send the Special

Resource Report (SRR) after the tone or
announcement is complete.
For details, see
requestAnnouncementComplete.
Reference Standards
For details, see 4.6.3.3 "Play Announcement" in 3rd Generation Partnership Project (3GPP)
23.078.
Prompt And Collect User Information

Message Function
Associated IEs
Reference Standards
Message Function
The Prompt And Collect User Information message is sent from the SCP to the assistant
MSC. When subscribers interact with other in a Customized Applications for Mobile network
Enhanced Logic (CAMEL) call, the SCP sends this message to the MSC, requesting the
MSC to play an announcement to the subscriber. This announcement notifies the subscriber
to enter relevant information, such as the account and password. After the MSC collects
the information entered by the subscriber, it sends the collected information as the result of
the Prompt And Collect User Information message to the SCP. In this process, the MSC
serves as a signaling relay. On receiving the Prompt And Collect User Information message,
the MSC forwards this message to the controlling MSC. Figure 1 shows the main IEs of the
message.
Figure 1 Prompt And Collect User Information message
Associated IEs
Description
Indicates the subscriber information to be
Collected Info
collected.
For details, see Collected Info.
minimumNbOfDigits
Indicates the minimum number of valid digits

to be collected.
For details, see minimumNbOfDigits.
maximumNbOfDigits
Indicates the maximum number of valid digits

to be collected.
For details, see maximumNbOfDigits.
endOfReplyDigit
Indicates the digit string used to signal the

end of input. It is an optional IE.
For details, see endOfReplyDigit.
cancelDigit
Indicates the cancel digit string that may be

entered by the user to request a retry. It is
an optional IE.
For details, see cancelDigit.
startDigit
Indicates the start digit string that denotes

the start of the valid digits to be collected. It
is an optional IE.
For details, see startDigit.
firstDigitTimeOut
Indicates the duration of the first-digit timer.

It is an optional IE. If this IE is not present,
the MSC uses a default value for the firstdigit timer. The default value is 10 seconds
and is configurable. If the subscriber does
not enter any valid information before the
first-digit timer expires, the MSC performs
the timeout processing.
For details, see firstDigitTimeOut.
interDigitTimeOut
Indicates the duration of the inter-digit timer.

the MSC uses a default value for the interdigit timer. The default value is 10 seconds
and is configurable. When the subscriber
enters the information, if the interval between
two keystrokes exceeds the duration of the
inter-digit timer, the MSC performs the
timeout processing.
For details, see interDigitTimeOut.
Indicates the specific action to be taken
errorTreatment
when errors occur, that is, the processing

mode of the MSC when the input of the
subscriber is invalid or incorrect.
For details, see errorTreatment.
interruptableAnnInd
Indicates whether to interrupt the

announcement after the first valid digit is
received by the MSC. If the value of this IE is
TRUE, the announcement is interrupted after
the first valid digit is received by the MSC. If
the value of this IE is FALSE, the
announcement is not interrupted after the first
valid digit is received by the MSC.
For details, see interruptableAnnInd.
informationToSend

The values are inbandInfo and tone.
For details, see informationToSend.
inbandInfo

optional IE.
an optional IE.
For details, see inbandInfo.
tone

For details, see tone.

complete.
For details, see disconnectFromIPForbidden.
Reference Standards
For details, see 4.6.3.4 "Prompt And Collect User Information" in 3rd Generation
Partnership Project (3GPP) 23.078.
Specialized Resource Report

Message Function
Associated IEs
Reference Standards
Message Function
The Specialized Resource Report (SRR) message is sent from the MSC to the SCP. The
MSC uses this message to notify the SCP that a Play Announcement operation has been
completed. The SRR message is a null message, as shown in Figure 1.
Figure 1 Specialized Resource Report message

Associated IEs
Description
None
None
Reference Standards
For details, see 4.6.4.4 "Specialized Resource Report" in 3rd Generation Partnership
Connect To Resource
Message Function
Associated IEs
Reference Standards
Message Function
The Connect To Resource message is sent from the SCP to the MSC. The GSM service
control function (gsmSCF) uses this operation to connect a call segment from the GSM
service switching function (gsmSSF) to a specialized local resource. After the successful
connection to the GSM specialized resource function (gsmSRF), the gsmSCF can interact
with the subscriber. The gsmSSF relays all operations for the gsmSRF and all responses
from the gsmSRF. Figure 1 shows the main IEs of the message.
Figure 1 Connect To Resource message
Associated IEs
Description
resourceAddress
Indicates the physical address of the

gsmSRF.
For details, see resourceAddress.
iPRoutingAddress
Indicates the routing address to set up a

connection to the gsmSRF.
For details, see iPRoutingAddress.
none
Indicates that the call segment shall be

connected to a predefined gsmSRF.
Indicates whether to set up the connection
serviceInteractionIndicatorsTwo
between the caller and the gsmSRF. This IE

is sent from the gsmSCF to the gsmSSF.
For details, see
serviceInteractionIndicatorsTwo.
Reference Standards
For details, see 4.6.2.7 "Connect To Resource" in 3rd Generation Partnership Project
(3GPP) 23.078.
Any Time Interrogation Request

Message Function
Associated IEs
Reference Standards
Message Function
The Any Time Interrogation Request message is sent from the GSM service control function
(gsmSCF) to the home location register (HLR) serving called parties so that the gsmSCF
can query subscriber information, such as the location, status, IMEI (with software version),
and MS classmark information for the requested domain, from the HLR at any time. Figure
1 shows the information elements (IEs) contained in the message.
Figure 1 IEs contained in the Any Time Interrogation Request message
Associated IEs
IE
Subscriber Identity
Description
Identifies the subscriber whose information is being requested.
This IE is either the subscriber's IMSI or MSISDN.
Indicates the type of subscriber information being requested.
This IE includes the following parameters:
Location Information (optional): Indicates that the
Location Information is requested.
Requested Info
Subscriber State (optional): Indicates that the

Subscriber State is requested.
Current Location (optional with a specific requirement):
Indicates that the Current Location is requested. This
parameter must be present together with Location
Information.
Location Information in EPS Supported (optional with a
specific requirement): Indicates by its presence that
Location Information in EPS is supported. This
parameter must be present together with Location
Information.
Requested Domain (mandatory): Indicates for which
domain the subscriber info is requested. It shall be
either of the following:
CS domain
PS domain
IMEI (with software version) (optional): Indicates that
the IMEI (with software version) is requested.
MS class mark information for the requested domain
(optional): Indicates that the MS classmark information
for the indicated domain is requested.
gsmSCF Address
Indicates the address of the interrogating gsmSCF. The gsmSCF

Address shall be in international E.164 format.
Reference Standards
For details about the Any Time Interrogation Request message, see 11.3.3.1 "Any Time
Interrogation Request" in 3rd Generation Partnership Project (3GPP) 23.078.
Any Time Interrogation ACK

Message Function
Associated IEs
Reference Standards
Message Function
The Any Time Interrogation ACK (ATI ACK) message is sent from the HLR to the gsmSCF.
The HLR uses this message to return the requested subscriber location and/or subscriber
state information to the gsmSCF.
Associated IEs
The table shows the main information elements (IEs) in the message. The following
information elements (IEs) are optional:
Information Element(IE) Description
LocationInformation
Location Information For
GPRS
Subscriber State
PS Domain Subscriber
State
IMEI (with software
version)
MS Classmark 2
Indicates the location of the served subscriber in the MSC/VLR.

Indicates the location of the served subscriber in the SGSN.
Indicates the state of the MS in the CS domain.
Indicates the state of the MS in the PS Domain.
This IE contains the IMEISV of the ME in use by the served
subscriber.
This IE contains the MS classmark 2, which is returned by the
MS when it responds to paging in the CS domain.
Reference Standards
For details, see 11.3.4.1 "Any Time Interrogation Request ACK" in 3rd Generation
Partnership Project (3GPP) 23.078.
Disconnect Forward Connection

Message Function
Associated IEs
Reference Standards
Message Function
The Disconnect Forward Connection message is sent from the SCP to the MSC. This
message instructs the MSC to disconnect from the GSM specialized resource function
(gsmSRF). The message does not contain any Information Element (IE), as shown in
Figure 1.
Figure 1 Disconnect Forward Connection message
Associated IEs
IE
Description
None
None
Reference Standards
For details, see 4.6.2.10 "Disconnect Forward Connection" in 3rd Generation Partnership

ipSSPCapabilities
Alerting Pattern
Application Timer
bearcapability
CallActive
CalledPartyNumber
CallingPartyNumber
CallResult
cancelDigit
Collected Info
endOfReplyDigit
errorTreatment
eventTypeBCSM
firstDigitTimeOut
FreeFormatData
Generic Number
IMSI
inbandInfo
informationToSend
interDigitTimeOut
interruptableAnnInd
iPRoutingAddress
legID
locationInformation
LocationNumber
maximumNbOfDigits
minimumNbOfDigits
Monitor Mode
MSCAddress
PartyToCharge
PlayTone
resourceAddress
ServiceKey
startDigit
SubscriberState
timeIfTariffSwitch
timeZone
tone
ipSSPCapabilities
Reference Standards
Description
Indicates the IP/SSP capabilities supported
by the MSC. These capabilities are defined
as optional in the CAMEL Application Part
(CAP) protocol.
ipSSPCapabilities
IPRoutingAddresssupported:
indicates whether the MSC supports
the field IPRoutingAddress in the
ConnectToResource (CTR)
message.
VoiceBacksupported: indicates
whether the number dialed by the
subscriber can be announced back
to the subscriber after the MSC
collects the number.
The initial detection point (DP) message is
example, the value of
IPRoutingAddresssupported is yes, indicating
that the MSC supports the field
IPRoutingAddress in the CTR message.
The value of VoiceBacksupported is yes,
indicating the number dialed by the
subscriber can be announced back to the
subscriber after the MSC collects the
number.
You can configure the parameters contained
by the IE ipSSPCapabilities by setting

IP/SSP capability in the ADD SSPCAPA
command.
Reference Standards
For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078.
Alerting Pattern
Reference Standards
Description
Indicates the alerting pattern to be applied.
Alerting Pattern: indicates the alerting pattern

to be applied.
The Connect message is considered as an
example here. In this example, the value of
Alerting Pattern is 0x11, indicating that the
key value of the alerting pattern of the
subscriber is 0x11.
Alerting Pattern
Reference Standards
Reference Standards
Description
Indicates how the MSC processes multiple
FCIs that are sent in a flow.
If the value is Append, it indicates
that the next furnish charging
information (FCI) is appended to the
previous FCI.
If the value is Overwrite, it indicates
that the previous FCI is overwritten
by the next FCI.
AppendFreeFormatData: indicates how the
MSC processes multiple FCIs that are sent in
a flow.
The Furnish Charging Information is
example, the value of AppendFreeFormat
Data is Overwrite, indicating that the previous
FCI is overwritten by the next FCI.
Reference Standards
Application Timer
Reference Standards
Description
Indicates the timer duration for No_Answer
event. If the answer message is not received
after this timer expires, the MSC reports the
No_Answer event.
Note that this duration must be shorter than the
duration of the network No_Answer timer.
Application Timer
ApplicationTimer: indicates the timer duration

for No_Answer event.
The Request Report basic call state model
(BCSM) Event is considered as an example

here. In this example, the value of Application
Timer is 40, indicating that the MSC reports
the No_Answer event if the answer message is
not received within 40 seconds.
Reference Standards
bearcapability
Reference Standards
Description
Indicates the bearer capability connection to
the subscriber.
bearcapability
informationTransferCapability:
indicates the transfer capability.
transferMode: indicates the transfer
mode.
The Initial detection point (DP) is considered
as an example here. In this example, the
value of informationTransferCapability is
speech, indicating the speech transmission is
supported; the value of transferMode is
circuit-mode, indicating that the transfer
mode is the circuit mode.
Reference Standards
Reference Standards
Description
Indicates a list of parameters required for the
Customer Support Engineer (CSE) control of
call duration.
It contains information, such as
maxCallPeriodDuration,
releaseIfdurationExceeded, and PlayTone.
The Apply Charging is considered as an

maxCallPeriodDuration is 600, indicating that
the maximum call duration is 60 seconds.
Reference Standards
CallActive
Reference Standards
Description
Indicates the call status (active or released)
when the ACR message is sent. It is one of
the criteria based on which the SCP
determines whether to send the next Apply
Charging (AC) message after receiving the
Apply Charging Report (ACR) message.
CallActive
The Apply Charging Report message is

example, the value of CallActive is FALSE,
indicating that the call is released.
Reference Standards
CalledPartyNumber
Reference Standards
Description
Indicates the called number.
This IE is mandatory in the Mobile Terminated Call (MTC)
flow and the Call Forwarding (CF) flow, and is optional in
the Mobile Originated Call (MOC) flow.
CalledPartyNumber
The Initial detection point (DP) message is considered as

an example here. In this example, the called number is
8613907550446.
Reference Standards
CallingPartyNumber
Reference Standards
Description
Indicates the calling number.
CallingPartyNumber
The Initial detection point (DP) message is
considered as an example here. In this example, the
calling number is 8613907521137 (international
number).
Reference Standards
Reference Standards
Description
Indicates the caller category.

example, the value of CallingPartys Category
is ordinary subscriber, indicating that the
caller is an ordinary subscriber.
Reference Standards
Reference Standards
Description
Identify a call. This IE provides the call
reference number allocated by the
GMSC/MSC for the call.
example, the call reference number is 16 02
66 09 05 82.
Reference Standards
CallResult
Reference Standards
Description
Indicates the charging information requested
by the SCF in the Apply Charging message.
CallResult
example, partyToCharge and timeInformation
are provided.
The value of partyToCharge is leg1,
indicating that the current call is paid
by the caller.
The value of callActive is TRUE,
indicating that the call is in active
state.
Reference Standards
cancelDigit
Reference Standards
Description
Indicates the cancel digit string that may be
entered by the user to request a retry. It is
an optional IE.
cancelDigit
The Prompt And Collect User Information

In this example, the value of cancelDigit is
oB, indicating that the entered characters are
discarded if the asterisk (*) is received.
Reference Standards
Collected Info
Reference Standards
Description
Indicates the subscriber information to be
collected. Information to be collected is as
follows:
minimumNbOfDigits
maximumNbOfDigits
endOfReplyDigit
cancelDigit
startDigit
firstDigitTimeOut
interDigitTimeOut
errorTreatment
interruptableAnnInd
voiceInformation
voiceBack
Collected Info

In this example, the value of
maximumNbOfDigits is 16, indicating that the
maximum number of valid digits to be
collected is 16.
Reference Standards

Reference Standards
Description
Indicates the number to which the call is routed. It is a
mandatory IE.

The Connect message is considered as an example here.
In this example, the destination routing address is
8613466784401 (international number).
Reference Standards
Reference Standards
Description
complete. If the value is TRUE, it indicates
that disconnecting the subscriber from the
special resource is prohibited. If the value is
FALSE, it indicates that disconnecting the
subscriber from the special resource is
permitted.
The Play Announcement message is

disconnectFromIPForbidden is TRUE,
indicating that disconnecting the subscriber
from the special resource is permitted.
Reference Standards
endOfReplyDigit
Reference Standards
Description
Indicates the digit string used to signal the
end of input. It is an optional IE.
endOfReplyDigit

In this example, the value of endOfReplyDigit
is 0C, indicating that the input is complete
when the pound key (#) is received.
Reference Standards
errorTreatment
Reference Standards
Description
Indicates the specific action to be taken
when errors occur, that is, the processing
mode of the MSC when the input of the
subscriber is invalid or incorrect.
errorTreatment

In this example, the value of errorTreatment
is repeatPrompt, indicating that the system
prompts the subscriber to enter information
again when the input is invalid.
Reference Standards
Reference Standards
Description
Indicates the call information related to the
specified event.
If the event is RouteSelectFailure,

the IE
contains the failure cause (if
available).
If the event is O-Busy or T-Busy, the
IE eventSpecificInformationBCSM
contains the busy cause (if
available).
If the event is O-NoAnswer or TNoAnswer, the IE
empty.
If the event is O-Answer or TAnswer, the IE
empty.
If the event is O-Disconnect or TDisconnect, the IE
available).
If the event type is O-NotReachable
or T-NotReachable, the IE
available).
The Event Report basic call state model

(BCSM) message is considered as an
example here. In this example, the release
cause is terminal error.
Reference Standards
eventTypeBCSM
Reference Standards
Description
Indicates the type of the event to the
reported.
eventTypeBCSM
The Event Report basic call state model

(BCSM) message is considered as an
eventTypeBCSM is tDisconnect, indicating
the call release event.
Reference Standards
firstDigitTimeOut
Reference Standards
Description
Indicates the duration of the first-digit timer.
the MSC uses a default value for the firstdigit timer. The default value is 10 seconds
and is configurable. If the subscriber does
not enter any valid information before the
first-digit timer expires, the MSC performs
the timeout processing.
firstDigitTimeOut

In this example, the value of firstDigitTimeOut
is 8, indicating that the timer expires if the
first digit is not received within eight seconds.
Reference Standards

FreeFormatData
Reference Standards
Description
Indicates the relevant charging information.
This IE contains the free-format billing and/or
charging characteristics. The MSC must
insert the contents contained by this IE to the
Customized Applications for Mobile network
Enhanced Logic (CAMEL) call detail record
(CDR).
FreeFormatData
The Furnish Charging Information message is

example, the content to be inserted to the
CAMEL CDR is 80 01 30.
Reference Standards
Generic Number
Reference Standards
Description
Indicates the generic number.
This generic number is used to overwrite the calling
line ID presented to the callee and is filled in the
calling number field in the call detail record (CDR).
Generic Number
The Connect message is considered as an example

here. In this example, the generic number is 607040.
Reference Standards
IMSI
Reference Standards
Description
Identifies a mobile subscriber.

example, the IMSI is 460077552000446.
Reference Standards
inbandInfo
Reference Standards
Description
Indicates the inband information.
This IE contains the following IEs:
optional IE.
an optional IE.
inbandInfo

example, the announcement is repeated
twice, the duration is 16 seconds, and there
is no interval between two successive
announcements.
Reference Standards
informationToSend
Reference Standards
Description
inbandInfo: indicates the inband
information
tone: indicates the tone.
informationToSend

example, the inband information is sent.
Reference Standards
interDigitTimeOut
Reference Standards
Description
Indicates the duration of the inter-digit timer.
the MSC uses a default value for the interdigit timer. The default value is 10 seconds
and is configurable. When the subscriber
enters the information, if the interval between
two keystrokes exceeds the duration of the
inter-digit timer, the MSC performs the
timeout processing.
interDigitTimeOut

interDigitTimeOut is 5, indicating that the
timer expires if the interval between two
digits exceeds five seconds.
Reference Standards
interruptableAnnInd
Reference Standards
Description
Indicates whether to interrupt the
announcement after the first valid digit is
received by the MSC.
If the value of this IE is TRUE, the
announcement is interrupted after the first
valid digit is received by the MSC. If the
value of this IE is FALSE, the announcement
is not interrupted after the first valid digit is
received by the MSC.
interruptableAnnInd


interruptableAnnInd is TRUE, indicating that
the announcement is interrupted after the first
valid digit is received by the MSC.
Reference Standards
iPRoutingAddress
Reference Standards
Description
Indicates the routing address to set up a connection to the
GSM specialized resource function (gsmSRF).
iPRoutingAddress
The Connect To Resource message is considered as an

example here. In this example, the routing address is
8613907521124.
Reference Standards
legID
Reference Standards
Description
reported to the SCF.
The SCF can use only the option
sendingSideID. If sendingSideID is not
available, the following default values of legID
are used:
legID
For the event types O-Abandon and

T-Abandon, the default value of
legID is 1.
For the event types
RouteSelectFailure, OCalledPartyBusy, O-NoAnswer, OAnswer, O-NotReachable, TCalledPartyBusy, T-NoAnswer, TAnswer, and T-NotReachable, the
default value of legID is 2.
For the event types O_Disconnect
and T_Disconnect, the value of
legID must be explicitly given.

(BCSM) Event message is considered as an
legID is 2, indicating that the call events of
the callee shall be reported to the SCF.
Reference Standards

locationInformation
Reference Standards
Description
locationInformation

the VLR number is 861310752051.
Reference Standards
LocationNumber
Reference Standards
Description
Indicates the area code of the location.
When the Calling Party Number does not contain any caller
location information, this IE indicates the caller location. The
format is Country code + Area code.
LocationNumber
The Initial detection point (DP) message is considered as an

example here. In this example, the value of LocationNumber
is 86755, indicating that the country code is 86 and the area
code is 755.
Reference Standards
Reference Standards
Description
Indicates the maximum call duration of the
current call.
In the prepaid service (PPS) service, the
value of MaxCallPeriod Duration is 15
minutes. If the duration of the last segment of
conversation is equal to or shorter than one
minute, the duration of the last but two
segment of conversation must be configured
as the duration of the last segment of
conversation and set to a value between 15
and 16. In this way, the subscriber can still
hear the announcement in the last minute.
The Apply Charging message is considered

maximum call duration is 120 seconds.
Reference Standards
maximumNbOfDigits
Reference Standards
Description
Indicates the maximum number of valid digits
to be collected.
maximumNbOfDigits
maximumNbOfDigits is 16, indicating that the
maximum number of valid digits to be
collected is 16.
Reference Standards
minimumNbOfDigits
Reference Standards
Description
Indicates the minimum number of valid digits
to be collected.
minimumNbOfDigits
minimumNbOfDigits is 1, indicating that the
minimum number of valid digits to be
collected is 1.
Reference Standards
Monitor Mode
Reference Standards
Description
Indicates the mode in which the event is
reported. The values are as follows:
Monitor Mode
interrupted: indicates that the event

is reported as a request. The MSC
performs the subsequent
processing only after the response
is received.
notifyandcontinue: indicates that the
event is reported as a notification.
The MSC performs the subsequent
processing without receiving any
response from the SCP.
transparent: indicates that the event
is not reported to the SCF.

(BCSM) Event message is considered as an
Monitor Mode is interrupted, indicating that
the event is reported as a request.
Reference Standards

MSCAddress
Reference Standards
Description
MSCAddress
the MSC address is 861310752051.
Reference Standards

Reference Standards
Information Element
(IE)
Description
Indicates the original called number. This IE is present when the
call is forwarded.
The Connect message is considered as an example here. In this

example, the original called number is 8613907521124.
Reference Standards
PartyToCharge
Reference Standards
Description
This IE must be present in the Apply
Charging Report (ACR) message sent by the
MSC.
PartyToCharge
value of PartyToCharge is leg1, indicating
that the call is paid by the caller.
Reference Standards
PlayTone
Reference Standards
Description
Indicates that the MSC plays a warning tone
or an announcement when the balance of the
subscriber is insufficient.
The MSC determines whether the
announcement is played one minute or three
minutes before the balance of the subscriber
is exhausted. The IE PlayTone is present in
the last Apply Charging (AC) message only
when the value of the IE ReleaseIfDuration
Exceeded is TRUE.
PlayTone

as an example here.
Reference Standards
Reference Standards
Description
Indicates the redirecting number from which the route is
forwarded.
The Connect message is considered as an example

here. In this example, the redirecting number is
8613907521124.
Reference Standards
Reference Standards
Information
Element
Description
(IE)
Indicates the redirecting information, such as the forwarding times and
forwarding reason.
Redirection
Information
The Connect message is considered as an example here. In this example, the

call is forwarded for once because the subscriber is busy.
Reference Standards
Reference Standards
Description
Indicates whether the call is released after
the maximum call duration is reached.
In normally cases, the value of this IE is
FALSE. The value of this IE is TRUE
(indicating that the call is released) in the
Apply Charging (AC) message only when the
balance of the subscriber is sufficient only for
one AC operation.

value of releaseIfdurationExceeded is 1,
indicating the call is released after the
maximum call duration is reached.
Reference Standards
Reference Standards
Description
Indicates whether to send the Special
Resource Report (specialized resource
report (SRR)) after the tone or
announcement is complete.

requestAnnouncementComplete is TRUE,
indicating that the MSC sends the SRR after
the tone or announcement is complete.
Reference Standards
resourceAddress
Reference Standards
Description
Indicates the physical address of the GSM
specialized resource function (gsmSRF).
resourceAddress
The Connect To Resource message is
example, the value of resourceAddress is
none, indicating that the MSC has the
gsmSRF function.
Reference Standards
Reference Standards
Description
Indicates that the MSC sends the Apply
Charging Report (ACR) message after the
maximum call duration specified in the Apply
Charging (AC) message is reached. This IE
is always set to TRUE.

value of sendCalculationToSCPIndication is
TRUE, indicating that the MSC sends the
ACR message after the maximum call
duration specified in the AC message is
reached.
Reference Standards
Reference Standards
Description
Indicates whether to set up the connection
between the caller and the GSM specialized
resource function (gsmSRF).
The Connect To Resource message is

example, the bidirectional connection is set
up.
Reference Standards
ServiceKey
Reference Standards
Description
Identifies a type of Customized Applications
for Mobile network Enhanced Logic (CAMEL)
service. The SCP enters the service flow
based on the service key contained in the
initial detection point (IDP) message received
by the SCP. This IE is mandatory. The
service key of the prepaid service (PPS)
service is 1, and the service key of the
mobile virtual private network (MVPN)
service is 3.
ServiceKey

example, the service key is 1.
Reference Standards
startDigit
Reference Standards
Description
Indicates the start digit string that denotes
the start of the valid digits to be collected. It
is an optional IE.
startDigit

In this example, the value of startDigit is 0,
indicating that the start digit string is 0.
Reference Standards
SubscriberState
Reference Standards
Description
Indicates the current state of the subscriber.
The states are Customized Applications for
Mobile network Enhanced Logic (CAMEL)
Busy, Network Determined Not Reachable,
and Assumed Idle.
SubscriberState

Reference Standards

Reference Standards
Description
Indicates the tariff switch interval, that is, the
time interval at which the tariff is switched.

as an example here.
Reference Standards
Reference Standards
Description
Indicates whether tariff switch occurs.
The Apply Charging Report message
contains this IE only when the tariff is
switched. This IE is mutually exclusive with
the IE timeIfTariffSwitch.

Reference Standards
timeIfTariffSwitch
Reference Standards
Description
This IE is present only when tariff switch has
occurred during the conversation. It indicates
the conversation duration before and after
the tariff is switched. This IE contains the
following information:
timeIfTariffSwitch
Time SinceTariff Switch: indicates

the conversation duration from the
time that tariff switch occurs in the
time that the apply charging report
(ACR) message is sent.
Tariff Switch Interval: indicates the
conversation duration from the time
that the Apply Charging (AC)
message is sent to the time that
tariff switch occurs.

example, the value of timeSinceTariffSwitch is
5, indicating the conversation duration from
the time that tariff switch occurs in the time
that the ACR message is sent is 500
milliseconds.
Reference Standards

timeZone
Reference Standards
Description
Indicates the time that the Customized
Applications for Mobile network Enhanced
Logic (CAMEL) service is triggered and the
time zone where the MSC that triggers the
CAMEL service is located.
timeZone

Reference Standards
tone
Reference Standards
Description
Indicates the tone information.
It contains the following information:
tone

example, the tone ID is 0x100001f and the
tone duration is 15 seconds.
Reference Standards
ISUP Protocol
Description of the ISUP Protocol
Description of the ISUP Protocol

Protocol Stack
Message Structure
Message List
Integrated Services Digital Network User Part (ISUP) is the user part of the signaling
system No. 7 (SS7). It provides the signaling function for the basic bearer services and
supplementary services for voice and non-voice purposes on the Integrated Services Digital
Network (ISDN). The MSC communicates with other MSCs or the Public Switched
Telephone Network (PSTN) through the ISUP protocol. Figure 1 shows the application of
the protocol.
Figure 1 Application of the ISUP protocol
Protocol Stack
The MSOFTX3000 support the following types of transmission of the ISUP protocol:
MTP3-based transmission: Messages are transmitted through the services
provided by the Message Transfer Part (MTP). Figure 2 shows the protocol stack.
IP-based transmission: Messages are transmitted through the services provided
by Signaling Transport (SIGTRAN).
Figure 2 ISUP protocol stack (MTP3-based)
Figure 3 ISUP protocol stack (M3UA based)
Message Structure
Figure 4 shows the structure of an ISUP message.
Figure 4 ISUP message structure
The ISUP parameters can be classified into three types based on the message structure
shown in Figure 4.
Parameter Type
Description
The position and length of this type of parameter in messages

are invariable; therefore, parameter name and length indicator
Mandatory fixed parameter are not required. For example, transmission medium
requirement in the IAM message is a mandatory fixed
parameter.
Mandatory variable
parameter
The position of this type of parameter in messages is relatively

fixed; therefore, parameter name is not required. The length of
this type of parameter, however, is variable; therefore, the
length indicator is required. For example, called party number
in the IAM message is a mandatory variable parameter.
Optional parameter
This type of parameter may or may not be included in a

message; therefore, parameter name and length indicator are
required. For example, calling party number is an optional
parameter.
Message List
Message
Function
Initial address message

(IAM)
This message is 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.
Application transport
message (APM)
This message is sent in either direction to convey application

information using the Application Transport mechanism.
This message is sent in the backward direction indicating that

Address complete message
all the address signals required for routing the call to the called
(ACM)
party have been received.
Answer message (ANM)

the call has been answered.
Information request
message (INR)
This message is sent by an exchange to request information in

association with a call.
Information message (INF)
This message is sent to convey information in association with

a call.
Call progress message

(CPG)
This message is sent in either direction during the setup or

active phase of the call, indicating that a significant event has
occurred.
Connect message (CON)

all the address signals required for routing the call to the called
party have been received and that the call has been answered.
Subsequent address
message (SAM)
This message is sent in the forward direction following an IAM,

to convey additional called party number information.
This message is sent in either direction to indicate that the
Release message (REL)
circuit is being released due to the provided reason.
Release complete message This message is sent in either direction in response to a REL
(RLC)
or a reset circuit message.
Suspend message (SUS)
This message is sent in either direction indicating that the

calling or called party has been temporarily disconnected.
Resume message (RES)
This message is sent in either direction indicating that the

calling or called party, after having been suspended, is
reconnected.
Parent topic: ISUP Protocol


Information Element
(IE)
Description
Indicates the information provided to the message transfer part for
the purpose of message routing.
Routing label
Destination point code: Indicates the signaling point code

(SPC) of the network element (NE) to which the message
is routed. If the message is sent to the local office, the
destination point code is the same as the originating point
code.
Originating point code: Indicates the SPC of the NE that
sends the message.
Signalling link selection: Indicates the way in which a link
is selected for sending the ISDN user part (ISUP)
message. Signalling link selection is carried in the
message sent by the ISUP layer to the Message Transfer
Part Layer 3 (MTP3) or MTP3-User Adaptation Layer
(M3UA) layer. The MTP3 or M3UA layer selects a link,
based on Signalling link selection, to send the ISUP
message.
Circuit identification code: Uniquely identifies an interoffice circuit when the originating point code is the same
as the destination point code and the network indicator of
the originating signaling point is the same as the network
indicator of the destination signaling point. According to
the International Telecommunication UnionTelecommunication Standardization Sector (ITU-T)
recommendations, the circuit identification code (CIC) is
of 12 bits. The CIC is of 14 bits according to the
American National Standard Institute (ANSI) ISUP
protocol released in 1995 and of 16 bits according to the
ANSI ISUP protocol released in 2005. On the
MSOFTX3000 the length of the CIC can be configured by
using the ADD OFC and MOD OFC commands.

The IAM is considered as an example here. In this example, the
destination point code is 2A1004, originating point code is 2A1003,
signalling link selection is 0, and circuit identification code is 1.

IAM
APM
ACM
ANM
INR
INF
CPG
CON
SAM
REL
RLC
SUS
RES
IAM
Message Function
Associated IEs
Reference Standards
Message Function
This message is 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. Figure 1
Figure 1 IAM
Associated IEs
Message
Function
Provides the information about the transmission path used

Nature of connection indicators on a connection.
For details, see Nature of Connection Indicators.
Forward call indicators
Provides the information about the characteristics of the

connection, signaling path, and calling party sent in the
forward direction.
For details, see Forward Call Indicators.
Calling party's category
Indicates the category of the calling party.

For details, see Calling Party's Category.
Transmission medium
requirement
Indicates the type of transmission medium required for the

connection.
For details, see Transmission Medium Requirement.
Called party number
Indicates the number of the called party.

For details, see Called Party Number.
Calling party number
Indicates the number of the calling party.

For details, see Calling Party Number
Propagation delay counter
Indicates the propagation delay of a connection.

For details, see Propagation Delay Counter.
Optional forward call

indicators

connection, signaling path, and called party sent in the
forward direction.
For details, see Optional Forward Call Indicators.
Reference Standards
For details, see 2.28 in International Telecommunication Union-Telecommunication
Standardization Sector (ITU-T) Q-762 and Table 32/Q.763 in ITU-T Q-763.
APM
Message Function
Reference Standards
Message Function
This message is sent in either direction to convey application information using the
Application Transport mechanism. The MSOFTX3000 can either discard this message or
transfers this message without interpreting it.
Reference Standards
For details, see the description related to "Application transport" in International
Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and Q763.
ACM
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent in the backward direction indicating that all the address signals
required for routing the call to the called party have been received. Figure 1 shows the main
IEs of the message.
Figure 1 ACM
Associated IEs
Description
Backward call indicators

backward direction.
For details, see Backward Call Indicators.
Reference Standards
ANM
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent in the backward direction indicating that the call has been answered.
Figure 1 shows the main IEs of the message. The answer message (ANM) may carry no
Information Element (IE).
Figure 1 ANM
Associated IEs
IE
Description

backward direction.
Reference Standards
INR
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent by an exchange to request information in association with a call.
Generally, the information request (INR) message is sent to request the calling number or
category of the calling party. Figure 1 shows the main IEs of the message.
Figure 1 INR message
Associated IEs
Information request
indicators
Identifies the optional parameters requested in a message.

For details, see Information Request Indicators.
Reference Standards
INF
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent to convey information in association with a call, which may have been
requested in an information request (INR) message. Generally, this message conveys the
calling number or category of the calling party. Figure 1 shows the main IEs of the
message.
Figure 1 INF message

Associated IEs
Description
Information indicators
Identifies the optional parameters included in a message.

For details, see Information Indicators.
Reference Standards
CPG
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent in either direction during the setup or active phase of the call,
indicating that a significant event has occurred. Figure 1 shows the main IEs of the
message.
Figure 1 CPG message

Associated IEs
Description
Event information
Indicates the type of event which causes a call progress

(CPG) message to be sent.
For details, see Event Information.
Generic notification
indicator
Indicates a generic notification.

For details, see Generic Notification Indicator.
Reference Standards
CON
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent in the backward direction 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. The connect (CON) message can be regarded as the address complete
message (ACM) message + the answer message (ANM) message. Figure 1 shows the
Figure 1 CON message

Associated IEs
Description

backward direction.
Reference Standards
SAM
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent in the forward direction following an IAM, to convey additional called
party number information. Figure 1 shows the main IEs of the message.
Figure 1 SAM
Associated IEs
Subsequent number
Indicates the additional called party address digits sent

subsequent to the sending of the called party number
parameter.
For details, see Subsequent Number.
Reference Standards
REL
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent in either direction to indicate that the circuit is being released due to
the provided reason and is ready to be put into the idle state on receipt of the Radio Link
Control (RLC) message. Figure 1 shows the main IEs of the message.
Figure 1 REL message

Associated IEs
Cause indicators
Indicates the reason for sending the message.

For details, see Cause Indicators.
Reference Standards
RLC
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent in either direction in response to a release (REL) message or an
reset circuit signal (RSC) message. When this message is sent, the related circuit has
changed to the idle condition. Figure 1 shows the main IEs of the message. The Release
Confirm (RLC) message may carry no Information Element (IE).
Figure 1 RLC message

Associated IEs
IE
Description
Cause indicators
Indicates the reason for sending the message.

For details, see Cause Indicators.
Reference Standards
SUS
Message Function
Reference Standards
Message Function
This message is sent in either direction indicating that the calling or called party has been
temporarily disconnected. Figure 1 shows the main IEs of the message.
Figure 1 SUS message

Reference Standards
RES
Message Function
Reference Standards
Message Function
This message is sent in either direction indicating that the calling or called party, after having
been suspended, is reconnected. Figure 1 shows the main IEs of the message.
Figure 1 RES message

Reference Standards

Called Party Number
Propagation Delay Counter
Transmission Medium Requirement
Subsequent Number
Backward Call Indicators
Nature of Connection Indicators
Forward Call Indicators
Optional Forward Call Indicators
Event Information
Generic Notification Indicator
Information Indicators
Information Request Indicators
Cause Indicators
Calling Party Number
Calling Party's Category
Called Party Number

Reference Standards
Description
Identifies the called party. The message is routed and the
called party is located based on this IE.
Generally, this IE is contained in the IAM as a mandatory
variable parameter.
Called party number
Nature of address indicator: Indicates the nature of

a number, for example, integrated services digital
network (ISDN) international number, ISDN
national significant number, or ISDN subscriber
number.
Odd/even indicator: Indicates whether the number
is even or odd. F, the character indicating the end
of a number, is also treated as a digit of the called
number.
Address signal: Indicates the called number in
binary-coded data (BCD) format. Every four bits
represent a digit, and F indicates the end of a
number.
The IAM is considered as an example here. In this
message, 4778613807557733F refers to the called number.
This message indicates that the called number is a national
number and is odd.
Reference Standards

Standardization Sector (ITU-T) Q-762 and 3.9 in ITU-T Q-763.
Propagation Delay Counter

Reference Standards
Description
Indicates the propagation delay of a connection.
This IE is sent in the forward direction and carried in the IAM.
It is accumulated when the IE is transferred through the
network. The propagation delay information is represented
by a counter counting in integer multiples of 1 ms.
Propagation delay counter

Propagation delay value: Indicates the propagation delay in
ms.
The IAM is considered as an example here. In this example,
Propagation delay value is 5, which indicates that the
propagation delay is 5 ms.
Reference Standards
Transmission Medium Requirement

Reference Standards
Description
connection.
It is sent in the forward direction and carried in the IAM as a
mandatory parameter.
Transmission medium
requirement
Transmission medium requirement: Indicates the type of

transmission medium required for the connection. It can be
speech, 3.1 kHz audio, or 64 kbit/s unrestricted.
Transmission medium requirement is speech, which
indicates that voice calls need to be supported.
Reference Standards
Subsequent Number
Reference Standards
Subsequent number
Description
Indicates the additional called party address digits sent
subsequent to the sending of the called party number
parameter.
For example, in the case of overlap sending, the IAM does
not carry the complete called number. The remaining digits of
the called number are sent through the Subsequent number IE
in several SAMs.
Reference Standards
Backward Call Indicators

Reference Standards
Description
Indicates the characteristics of the connection, signaling path,
and called party sent in the backward direction.
This IE is mandatory for the address complete message
(ACM) and connect (CON) message and optional for the
answer message (ANM).
Charge indicator: Indicates whether the called party

is charged for the call. On receiving a message
carrying Backward call indicators, the
MSOFTX3000 queries the data configuration and
then determines whether the called party is
charged. For details, see Charge Indicator in the
online help of ADD CNACLD command.
Called party's status indicator: Indicates the status
of the called party.
Echo control device indicator: Indicates whether an
echo control device is enabled in the connection.
Charge indicator is 2, which indicates that the called party is
charged for the call; Called party's status indicator is 1,
which indicates that the called party is free; Echo control
device indicator is 1, which indicates that the echo control
device is enabled.
Reference Standards
Nature of Connection Indicators

Reference Standards
Description
Indicates the transmission path used on a connection.
It is sent in the forward direction and carried in the IAM as a
mandatory parameter.
Nature of connection
indicators
Satellite indicator: Indicates whether the satellite is

involved in the transmission. If the satellite is
involved in the transmission, the propagation delay
is comparatively long.
Continuity check indicator: Indicates whether to
perform a continuity check on the concerned
circuit(s) and whether a continuity check is
performed on a previous circuit in the connection.
Echo control device indicator: Indicates whether an
echo control device is enabled in the connection.
Satellite indicator is 0, which indicates that satellite is not
involved in the transmission; Continuity check indicator is 0,
which indicates that continuity check need not be performed
on the concerned circuit; Echo control device indicator is 1,
which indicates that the echo control device is enabled.
Reference Standards

Forward Call Indicators

Reference Standards
Description
and calling party sent in the forward direction.
Forward call indicators
National International Call Indicator: Indicates in the

destination national network whether the call is
treated as an international call or as a national call.
End to End Method Indicator: Indicates the available
methods for end-to-end transfer of information.
Interwork Indicator: Provides the information about
interworking.
Isdn User Part Indicator: Indicates that the
integrated services digital network (ISDN) user part
is used in all preceding parts of the network
connection.
National International Call Indicator is 0, which indicates that
the call is treated as a national call; End to End Method
Indicator is 0, which indicates that the method for end-to-end
transfer is unavailable and only the methods for link-to-link
transfer are available; Interwork Indicator is 0, which indicates
that Signaling System No. 7 (SS7) signaling is used in all
preceding parts of the network connection and interworking is
not involved; Isdn User Part Indicator is 1, which indicates that
the ISDN user part is used in all preceding parts of the

network connection.
Reference Standards
Optional Forward Call Indicators

Reference Standards
and called party sent in the forward direction
Optional forward call

indicators
Closed user group call indicator: Indicates whether the

concerned call can be set up as a closed user group
call and, if a closed user group call, whether outgoing
access is allowed.
Simple segmentation indicator: Indicates whether
additional information will be forwarded in an segment
message (SGM). If an IAM is too long, an IAM
carrying Simple segmentation indicator is sent, and
then an SGM is sent.
Connected line identity request indicator: Indicates
whether the connected party number is requested.
The IAM is considered as an example. In this example, Closed
user group call indicator is 3, which indicates that the outgoing
calls are not allowed; Simple segmentation indicator is 0, which
indicates that an SGM will not be sent; Connected line identity
request indicator is 0, which indicates that the connected party
number is not requested.
Reference Standards

Event Information
Reference Standards
Description
Indicates the type of event which causes the sending of a
call progress (CPG) message.
This IE mandatory for the CPG message.
Event information
Event indicator: Indicates the type of event which causes a

CPG message to be sent. A CPG message is sent when
the called party is altered, inband announcement is played,
or call forwarding occurs.
In this example, Event indicator-ITUT is 2, which indicates
that the call is being processed.
Reference Standards
Generic Notification Indicator

Reference Standards
Description
Provide supplementary service notification to a user.
It can be sent in either direction.
Generic notification indicator
Notification indicator: Indicates the supplementary service,

such as call forwarding service and multiparty service.
The IAM is considered as an example. In this example,
Notification indicator is 105, which indicates the notification
of the call forwarding service.
Reference Standards
Information Indicators
Reference Standards
Identifies the optional parameters included in a message. It is
carried in the information (INF) message.
Information indicators
Calling party address response indicator: Indicates

whether the provided information contains the calling
number.
Calling party's category response indicator: Indicates
whether the provided information contains the category
of the calling party.
Charge information response indicator: Indicates
whether the provided information contains the charge
information.
The INF message is considered as an example here. In this
example, Calling party address response indicator is 3, which
indicates the calling number is provided; Calling party's category
response indicator is 1, which indicates that the category of the
calling party is provided; and Charge information response
indicator is 0, which indicates that the charge information is not
provided.
Reference Standards

Information Request Indicators

Reference Standards
Information
Element (IE)
Description
Indicates the information requested for a call. It is carried in the
information request (INR) message.
Calling party address request indicator: Indicates whether the

calling number is required.
Calling party's category request indicator: Indicates whether
the category of the calling party is required.
Charge information request indicator: Indicates whether the
charge information is required.
Information request
indicators
The INR message is considered as an example here. In this example,

Calling party address request indicator is 1, which indicates the calling
number is required; Calling party's category request indicator is 1,
which indicates that the category of the calling party is required; and
Charge information request indicator is 0, which indicates that the
charge information is not required.
Reference Standards
Cause Indicators
Reference Standards
Description
Indicates the reason for sending the message (for example,
release (REL) message).
This IE is sent in either direction. Generally, it is carried in the
REL, address complete message (ACM), and call progress
(CPG) message.
Cause indicators
Location: Indicates whether the event is caused by
the network or subscriber.
Cause value: Indicates the reason for sending the
message.
The REL message is considered as an example. In this
example, Location is 1, which indicates that the local
subscriber terminates the call; Cause value is 16, which
indicates that the call is released normally.
Reference Standards
Standardization Sector (ITU-T) Q-762, 3.12 in ITU-T Q-763, and ITU-T Q-850.
Calling Party Number

Reference Standards
Description
Identifies the calling party.
Generally, this IE is carried in the IAM. It is optional.
Nature of address indicator: Indicates the nature of

a number, for example, integrated services digital
network (ISDN) subscriber number, unknown
number, ISDN international number, or ISDN
national significant number.
Odd/even indicator: Indicates whether the number
is even or odd.
Address signal: Indicates the calling number in
binary-coded data (BCD) format. Every four bits
represent a digit.
Address presentation restricted indicator: Indicates
whether the calling number is presented to the
called party. This IE is used in services such as the
calling line identification presentation (CLIP) and
calling line identification restriction (CLIR).
Number Incomplete indicator: Indicates whether
the delivered number is complete.
The IAM is considered as an example. In this example,
Nature of address indicator is international-number(4), which
indicates an international number; Odd/even indicator is 1,
which indicates that the number is odd; Address signal is
8613807557722, which indicates the calling number;

Address presentation restricted indicator is presentation
allowed(0), which indicates that the calling number is
presented to the called party.
Reference Standards
Calling Party's Category

Reference Standards
Description
Indicates the category of the calling party.
This IE is sent in the forward direction.
Calling party's category
Calling party's category: Indicates the category of the

calling party.
Calling party's category is ordinary-calling-subscriber(10),
which indicates that the calling party is an ordinary
subscriber.
Reference Standards
BICC Protocol
Description of the BICC Protocol
Description of the BICC Protocol

Protocol Stack
Message Structure
Message List
The Bearer Independent Call Control (BICC) protocol is used by the Nc interface in the 3rd
Generation Partnership Project (3GPP) R4 CS domain to provide support for call
connection between MSC servers. Completion of the BICC protocol is a historic step as it
separates call control from bearer control, making it possible for call control signaling to
traverse various transport networks, including asynchronous transfer mode (ATM), IP, and
Message Transfer Part (MTP) Signaling System No. 7 (SS7) networks.
Figure 1 shows the application of the BICC protocol.
Figure 1 Application of the BICC protocol

Protocol Stack
Theoretically, BICC can run on any underlying transport protocols. In real network
environment, Message Transfer Part Layer 3 (MTP3), MTP3-User Adaptation Layer
(M3UA), message transfer part layer 3 broadband (MTP3b), and Stream Control
Transmission Protocol (SCTP) are often selected to carry BICC messages as they are
technologically mature. Figure 2 shows the BICC protocol stack.
Figure 2 BICC protocol stack
Message Structure
Figure 3 shows the structure of a BICC message.
Figure 3 BICC message structure
Message List
Message Direction
Type
Function
Initial
Address
MSC<->MSC BICC
Message
(IAM)
This message is sent in the forward direction to

initialize seizure of an outgoing circuit and to transmit
number and other information relating to the routing
and handling of a call.
Application
Transport
MSC<->MSC BICC
Message
(APM)
This message is sent in either direction to convey

application information using the Application Transport
mechanism.
Address
Complete
MSC<->MSC BICC
Message
(ACM)
This message is sent in the backward direction to

indicate that the address signals required for routing
the call to the called party have been received.
Answer
Message MSC<->MSC BICC
(ANM)
This message is sent in the backward direction to

indicate that the call has been answered.
Parent topic: BICC Protocol


Information
Element (IE)
Description
Identifies the office direction that sends the message.
Office number
An IAM message is considered as an example. In this example, officenumber is 0, indicating that the message is sent in office direction 0.
Indicates the type of bearers that carry Bearer Independent Call Control
(BICC) messages.
Signal type
An IAM message is considered as an example. In this example, signal-type
is bicc-over-m3ua, indicating that BICC messages are transported on
MTP3-User Adaptation Layer (M3UA) links.
Bicc protocol
type
Indicates the type of BICC protocol. This IE is encoded as 0 to indicate

International Telecommunication Union-Telecommunication Standardization
Sector (ITU-T) BICC, and as 1 to indicate American National Standard
Institute (ANSI) BICC.
An IAM message is considered as an example. In this example, biccprotocol-type is itut-protocol, indicating that ITU-T BICC is applied.
Provides information about bearers that carry BICC messages.
If BICC runs on Stream Control Transmission Protocol (SCTP), this IE
contains the sctp-information field to convey SCTP link information. If BICC
runs on M3UA or Message Transfer Part Layer 3 (MTP3), this IE contains
the mtp-information field to convey Message Transfer Part (MTP) link
information.
The mtp-information field consists of the following subfields:
net-indicator: identifies the signaling network across which BICC
messages are transported.
originating-point-code-24-bit: provides the 24-bit originating
signaling point code (OPC) of the network entity that sends a
Signal
information
BICC message.
destination-point-code-24-bit: provides the 24-bit destination
signaling point code (DPC) of the network entity that receives a
BICC message.
The sctp-information field consists of the following subfields:
start-link-number
end-link-number
sis-data: indicates the signaling link selection code (SLS).
In the example figure, net-indicator is 2 indicating that the local MSC is

served by a national signaling network and is assigned SPCs, OPC is
74a006, and DPC is 74a019.
Identifies signaling relation between peer BICC entities.
Call Instance
Code
An IAM message is considered as an example. In this example, callinstance-code is 0xf.

IAM
APM
ACM
ANM
IAM
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent in the forward direction to initialize seizure of an outgoing circuit and
to transmit number and other information relating to the routing and handling of a call. Figure
Figure 1 IAM message

Associated IEs
Description
nature of connection indicators
Provides information relating to the transmission path

used on a connection. The information includes whether
a satellite circuit is used in the connection and whether
an echo control device is present.
For details, see nature of connection indicators.
forward call indicators
Provides information relating to the characteristics of

the connection, signaling path, and calling party sent in
the forward direction.
For details, see forward call indicators.
calling party's category
Provides information sent in the forward direction to

indicate the category of the calling party, and in case of
semi-automatic calls, the service language to be
spoken by the incoming, delay, and assistance
operators.
For details, see calling party's category.
transmission medium requirement

indicate the type of transmission medium required for
the connection (for example, 64 kbit/s unrestricted and
speech).
For details, see transmission medium requirement.
called party number
Identifies the called party.

For details, see called party number.
propagation delay counter

indicate the propagation delay of a connection. The
propagation delay information is accumulated whilst the
IE is transferred across the network. The propagation
delay information is represented by a counter counting
in integer multiples of 1 millisecond.
For details, see propagation delay counter.
calling party number
Provides called party address sent in the forward

direction.
For details, see calling party number.
location number
Identifies the geographical area of the origin of a call.

This IE is primarily intended to provide services for
mobile originated calls.
For details, see location number.
user service information

indicate the bearer capability required by the calling
party.
For details, see user service information.
call reference
Identifies a particular call.

For details, see call reference.
optional forward call indicators
Provides information relating to the characteristics of

the connection, signaling path, and called party sent in
the forward direction.
For details, see optional forward call indicators.
application transport parameter
Provides information sent in either direction to allow the

peer-to-peer communication of Application Transport
mechanism user applications.
For details, see application transport parameter.
Reference Standards
For details, see International Telecommunication Union-Telecommunication Standardization
Sector (ITU-T) Q.1902.2 and Q.1902.3.
APM
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent in either direction to convey application information using the
Application Transport mechanism. Figure 1 shows the main IEs of the message.
Figure 1 APM message

Associated IEs
Description
Provides information sent in either direction
to allow the peer-to-peer communication of
Application Transport mechanism user

applications.
For details, see application transport
parameter.
Reference Standards
ACM
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent in the backward direction to indicate that the address signals required
for routing the call to the called party have been received. Figure 1 shows the main IEs of
the message.
Figure 1 ACM message

Associated IEs
Description
backward call indicators
Provides information relating to the

characteristics of the connection, signaling
path, and called party sent in the backward
direction.
For details, see backward call indicators.
cause indicators
Provides information sent in either direction

to indicate the reason for sending the
message.
For details, see cause indicators.
Reference Standards

ANM
Message Function
Associated IEs
Reference Standards
Message Function
This message is sent in the backward direction to indicate 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 in order to:
start metering the charge to the calling party (see International Telecommunication
Union-Telecommunication Standardization Sector (ITU-T) Rec.Q.28)
start measurement of call duration for international accounting purposes (see ITUT Rec.E.260)
Figure 1 ANM message

Associated IEs
Description
Provides information relating to the

characteristics of the connection, signaling
path, and called party sent in the backward
direction.
For details, see backward call indicators.
Reference Standards
For details, see ITU-T Q.1902.2.

called party number
location number
call reference
cause indicators
called party number

Reference Standards
Description
Identifies the called party. This IE is primarily used to
determine a route towards the called party.
It is mandatory in an IAM message and consists of the
following fields:
called party number
nature of address indicator: indicates the nature of

called number, for example, international number,
national number, subscriber number, or unknown
number.
odd/even indicator: indicates whether the number of
address signals contained in the called number is
even or odd.
address signal: Address signals are represented by
binary-coded data (BCD) numbers and sent in
successive 4-bit fields. The character F indicates the
end of address signal.
numbering plan indicator: indicates the numbering
plan used for the called number.
internal network number indicator: indicates whether
routing to an internal network number is allowed.
An IAM message is considered as an example here. In this

example, nature of address indicator is national-number
indicating that the called number is a national number, odd
even flag is even(0) indicating that the called number consists
of an even number of address signals, numbering plan
indicator is numbering-plan-according-to-e164 (1) indicating

that the called number is E.164 coded, internal network
number indicator is routing-to-internal-network-number-allowed
(0).
Reference Standards
For details, see 6.17 "Called party number" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.1902.3.

Reference Standards
Description
Expresses in pure binary representation the propagation
delay value of a call in milliseconds to be accumulated during
call setup.
This IE is sent in the forward direction and optional in an IAM
message.

example, propagation delay value is 0, indicating that the
accumulated propagation delay is 0 milliseconds during call
setup.
Reference Standards
For details, see 6.78 "Propagation delay counter" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.1902.3.

Reference Standards
transmission medium
requirement
Description
connection, for example, speech, 3.1 kHz audio, or 64 kbit/s
unrestricted.
This IE is sent in the forward direction and mandatory in an
IAM message.
An IAM message is considered as an example. In this
example, transmission medium requirement is speech (0),
indicating that speech transmission medium is required.
Reference Standards
For details, see 6.97 "Transmission medium requirement" in International Telecommunication
Union-Telecommunication Standardization Sector (ITU-T) Q.1902.3.
location number
Reference Standards
Description
Identifies the geographical area of the origin of a call. This
IE is primarily intended to provide services for mobile
originated calls. It consists of the following fields:
location number

location number, for example, international number,
number.
odd/even indicator: indicates whether the number
of address signals contained in location number is
even or odd.
screening indicator: indicates whether the location
number is provided by the user or network.
address signal: Address signals are represented
by binary-coded data (BCD) numbers and sent in
successive 4-bit fields.
address presentation restricted indicator: indicates
whether the caller location number should be
hidden from the called party. This field is included
when calling line identification presentation (CLIP)
or calling line identification restriction (CLIR)
service is required.
plan used for location number.
internal network number indicator: indicates
whether routing to an internal network number is
allowed.

example, nature of address indicator is international-number
indicating that location number is an international number,
odd even flag is even(0) indicating that location number
consists of an even number of address signals, screening
indicator is 3 indicating that location number is networkprovided, address presentation restricted indicator is 01
indicating that number presentation is not allowed,
numbering plan indicator is isdn-numbering-plan indicating
that location number is coded in compliance with the
integrated services digital network (ISDN) numbering plan,
internal network number indicator is routing-to-internalnetwork-number-allowed (0).
Reference Standards
For details, see 6.55 "Location number" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.1902.3.

Reference Standards
Description
Provides information relating to the characteristics of the
backward direction. This IE consists of the following fields:
charge indicator: indicates whether the call is

chargeable.
called party's status indicator: indicates the status
of called party.
called party's category indicator: indicates the
category of called party.
end-to-end method indicator: indicates available
methods, if any, for end-to-end transfer of
information.
interworking indicator: indicates whether
interworking is encountered. If Signaling System
No. 7 (SS7) or Bearer Independent Call Control
(BICC) is used in all parts of the network
connection, it implies that no interworking is
encountered.
end-to-end information indicator: indicates whether
the sending exchange has further call information
available for end-to-end transmission.
BICC indicator: indicates whether BICC is used all
the way.
holding indicator: indicates whether call hold is
requested.
integrated services digital network (ISDN) user
part/BICC preference indicator: indicates whether
BICC is preferred.
ISDN access indicator: indicates whether the
access signaling protocol is ISDN.
Signaling Connection Control Part (SCCP) method
indicator: indicates available SCCP method.
An address complete message (ACM) message is

considered as an example here. In this example, charge
indicator is charge, called party's status indicator is
subscriber-free, called party's category indicator is
ordinary-subscriber, end-to-end method indicator is no-endto-end-method-available, BICC indicator is used-all-the-way
(BICC is used all the way), and holding indicator is holdingnot-requested.
Reference Standards
For details, see 6.6 "Backward call indicators" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.1902.3.

Reference Standards
Description
Provides information relating to the transmission path used
on a connection.
IAM message. It consists of the following fields:
satellite indicator: indicates the number of satellite

circuits in the connection. The maximum value is 2.
continuity indicator: indicates whether a continuity
message is to be expected. This field is encoded
as 00 to indicate that continuity check is not
required, and as 10 to indicate otherwise.
echo control device indicator: indicates whether an
outgoing echo control device is present.

example, satellite indicator is 0 indicating that no satellite
circuit is used in the connection, continuity indicator is nocot-to-be-expected indicating that no continuity message is
to be expected, and echo control device indicator is
outgoing-echo-control-device-included.
Reference Standards
For details, see 6.61 "Nature of connection indicators" in International Telecommunication

Reference Standards
Description
connection, signaling path, and calling party.
national/international call indicator: indicates

whether the call has to be treated as an
international call or a national call.
end-to-end method indicator: indicates available
methods, if any, for end-to-end transfer of
information.
interworking indicator: indicates whether
interworking is encountered. If Signaling System
No. 7 (SS7) or Bearer Independent Call Control
(BICC) is used in all parts of the network
connection, it implies that no interworking is
encountered.
end-to-end information indicator: indicates whether
the sending exchange has further call information
available for end-to-end transmission.
BICC indicator: indicates whether BICC is used all
the way.
integrated services digital network (ISDN) user
part/BICC preference indicator: indicates whether
BICC is preferred.
ISDN access indicator: indicates whether the
access signaling protocol is ISDN.
Signaling Connection Control Part (SCCP) method
indicator: indicates available SCCP method.

example, national/international call indicator is call-to-betreated-as-a-national-call, end-to-end method indicator is
no-end-to-end-method-available, interworking indicator is
no-interworking-encountered (BICC is used all the way),
BICC indicator is BICC-used-all-the-way, ISDN access
indicator is originating-access-ISDN, and SCCP method
indicator is no-indication.
Reference Standards
For details, see 6.43 "Forward call indicators" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.1902.3.

Reference Standards
connection, signaling path, and called party.
This IE is sent in an IAM message in the forward direction. It
consists of the following fields:
closed user group call indicator: indicates whether the
concerned call can be set up as a closed user group
call and, if a closed user group call, whether outgoing
access is allowed.
00: non-CUG call
01: spare
10: closed user group (CUG) call, outgoing
access allowed
11: CUG call, outgoing access not allowed
optional forward call
indicators
simple segmentation indicator: indicates that additional

information will be forwarded in a segmentation
message (SGM). SGM messages are used when an
IAM message is too long and cannot contain all the
information.
connected line identity request indicator: indicates
whether connected number identity is requested.

example, closed user group call indicator is non-CUG-call,
simple segmentation indicator is no-additional-information-willbe-sent, and connected line identity request indicator is notrequested.
Reference Standards
For details, see 6.67 "Optional forward call indicators" in International Telecommunication

Reference Standards
Description
Indicates the bearer capability required by the calling party.
This IE is sent in the forward direction and optional in an
information transfer capability
coding standard
information transfer rate
transfer mode

example, information transfer capability is speech,
information transfer rate is 64 kbit/s, and transfer mode is
circuit-mode.
Reference Standards
For details, see 6.102 "User service information" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.1902.3.
call reference
Reference Standards
Description
Identifies a particular call. This IE is relevant to Bearer
Independent Call Control (BICC) only in Message Transfer
Part Layer 3 (MTP3) and message transfer part layer 3
broadband (MTP3b) based signaling networks. It consists
of the following fields:
call reference
call identity: expresses in pure binary

representation the identification number allocated
to the call identity.
signaling point code: indicates the code of the
signaling point to which the call identity is relevant.

example, call identity is 0x20116, signaling point code is
hexadecimal H'74a006 (7643142, 116-160-6) (decimal
7643142 or binary 116-160-6).
Reference Standards
For details, see 6.12 "Call reference" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.1902.3.

Reference Standards
Description
Provides information sent in either direction to allow the
peer-to-peer communication of Application Transport
mechanism user applications.
application context identifier: identifies the
application using the Application Transport
mechanism.
application transport instruction indicators:
indicates how a node should react in case that the
indicated application using the Application
Transport mechanism is not supported.
Release call indicator
Send notification indicator
APM segmentation indicator: indicates whether the
received APM message is the final segment.
sequence indicator: indicates whether this is the
beginning of APM segmentation procedure.
encapsulated application information: provides
application information required to be transported
by the Application Transport mechanism. Each
information unit in this field is coded in the same
manner, with four octets in total. It is suggested
that this field be structured such that the first octet
is an identifier, followed by length indicator and
compatibility information. The following are typical
identifiers:
Action Indicator
Codec List (codecs are listed in
descending order of priority)
Single Codec
Bearer Network Connection
Characteristics
application transport
parameter
Bearer Control Information

Bearer Control Tunnelling
Bearer Control Unit Identifier
Signal
Bearer Redirection Capability
Bearer Redirection Indicators
Signal Type
Duration

example, application context identifier is bat-ase, release
call indicator is release-call, send notification indicator is do-
not-send-notification, APM segmentation indicator is finalsegment, sequence indicator is new-sequence, and

encapsulated application information conveys bearer
information such as codec list and tunneling information.
Reference Standards
For details, see 6.61 "Application transport parameter" in International Telecommunication
Union-Telecommunication Standardization Sector (ITU-T) Q.1902.3 and ITU-T Q.765.58.3.
cause indicators
Reference Standards
Description
Provides information sent in either direction to indicate the
reason for sending the message. This IE consists of the
following fields:
location
coding standard
cause value
cause indicators
An release (REL) message is considered as an example

here. In this example, cause value is normal-unspecified,
indicating that the call release does not result from errors.
Reference Standards
For details, see 6.23 "Cause indicators" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.1902.3 and ITU-T Q.850.

Reference Standards
Description
Identifies the calling party.
This IE is optional in an IAM message. It consists of the
following fields:

calling number, for example, international number,
number.
odd/even indicator: indicates whether the number
of address signals contained in the calling number
is even or odd.
screening indicator: indicates whether the calling
number is provided by the user or network.
address signal: Address signals are represented
by binary-coded data (BCD) numbers and sent in
successive 4-bit fields.
address presentation restricted indicator: indicates
whether the calling number should be hidden from
the called party. This field is included when calling
line identification presentation (CLIP) or calling line
identification restriction (CLIR) service is required.
plan used for the calling number.
number incomplete indicator: indicates whether the
delivered calling number is complete or incomplete.

example, nature of address indicator is internationalnumber, odd even flag is odd, caller address signal is
8613802900318, numbering plan indicator is isdnnumbering-plan (calling number is coded in compliance with
the integrated services digital network (ISDN) numbering
plan), and number incomplete indicator is number-complete.
Reference Standards
For details, see 6.20 "Calling party number" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.1902.3.

Reference Standards
Description
Provides information sent in the forward direction to indicate
the category of the calling party, and in case of semiautomatic calls, the service language to be spoken by the
incoming, delay, and assistance operators.

example, calling party's category is ordinary-callingsubscriber, indicating that the calling party is an ordinary
service subscriber.
Reference Standards
For details, see 6.21 "Calling party's category" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.1902.3.
SIP Protocol
Description of the SIP Protocol
Description of the SIP Protocol

Protocol Stack
Message Structure
Message List
Description of the SIP-I Protocol
Protocols with which the SIP complies
Session Initiation Protocol (SIP) can be used for interworking between MSC servers (over
the Nc interface), interworking between the MSC server and the IP multimedia subsystem
(IMS), and interworking between the MSC server and the next generation network (NGN).
Figure 1 shows the application of the protocol.
Figure 1 Application of the SIP protocol

The SIP protocol is a session control protocol on the application layer. It is used for
creation, modification, and termination of sessions, for example, multimedia conference
sessions and Internet sessions. The SIP protocol supports multi-party sessions in Multipoint
Control Unit (MCU) mode, unicast mode, or multicast mode.
In addition, it supports alias mapping, redirection, integrated services digital network (ISDN)
services, and intelligent network (IN) services. It also supports personal mobility. In other
words, an MS can request or obtain any telecommunication service at any time anywhere.
The SIP protocol provides the following telecommunication functions:
User location: determination of the end system to be used for communication
User capabilities: determination of the media and media parameters to be used
User availability: determination of the willingness of the callee to engage in

communications
Session setup: "ringing", establishment of session parameters on the caller and
callee sides
Session management: including transfer and termination of sessions, modifying
session parameters, and invoking services
Protocol Stack
The SIP protocol can use User Datagram Protocol (UDP), Stream Control Transmission
Protocol (SCTP) or Transmission Control Protocol (TCP) as its transport protocol. By
default, UDP is used.
Figure 2 shows the protocol stack of the UDP-based SIP protocol.
Figure 2 Protocol stack of the UDP-based SIP protocol
Figure 3 shows the protocol stack of the SCTP-based SIP protocol.

Figure 3 Protocol stack of the SCTP-based SIP protocol
Figure 4 shows the protocol stack of the TCP-based SIP protocol.

Figure 4 Protocol stack of the TCP-based SIP protocol
Message Structure
SIP is a text-based protocol and uses the UTF-8 character set. A SIP message is either a
request or a response.
Both types of messages consist of a start line, one or more header fields, an
empty line indicating the end of the header fields, and an optional message body.
The start line in a request is named Request-Line, and that in a response is named
Status-Line.
A message body can be a specific implementation mode of the current session,
which is described by using Session Description Protocol (SDP), or an
encapsulated ISUP message.
Any SIP message must contain header fields, whereas a message body is
optional, depending on the message type and service requirements.
A SIP request consists of a Request-Line, a message header, an empty line, and a
message body. The carriage-return line-feed sequence (CRLF) is used to distinguish the
parameter lines from each other in the message header. Figure 5 shows the structure of a
SIP request.
Figure 5 Structure of a SIP request
A SIP response consists of a Status-Line, a message header, an empty line, and a

message body. The CRLF is used to distinguish the parameter lines from each other in the
message header. The parameters vary in different responses. Figure 6 shows the structure
of a SIP response.
Figure 6 Structure of a SIP response
Message List
A SIP message is either a request or a response.
A SIP request is sent from a client to a server to activate a specific operation.
SIP requests are categorized as follows:
INVITE: Indicates that a UE originates a session request and invites another UE to
join the session.
PRACK: Indicates a response to a 1xx message.
acknowledgement (ACK): Indicates a final response to an INVITE message.
BYE: To terminate an existing session.
OPTIONS: To query the information and function of the callee.
CANCEL: To cancel a request before the final response to the request is received.
A SIP response is used to respond to a request, indicating the status (success or failure) of
a session. SIP responses are categorized based on the Status-Code. The Status-Code is a
3-digit integer result code. The first digit defines the type of the SIP response. The other
two digits provide a detailed description of the SIP response.
SIP responses are categorized as follows:
1xx (Provisional): Indicates that a request is received and the server is continuing
to process the request.
2xx (Success): Indicates that the action was successfully received, understood,
and accepted.
3xx (Redirection): Indicates that a further action needs to be taken in order to
complete the request.
4xx (Client Error): Indicates that the request contains bad syntax or cannot be
fulfilled at this server.
5xx (Server Error): Indicates that the server failed to fulfill an apparently valid
request.
6xx (Global Failure): Indicates that the request cannot be fulfilled at any server.
Table 1 lists common SIP responses.
Table 1 List of common SIP responses
Message
Direction
Function
100
MSC -> MSC
Trying
180
MSC -> MSC
Ringing
181
MSC -> MSC
Call Is Being Forwarded
182
MSC -> MSC
Queued
183
MSC -> MSC
Session Progress
200
MSC -> MSC
OK
300
MSC -> MSC
Multiple Choices
301
MSC -> MSC
Moved Permanently
302
MSC -> MSC
Moved Temporarily
305
MSC -> MSC
Use Proxy
380
MSC -> MSC
Alternative Service
400
MSC -> MSC
Bad Request
401
MSC -> MSC
Unauthorized
402
MSC -> MSC
Payment Required
403
MSC -> MSC
Forbidden
404
MSC -> MSC
Not Found
405
MSC -> MSC
Method Not Allowed
406
MSC -> MSC
Not Acceptable
407
MSC -> MSC
Proxy Authentication Required
408
MSC -> MSC
Request Timeout
410
MSC -> MSC
Gone
413
MSC -> MSC
Request Entity Too Large
414
MSC -> MSC
Request-URI Too Long
415
MSC -> MSC
Unsupported Media Type
416
MSC -> MSC
Unsupported uniform resource identifier (URI)

Scheme
420
MSC -> MSC
Bad Extension
421
MSC -> MSC
Extension Required
423
MSC -> MSC
Interval Too Brief
480
MSC -> MSC
Temporarily Unavailable
481
MSC -> MSC
Call/Transaction Does Not Exist
482
MSC -> MSC
Loop Detected
483
MSC -> MSC
Too Many Hops
484
MSC -> MSC
Address Incomplete
485
MSC -> MSC
Ambiguous
486
MSC -> MSC
Busy Here
487
MSC -> MSC
Request Terminated
488
MSC -> MSC
Not Acceptable Here
491
MSC -> MSC
Request Pending
493
MSC -> MSC
Undecipherable
500
MSC -> MSC
Server Internal Error
501
MSC -> MSC
Not Implemented
502
MSC -> MSC
Bad Gateway
503
MSC -> MSC
Service Unavailable
504
MSC -> MSC
Server Timeout
505
MSC -> MSC
Version Not Supported
513
MSC -> MSC
Message Too Large
600
MSC -> MSC
Busy Everywhere
603
MSC -> MSC
Decline
604
MSC -> MSC
Does Not Exist Anywhere
606
MSC -> MSC
Not Acceptable
SIP header fields convey characteristics of SIP entities, attributes of message bodies, and
other important parameters. One or more header fields may appear in a SIP message. The
following are important header fields:
Call-ID: uniquely identifies a particular invitation or all registrations of a particular
client.
From: indicates the logical initiator of the request. It always contains the tag
parameter of the initiator.
To: indicates the logical recipient of the request. It always contains the tag
parameter of the recipient.
Contact: provides a URI for routing purposes.
Via: indicates the path taken by the request so far and the path that should be
followed in routing responses.
Route: forces a request to be routed across a listed set of proxies.
CSeq: provides a unique sequence number of the request.
Content-Length: indicates the size of the message body in decimal number of
octets.
Content-Type: indicates the media type of the message body sent to the
recipient.
Record-Route: forces future requests in the dialog to be routed through a
particular proxy.
Max-Forwards: limits the number of proxies or gateways that can forward the
request to the next downstream server. This is useful to prevent a routing loop.
P-Access-Network-Info: conveys the Location Number parameter.
A SIP message may contain zero or more message bodies, which are mostly SDP and
ISUP bodies. An SDP body contains the session description, time description, and media
description. Figure 7 shows the format of an SDP body. An ISUP body is in the binary
format, as opposed to the textual form of an SDP body.
Figure 7 Format of SDP body
Description of the SIP-I Protocol

For interoperation between SIP signaling and ISUP signaling, a mechanism of SIP
messages incorporated with ISUP signaling is provided.
To meet the requirements, the ISUP information must be encapsulated in SIP messages
without any loss, or some key information of ISUP messages must be mapped to the
corresponding header fields of SIP messages.
There are two types of mapping:
Mapping between an ISUP message and a SIP message: This is a message-layer
mapping between ISUP and SIP. For example, the IAM message of ISUP is
mapped to the INVITE message of SIP.
Mapping between ISUP parameters and SIP header fields: For example, the
called number in the ISUP message must be mapped to the To and Request-URI
header fields of the SIP message. Since certain header fields in a SIP request
(especially in an INVITE message) change, a conflict may occur between the SIP
header fields and the encapsulated ISUP body. In such a case, the MSC server
determines, based on the service scenario, whether to use the values of the SIP
header fields or the values of the information elements (IEs) in the ISUP body.
Protocols with which the SIP complies
Table 2 shows the protocols with which the SIP complies.
Table 2 Protocols with which the SIP complies
Name
Description
3GPP TS 29.231
Application of SIP-I Protocols to Circuit

Switched (CS) core network architecture
3GPP TS 29.235
Interworking between SIP-I based circuitswitched core network and other networks
ITU-T Q.1912.5
Interworking between Session Initiation

Protocol (SIP) and Bearer Independent Call
Control Protocol or ISDN User Part
IETF RFC 2046
Multipurpose Internet Mail Extensions

(MIME) Part Two: Media Types
IETF RFC 2327
Caller Preferences for the Session Initiation

Protocol (SIP)
IETF RFC 2833
RTP Payload for DTMF Digits, Telephony

Tones and Telephony Signals
IETF RFC 2916
E.164 number and DNS (ENUM)
IETF RFC 2976
The SIP INFO Method
IETF RFC 3204
MIME media types for ISUP and QSIG

Objects
IETF RFC 3261
SIP: Session Initiation Protocol
IETF RFC 3262
Reliability of Provisional Responses in the

Session Initiation Protocol
IETF RFC 3263
SIP: Locating SIP Servers
IETF RFC 3264
An Offer/Answer Model with the Session

Description Protocol
IETF RFC 3265
SIP-Specific Event Notification
IETF RFC 3311
The Session Initiation Protocol (SIP)

UPDATE Method
IETF RFC 3319
Dynamic Host Configuration Protocol

(DHCPv6) Options for Session Initiation
Protocol (SIP) Servers
IETF RFC 3323
A Privacy Mechanism for the Session

Initiation Protocol
IETF RFC 3325
Private Extensions to the Session Initiation
IETF RFC 3326
The Reason Header Field for the Session

Initiation Protocol
IETF RFC 3327
Session Initiation Protocol (SIP) Extension

Header Field for Registering Non-Adjacent
Contacts
IETF RFC 3329
Security Mechanism Agreement for the

Session Initiation Protocol (SIP)
IETF RFC 3361
Dynamic Host Configuration Protocol (DHCPfor-IPv4) Option for Session Initiation

Protocol (SIP) Servers
IETF RFC 3372
SIP-T
Session Initiation Protocol for Telephones
(SIP-T): Context and Architectures
IETF RFC 3398
Integrated Services Digital Network (ISDN)

User Part (ISUP) to Session Initiation
Protocol (SIP) Mapping
IETF RFC 3420
Internet Media Type message/sipfrag
IETF RFC 3428
Session Initiation Protocol (SIP) Extension for

Instant Messaging
IETF RFC 3455
Private Header (P-Header) Extensions to the

Session intial Protocol (SIP) for the 3rdGeneration Partnership Project (3GPP)
IETF RFC 3515
The Session Initiation Protocol (SIP) Refer

Method
IETF RFC 3578
Mapping of Integrated Services Digital

Network (ISDN) User Part (ISUP) Overlap
Signalling to the Session Initiation Protocol
(SIP)
IETF RFC 3581
An Extension to the Session Initiation

Protocol (SIP) for Symmetric Response
Routing
IETF RFC 3608
Session Initiation Protocol (SIP) Extension

Header Field for Service Route Discovery
During Registration
IETF RFC 3665
Session Initiation Protocol (SIP) Basic Call

Flow Examples
IETF RFC 3666
Session Initiation Protocol (SIP) Public

Switched Telephone Network (PSTN) Call
Flows
IETF RFC 3702
Authentication, Authorization, and Accounting

Requirements for the Session Initiation
Protocol (SIP)
IETF RFC 3725
Best Current Practices for Third Party Call

Control (3pcc) in the Session Initiation
Protocol (SIP)
IETF RFC 3824
Using E.164 numbers with the Session

Initiation Protocol (SIP)
IETF RFC 3840
Indicating User Agent Capabilities in the

Session Initiation Protocol (SIP)
IETF RFC 3841
Caller Preferences for the Session Initiation

Protocol (SIP)
IETF RFC 3842
A Message Summary and Message Waiting

Indication Event Package for the Session
Initiation Protocol (SIP)
IETF RFC 3891

"Replaces" Header
IETF RFC 3892

Referred-By Mechanism
IETF RFC 3893
session Initiation Protocol (SIP)

Authenticated Identity Body (AIB) Format
IETF RFC 3966
The tel URI for Telephone Numbers
IETF RFC 4028
Session Timers in the Session Initiation

Protocol
IETF RFC 4240
Basic Network Media Services with SIP
IETF RFC 5009
Private Header (P-Header) Extension to the

Session Initiation Protocol (SIP) for
Authorization of Early Media

IETF RFC 5086
Diversion Indication in SIP
IETF RFC 6035
Session Initiation Protocol Event Package for

Voice Quality Reporting
Parent topic: SIP Protocol


Reference Standards
Information
Element (IE)
Method
Description
Indicates the type of a request. The methods in Session Initiation
Protocol (SIP) requests can be categorized as INVITE,
acknowledgement (ACK), BYE, CANCEL, REGISTER, and OPTIONS.
The INVITE method is considered as an example here.
Indicates the receipt of a request.
Generally, the Request-URI is in the following format:
SIP: host: port; user: password; transport-param|user-param|methodparam|ttl-param|maddr-param|other-param
The meaning of each part is as follows:
Request-URI
SIP: Indicates that SIP is used for communication with the

specific end system.
host: Indicates the domain name or IP address of the host.
Port: Indicates the number of the port to which the request is
sent. The default value is 5060, that is, the well-known SIP
port number.
user: Is composed of any digit, for example, a telephone
number or a user name similar to an Email address. The
default value is phone.
password: The password can be placed in the SIP uniform
resource identifier (URI). It is not safe to transfer
authentication information in text mode. Thus, the password is
not displayed in the SIP URI.
transport-param: An optional parameter. It indicates whether
Transmission Control Protocol (TCP) or User Datagram
Protocol (UDP) is used for transmission. By default, UDP is
used.
user-param: An optional parameter. The SIP URI allows the
host to be an IP telephone gateway. In this case, the user
name can be a common telephone number. This field has two
options: IP and phone. When it is set to phone, it indicates that

the user name is a telephone number and the corresponding
end system is an IP telephone gateway.
method-param: An optional parameter. It indicates the method
(operation) to be used.
ttl-param: Indicates the lifespan of a UDP multicast packet. It
is available only when transport-param is set to UDP and
maddr-param is set to multicast address.
maddr-param: Indicates the address of the server
communicating with a specific user. It covers the address
specified by host and is set to multicast address usually.
The Request-URI header field in the INVITE message is considered as
an example here. In this example, the domain name of the host is
+86263201800001.
Indicates the version of the SIP protocol used by a message.
SIP-Version
The SIP-Version header field in the INVITE message is considered as

an example here. In this example, SIP/2.0 is used.
Indicates the status code of a response. It is 3-digit long. 1xx, 2xx, 3xx,
4xx, 5xx, and 6xx indicate different types of responses.
Status-Code
The Status-Code header field in the 183 message is considered as an
example here.
Indicates the meaning of the status code. It is a text description of
Status-Code.
Reason-Phrase
The Reason-Phrase header field in the 183 message is considered as
an example here.
Reference Standards
For details, see 20 "Header Fields" in RFC3261.

INVITE
PRACK
ACK
BYE
OPTIONS
CANCEL
INVITE
Message Function
Associated IEs
Reference Standards
Message Function
Through number analysis, the local MSC server detects that the outgoing office direction is
a Session Initiation Protocol (SIP) office direction or a SIP subscriber, the MSC server
sends an INVITE message to the callee, containing the bearer information about the caller.
After receiving the INVITE message, the peer MSC server sends a 100 message
immediately. Meanwhile, the peer MSC server performs paging, assignment, and tone
playing. Figure 1 shows the main header fields of the message.
Figure 1 INVITE message
Associated IEs
Description
Via
Indicates the path through which the request

has passed.
For details, see Request-Line and Message
Header.
Call-ID
Indicates the ID of the SIP session.

Header.
From
Indicates the originator of the request.

Header.
To
Indicates the receipt of the request.

Header.
command sequence (CSeq)
Indicates the command sequence.

Header.
Max-Forwards
Indicates the maximum number of times the

request can be forwarded before it arrives at
the destination.
Header.
Session-Expires
Indicates the time at which the request

expires.
Header.
Contact
Indicates the address for direction

communication.
Header.
Allow
Indicates the request types supported by the

server.
Header.
Content-Length
Indicates the length of the message body.

Header.
Content-Type
Indicates the media type of the message

body.
Header.
Message body 1
Indicates the Session Description Protocol

(SDP) body contained in the request.
For details, see Message Body 1.
Indicates the integrated services digital
Message body 2
network (ISDN) user part (ISUP) body

contained in the request.
For details, see Message Body 2.
Reference Standards
For details, see 13.2.1 "Creating the Initial INVITE" in RFC3261.
PRACK
Message Function
Associated IEs
Reference Standards
Message Function
When receiving a 180 message, the local MSC server sends a PRACK message (in
response to the 180 message). When receiving the PRACK message, the peer MSC server
sends a 200 message (in response to the PRACK message). When the callee answers the
call, the peer MSC server sends a 200 message (in response to the INVITE message).
The 1xx message defined in the Session Initiation Protocol (SIP) protocol use unreliable
transmission. Reliable transmission must be guaranteed to carry media information in the
1xx message. Therefore, the PRACK message is introduced. The PRACK message is a
response to the 1xx message, notifying the peer end that the 1xx message is received.
Figure 1 shows the main header fields of the message.
Figure 1 PRACK message
Associated IEs
Description
Via

has passed.
Header.
Call-ID

Header.
From

Header.
To

Header.
CSeq

Header.
Max-Forwards

the destination.
Header.
RAck

PRACK message that maps a reliable
provisional response message 1XX.
Header.
Content-Length

Header.
Reference Standards
For details, see 4 "UAC Behavior" in RFC3262.
ACK
Message Function
Associated IEs
Reference Standards
Message Function
The acknowledgement (ACK) message is a final response to the INVITE message. When
receiving a 200 message (in response to an INVITE message), the local MSC server sends
an ACK message. Then, the caller and the callee start conversation. Figure 1 shows the
main header fields of the message.
Figure 1 ACK message
Associated IEs
Description
Via

has passed.
Header.
Call-ID
Indicates the ID of the Session Initiation

Protocol (SIP) session.
Header.
From

Header.
To

Header.
command sequence (CSeq)

Header.
Max-Forwards

the destination.
Header.
Content-Length

Header.
Reference Standards
For details, see 17.1.1.3 "Construction of the ACK Request" in RFC3261.
BYE
Message Function
Associated IEs
Reference Standards
Message Function
If either party releases the session during the conversation, the MSC server to which the
party belongs sends a BYE message to the peer MSC server, notifying the peer MSC
server of the session release event. When receiving the BYE message, the peer MSC
server sends a 200 message (in response to the BYE message). Thus, the session ends.
Figure 1 shows the main header fields of the message.
Figure 1 BYE message
Associated IEs
Description
Via

has passed.
Header.
Call-ID

Header.
From

Header.
To

Header.
Command sequence (CSeq)

Header.
Max-Forwards

the destination.
Header.
Reason
Indicates the reason of session release.

Header.
Content-Length

Header.
Reference Standards
For details, see 15.1 "Terminating a Session with a BYE Request" in RFC3261.
OPTIONS
Message Function
Associated IEs
Reference Standards
Message Function
The OPTIONS message is used to query the information and function of the callee. Figure 1
shows the main header fields of the message.
The MSOFTX3000 supports inter-MSC heartbeat detection and Session Initiation Protocol
(SIP) subscriber paging by using the OPTIONS message.
Figure 1 OPTIONS message
Associated IEs
Description
Via

has passed.
Header.
Call-ID

Header.
From

Header.
To

Header.

Header.
Max-Forwards

the destination.
Header.
Content-Length

Header.
Reference Standards
For details, see 11 "Querying for Capabilities" in RFC3261.
CANCEL
Message Function
Associated IEs
Reference Standards
Message Function
The CANCEL message is used to cancel a pending session. The client can send a CANCEL
message at any time. Figure 1 shows the main header fields of the message.
Figure 1 CANCEL message
Associated IEs
Description
Via

has passed.
Header.
Call-ID

Header.
From

Header.
To

Header.

Header.
Max-Forwards

the destination.
Header.
Reason

Header.
Content-Length

Header.
Reference Standards
For details, see 16.10 "CANCEL Processing" in RFC3261.

Request-Line and Message Header
Message Body 1
Message Body 2
183
180
200 FOR INVITE
Request-Line and Message Header

Reference Standards
Table 1 describes the IEs in the Request-Line and message header.
Table 1 IEs in the Request-Line and message header
Information
Element
Description
(IE)
Via
Indicates the path through which the request has passed.

The Via header field prevents loops during the transmission of a request. It
also ensures that the corresponding response takes the same path as the
request. Therefore, the transmission of the request and response passes
through firewalls or meets special requirements on route selection.
Generally, the Via header field is in the following format:
Via: sent-protocol sent-by; via-params comment
Here, sent-protocol = protocol-name/protocol-version/transport; via-params =
via-branch.
The Via header field must contain the host name or network address of the
client and if the default port number is not contained, the port number at which
the client wishes to receive responses. Normally, each host that sends or
forwards a Session Initiation Protocol (SIP) message places its host name or
network address to the Via header field to indicate the path that the SIP
message has passed. The sent-by parameter in the Via header field specifies
the address to which a response is to be sent.
The Via header field in the INVITE message is considered as an example here.
In this example, the request is transmitted through User Datagram Protocol
(UDP) and sent from a termination with the IP address 129.9.30.50 and port
number 5062.
Call-ID

A single multimedia conference may have several calls with different Call-IDs.
For example, a subscriber can identify whether the invitations are repeated by
using the session ID of the o IE and the version number in the Session
Description Protocol (SDP) body.
Generally, the Call-ID header field is in the following format:
Call-ID: local-id@host
Here, host must be a domain name or an available IP address defined globally.
In such a case, local-id, which is composed of uniform resource identifier (URI)
characters, must be uniquely in the scope defined by host. local-id can also be
set to a globally unique value to ensure the uniqueness of Call-ID globally. CallIDs are case-sensitive.
The Call-ID header field in the INVITE message is considered as an example
here. In this example, 10.18.5.64 is a globally defined domain name and
57a5882d4d39645728558b68cc55eb19 is a local ID.
From

The server copies the value of the From header field from the request to the
corresponding response. All the SIP requests and responses must contain this
header field.
Generally, the From header field is in the following format:
From: display-name <SIP-URI>;tag=xxxx
Here, display-name specifies the characters displayed on the user interface. If
presentation is forbidden, Anonymous is displayed on the user interface by
default. display-name is an optional parameter.
tag must be set to a hexadecimal character string, including hyphens (-). When
two user instances sharing the same SIP address originate a session by using
the same Call-ID, the tag parameter is used for distinguishing. The value of tag
must be globally unique. The values of Call-ID and tag cannot be changed
during a session.
The From header field in the INVITE message is considered as an example
here. In this example, 86263201800002 is the calling number of the session.
To
Indicates the recipient of the request.

Its format is the same as that of the From header field. All the SIP requests
and responses must contain this header field.
The To header field in the INVITE message is considered as an example here.
In this example, 86263201800001 is the called number of the session.
Command
sequence
(CSeq)
All the SIP requests must contain this header field. The header field
consists of a decimal sequence number and a method. The sequence
number must be unique in the scope defined by Call-ID. The initial
sequence number is arbitrary. For the subsequent requests with the
same Call-ID but different methods or message bodies, the sequence
number increases by one for each request. The request that is resent
has the same sequence number as that of the request that is sent for
the first time.
The server copies the value of the CSeq header field from the
request to the corresponding response.
The CSeq header field in the INVITE message is considered as an example
here. In this example, the sequence number of the INVITE message is 1.
Indicates the session update interval for update negotiation. This header field
can be contained in the INVITE, UPDATE, and 2xx messages.
SessionExpires
Contact
The Session-Expires header field in the INVITE message is considered as an

example here. In this example, the local end sends a re-INVITE or UPDATE
message to the peer end every 1800 seconds after the session is connected,
to check whether the peer end has terminated the session.
Indicates the address for direction communication, that is, the URI of the
originator.
This header field can be contained in the INVITE, ACKnowledgement (ACK),
REGISTER, 1xx, 2xx, and 3xx messages.
The Contact header field in the INVITE and ACK messages indicates the
location from which the request is sent. Therefore, the callee can directly send
requests, for example, a BYE message, to the location identified by the
Contact header field, rather than through the proxy servers identified by the
Via header field.
The Contact header field in the INVITE message is considered as an example
here. In this example, the IP address of the caller is 129.9.30.50.
Indicates the types of requests supported by the proxy server.
Allow
MaxForwards
The Allow header field in the INVITE message is considered as an example

here. In this example, the proxy server supports the following methods:
INVITE, ACK, OPTIONS, BYE, CANCEL, Information (INFO), PRACK,
NOTIFY, MESSAGE, REFER, and UPDATE.
Indicates the maximum number of times the request can be forwarded before
it arrives at the destination.
When receiving a request containing the Max-Forwards header field, the proxy
server or gateway must check and update the value of the header field. The
initial value of the header field is 70. The value decreases by one at each hop,
that is, when the request passes through each proxy server or gateway. If the
value reaches 0 but the request does not arrive at the destination, the server
sends a 483 message and terminates the request.
The header field is used to ensure that resources of the proxy servers are not
wasted because of loops during message transmission.

The Max-Forwards header field in the INVITE message is considered as an
example here. In this example, the request can be forwarded for 70 times
before it arrives at the destination. If the request does not arrive at the
destination after being forwarded for 70 times, the request is terminated.
Response
Sequence
(RSeq)
Indicates the sequence number of a reliable provisional response message

1XX.
This header field consists of a decimal sequence number and a command
name. When a 100rel message is sent and supported, this header field is
contained in the reliable provisional response 1XX message, which ensures the
reliability of message transmission.
The RSeq header field in the 183 message is used as an example here. In this
example, the sequence number of the 183 message is 101.
RAck
Indicates the sequence number of the PRACK message that maps a reliable
provisional response message 1XX.
This header field consists of three parts: two decimal sequence numbers and
the message type. The first decimal sequence number is the sequence number
indicated by the RSeq header field in the 1XX message. The second decimal
sequence number and the message type are those indicated by the CSeq
header field in the 1XX message.
The RAck header field in the PRACK message is considered as an example
here. In this example, the PRACK message is a message in response to the
1XX message, in which the RSeq header field has the sequence number 1 and
the CSeq header field has the sequence number 1 INVITE.
This header field can be contained in the CANCEL and BYE messages.
Reason
ContentLength
The Reason header field in the BYE message is considered as an example

here. In this example, the release cause value is 16, which indicates that the
session is released normally.
Indicates the length of the message body, expressed in decimal values.
This header field is used to indicate the size of the message body to be sent.
The empty line used for separating the message header from the message
body is not counted as Content-Length. The value of Content-Length must not
be smaller than 0. If no message body is contained, the value must be set to
0.
The Content-Length header field in the INVITE message is considered as an

example here. In this example, the length of the message body is 444 bytes.
ContentType
Indicates the media type of the message body.

If the message body is contained, the Content-Type header field must be
specified.
The Content-Type header field in the INVITE message is considered as an
example here. In this example, the media type of the message body is SDP.
Reference Standards
For details, see 20 "Header Fields" in RFC3261.
Message Body 1
Reference Standards
Session Description Protocol (SDP) is a text-based protocol and uses the International
Organization for Standardization (ISO) 10646 character set encoded based on unicode
transformation format (8-bit form) (UTF-8). Table 1 describes the IEs carried in the SDP
body.
Table 1 IEs carried in the SDP body
Description
Indicates the version number of the SDP protocol.
The v IE in the SDP body is considered as an

example here. In this example, the version number of
the SDP protocol is 0.
Indicates the originator of the session and the session
ID.
Generally, the o IE is in the following format:
o = <username><session id><network type>
<address type><address>
The o IE in the SDP body is considered as an
example here. In this example,
<username>: Indicates the host to which the

user logs in and from which the user
originates the session.
<session id>: Indicates the globally unique
sequence number of the session.
<network type>: IN stands for Internet
Network.
<address type>: The value can be Internet
Protocol version 4 (IPv4) and Internet
Protocol version 6 (IPv6).
<address>: Indicates the address of the
originator.
Indicates the name of the session.
The s IE in the SDP body is considered as an
example here. In this example, the session name is

SipCall.
Indicates the connection information. It is an optional
IE.
Generally, the c IE is in the following format:
c = <network type><address type><connection
address>
The c IE in the SDP body is considered as an

<network type>: IN stands for Internet
Network.
<address type>: The value can be IPv4 and
IPv6.
<connection address>: Indicates the
multicast address that can receive the
session.
Indicates the start time and end time of the

association of the session.
Generally, the t IE is in the following format:
t = <start time><stop time>
The t IE in the SDP body is considered as an
example here. In this example, the t IE is set to 0,
which indicates that the session is permanent.
Indicates the media name and transmission address.
Generally, the m IE is in the following format:
m = <media><port><transport>
The m IE in the SDP body is considered as an
<media>: The value can be audio, video, or

data.
<port>: Indicates the Session Initiation
Protocol (SIP) port number used for media
stream transmission. In a request for port
number allocation, set the parameter to $. In
this example, <port> is set to 8952.
<transport>: Real-Time Transport Protocol

(RTP)/Audio Video Profile (AVP) indicates
that the media stream uses the audio and
video protocols in the real-time transport
protocol. 108 indicates the PayloadType of
the media stream. If the parameter is set to
a value smaller than 96, the static
PayloadType is used and a detailed
description is not required. If the parameter
is set to a value greater than 96, the
dynamic PayloadType is used and a detailed
description is required. The detailed
description is contained in the "a=" line. 102
is a PayloadType.
Provides a description of zero or multiple attributes.
Generally, the a IE is in the following format:
a = <attribute>:<value>
a
The a IE in the SDP body is considered as an

example here. In this example, rtpmap: 108 indicates
the dynamic PayloadType in the "m=" line. Adaptive
multirate (AMR) indicates the name of the codec.
8000 indicates the sampling rate of the codec.
Reference Standards
For details, see 5 "Examples of MTP3-User Adaptation Layer (M3UA) Procedures" in
RFC4566.
Message Body 2
Reference Standards
Description
Indicates that the integrated services digital
network (ISDN) user part (ISUP) body is
encapsulated in a Session Initiation Protocol
(SIP) message in binary format.
Message body 2
The IAM message body in the INVITE message
is considered as an example here. In this
example, the length of the IAM message body is
35 bytes.
The ISUP body encapsulated in the SIP
message has the same message structure as
the common ISUP message. For details on the
ISUP message, see the ISUP protocol.
Reference Standards
For details, see 6 "Incoming call interworking from SIP to Bearer Independent Call Control
(BICC)/ISUP at I-IWU" in Q1912.5.
183
Message Function
Associated IEs
Reference Standards
Message Function
The local MSC server completes the media negotiation using the media information
contained in the INVITE message sent by the peer service data point (SDP). Meanwhile, it
encapsulates bearer-related information in the 183 message and sends the message to the
peer MSC server.
The 1xx response defined in the Session Initiation Protocol (SIP) uses unreliable
transmission. Reliable transmission must be used to carry media information in the 1xx
response. A reliable 183 message must contain a Require header field and a RSeq header
field. Figure 1 shows the main header fields of the message.
Figure 1 183 message
Associated IEs
Description
Via
Indicates the path through which a request

message is transmitted.
Header.
Call-ID
Identifies a SIP call.

Header.
From

Header.
To

Header.

Header.
Max-Forwards

request can be forwarded before it reaches
the destination.
Header.
RSeq
Indicates the sequence of the temporary

response message 1XX.
Header.
Content-Length
Indicates the length of the message body of

the request message.
Header.
Reference Standards
For details, see 4 "Overview of Operation" in RFC3261.
180
Message Function
Associated IEs
Reference Standards
Message Function
On setting up a bearer on the terminating side and assigning the required Iu interface
resources, the terminating mobile switching center (MSC) returns a 180 message to the
originating MSC server.
The 1xx response defined in the Session Initiation Protocol (SIP) uses unreliable
transmission. Reliable transmission must be used to carry media information in the 1xx
response. A reliable 180 message must contain a Require header field and a RSeq header
field. Figure 1 shows the main header fields of the message.
Figure 1 180 message
Associated IEs
Description
Via
Indicates the path through which a request

message is transmitted.
Header.
Call-ID
Identifies a SIP call.

Header.
From

Header.
To

Header.

Header.
Max-Forwards

the destination.
Header.
RSeq
Indicates the sequence of the temporary

response message 1XX.
Header.
Content-Length

Header.
Reference Standards
200 FOR INVITE

Message Function
Associated IEs
Reference Standards
Message Function
The 200 FOR INVITE message is a message sent from the terminating MSC server to the
originating MSC server after calls are answered. The originating MSC server then returns
an ACK message, indicating that the call is connected. Figure 1 shows the main header
fields of the message.
Figure 1 200 FOR INVITE message
Associated IEs
Description
Via
Indicates the path through which a request is

transmitted.
Header.
Call-ID
Identifies a Session Initiation Protocol (SIP)

call.
Header.
From

Header.
To

Header.

Header.
Max-Forwards

the destination.
Header.
Content-Length

Header.
Reference Standards
M2UA Protocol
Description of the M2UA Protocol

Protocol Stack
Message Structure
Message List
The Message Transfer Part 2 (MTP2)-User Adaptation Layer (M2UA) protocol is used for
signaling transmission between SGs and MSC servers.
The services provided by M2UA to Message Transfer Part Layer 3 (MTP3) are the same
as those provided by MTP2 to MTP3. The services include the following:
Support for MTP2/MTP3 interface boundary
Support for communication between Layer Management (LM) modules on the
signaling gateway (SG) and the MSC server
Support for management of Stream Control Transmission Protocol (SCTP) active
associations between the SG and the MSC server
Protocol Stack
The signaling point (SP) in the Signaling System No. 7 (SS7) signaling network connects to
the MSC server through the SG. On the SG side, the Nodal Interworking Function (NIF)
module is used for interworking between MTP2 and M2UA through primitives. On the MSC
server side, M2UA provides services for MTP3.
Figure 1 shows the application of the protocol.
Figure 1 Application of the M2UA protocol
Message Structure
An M2UA message consists of a common header, an M2UA message header, and multiple
variable-length M2UA messages.
Figure 2 shows the structure of an M2UA message.
Figure 2 Structure of an M2UA message
NOTE:
M2UA message 0 to M2UA message n indicate multiple variable-length M2UA messages.
The common message classes are as follows:
MTP2 User Adaptation (MAUP) messages
Application Service Provider (ASP) State Maintenance (ASPSM) messages
ASP Traffic Maintenance (ASPTM) messages
Management (MGMT) messages
NOTE:
Application Server (AS): A logical entity serving a specific application instance.
Practically speaking, an AS is modeled on the SG as an ordered list of one or
more related Application Server Processes (ASPs).
ASP: A process instance of an AS. Its status is active/standby. Each ASP contains
an SCTP endpoint and can process services of multiple ASs.
Message List
Table 1 List of common M2UA messages

Message
Direction
Function
MSC<->SG
The message contains an

SS7 MTP2-User Protocol
Data Unit (PDU).
MSC -> SG
The message is used to

establish an SS7 link or to
indicate that a channel has
been established. The MSC
server controls the state of
the SS7 link.
Establish Confirm
SG -> MSC
If the SG already has an SS7

link established at its layer,
upon receipt of an Establish
Request message, the SG
takes no action except to
send an Establish Confirm
message.
Release Request
MSC -> SG

release a channel.
SG -> MSC
The message is sent in

response to a Release
Request message.
SG -> MSC

indicate that a channel has
been released.
MSC -> SG
The message is sent from the

MSC server to cause an
action on a particular SS7 link
supported by the SG. The SG
sends a State Confirm
message to the MSC server if
the action has been
successfully completed.
SG -> MSC

response to a State Request
message.
Data
Establish Request
Release Confirm
Release Indication
State Request
State Confirm
State Indication
SG -> MSC

SG to the ASP to indicate a
condition on an SS7 link.
Data Acknowledge Message MSC <-> SG
The message must contain

the correlation ID of the Data
message that the sending
M2UA is acknowledging as
successfully processed to the
peer M2UA.
ASP Up
MSC <-> SG

indicate to a remote M2UA
peer that the adaptation layer
is ready to receive traffic or
maintenance messages.
MSC <-> SG

is not ready to receive traffic
or maintenance messages.
MSC <-> SG
The message is optionally

used to ensure that the M2UA
peers are still available to
each other.
MSC <-> SG

acknowledge an ASP Up
message received from a
remote M2UA peer.
MSC <-> SG

acknowledge an ASP Down
remote M2UA peer.
MSC <-> SG

response to a Heartbeat
message. A peer must send a
Heartbeat Ack message in
response to a Heartbeat
message. The message
includes all the parameters of
the received Heartbeat
message, without any
change.
ASP Down
Heartbeat
ASP Up Ack
ASP Down Ack
Heartbeat Ack
ASP Active
MSC -> SG
ASP Inactive
ASP Active Ack
ASP Inactive Ack
Error
Notify
The message is sent by the

ASP to indicate to the SG
that the ASP is Active and
ready to be used.
MSC -> SG

ASP to indicate to the SG
that the ASP is no longer an
active ASP to be used from
within a list of ASPs.
SG -> MSC

acknowledge an ASP Active
remote M2UA peer.
SG -> MSC

acknowledge an ASP Inactive
remote M2UA peer.
MSC <-> SG
The message is used to notify

a peer of an error event
associated with an incoming
message. For example, the
message type might be
unexpected given the current
state, or a parameter value
might be invalid.
MSC <-> SG

provide an autonomous
indication of M2UA events to
an M2UA peer.
Parent topic: M2UA Protocol


Description
Indicates the version of the MTP2-User
Adaptation Layer (M2UA) protocol.
Currently, the 1.0 version is supported.
Version
version: Indicates the version of the M2UA
protocol.
The Application Service Provider (ASP) Up
In this example, version is 1, which indicates
that the version of the M2UA protocol is 1.0.
Indicates the class of an M2UA message.
The message class is an 8-bit unsigned
integer. M2UA messages are categorized as
follows:
0: Management (MGMT) message
[ISDN Q.921-User Adaptation Layer
(IUA)/M2UA/MTP3-User Adaptation
Layer (M3UA)/Signaling Connection
and Control Part -User Adaptation
Layer (SUA)]
1: transfer messages [M3UA]
2: SS7 Signaling Network
Management (SSNM) messages
[M3UA/SUA]
3: ASP State Maintenance
(ASPSM) messages
[IUA/M2UA/M3UA/SUA]
4: ASP Traffic Maintenance
(ASPTM) messages
Message Class
[IUA/M2UA/M3UA/SUA]
5: Q.921/Q.931 Boundary Primitives
Transport (QPTM) messages [IUA]
6: MTP2 User Adaptation (MAUP)
messages [M2UA]
7: connectionless messages [SUA]
8: connection-oriented messages
[SUA]
9: Routing Key Management (RKM)
messages (M3UA)
10: Interface Identifier Management
(IIM) messages (M2UA)
11 to 127: reserved by the Internet
Engineering Task Force (IETF)
128 to 255: reserved for IETFdefined message class extensions
Message Class: Indicates the class of an

M2UA message.
The ASP Up message is considered as an
example here. In this example, Message
Class is 3, which indicates that the message
is an ASPSM message.
Indicates the type of an M2UA message.
Each message class contains messages of
different types. For example, the ASPSM
messages have the following message types:
0: reserved
1: ASP Up (UP)
2: ASP Down (DOWN)

3: Heartbeat (BEAT)
4: ASP Up Ack (UP ACK)
5: ASP Down Ack (DOWN ACK)
6: Heartbeat Ack (BEAT ACK)
7 to 127: reserved by the IETF
128 to 255: reserved for IETFdefined ASPSM extensions
Message Type
Message Type: Indicates the type of an

M2UA message.
Type is 1, which indicates that the message
is ASP Up.
Indicates the length of an M2UA message.
It is expressed in octets and must include the
header and parameter padding bytes, if any.
Message Length
Message Length: Indicates the length of an

M2UA message.
Length is 8, which indicates that the length of
the message is 8.

Data
Establish
Release
State
Error
Notify
ASP Up
ASP Active
ASP Inactive
Data
Message Function
Associated IEs
Reference Standards
Message Function
The Data message is an MTP2 User Adaptation (MAUP) message.
It contains the protocol data unit (PDU) of Message Transfer Part Layer 3 (MTP3). Figure 1
Figure 1 Data message

Associated IEs
Description
Protocol Data
Contains the MTP2-User application

message.
For details, see Protocol Data.
Reference Standards
For details, see 3.3.1.1 "Data" in RFC3331.
Establish
Message Function
Associated IEs
Reference Standards
Message Function
The Establish messages are MTP2 User Adaptation (MAUP) messages.
The Establish Request and Establish Confirm messages are used to set up an Signaling
System No. 7 (SS7) link or to indicate a channel has been set up. Figure 1 and Figure 2
show the main IEs of the Establish Request and Establish Confirm messages.
Figure 1 Establish Request message

Figure 2 Establish Confirm message
Associated IEs
Description
Establish Request
The message is used to establish an SS7 link

or to indicate that a channel has been
established. The MSC server controls the
state of the SS7 link.
If the signaling gateway (SG) already has an
Establish Confirm
SS7 link established at its layer, upon receipt

of an Establish Request message, the SG
takes no action except to send an Establish
Confirm message.
Reference Standards
For details, see 3.3.1.3 "Establish (Request, Confirmation)" in RFC3331.
Release
Message Function
Associated IEs
Reference Standards
Message Function
The Release messages are MTP2 User Adaptation (MAUP) messages.
The Release Request message is used to release a channel. The Release Indication and
Release Confirm messages are used to indicate or confirm that a channel has been
released. Figure 1 and Figure 2 show the main IEs of the Release Request and Release
Indication messages. The Release Confirm message consists of only a common header
and an M2UA message header.
Figure 1 Release Request message

Figure 2 Release Indication message
Associated IEs
Description
Release Request
The message is sent from the layer

management (LM) to request the Application
Service Provider (ASP) to release an Stream
Control Transmission Protocol (SCTP)
association with the signaling gateway (SG).
Release Indication
The message is sent from the SG to inform

the LM that an ASP has released an SCTP
association.
Release Confirm
The message is sent from the ASP to

confirm to the LM that the ASP has released
an SCTP association with the SG.
NOTE:
LM is a node function in an SG or ASP that handles the inputs and outputs between the
M2UA layer and a local management entity.
Reference Standards
For details, see 3.3.1.4 "Release (Request, Indication, Confirmation)" in RFC3331.
State
Message Function
Associated IEs
Reference Standards
Message Function
The State messages are MTP2 User Adaptation (MAUP) messages.
The State Request message is sent from the MSC server to cause an action on a particular
Signaling System No. 7 (SS7) link supported by the signaling gateway (SG). The SG sends
a State Confirm message to the MSC server if the action has been successfully completed.
Figure 1 shows the main IEs of the State Request message.
Figure 1 State Request message

The State Confirm message is sent by the SG in response to a State Request message
from the MSC server. The State Confirm message reflects the state value received in the
State Request message. The structure and valid state values of the State Confirm message
are the same as those of the State Request message. Figure 2 shows the main IEs of the
State Confirm message.
Figure 2 State Confirm message
Associated IEs
Description
The state parameter in the State Request
message is mandatory. The common state
values are as follows:
0 (STATUS_LPO_SET): request
local processor outage
1 (STATUS_LPO_CLEAR): request
local processor outage recovered
2 (STATUS_EMER_SET): request
emergency alignment
3 (STATUS_EMER_CLEAR):
request normal alignment (cancel
emergency)
4 (STATUS_FLUSH_BUFFERS):
flush or clear receive, transmit and
retransmit queues
5 (STATUS_CONTINUE): continue
or resume
6 (STATUS_CLEAR_RTB): clear the
retransmit queue
7 (STATUS_AUDIT): audit state of
link
8 (STATUS_CONG_CLEAR):
congestion cleared
9 (STATUS_CONG_ACCEPT):
congestion accept
10 (STATUS_CONG_DISCARD):
congestion discard
State Request
The state value as shown in Figure 1 is 2

(STATUS_EMER_SET).
State Confirm
The structure and valid state values of the

State Confirm message are the same as
those of the State Request message.
Reference Standards
For details, see 3.3.1.5 "State Request" in RFC3331.

Error
Message Function
Associated IEs
Reference Standards
Message Function
The Error message is an MTP2-User Adaptation Layer (M2UA) Management (MGMT)
message.
It is used to notify a peer of an error event associated with an incoming message. Figure 1
Figure 1 Error message

Associated IEs
Description
Error Code
Indicates the reason for the Error message.

For details, see Error Code.
Reference Standards
For details, see 3.3.3.1 "Error (ERR)" in RFC3331.
Notify
Message Function
Associated IEs
Reference Standards
Message Function
The Notify message is an MTP2-User Adaptation Layer (M2UA) Management (MGMT)
message.
It is used to provide an autonomous indication of M2UA events to an M2UA peer. Figure 1
Figure 1 Notify message

Associated IEs
Description
Status Type
Indicates the type of the Notify message.

For details, see Status Type.
Reference Standards
For details, see 3.3.3.2 "Notify (NTFY)" in RFC3331.
ASP Up
Message Function
Associated IEs
Reference Standards
Message Function
The Application Service Provider (ASP) Up message is an ASP State Maintenance
(ASPSM) message.
It is used to indicate to a remote MTP2-User Adaptation Layer (M2UA) peer that the
adaptation layer is ready to receive traffic or maintenance messages. The ASP Up
message consists of only a common header. It does not contain any parameter. Figure 1
Figure 1 ASP Up message

Associated IEs
Description
None
None
Reference Standards
For details, see 3.3.2.1 "ASP Up (ASPUP)" in RFC3331.
ASP Active
Message Function
Associated IEs
Reference Standards
Message Function
The Application Service Provider (ASP) Active message is an ASP Traffic Maintenance
(ASPTM) message.
It is sent by the ASP to indicate to the SG that the ASP is Active and ready to be used.
Figure 1 ASP Active message

Associated IEs
Description
Traffic Mode Type
Indicates the traffic mode of operation of the

ASP within an application server (AS).
For details, see Traffic Mode Type.
Reference Standards
For details, see 3.3.2.7 "ASP Active (ASPAC)" in RFC3331.
ASP Inactive
Message Function
Associated IEs
Reference Standards
Message Function
The Application Service Provider (ASP) Inactive message is an ASP Traffic Maintenance
(ASPTM) message.
It is sent by the ASP to indicate to the SG that the ASP is no longer an active ASP to be
used from within a list of ASPs. Figure 1 shows the main IEs of the message.
Figure 1 ASP Inactive message

Associated IEs
Description
None
None
Reference Standards
For details, see 3.3.2.9 "ASP Inactive (ASPIA)" in RFC3331.

Protocol Data
Error Code
Status Type
Traffic Mode Type
Protocol Data
Reference Standards
Description
Contains the MTP2-User application
message, that is, Message Transfer Part
Layer 3 (MTP3) message.
Protocol Data is a mandatory IE of the Data
message. It contains the MTP2-User
application message in network byte order
starting with the Signaling Information Octet
(SIO). The length of the Protocol Data IE
cannot exceed the length of the MTP2-User
application message.
Protocol Data
ProtData: Contains the MTP2-User

application message.
The Data message is considered as an
example here. In this example, ProtData is
C3 11 34 82 18 06 00 10 0A 00 01 03 00 01
2 and SIO is C3.
Reference Standards
For details, see 3.3.1.1 "Data" in RFC3331.
Error Code
Reference Standards
Description
Indicates the reason for the Error message.
Error Code is a mandatory IE of the Error
message. Error Code can be any of the
following values:
Error Code
1: invalid version
2: invalid interface identifier
3: unsupported message class
4: unsupported message type
5: unsupported traffic handling
mode
6: unexpected message
7: protocol error
8: unsupported interface identifier
type
9: invalid stream identifier
10: not used in MTP2-User
Adaptation Layer (M2UA)
11: not used in M2UA
13: refused-management blocking
14: Application Service Provider
(ASP) identifier required
15: invalid ASP identifier
16: ASP active for interface
identifier
17: invalid parameter value
18: parameter field error
19: unexpected parameter

22: missing parameter
Error Code: Indicates the reason for the

Error message.
The Error message is considered as an
example here. In this example, Error Code is
8, which indicates an unexpected message.
Reference Standards
For details, see 3.3.3.1 "Error (ERR)" in RFC3331.
Status Type
Reference Standards
Description
Status Type can be set to any of the
following values:
1: application server state change
(AS_State_Change)
2: other
Status Type: Indicates the type of

the Notify message.
Status Information: Provides more
detailed information for the
notification, based on the value of
Status Type.
When Status Type is set to
1, Status Information can
be set to any of the
following values:
Status Type
1: reserved
2: application
server inactive
(AS_Inactive)
3: application
server active
(AS_Active)
4: application
server pending
(AS_Pending)
following values:
1: insufficient
Application
Service Provider
(ASP) resources
active in
application server
(AS)
2: alternate ASP
active
3: ASP failure
The NOTIFY message is considered as an
example here. In this example, Status Type is
1, which indicates that the state of the AS
changes; Status Information is 4, which
indicates that the AS is pending.
Reference Standards
For details, see 3.3.3.2 "Notify (NTFY)" in RFC3331.
Traffic Mode Type

Reference Standards
Description
Application Service Provider (ASP) within an
application server (AS).
Within a particular AS, only one Traffic Mode
Type can be used. Traffic Mode Type can be
set to any of the following values:
1: override
2: load-share
Traffic Mode Type
Traffic Mode Type: Indicates the traffic mode

of operation of the ASP within an AS.
The ASP Active message is considered as
an example here. In this example, Traffic
Mode Type is 2, which indicates that the
load-sharing mode is used.
Reference Standards
For details, see 3.3.2.7 "ASP Active (ASPAC)" in RFC3331.
M3UA Protocol

Protocol Stack
Message Structure
Message List
The Message Transfer Part 3 (MTP3)-User Adaptation Layer (M3UA) protocol implements
interworking between the Signaling System No. 7 (SS7) network and the IP network by
using Stream Control Transmission Protocol (SCTP) to transmit MTP3-User signaling
messages (for example, ISDN user part (ISUP) and Signaling Connection Control Part
(SCCP) messages) over the IP network.
The services provided by M3UA to upper layer are the same as those provided by MTP3 to
the upper layer (ISUP, Telephone User Part (TUP), Bearer Independent Call Control (BICC),
and SCCP). The services include the following:
Support for the transfer of all SS7 MTP3-User Part messages
Support for interoperation of the MTP3 network management function
Support for management of SCTP associations between the Signaling Gateway
Process (SGP) and the Application Server Process (ASP)
Supports for management of connections to multiple SGPs
NOTE:
Application Server (AS): A logical entity serving a specific routing key.
An example of an AS is a virtual switch element handling all call processing for a
unique range of public switched telephone network (PSTN) trunks, identified by a
destination point code (DPC)/overrun performance counter (OPC)/CIC_range.
Another example of an AS is a virtual database unit handling all query transactions,
identified by a DPC/OPC/ signaling connection control part sub-system number
(SCCP_SSN).
Each AS contains a group of ASPs. Among them, one or multiple ASPs can
process services.
ASP: A process instance of an AS. Its status is active/standby. Each ASP contains
an SCTP endpoint and can process services of multiple ASs.
SGP: A process instance of a signaling gateway (SG). It serves as an active,
backup, or load-sharing process of an SG.

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-topoint fashion. Conceptually, an IPSP does not use the services of an SG node.
Protocol Stack
The M3UA protocol can be used for signaling transmission between SGs and MSC servers
as well as signaling transmission between IP-based applications. That is, the M3UA
protocol supports non-peer-to-peer networking and peer-to-peer networking modes.
NOTE:
The devices interworking through Signaling Transport (SIGTRAN) can be networked in any
of the following modes:
Non-peer-to-peer networking mode: In this mode, one end is an AS and the other
end is an SG.
Peer-to-peer networking mode: In this mode, both ends are ASs or SGs.
1. Protocol Stack of the M3UA Protocol in Non-Peer-to-Peer Networking Mode
Figure 1 Protocol stack of the M3UA protocol in non-peer-to-peer networking
mode
As shown in Figure 1, the M3UA protocol is used for signaling transmission
between SGs and MSC servers. In the SIGTRAN protocol stack, M3UA runs on
the upper layer of SCTP. In other words, M3UA is a user of SCTP. On the MSC
side, the upper layer of M3UA is MTP3 (ISUP, TUP, BICC, or SCCP). On the SG
side, the upper layer of M3UA is Nodal Interworking Function (NIF).
2. Protocol Stack of the M3UA Protocol in Peer-to-Peer Networking Mode
Figure 2 Protocol stack of the M3UA protocol in peer-to-peer networking mode
As shown in Figure 2, the M3UA protocol is used for signaling transmission

between two MSC servers to provide the same primitives and services to the
upper layer as those provided by MTP3.
Message Structure
An M3UA message consists of a common header followed by zero or more variable-length
parameters.
Figure 3 shows the structure of the common header.
Figure 3 Structure of the common header
All the parameters in the M3UA message are in tag-length-value format. Figure 4 shows the
structure of a parameter.
Figure 4 Structure of a parameter
The common message classes are as follows:

Management (MGMT) messages
Transfer messages
SS7 Signaling Network Management (SSNM) messages
ASP State Maintenance (ASPSM) messages
ASP Traffic Maintenance (ASPTM) messages
Message List
Message
Direction
Function
The message is used to notify
Error
MSC <-> SG
MSC <-> MSC
a peer of an error event

associated with an incoming
message.
Notify
MSC <-> SG
MSC <-> MSC
The message used to provide

an autonomous indication of
M3UA events to an M3UA
peer.
Data
MSC <-> SG
MSC <-> MSC
The message contains the

SS7 MTP3-User protocol
data.
SG -> MSC

SGP in an SG to all
concerned ASPs to indicate
that the SG has determined
that one or more SS7
destinations are unreachable.
Destination Available (DAVA) SG -> MSC

SGP in an SG to all
that one or more SS7
destinations are now
reachable (and not
restricted), or in response to
a DAUD message if
appropriate.
Destination State Audit

(DAUD)

ASP to the SGP to audit the
availability/congestion state of
SS7 routes from the SG to
one or more affected
destinations.
Destination Unavailable
(DUNA)
MSC -> SG
Signaling Congestion (SCON) SG -> MSC

SGP in an SG to all
that there is congestion in the
SS7 network to one or more
destinations, or to the ASP in
response to a DATA or DAUD
message as appropriate.
Destination User Part

Unavailable (DUPU)
Destination Restricted
(DRST)
ASP Up
ASP Down
ASP Up Ack
ASP Down Ack
SG -> MSC
The message is used by the

SGP to inform all concerned
ASPs that a remote peer
MTP3-User Part (for
example, ISUP or SCCP) at
an SS7 node is unavailable.
SG -> MSC
The message is optionally

sent from the SGP in an SG
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.
MSC -> SG

is ready to receive any
ASPSM/ASPTM messages
for all routing keys that the
ASP is configured to serve.
MSC -> SG

is not ready to receive Data,
SSNM, or ASPTM messages.
SG -> MSC

acknowledge an ASP Up
remote M3UA peer.
SG -> MSC

acknowledge an ASP Down
remote M3UA peer.
ASP to indicate to a remote
M3UA peer that the ASP is
ASP Active
MSC -> SG
ASP Inactive
ASP Active Ack
ASP Inactive Ack
ready to process signaling

traffic for a particular AS.
MSC -> SG

ASP to indicate to a remote
M3UA peer that the ASP is no
longer an active ASP to be
used from within a list of
ASPs.
SG -> MSC

acknowledge an ASP Active
remote M3UA peer.
SG -> MSC

acknowledge an ASP Inactive
remote M3UA peer.


Description
Indicates the version of the MTP3-User
Adaptation Layer (M3UA) protocol.
Currently, the 1.0 version is supported.
Version
M3UA Protocol Version: Indicates the version
of the M3UA protocol.
The Application Service Provider (ASP) Up
In this example, M3UA Protocol Version is 1,
which indicates that the version of the M3UA
protocol is 1.0.
Indicates the class of an M3UA message.
The message class is an 8-bit unsigned
integer. M3UA messages are categorized as
follows:
0: Management (MGMT) message
1: transfer messages
2: Signaling System No. 7 (SS7)
SSNM messages
3: ASP State Maintenance
(ASPSM) messages
4: ASP Traffic Maintenance
(ASPTM) messages
5: reserved for other Signaling
Transport (SIGTRAN) adaptation
layers
6: reserved for other SIGTRAN
adaptation layers
Message Class
adaptation layers
adaptation layers
9: Routing Key Management (RKM)
messages
10 to 127: reserved by the Internet
Engineering Task Force (IETF)
128 to 255: reserved for IETFdefined message class extensions
Message Class: Indicates the class of an

M3UA message.
Class is 3, which indicates that the message
is an ASPSM message.
Indicates the type of an M3UA message.
Each message class contains messages of
different types. For example, the ASPSM
messages have the following message types:
0: reserved
1: ASP Up (ASPUP)
2: ASP Down (ASPDN)
3: Heartbeat (BEAT)
4: ASP Up Ack (ASPUP ACK)
5: ASP Down Ack (ASPDN ACK)
6: Heartbeat Ack (BEAT ACK)
7 to 127: reserved by the IETF
128 to 255: reserved for IETFdefined ASPSM extensions
Message Type

M3UA message.
Type is 1, which indicates that the message
is ASP Up.
Indicates the length of an M3UA message.
It is expressed in octets and must include the
header and parameter padding bytes, if any.
Message Length
Message Length: Indicates the length of an

M3UA message.
Length is 8, which indicates that the length of
the message is 8.

Notify
ASP Up
ASP Active
ASP Inactive
Notify
Message Function
Associated IEs
Reference Standards
Message Function
The Notify message is an MTP3-User Adaptation Layer (M3UA) Management (MGMT)
message.
It is used to provide an autonomous indication of M3UA events to an M3UA peer. Figure 1
Figure 1 Notify message

Associated IEs
Description
Status Type

For details, see Status Type.
Reference Standards
For details, see 3.8.2 "Notify" in RFC3332.
ASP Up
Message Function
Associated IEs
Reference Standards
Message Function
The Application Service Provider (ASP) Up message is an ASP State Maintenance
(ASPSM) message.
It is used to indicate to a remote MTP3-User Adaptation Layer (M3UA) peer that the
adaptation layer is ready to receive traffic or maintenance messages. Figure 1 shows the
Figure 1 ASP Up message

Associated IEs
Description
None
None
Reference Standards
For details, see 3.5.1 "ASP Up" in RFC3332.
ASP Active
Message Function
Associated IEs
Reference Standards
Message Function
The Application Service Provider (ASP) Active message is an ASP Traffic Maintenance
(ASPTM) message.
It is sent by the ASP to indicate to a remote MTP3-User Adaptation Layer (M3UA) peer
that the ASP is ready to process signaling traffic for a particular application server (AS).
Figure 1 ASP Active message

Associated IEs
Description
Traffic Mode Type

ASP within an AS.
For details, see Traffic Mode Type.
Reference Standards
For details, see 3.7.1 "ASP Active" in RFC3332.
ASP Inactive
Message Function
Associated IEs
Reference Standards
Message Function
The Application Service Provider (ASP) Inactive message is an ASP Traffic Maintenance
(ASPTM) message.
It is sent by the ASP to indicate to a remote MTP3-User Adaptation Layer (M3UA) peer
that the ASP is no longer an active ASP to be used from within a list of ASPs. Figure 1
Figure 1 ASP Inactive message

Associated IEs
Description
None
None
Reference Standards
For details, see 3.7.3 "ASP Inactive" in RFC3332.

Traffic Mode Type
Status Type
Traffic Mode Type

Reference Standards
Description
Application Service Provider (ASP) within an
application server (AS).
Traffic Mode Type can be set to any of the
following values:
1: override
2: loadshare
Traffic Mode Type
Traffic Mode Type: Indicates the traffic mode

of operation of the ASP within an AS.
The ASP Active message is considered as
an example here. In this example, Traffic
Mode Type is 2, which indicates that the
load-sharing mode is used.
Reference Standards
For details, see 3.7.1 "ASP Active" in RFC3332.
Status Type
Reference Standards
Description
Status Type can be set to any of the
following values:
1: application server state change
(AS_State_Change)
2: other
Status Type: Indicates the type of

the Notify message.
Status Information: Provides more
detailed information for the
notification, based on the value of
Status Type.
following values:
Status Type
1: reserved
2: application
server inactive
(AS_Inactive)
3: application
server active
(AS_Active)
4: application
server pending
(AS_Pending)
following values:
1: insufficient
Application
Service Provider
(ASP) resources
active in
application server
(AS)
2: alternate ASP
active
3: ASP failure
The NOTIFY message is considered as an
example here. In this example, Status Type is
1, which indicates that the state of the AS
changes; Status Information is 2, which
indicates that the AS is inactive.
Reference Standards
For details, see 3.8.2 "Notify" in RFC3332.
SCCP Protocol
Description of the SCCP Protocol
Description of the SCCP Protocol

Protocol Stack
Message Structure
Message List
The Signaling Connection Control Part (SCCP) protocol provides additional functions to
Message Transfer Part (MTP). It implements the packet switching function for virtual
circuits and data messages. Thus, it is used for both connectionless and connectionoriented network services between the MSC servers and devices such as the BSC, RNC,
HLR, SGSN, and GMLC in telecommunication networks via the Signaling System No. 7
(SS7) network, thus transferring circuit related and non-circuit related signaling information
and other types of information (for example, messages for management and maintenance
purposes). SCCP and MTP3 together are equivalent to the functions of the network layer in
the OSI system. They make transparent transmission available.
The overall objectives of the SCCP protocol are to provide the means for the following:
Logical signaling connections within the SS7 network
Transfer capability for network service data units with or without the use of logical
signaling connections
The services provided by the SCCP protocol can be categorized as follows:
0: basic connectionless services
1: in-sequence delivery connectionless services
2: basic connection-oriented services
3: flow control connection-oriented services
Protocol Stack
As a middle layer for message transmission, the upper layers of SCCP include ISDN user
part (ISUP), Base Station Subsystem Application Part (BSSAP), and Transaction Capability
Application Part (TCAP), and the lower layers of SCCP include MTP3 and MTP3-User
Adaptation Layer (M3UA).
Figure 1 shows the protocol stack of the SCCP protocol.
Figure 1 Protocol stack of the SCCP protocol

Message Structure
As stipulated in the layered structure of SS7, when an upper layer requests services from a
lower layer or a lower layer provides services to an upper layer, interaction is required
between the service user and the service provider.
The signaling data transmitted between two neighboring layers is named primitive.
Primitives can be categorized as follows:
Request
Indication
Response
Confirmation
The lower layer of SCCP is MTP3 or M3UA. For example, for MTP, the corresponding
primitive is marked as MTP-primitive. The upper layer is SCCP User. The primitive
transmitted between SCCP and SCCP User is named N-primitive, also named SCCP User
primitive.
SCCP messages are used for communication between SCCPs, and MTP messages are
used for communication between MTPs. Figure 2 shows the primitives and messages
between SCCP and MTP.
Figure 2 Primitives and messages
A complete primitive consists of a primitive name, a primitive type, and primitive

parameters. Figure 3 shows the structure of a primitive.
Figure 3 Primitive structure
The meaning of each part of a primitive is as follows:

X: Indicates the functional module that provides the service. (M stands for MTP
and N stands for SCCP).
Generic name: Primitive name, indicating the service provided.
Specific name: Primitive type, indicating the direction of the primitive.
Parameters: Indicates the data transmitted between two layers.
NOTE:
For example, a signaling message is transmitted to the destination in Unit Data (UDT) mode
through a connectionless service protocol. When the SCCP on the destination node
transfers the message to other users, the primitive in the UDT is N-UNITDATA-IND (CDA,
CGA, and UD). Here, N stands for the SCCP User primitive; UNITDATA stands for the
generic name; IND stands for the specific name, and the direction is from SCCP to SCCP
User; CDA, CGA, and UD are parameters, which stand for the called address, calling
address, and user data respectively.
Message List
Table 1 Common primitives of the SCCP protocol
Primitive
N-UNITDATA-REQ
Direction
Function
SCCP User -> SCCP
The primitive is used by

SCCP User to request SCCP
to transfer SCCP data to
another SCCP.
N-UNITDATA-IND
N-CONNECT-REQ
N-CONNECT-IND
N-CONNECT-RES
N-CONNECT-CON
N-DISCONNECT-REQ
N-DISCONNECT-IND
SCCP -> SCCP User

SCCP to inform SCCP User
that SCCP data is being
delivered to SCCP User in a
connectionless service.
SCCP User -> SCCP

to establish a signaling
connection.
SCCP -> SCCP User

SCCP to request a callee to
establish a signaling
connection with a caller.
SCCP User -> SCCP
The primitive is used by a

callee to notify the local
SCCP that the callee is
agreed to establish a
signaling connection.
SCCP -> SCCP User

SCCP on the originating side
to confirm to the caller that a
signaling connection has been
established.
SCCP User -> SCCP

to reject a signaling
connection request or
disconnect a signaling
connection.
SCCP -> SCCP User

SCCP to request SCCP User
to reject a signaling
connection request or
disconnect a signaling
connection.
to transfer SCCP data to
N-DATA-REQ
N-DATA-IND
MTP-TRANSFER-REQ
MTP-TRANSFER-IND
MTP-RESUME-IND
MTP-PAUSE-IND
MTP-STATUS-IND
Parent topic: SCCP Protocol
SCCP User -> SCCP
another SCCP in a
connection-oriented service.
In a connectionless service,
the N-UNITDATA-REQ
primitive is used by SCCP
User to request SCCP to
transfer SCCP data to
another SCCP.
SCCP -> SCCP User

SCCP to notify SCCP User
that the SCCP data is being
delivered in a connectionoriented service.
SCCP -> MTP

SCCP to request M3UA to
transfer data to the peer
M3UA.
MTP -> SCCP
The primitive is used by the

peer M3UA to notify its SCCP
that the data is received.
MTP -> SCCP
The primitive is used by MTP

to inform SCCP of the ability
of providing the MTP service
to the specified destination.
MTP -> SCCP

to inform SCCP of the total
inability of providing the MTP
service to the specified
destination.
MTP -> SCCP

to inform SCCP of the partial
inability of providing the MTP
service to the specified
destination. The primitive is
also used to indicate to a user
that a remote corresponding
user is unavailable and the
cause of unavailability.


Description
Indicates the type of an Signaling Connection
Control Part (SCCP) message.
Message Type

SCCP message.
The N-STATE-IND primitive is considered as
an example here. In this example, Message
Type is N-STATE-IND.
Indicates the direction of an SCCP message.
Message Direction
Message Direction: Indicates the direction of

an SCCP message.
Direction is sccp-to-user (0), which indicates
that the SCCP message is sent from SCCP
to SCCP User.
Indicates the contents of an SCCP message.
Message Content
Message Content: Indicates the contents of

an SCCP message.
Content is the contents of the N-STATE-IND
primitive.


SCCP User Primitive
MTP Service Primitive
SCCP User Primitive

Message Function
Associated IEs
Reference Standards
Message Function
Signaling Connection Control Part (SCCP) User primitives are used by service interfaces
between SCCP and SCCP User.
The SCCP User primitives can be used for connectionless services. For example,
the N-UNITDATA-REQ primitive is used for connectionless services. Figure 1
shows the structure of the N-UNITDATA-REQ primitive.
Figure 1 N-UNITDATA-REQ primitive
The SCCP User primitives can also be used for connection-oriented services. For
example, the N-DISCONNECT-REQ primitive is used for connection-oriented
services. Figure 2 shows the structure of the N-DISCONNECT-REQ primitive.
Figure 2 N-DISCONNECT-REQ primitive
The SCCP User primitives can also be used for SCCP management; that is, to
perform route reselection or service adjustment during network failure or
congestion to maintain the network performance. For example, the N-STATE-IND
primitive is used for SCCP management. Figure 1 shows the structure of the NSTATE-IND primitive.
Figure 3 N-STATE-IND primitive
Associated IEs
Description
Service Information Octet (SIO)
Indicates the class of an SCCP message.

For details, see Service Information Octet.
Protocol class
Indicates the protocol class of an SCCP

message.
For details, see Protocol Class.
Calling/Called address
Indicates the originating point code

(OPC)/destination point code (DPC) and (or)
SCCP access point.
For details, see Calling/Called Address.

User data
Contains SCCP upper layer information or

SCCP management information.
For details, see User Data.
Reason
Indicates the reason for signaling connection

rejection or interruption.
For details, see Reason.
N-PCSTATE
Is used to inform a local subsystem about the

status of an signaling point (SP) during SCCP
management.
For details, see N-PCSTATE.
N-STATE
Is used to inform SCCP management about

the status of a local subsystem.
For details, see N-STATE.
Reference Standards
For details, see 6 "Services provided by the SCCP" in International Telecommunication
Union-Telecommunication Standardization Sector (ITU-T) Q.711.
MTP Service Primitive

Message Function
Associated IEs
Reference Standards
Message Function
Message Transfer Part (MTP) service primitives are used by service interfaces between
Signaling Connection Control Part (SCCP) and MTP. The MTP service primitives can be
used to send messages from SCCP to MTP and messages from MTP to SCCP.
Associated IEs
Description
MTP-TRANSFER-REQ
The primitive is used by SCCP to request

MTP3-User Adaptation Layer (M3UA) to
transfer data to the peer M3UA.
MTP-TRANSFER-IND
The primitive is used by the peer M3UA to

notify its SCCP that the data is received.
MTP-PAUSE-IND
The primitive is used by MTP to inform SCCP

of the total inability of providing the MTP
service to the specified destination.
For details, see MTP-PAUSE-IND.
MTP-RESUME-IND

of the ability of providing the MTP service to
the specified destination.
For details, see MTP-RESUME-IND.
MTP-STATUS-IND

of the partial inability of providing the MTP
service to the specified destination. The
primitive is also used to indicate to a user
that a remote corresponding user is
unavailable and the cause of unavailability.
For details, see MTP-STATUS-IND.
Reference Standards
For details, see 7.2 "MTP-primitives and parameters" in International Telecommunication


MTP-PAUSE-IND
MTP-RESUME-IND
MTP-STATUS-IND
N-PCSTATE
N-STATE
Protocol Class
Service Information Octet
User Data
Reason
Calling/Called Address
MTP-PAUSE-IND
Reference Standards
Description
The primitive is used by Message Transfer
Part (MTP) to inform Signaling Connection
Control Part (SCCP) of the total inability of
providing the MTP service to the specified
destination.
MTP-PAUSE-IND
Affected destination point code (DPC):

Indicates the affected SPs.
The MTP-PAUSE-IND primitive is considered
Affected DPC is 0x840010, which indicates
that MTP is unable to send messages to the
destination with the signaling point (SP)
0x840010.
Reference Standards
For details, see 7.2 "Services provided by the SCCP" in International Telecommunication
MTP-RESUME-IND
Reference Standards
Description
Control Part (SCCP) of the ability of
providing the MTP service to the specified
destination.
MTP-RESUME-IND

The MTP-RESUME-IND primitive is
example, Affected DPC is 0x2A1002, which
indicates that MTP is able to provide the
MTP service to the destination with the
signaling point (SP) 0x2A1002.
Reference Standards
MTP-STATUS-IND
Reference Standards
information element (IE)
Description
Control Part (SCCP) of the status of a
signaling point (SP) of the destination.
MTP-STATUS-IND
The MTP-STATUS-IND primitive is
example, Affected DPC is 0x123456, which
indicates that the SP 0x123456 is
unavailable.
Reference Standards
N-PCSTATE
Reference Standards
Description
Is used to inform a user about the status of a
signaling point (SP) during Signaling Connection
Control Part (SCCP) management.
Affected signaling point: Indicates an

affected SP, that is, an SP that is
failed, congested, withdrawn, or
allowed.
Signaling point status: Indicates the
status of an affected SP.
Remote SCCP status: Indicates the
status of a remote SCCP.
N-PCSTATE
The N-PCSTATE-IND primitive is considered as

an example here. In this example, Affected
signaling point is H'2a1111; signaling point status
is 1, which indicates that the SP H'2a1111 is not
allowed to use; Remote SCCP status is 1,
which indicates that the remote SCCP is
unreachable.
Reference Standards
For details, see 6.3.2 "Primitives and parameters of the SCCP management" in
Q.711.

N-STATE
Reference Standards
Description
Is used to inform Signaling Connection Control Part
(SCCP) management about the status of a user.
N-STATE
Affected subsystem: Indicates an affected

subsystem, that is, a subsystem that is
failed, congested, withdrawn, or allowed.
User status: Indicates the status of the
affected subsystem.
Subsystem multiplicity indicator: Used by
SCCP management messages; indicates
the number of replications of a subsystem.
The N-STATE-IND primitive is considered as an
example here. In this example, Affected subsystem
is 1, which indicates that the affected subsystem is
an SCCP management subsystem; User status is 1,
which indicates that the SCCP management
subsystem is not allowed to use; Subsystem
multiplicity indicator is 0, which indicates that the
number of replications of the SCCP management
subsystem is 0.
Reference Standards
For details, see 6.3.2 "Primitives and parameters of the SCCP management" in
Q.711.

Protocol Class
Reference Standards
information element
(IE)
Description
Indicates the protocol class of an Signaling Connection Control
Part (SCCP) message.
The protocol classes of the SCCP protocol can be categorized as
follows:
Protocol Class
0:
1:
2:
3:
basic connectionless class

in-sequence delivery connectionless class
basic connection-oriented class
flow control connection-oriented class
protocol class: Indicates the protocol class of an SCCP message.

The N-UNITDATA-REQ primitive is considered as an example
here. In this example, protocol class is 0, which indicates that the
protocol class of the message is 0, basic connectionless class.
Reference Standards
For details, see 2.10 "protocol class" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.712.

Reference Standards
Description
Indicates the class of a Signaling Connection
Control Part (SCCP) message.
service information octet (SIO) consists of the
network indicator and service indicator. MTP3
uses SIO to distribute messages to the
corresponding functional module. The Service
Information Octet parameter is 8-bit long, where
the network indicator occupies 2 bits and the
service indicator occupies 4 bits.
Network Indicator: Indicates the type of a

signaling network. The network indicator can be
set to any of the following values:
0:
1:
2:
3:
international network
international reserved network
national network
national reserved network
Service indicator: Indicates a specific service.

The common service indicators are as follows:
0: signaling network management
messages
1: signaling network testing and
maintenance messages
2: reserved
3: SCCP
4: Telephone User Part (TUP)
5: ISDN user part (ISUP)

The N-UNITDATA-REQ primitive is considered
as an example here. In this example, Network
Indicator is 2, which indicates that the signaling
network is a national network; Service indicator
is 3, which indicates the SCCP service.
Reference Standards
For details, see 14.2 "Service information octet" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.704.
User Data
Reference Standards
Description
Contains Signaling Connection Control Part
(SCCP) upper layer information or SCCP
management information.
The SCCP upper layer information includes
user information about ISDN user part
(ISUP), Base Station Subsystem Application
Part (BSSAP), and Transaction Capability
Application Part (TCAP).
User Data
SCCP DATA: Indicates the user information

contained in an SCCP message.
The N-UNITDATA-IND primitive is considered
as an example here. In this example, SCCP
contains the TCAP user information.
Reference Standards
For details, see 6.1.1.2.3 "Data transfer phase" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.711.
Reason
Reference Standards
Description
Indicates the reason for signaling connection
rejection or interruption.
Reason
reason: Indicates the reason for signaling
connection rejection or interruption.
The N-DISCONNECT-REQ primitive is
reason (disconnect cause) is 5, end-useroriginated, which indicates that the signaling
connection is released at the request of the user.
Reference Standards
For details, see 6.1.1.2.4 "Release phase" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.711.
Calling/Called Address
Reference Standards
Description
Uniquely identifies an originating point code
(OPC)/destination point code (DPC) and (or) a
Signaling Connection Control Part (SCCP)
access point.
An SCCP address consists of GT, DPC, and
SSN.
Calling/Called address
Subsystem number: Indicates the

subsystem number in an SCCP
address.
Signaling point code: Indicates the
signaling point (SP) in an SCCP

address.
Global title: Indicates the GT in an
SCCP address.
The N-UNITDATA-REQ primitive is considered
as an example here. In this example, the GT
mode is used for addressing, and the address is
the combination of GT and SSN. For the calling
address, Subsystem number is 6, which
indicates that the subsystem is an HLR; Global
title is 8613990001. For the called address,
Subsystem number is 8, which indicates that the
subsystem is an MSC server; Global title is
8613915001.
Reference Standards
For details, see 6.1.1.2.2 "Connection establishment phase" in International
PRA Protocol
Description of the PRA Protocol
Description of the PRA Protocol

Protocol Stack
Message Structure
Message List
The Primary Rate Access (PRA) protocol is one of the interface protocols defined by the
Digital Subscriber Signaling No.1 (DSS1) signaling system. The DSS1 signaling system is a
group of interface protocols between integrated services digital network (ISDN) users and
networks. It consists of the physical layer, link layer, and network layer, corresponding to
the three bottom layers of the OSI system. Figure 1 shows the scenarios of the PRA
protocol.
Figure 1 Networking between MSC servers through the PRA protocol
Figure 2 Networking between the MSC server and the PBX through the PRA protocol
Protocol Stack
Figure 3 shows the protocol stacks of the PRA protocol in the two scenarios.
Figure 3 Protocol stacks of the PRA protocol in the two scenarios
Message Structure
Figure 4 shows the structure of a PRA message.
Figure 4 Structure of a PRA message
Message List
Message
Function
ALERTING
The message is sent by the callee to the network and by the

network to the caller to indicate that callee alerting has been
initiated.
CALL PROCEEDING
The message is sent by the callee to the network or by the

network to the caller to indicate that requested call
establishment has been initiated and no more call
establishment information will be accepted.

CONNECT
The message is sent by the callee to the network and by the

network to the caller to indicate call acceptance by the callee.
CONNECT
ACKNOWLEDGE
The message is sent by the network to the callee to indicate

the user has been awarded the call. It may also be sent by the
caller to the network to allow symmetrical call control
procedures.
DISCONNECT
The message is sent by the user to request the network to

clear an end-to-end connection or is sent by the network to
indicate that the end-to-end connection is cleared.
RELEASE
The message is sent by the user or the network to indicate

that the equipment sending the message has disconnected the
channel (if any) and intends to release the channel and the call
reference. Thus, the receiving equipment should release the
channel and prepare to release the call reference after
sending a RELEASE COMPLETE message.
RELEASE COMPLETE
The message is sent by the user or the network to indicate

that the equipment sending the message has released the
channel (if any) and call reference, the channel is available for
reuse, and the receiving equipment should release the call
reference.
SETUP
The message is sent by the caller to the network and by the

network to the callee to initiate call establishment.
SETUP ACKNOWLEDGE
The message is sent by the network to the caller or by the

callee to the network to indicate that call establishment has
been initiated, but additional information may be required.
Parent topic: PRA Protocol


information element
(IE)
Description
Protocol discriminator: Is used to distinguish messages

for user-network call control from other messages. The
length of the IE is one byte.
Call reference: Identifies a call on the B channel.
Message type: Indicates the type of the message being
sent. The length of the IE is one byte. Q.931 has defined
dozens of messages of different types. Messages of
different types have different functions and contain
different IEs.
Common IEs
The SETUP message is considered as an example here. In this

example, Protocol discriminator is user-network-call-controlmessage-recommendation-Q931(8), which indicates that the
protocol class of the message is Q.931; Call reference is
0x500(1280), which indicates a call with the call ID 0x500 on the B
channel; Message type is setup(5), which indicates that the
message being sent is a SETUP message.

ALERTING
CALL PROCEEDING
CONNECT
CONNECT ACKNOWLEDGE
DISCONNECT
RELEASE
RELEASE COMPLETE
SETUP
SETUP ACKNOWLEDGE
ALERTING
Message Function
Associated IEs
Reference Standards
Message Function
The message is sent by the callee to the network and by the network to the caller to
indicate that callee alerting has been initiated. Figure 1 shows the main IEs of the message.
Figure 1 ALERTING message
Associated IEs
Message
Function
Message type
Indicates the type of a message.

Progress indicator
Indicates an event that has occurred during the life of a call.

Reference Standards
For details, see 3.1.1 "ALERTING" in ITU-T Q.931.
CALL PROCEEDING
Message Function
Associated IEs
Reference Standards
Message Function
The message is sent by the callee to the network or by the network to the caller to indicate
that requested call establishment has been initiated and no more call establishment
information will be accepted.
Figure 1 CALL PROCEEDING message

Associated IEs
Message
Function
Channel identification
Indicates a channel within the interface controlled by the

signaling procedures.
For details, see Channel identification.
Reference Standards
For details, see 3.1.2 "CALL PROCEEDING" in ITU-T Q.931.
CONNECT
Message Function
Associated IEs
Reference Standards
Message Function
The message is sent by the callee to the network and by the network to the caller to
indicate call acceptance by the callee. Figure 1 shows the main IEs of the message.
Associated IEs
Description
Progress indicator

Reference Standards
For details, see 3.1.3 "CONNECT" in ITU-T Q.931.

CONNECT ACKNOWLEDGE
Message Function
Reference Standards
Message Function
The message is sent by the network to the callee to indicate the user has been awarded
the call. It may also be sent by the caller to the network to allow symmetrical call control
procedures. Figure 1 shows the main IEs of the message. The message may contain no
information element (IE).
Figure 1 CONNECT ACKNOWLEDGE message
Reference Standards
For details, see 3.1.4 "CONNECT ACKNOWLEDGE" in ITU-T Q.931.
DISCONNECT
Message Function
Associated IEs
Reference Standards
Message Function
The message is sent by the user to request the network to clear an end-to-end connection
or is sent by the network to indicate that the end-to-end connection is cleared. Figure 1
Figure 1 DISCONNECT message
Associated IEs
Cause
Indicates the cause for the message.

Reference Standards
For details, see 3.1.5 "DISCONNECT" in ITU-T Q.931.
RELEASE
Message Function
Associated IEs
Reference Standards
Message Function
The message is sent by the user or the network to indicate that the equipment sending the
message has disconnected the channel (if any) and intends to release the channel and the
call reference. Thus, the receiving equipment should release the channel and prepare to
release the call reference after sending a RELEASE COMPLETE message. Figure 1 shows
Figure 1 RELEASE message

Associated IEs
Description
Cause

Reference Standards
For details, see 3.1.9 "RELEASE" in ITU-T Q.931.

RELEASE COMPLETE
Message Function
Reference Standards
Message Function
The message is sent by the user or the network to indicate that the equipment sending the
message has released the channel (if any) and call reference, the channel is available for
reuse, and the receiving equipment should release the call reference. Figure 1 shows the
Figure 1 RELEASE COMPLETE message
Reference Standards
For details, see 3.1.10 "RELEASE COMPLETE" in ITU-T Q.931.
SETUP
Message Function
Associated IEs
Reference Standards
Message Function
The message is sent by the caller to the network and by the network to the callee to initiate
call establishment. Figure 1 shows the main IEs of the message.
Figure 1 SETUP message

Associated IEs
Description
Bearer capability
Indicate a requested bearer service to be provided by the

network.

Indicates a caller number.

For details, see Calling party number.
Called party number
Indicates a callee number.

For details, see Called party number.

Reference Standards
For details, see 3.1.14 "SETUP" in ITU-T Q.931.
SETUP ACKNOWLEDGE
Message Function
Associated IEs
Reference Standards
Message Function
The message is sent by the network to the caller or by the callee to the network to indicate
that call establishment has been initiated, but additional information may be required. Figure
Figure 1 SETUP ACKNOWLEDGE message
Associated IEs

Reference Standards
For details, see 3.3.10 "SETUP ACKNOWLEDGE" in ITU-T Q.931.


Bearer capability
Call reference
Called party number
Called party subaddress
Calling party subaddress
Cause
Date/time
Display
High layer compatibility
Keypad facility
Message type
Network-specific facilities
Progress indicator
Protocol discriminator
Repeat indicator
Sending complete
Signal
Transit network selection
Bearer capability
Reference Standards
Description
Indicates a requested bearer service to be provided by the
network.
It contains bearer related information, for example,
transmission information, transmission rate mode, and
codec information.
Bearer capability
info transfer capability: Indicates the transmission
capability.
info transfer rate: Indicates the transmission rate.
user info layer1 proto: Indicates the codec used
for transmission.
The SETUP message is considered as an example here. In
this example, info transfer capability is speech(0), which
indicates that the call is a voice call; info transfer rate is
kbit-64; user info layer1 proto is recommendation-G711-ALaw.
Reference Standards
For details, see 4.5.5 "Bearer capability" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.931.

Call reference
Reference Standards
Description
Indicates a call at the local user-network interface to which
the particular message applies.
Call reference
length: Indicates the length of the call reference.

cr-value-2-byte: Indicates the value of the callee
reference.
this example, length is 2, and cr-value-2-byte is 0x300.
Reference Standards
For details, see 4.3 "Call reference" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.931.
Called party number

Reference Standards
Description
Identifies the callee of a call.
Generally, this IE is contained in the SETUP message.
Called party number
Numbering plan identification: The values include

unknown number and integrated services digital
network (ISDN) number.
Type of number: Indicates the type of the callee
number, for example, a national number or an
international number.
Number: Indicates the callee number.
this example, Numbering plan identification is 1, which
indicates that the number is an ISDN number; Type of
number is subscriber-number(4), which indicates that the
number is a subscriber number; Number is 13709260002,
which indicates that the callee number is 13709260002.
Reference Standards
For details, see 4.5.8 "Called party number" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.931.

Reference Standards
Description
Indicates the subaddress of the callee.
The maximum length of the IE is 23 octets.
Odd even indicator: Indicates whether the

subaddress is an odd or even.
Type of subaddress: Indicates the type of the
subaddress.
this example, Odd even indicator is 0, which indicates that
the subaddress is an even; Type of subaddress is NASP(0).
(For details on the NASP, see International
Telecommunication Union-Telecommunication
Standardization Sector (ITU-T) Rec.X.213[23] and
International Organization for Standardization
(ISO)/International Electro Technical Committee (IEC)
8348).
Reference Standards
For details, see 4.5.9 "Called party subaddress" in ITU-T Q.931.

Reference Standards
Description
Identifies the caller of a call.
Numbering plan identification: The values include

unknown number and integrated services digital
network (ISDN) number.
Type of number: The values include unknown
number, national number, and international number.
Number: Indicates the caller number.
this example, Numbering plan identification is 1, which
indicates that the number is an ISDN number; Type of
number is international number(1), which indicates that the
number is an international number; Number is
8613802900312, which indicates that the caller number is
8613802900312.
Reference Standards
For details, see 4.5.10 "Calling party number" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.931.

Reference Standards
Description
Indicates the subaddress of the caller.
The maximum length of the IE is 23 octets. It is expressed
in binary-coded data (BCD) code.
Odd even indicator: Indicates whether the

subaddress is an odd or even.
Type of subaddress: Indicates the type of the
subaddress.
this example, Odd even indicator is 0, which indicates that
the subaddress is an even; Type of subaddress is NASP(0).
(For details on the NASP, see International
Standardization Sector (ITU-T) Rec.X.213[23] and
International Organization for Standardization
(ISO)/International Electro Technical Committee (IEC)
8348).
Reference Standards
For details, see 4.5.11 "Calling party address" in ITU-T Q.931.
Cause
Reference Standards
Description
Cause
location: Indicates the network location.

coding standard: Indicates the coding standard
adopted.
cause value: Indicates the cause value contained in
the message.
The DISCONNECT message is considered as an example
here. In this example, location is public-network-serving-thelocal-user(2); coding standard is itu-T-standardizedcoding(0); cause value is normal-call-clearing(16).
Reference Standards
For details, see 4.5.12 "Cause" in International Telecommunication Union-Telecommunication
Standardization Sector (ITU-T) Q.931 and the related chapters in ITU-T Q.850.
Reference Standards
Description
Identifies a channel.
D channel indicator: Indicates whether the channel

is a D channel.
Preferred exclusive: Indicates the channel selection
mode. It is applicable only to B channels.
Interface type: Indicates the type of the interface.
this example, D channel indicator is not-D-channel(0), which
indicates that the channel is not a D channel; Preferred
exclusive is exclusive(1), which indicates that only identified
channel is to be selected; Interface type is otherinterface(1), which indicates that the interface is not a basic
interface.
Reference Standards
For details, see 4.5.13 "Channel identification" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.931.
Date/time
Reference Standards
Description
Indicates the date and time when the message is sent.
The IE can be expressed to the precise of seconds.
Date/time
Year: Indicates the year when the message is
sent.
Month: Indicates the month when the message is
sent.
The CONNECT message is considered as an example here.
In this example, Year is 0x5(5), which indicates that the
message is sent in 05; Month is 0x5(5), which indicates that
the message is sent in May.
Reference Standards
For details, see 4.5.15 "Date/time" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.931.
Display
Reference Standards
Description
Provides information that may be displayed to the user.
Display
Display information: Indicates the information displayed.

this example, Display information is 0, which indicates that
no information is displayed.
Reference Standards
For details, see 4.5.16 "Display" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.931.

Reference Standards
Description
Indicates the high layer compatibility used by the call.
This IE is transparently transmitted through two integrated
services digital network (ISDN) entities.
coding standard: Indicates the coding standard

adopted.
high layer characteristic identification: Indicates the
identification of the high layer characteristic.
this example, coding standard is itu-t-standardized coding,
which indicates that the protocol type is International
Standardization Sector (ITU-T); high layer characteristic
identification is facsimile Group, which indicates that the
high layer characteristic is fax.
Reference Standards
For details, see 4.5.17 "High layer compatibility" in ITU-T Q.931.
Keypad facility
Reference Standards
Description
It is used to convey IA5 characters.
The maximum length of the IE is 34 octets.
Keypad facility
Keypad facility information: Indicates the information about

the keypad facility.
this example, Keypad facility information is 0.
Reference Standards
For details, see 4.5.18 "Keypad facility" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.931.

Reference Standards
Description
Indicates the bearer capability.
It contains bearer related information, for example,
transmission information, transmission rate mode, and
codec information.

Information transfer capability: Indicates the
transmission compatibility.
Negotiation indicator: Indicates the compatibility
negotiation.
Transfer mode: Indicates the transmission mode.
this example, Information transfer capability is speech(0),
which indicates that the call is a voice call; Negotiation
indicator is out-band-negotiation-not-possible(0); Transfer
mode is circuit-mode(0), which indicates that circuit
transmission mode is used.
Reference Standards
For details, see 4.5.19 "Low layer compatibility" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.931.

Message type
Reference Standards
Description
Indicates the type of a message.
The message type indicates the message function.
Generally, the IE is the third part of every message. Bit 8 is
reserved for possible future use as an extension bit.
Message type
Message type: Indicates the type of a message.
this example, Message type is setup(5), which indicates
that the message is a SETUP message.
Reference Standards
For details, see 4.4 "Message type" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.931.
Reference Standards
Description
Indicates which network facilities are to be invoked.
This IE is contained when the caller or the network has
network-specific facilities. The number of IEs in a message
cannot exceed 4.
Length of network identification: Indicates the
length of the network facility information.
Network specific facility specification: Indicates the
information about the network-specific facilities.
this example, length of network identification is 0 and
network specific facility specification is 0.
Reference Standards
For details, see 4.5.21 "Network-specific facilities" in International Telecommunication
Progress indicator
Reference Standards
Description
The maximum length of the IE is four octets.
Progress indicator
location: Indicates the network location.

Coding standard: Indicates the coding standard
adopted.
Progress description: Provides an event description.
The ALERTING message is considered as an example here.
In this example, Location is public network serving the local
user(2); Coding standard is itu-T-standardized coding;
Progress description is In-band information or an appropriate
pattern is now available(8).
Reference Standards
For details, see 4.5.23 "Progress indicator" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.931.
Reference Standards
Description
Indicates the protocol class of the message.
From the direction network -> user, if the message is the
first response to a SETUP message, this IE must be
contained. From the direction user -> network, if the
message is the first response to a SETUP message, this IE
must be contained unless the user accepts the B channel
indicated in the SETUP message.
Protocol discriminator: Indicates the protocol class of the
message.
this example, Protocol discriminator is user network call
control message recommendation-Q931, which indicates
that the protocol class of the message is Q.931.
Reference Standards
For details, see 4.2 "Protocol discriminator" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.931.
Repeat indicator
Reference Standards
Description
Indicates how repeated IEs should be interpreted, when
included in a message.
The IE is included before the first occurrence of the IE that
will be repeated in a message. The length of the IE is one
octet.
Repeat indicator
Repeat indicator: Four bits are used to indicate repeated
information. The IE is valid only when it is set to 1, which
indicates that one value will be selected according to the
priority.
this example, Repeat indicator is 0.
Reference Standards
For details, see 4.5.24 "Repeat indicator" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.931.
Sending complete
Reference Standards
Description
Indicates the completion of a callee number.
The length of the IE is one octet.
Sending complete
Sending complete: Indicates the completion of a callee

number.
this example, Sending complete is used to indicate the
completion of a callee number.
Reference Standards
For details, see 4.5.27 "Sending complete" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.931.
Signal
Reference Standards
Description
It is used to convey information to a user regarding tones
and alerting signals.
Signal
signal value: Indicates the value of the signal.

this example, signal value is dial-tone-on(0), which indicates
the dial tone switch is enabled.
Reference Standards
For details, see 4.5.28 "Signal" in International Telecommunication Union-Telecommunication

Reference Standards
Description
Identifies one requested transit network.
A message can contain multiple such IEs.
Network identification plan: Indicates the network

identification plan. For example, it can be set to
unknown. For details, see Recommendation
X121[21].
Type of network identification: Indicates the type of
the network identification, for example, an
international number identification.
this example, Network identification plan is 0, unknown;
Type of network identification is 0, user defined type.
Reference Standards
For details, see 4.5.29 "Transit network selection" in International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) Q.931.
SGs Interface Protocol

Description of the SGs Interface Protocol
Description of Associated Messages in the Alert Flow
Description of Associated Messages in SMS
Description of Associated Messages in Location Updates
Description of Associated Messages in the Paging Flow
Description of Associated Messages in the Fault Processing Flow
Description of Associated Messages in the Reset Flow
Description of Associated Messages in the Service Abort Flow
Description of the SGs Interface Protocol

Protocol Stack
Message List
Reference Standards
The SGs interface interconnects the mobile switching center (MSC) server and mobility
management entity (MME). The MSC server together with the MME can implement mobility
management, paging during the voice call service and short message service (SMS) for
subscribers register with the Evolved Packet System (EPS) and circuit switched (CS)
networks. Figure 1 shows the application of the SGs interface protocol.
Figure 1 Application of the SGs interface protocol

Protocol Stack
Figure 2 shows the protocol stack of the SGs interface protocol.
Figure 2 Protocol stack of the SGs interface protocol
In the above protocol stack:

SGsAP is used on the application layer between the MSC server and MME.
SCTP is used on the transmission layer to ensure reliability of signaling
transmission between the MSC server and MME.
Message List
Table 1 List of common SGs interface messages
Message
Direction
Function
SGsAP-ALERTREQUEST
MSC server/VLR>MME
The MSC server/visitor location register (VLR)

sends this message, instructing the MME to
notify the MSC server/VLR when detecting
signaling exchange of a subscriber.
SGsAP-ALERT-ACK
MME->MSC
server/VLR
The MME sends this message in response to

an SGsAP-ALERT-REQUEST message when
the MME has a subscriber's IMSI information.
MME->MSC
server/VLR
The MME sends the message in response to

an SGsAP-ALERT-REQUEST message when
the MME does not have a subscriber's IMSI
information.
SGsAP-UE-ACTIVITY- MME->MSC
INDICATION
server/VLR
The MME sends this message to the MSC

server when detecting signaling exchange of a
subscriber.
SGsAP-UPLINKUNITDATA
MME->MSC
server/VLR
The MME sends this message to

transparently convey the NAS message sent
by the UE to the MSC server/VLR.
SGsAP-DOWNLINKUNITDATA
MSC server/VLR>MME
The MSC server/VLR sends this message to

transparently convey the NAS message to be
sent to the UE.
SGsAP-RELEASEREQUEST
MSC server/VLR>MME
The MSC server/VLR sends this message,

notifying the MME that no subsequent NAS
message is to be sent to the UE.
SGsAP-ALERTREJECT
SGsAP-EPS-DETACH- MME->MSC
INDICATION
server/VLR

server/VLR, notifying the MSC server/VLR of
the EPS detach initiated by the UE or MME.
SGsAP-EPS-DETACH- MSC server/VLRACK

>MME
The MSC server sends this message in

response to an SGsAP-EPS-DETACHINDICATION message.
SGsAP-IMSIMME->MSC
DETACH-INDICATION server/VLR

server/VLR, notifying the MSC server/VLR of
the IMSI detach initiated by the UE.
SGsAP-IMSIDETACH-ACK
MSC server/VLR>MME

response to an SGsAP-IMSI-DETACHINDICATION message.
MME->MSC
The MME sends this message, notifying the

MSC server/VLR that TMSI allocation is
SGsAP-TMSIREALLOCATION-
COMPLETE
server/VLR
complete on the UE.
SGsAP-LOCATIONUPDATE-REQUEST
MME->MSC
server/VLR

server/VLR to request a location update or
IMSI attach flow.
MSC server/VLR>MME

response to an SGsAP-LOCATION-UPDATEREQUEST message, indicating that a location
update or IMSI attach flow succeeds.
SGsAP-LOCATIONUPDATE-REJECT
MSC server/VLR>MME

response to an SGsAP-LOCATION-UPDATEREQUEST message, indicating that a location
update or IMSI attach flow fails.
SGsAP-PAGINGREQUEST
MSC server/VLR>MME
The MSC server sends this message,

instructing the MME to page a UE.
MME->MSC
server/VLR

an SGsAP-PAGING-REQUEST message,
notifying the MSC server/VLR of a failure in
paging the UE.
MME->MSC
server/VLR

response to an SGsAP-PAGING-REQUEST
message, notifying the MSC server/VLR that
NAS signaling connection is available between
the UE and MME.
MME->MSC
server/VLR

an SGsAP-PAGING-REQUEST message,
indicating that the paging fails because the
MME determines that UE is unreachable.
SGsAP-LOCATIONUPDATE-ACCEPT
SGsAP-PAGINGREJECT
SGsAP-SERVICEREQUEST
SGsAP-UEUNREACHABLE
SGsAP-STATUS
SGsAP-RESETINDICATION
MME>MSC
server/VLR The MSC server/VLR or MME sends this
message to indicate an error.
MSC
server/VLR>MME
MME>MSC
The MSC server/VLR or MME sends this
server/VLR message, indicating that the SGs association
MSC
on the VLR or MME is invalid.
server/VLR>MME
SGsAP-RESET-ACK
SGsAP-SERVICEABORT-REQUEST
MSC
server/VLRThe MSC server/VLR or MME sends this
>MME
message in response to an SGsAP-RESETMMEINDICATION message.
>MSC
server/VLR
MSC server/VLR>MME
The MSC server/VLR sends this message,

instructing the MME to terminate the fallback
process during a voice call destined for the
UE.
Reference Standards
For details about the SGs interface protocol, see 3GPP TS 29.118.
Parent topic: SGs Interface Protocol

Table 1 describes information elements (IEs) contained in the common part of messages.
Table 1 IEs contained in the common part of messages
IE
Description
Example
An SGsAP-PAGING-REQUEST
message is used as an example.
Specifies the sender and receiver of a

message. A message header contains
the following IEs:
Message
header
Message
content
indicator
sender-mid: Specifies the

number of the BSG process
that sends a message.
sender-pid: Specifies the
internal processing module
that sends a message.
receiver-mid: Specifies the
number of the BSG process
that receives a message.
recvr-pid: Specifies the
internal processing module
that receives a message.
In the message:
sender-mid is set to 1400,
indicating that a message is
sent by BSC process 1400.
sender-mid is set to pidSGSAP (354), indicating that
a message is sent by the SGs
module.
receiverMid is set to 1400,
indicating that a message is
received by BSC process
1400.
recvrPid is set to pid-SCTP
(300), indicating that a
message is received by the
SCTP module.
Specifies contents in an SGs message. message is used as an example.
A message content indicator contains
In the message, messagetype is set to
the Message Type IE.
sgsap-paging-request (1), indicating
that the message is an SGsAPPAGING-REQUEST message.

Description of Associated Messages in the Alert Flow

SGsAP-ALERT-REQUEST
SGsAP-ALERT-ACK
SGsAP-ALERT-REJECT
SGsAP-UE-ACTIVITY-INDICATION
SGsAP-ALERT-REQUEST
Message Function
Associated IEs
Reference Standards
Message Function
An SGs SMS message is sent to an LTE subscriber who is unreachable or does not
respond to a paging request. Then, the MSC server/VLR sets the subscriber status to
unreachable and sends an SGsAP-ALERT-REQUEST message to the mobility management
entity (MME). The SGsAP-ALERT-REQUEST message instructs the MME to notify the
MSC server/VLR when detecting signaling interaction from the LTE subscriber.
After the MSC server/VLR sends the SGsAP-ALERT-REQUEST message, it starts the
Waiting a Response to SGsAP-ALERT-REQUEST Timer to wait for a SGsAP-ALERTACK/SGsAP-ALERT-REJECT message from the MME. If the timer expires for the first
time, the MSC server/VLR sends another SGsAP-ALERT-REQUEST message to the MME.
If the timer expires again before the MSC server/VLR receives a response from the MME,
the MSC server/VLR generates 4061 Waiting a Response to SGsAP-ALERT-REQUEST
Timeout.
The MSC server/VLR can use the measurement entity SGs Service Alert Indication Times
to count the number of SGsAP-ALERT-REQUEST messages sent by the MSC server/VLR.
Figure 1 shows the key information element (IE) in an SGsAP-ALERT-REQUEST message.
Figure 1 Key IE in an SGsAP-ALERT-REQUEST message
Associated IEs
IE
Function
Message type
Uniquely identifies a message.
IMSI
Specifies a subscriber's IMSI.
Reference Standards
For details, see 8.3 "SGsAP-ALERT-REQUEST message" in 3GPP TS 29.118 V11.3.0.
Parent topic: Description of Associated Messages in the Alert Flow
SGsAP-ALERT-ACK
Message Function
Associated IEs
Reference Standards
Message Function
During an SGs SMS message sent to an LTE subscriber, the mobility management entity
(MME) receives an SGsAP-ALERT-REQUEST message from the MSC server/VLR. If a
subscriber's IMSI is available on the MME, the MME sends an SGsAP-ALERT-ACK
message in response to the SGsAP-ALERT-REQUEST message. Then, the MME sets the
Non-EPS Alert Flag (NEAF) to 1 for the subscriber. Once detecting signaling interaction
from the subscriber, the MME sets NEAF to 0.
After receiving the SGsAP-ALERT-ACK message, the MSC server/VLR terminates the
Waiting a Response to SGsAP-ALERT-REQUEST Timer and does not modify the
subscriber's SGs association state. In addition, the MSC server/VLR waits for the
subscriber activity information sent by the MME.
The MSC server/VLR can use the measurement entity SGs Service Alert Indication
Answered Times to count the number of SGsAP-ALERT-ACK messages received by the
MSC server/VLR.
Figure 1 shows the key information element (IE) in an SGsAP-ALERT-ACK message.
Figure 1 Key IE in an SGsAP-ALERT-ACK message
Associated IEs
IE
Function
Message type
IMSI
Reference Standards
For details, see 8.1 "SGsAP-ALERT-ACK message" in 3GPP TS 29.118 V11.3.0.
SGsAP-ALERT-REJECT
Message Function
Associated IEs
Reference Standards
Message Function
During an SGs SMS message sent to an LTE subscriber, the mobility management entity
(MME) receives an SGsAP-ALERT-REQUEST message from the MSC server/VLR. If a
subscriber's IMSI is unavailable on the MME, the MME sends an SGsAP-ALERT-REJECT
message in response to the SGsAP-ALERT-REQUEST message.
After receiving the SGsAP-ALERT-REJECT message, the MSC server/VLR terminates the
Waiting a Response to SGsAP-ALERT-REQUEST Timer and changes the subscriber's SGs
association state to SGs-NULL.
The MSC server/VLR can use the measurement entity SGs Service Alert Indication
Rejected Times to count the number of SGsAP-ALERT-REJECT messages received by the
MSC server/VLR.
Figure 1 shows the key information element (IE) in an SGsAP-ALERT-REJECT message.
Figure 1 Key IE in an SGsAP-ALERT-REJECT message
Associated IEs
IE
Function
Message type
IMSI
SGs Cause
Specifies a failure cause value.
Reference Standards
For details, see 8.2 "SGsAP-ALERT-REJECT message" in 3GPP TS 29.118 V11.3.0.
SGsAP-UE-ACTIVITY-INDICATION
Message Function
Associated IEs
Reference Standards
Message Function
The Non-EPS Alert Flag (NEAF) is set to 1 on the mobility management entity (MME) for a
subscriber. When the MME detects signaling interaction from the subscriber, and the MSC
server/VLR does not participate in the signaling interaction, the MME sends an SGsAP-UEACTIVITY-INDICATION message to the MSC server/VLR and sets NEAF to 0. Figure 1
shows the key information elements (IEs) in an SGsAP-UE-ACTIVITY-INDICATION
message.
NOTE:
If the MSC server/VLR participates in the signaling interaction detected by the MME, the
MME sets NEAF to xx and does not send an SGsAP-UE-ACTIVITY-INDICATION message
to the MSC server/VLR.
The MSC server/VLR can use the measurement entity UE Active Times to count the number
of SGsAP-UE-ACTIVITY-INDICATION messages received by the MSC server/VLR.
Figure 1 shows the key information element (IE) in an SGsAP-UE-ACTIVITY-INDICATION
message.
Figure 1 Key IEs in an SGsAP-UE-ACTIVITY-INDICATION message
Associated IEs
IE
Function
Message type
IMSI
Reference Standards
For details, see 8.20 "SGsAP-UE-ACTIVITY-INDICATION message" in 3GPP TS 29.118
V11.3.0.
Description of Associated Messages in SMS

SGsAP-UPLINK-UNITDATA
SGsAP-DOWNLINK-UNITDATA
SGsAP-RELEASE-REQUEST
Message Function
Associated IEs
Reference Standards
Message Function
During an SGs SMS message, VLR-Reliable is not set to false in the MM context variable
on the mobility management entity (MME). When the MME receives an Uplink NAS
Transport message from the user equipment (UE), the MME derives the NAS message
container from the Uplink NAS Transport message and adds the derived information to an
SGsAP-UPLINK-UNITDATA message sent to the MSC server/VLR. To ensure that the MSC
server/VLR correctly generates call detail records (CDRs), the SGsAP-UPLINK-UNITDATA
message also includes the IMEISV, UE Time Zone, Mobile Station Classmark 2, TAI, and ECGI IEs.
The MSC server/VLR can use the measurement entity Number of Uplink Unitdata Message
Received by MSC to count the number of SGsAP-UPLINK-UNITDATA messages received
by the MSC server/VLR.
Figure 1 shows the key information elements (IEs) in an SGsAP-UPLINK-UNITDATA
message.
Figure 1 Key IEs in an SGsAP-UPLINK-UNITDATA message
Associated IEs
IE
Function
Message type
IMSI
NAS message container
Specifies SMS message contents.
IMEISV
Specifies the software version of an

international mobile terminal. This IE is
optional.
UE Time Zone
Specifies the offset between Greenwich

Mean Time (GMT) and local time. This IE is
optional.
Specifies the priority information of a mobile

terminal. This IE is optional.
TAI
Uniquely identities a tracking area (TA). This

IE is optional.
E-CGI
Uniquely identities cell on an LTE network.

This IE is optional.
Reference Standards
For details, see 8.22 "SGsAP-UPLINK-UNITDATA message" in 3GPP TS 29.118 V11.3.0.
Parent topic: Description of Associated Messages in SMS
SGsAP-DOWNLINK-UNITDATA
Message Function
Associated IEs
Reference Standards
Message Function
During an SGs SMS message, if the user equipment (UE) is in the SGs-ASSOCIATED or
LA-UPDATE-PRESENT state, the MSC server sends an SGsAP-DOWNLINK-UNITDATA
message containing the NAS message to be sent to the UE to the mobility management
entity (MME).
The MSC server/VLR can use the measurement entity Number of Downlink Unitdata
Message Sent by MSC to count the number of SGsAP-DOWNLINK-UNITDATA messages
sent by the MSC server/VLR.
Figure 1 shows the key information elements (IEs) in an SGsAP-DOWNLINK-UNITDATA
message.
Figure 1 Key IEs in an SGsAP-DOWNLINK-UNITDATA message
Associated IEs
IE
Function
Message type
IMSI
Specifies SMS message contents.
Reference Standards
For details, see 8.4 "SGsAP-DOWNLINK-UNITDATA message" in 3GPP TS 29.118

V11.3.0.
SGsAP-RELEASE-REQUEST
Message Function
Associated IEs
Reference Standards
Message Function
The MSC server/VLR sends an SGsAP-RELEASE-REQUEST message to the mobility
management entity (MME) in either of the following scenarios:
The MSC server detects that it does not have NAS signaling interaction with the
user equipment (UE), for example, because the SGs SMS is complete.
The MSC server cannot continue exchanging NAS signaling interaction with the UE
due to a fault, for example, the SGs association information or IMSI is unavailable.
Figure 1 shows the key information elements (IEs) in an SGsAP-RELEASE-REQUEST
message.
Figure 1 Key IEs in an SGsAP-RELEASE-REQUEST message
Associated IEs
IE
Function
Message type
IMSI
SGs cause
Specifies a failure cause value. This IE is

optional.
Reference Standards
For details, see 8.23 "SGsAP-RELEASE-REQUEST message" in 3GPP TS 29.118
V11.3.0.

Description of Associated Messages in Location Updates

SGsAP-EPS-DETACH-INDICATION
SGsAP-EPS-DETACH-ACK
SGsAP-IMSI-DETACH-INDICATION
SGsAP-IMSI-DETACH-ACK
SGsAP-TMSI-REALLOCATION-COMPLETE
SGsAP-LOCATION-UPDATE-REQUEST
SGsAP-LOCATION-UPDATE-ACCEPT
SGsAP-LOCATION-UPDATE-REJECT
SGsAP-EPS-DETACH-INDICATION
Message Function
Associated IEs
Reference Standards
Message Function
The mobility management entity (MME) sends an SGsAP-EPS-DETACH-INDICATION
message, notifying the MSC server/VLR that the user equipment (UE)/MME has initiated an
evolved packet system (EPS) detach.
The MSC server/VLR can use the measurement entity EPS Detached Times to count the
number of SGsAP-EPS-DETACH-INDICATION messages received by the MSC
server/VLR.
Figure 1 shows the key information elements (IEs) in an SGsAP-EPS-DETACHINDICATION message.
Figure 1 Key IEs in an SGsAP-EPS-DETACH-INDICATION message
Associated IEs
IE
Function
Message type
IMSI
MME name
Specifies the domain name of an MME.
IMSI detach from EPS service type
Specifies how a subscriber is detached from

EPS services.
Reference Standards
For details, see 8.6 "SGsAP-EPS-DETACH-INDICATION message" in 3GPP TS 29.118

V11.3.0.
Parent topic: Description of Associated Messages in Location Updates
SGsAP-EPS-DETACH-ACK
Message Function
Associated IEs
Reference Standards
Message Function
The MSC server/VLR sends an SGsAP-EPS-DETACH-ACK message in response to an
SGsAP-EPS-DETACH-INDICATION message sent by the mobility management entity
(MME). After receiving an SGsAP-EPS-DETACH-INDICATION message:
If a subscriber's SGs association information is unavailable in the VLR, the MSC
server/VLR directly sends an SGsAP-EPS-DETACH-ACK message to the MME.
If a subscriber's SGs association information is available in the VLR, the MSC
server/VLR first deletes the subscriber's SGs association information and then
sends an SGsAP-EPS-DETACH-ACK message to the MME.
The MSC server/VLR can use the measurement entity EPS Detached Answer Times to
count the number of SGsAP-EPS-DETACH-ACK messages sent by the MSC server/VLR.
Figure 1 shows the key information elements (IEs) in an SGsAP-EPS-DETACH-ACK
message.
Figure 1 Key IEs in an SGsAP-EPS-DETACH-ACK message
Associated IEs
IE
Function
Message type
IMSI
Reference Standards
For details, see 8.5 "SGsAP-EPS-DETACH-ACK message" in 3GPP TS 29.118 V11.3.0.

SGsAP-IMSI-DETACH-INDICATION
Message Function
Associated IEs
Reference Standards
Message Function
The mobility management entity (MME) sends an SGsAP-IMSI-DETACH-INDICATION
message, notifying the MSC server/VLR that the user equipment (UE) has initiated an IMSI
detach.
The MSC server/VLR can use the measurement entity IMSI Detached Times to count the
number of SGsAP-IMSI-DETACH-INDICATION messages received by the MSC
server/VLR.
Figure 1 shows the key information elements (IEs) in an SGsAP-IMSI-DETACHINDICATION message.
Figure 1 Key IEs in an SGsAP-IMSI-DETACH-INDICATION message
Associated IEs
IE
Function
Message type
IMSI
MME name
IMSI detach from non-EPS service type
Specifies how a subscriber is detached from

non-evolved packet system (EPS) services.
Reference Standards
For details, see 8.8 "SGsAP-IMSI-DETACH-INDICATION message" in 3GPP TS 29.118
V11.3.0.
SGsAP-IMSI-DETACH-ACK
Message Function
Associated IEs
Reference Standards
Message Function
The MSC server/VLR sends an SGsAP-IMSI-DETACH-ACK message in response to an
SGsAP-IMSI-DETACH-INDICATION message sent by the mobility management entity
(MME). After receiving the SGsAP-IMSI-DETACH-INDICATION message:
If a subscriber's SGs association information is unavailable in the VLR, the MSC
server/VLR directly sends an SGsAP-IMSI-DETACH-ACK message.
If a subscriber's SGs association information is available in the VLR, the MSC
server/VLR first deletes the subscriber's SGs association information and then
sends an SGsAP-IMSI-DETACH-ACK message to the MME.
The MSC server/VLR can use the measurement entity IMSI Detached Answer Times to
count the number of SGsAP-IMSI-DETACH-ACK messages sent by the MSC server/VLR.
Figure 1 shows the key information elements (IEs) in an SGsAP-IMSI-DETACH-ACK
message.
Figure 1 Key IEs in an SGsAP-IMSI-DETACH-ACK message
Associated IEs
IE
Function
Message type
IMSI
Reference Standards
For details, see 8.7 "SGsAP-IMSI-DETACH-ACK message" in 3GPP TS 29.118 V11.3.0.

SGsAP-TMSI-REALLOCATION-COMPLETE
Message Function
Associated IEs
Reference Standards
Message Function
The MSC server/VLR sends an SGsAP-LOCATION-UPDATE-ACCEPT message containing
a new TMSI allocated by the MSC server/VLR to the mobility management entity (MME).
After the MME receives an ATTACH COMPLETE or TRACKING AREA UPDATE
COMPLETE message from the user equipment (UE), the MME sends an SGsAP-TMSIREALLOCATION-COMPLETE message, notifying the MSC server/VLR that the UE has
completed the TMSI allocation flow.
The MSC server/VLR can use the measurement entity TMSI Reallocation Complete Times
to count the number of SGsAP-TMSI-REALLOCATION-COMPLETE messages received by
the MSC server/VLR.
Figure 1 shows the key information elements (IEs) in an SGsAP-TMSI-REALLOCATIONCOMPLETE message.
Figure 1 Key IEs in an SGsAP-TMSI-REALLOCATION-COMPLETE message
Associated IEs
IE
Function
Message type
IMSI
Reference Standards
For details, see 8.19 "SGsAP-TMSI-REALLOCATION-COMPLETE message" in 3GPP TS
29.118 V11.3.0.

SGsAP-LOCATION-UPDATE-REQUEST
Message Function
Associated IEs
Reference Standards
Message Function
The mobility management entity (MME) sends an SGsAP-LOCATION-UPDATE-REQUEST
message, notifying the MSC server/VLR that the user equipment (UE) requests for a
location update or IMSI attach flow.
The MSC server/VLR can use the measurement entity Update Location Times to count the
number of SGsAP-LOCATION-UPDATE-REQUEST messages received by the MSC
server/VLR.
Figure 1 shows the key information elements (IEs) in an SGsAP-LOCATION-UPDATEREQUEST message.
Figure 1 Key IEs in an SGsAP-LOCATION-UPDATE-REQUEST message
Associated IEs
IE
Function
Message type
IMSI
MME name
EPS location update type
Specifies whether the UE has performed the

IMSI attach flow or common location update.
New location area identifier
Identifies the new location area (LA) in which

the UE is located.
Old location area identifier
Identifies the original LA in which the UE is

located. This IE is optional.
TMSI status
Specifies whether the UE has a valid TMSI.

IMEISV

optional.
TAI

IE is optional.
E-CGI

Reference Standards
For details, see 8.11 "SGsAP-LOCATION-UPDATE-REQUEST message" in 3GPP TS
29.118 V11.3.0.
SGsAP-LOCATION-UPDATE-ACCEPT
Message Function
Associated IEs
Reference Standards
Message Function
The MSC server/VLR sends an SGsAP-LOCATION-UPDATE-ACCEPT message, notifying
the MME that a location update or IMSI attach flow is complete. If the MSC server/VLR
supports TMSI allocation, it includes the location area identity (LAI) and a new TMSI in the
SGsAP-LOCATION-UPDATE-ACCEPT message. If the MSC server/VLR does not support
TMSI allocation, it includes the LAI and IMSI in the SGsAP-LOCATION-UPDATE-ACCEPT
message.
The MSC server/VLR can use the measurement entity Update Location Accepted Times to
count the number of SGsAP-LOCATION-UPDATE-ACCEPT messages sent by the MSC
server/VLR.
Figure 1 shows the key information elements (IEs) in an SGsAP-LOCATION-UPDATEACCEPT message.
Figure 1 Key IEs in an SGsAP-LOCATION-UPDATE-ACCEPT message
Associated IEs
IE
Function
Message type
IMSI
Location area identifier
Identifies the location area (LA) in which the

UE is located.
New TMSI, or IMSI
Identifies a subscriber. This IE is optional.
Reference Standards
For details, see 8.9 "SGsAP-LOCATION-UPDATE-ACCEPT message" in 3GPP TS 29.118
V11.3.0.
SGsAP-LOCATION-UPDATE-REJECT
Message Function
Associated IEs
Reference Standards
Message Function
If the MSC server rejects a location update request after receiving a SGsAP-LOCATIONUPDATE-REQUEST message from the mobility management entity (MME), the MSC server
sends an GsAP-LOCATION-UPDATE-REJECT message containing the Reject cause IE,
notifying the MME that the location update or IMSI attach flow fails. Then, the MSC
server/VLR sets the UE's SGs association state to SGs-NULL.
The MSC server/VLR can use the measurement entity Update Location Rejected Times to
count the number of SGsAP-LOCATION-UPDATE-REJECT messages sent by the MSC
server/VLR.
Figure 1 shows the key information elements (IEs) in an SGsAP-LOCATION-UPDATEREJECT message.
Figure 1 Key IEs in an SGsAP-LOCATION-UPDATE-REJECT message
Associated IEs
IE
Function
Message type
IMSI
Reject cause
Specifies a cause value used by the MSC

server/VLR to reject a service request sent
by the UE.

UE is located. This IE is optional.
Reference Standards
For details, see 8.10 "SGsAP-LOCATION-UPDATE-REJECT message" in 3GPP TS 29.118
V11.3.0.
Description of Associated Messages in the Paging Flow

SGsAP-PAGING-REQUEST
SGsAP-PAGING-REJECT
SGsAP-SERVICE-REQUEST
SGsAP-UE-UNREACHABLE
Message Function
Associated IEs
Reference Standards
Message Function
The MSC server/VLR sends an SGsAP-PAGING-REQUEST message, instructing the
mobility management entity (MME) to page a user equipment (UE).
The MSC server/VLR can use the measurement entity SGs Interface Paging Message
Times to count the number of SGsAP-PAGING-REQUEST messages sent by the MSC
server/VLR.
Figure 1 shows the key information elements (IEs) in an SGsAP-PAGING-REQUEST
message.
Figure 1 Key IEs in an SGsAP-PAGING-REQUEST message
Associated IEs
IE
Function
Message type
IMSI
VLR name
Specifies the domain name of a VLR.
Service indicator
Specifies the CS service type.
TMSI
Specifies a subscriber's TMSI. This IE is

optional.
CLI
Identifies a calling number in a circuit

switched (CS) mobile terminated (MT) call.

UE is located. This IE is optional.
Global CN-Id
Identifies a core network (CN) node. This IE

is optional.
LCS indicator
Specifies that the origin of the message is

due to a location service (LCS) request and
the type of this request. This IE is optional.
LCS client identity
Specifies the information about the client that

sends an LCS request. This IE is optional.
Channel needed
Specifies the type of the channel that is

required for the paging flow. This IE is
optional.
eMLPP Priority
Specifies the call priority information. This IE

is optional.
Additional paging indicators
Specifies the additional information during the

paging flow. This IE is optional.
Reference Standards
For details, see 8.14 "SGsAP-PAGING-REQUEST message" in 3GPP TS 29.118 V11.3.0.
Parent topic: Description of Associated Messages in the Paging Flow
SGsAP-PAGING-REJECT
Message Function
Associated IEs
Reference Standards
Message Function
The mobility management entity (MME) sends an SGsAP-PAGING-REJECT message,
notifying the MSC server/VLR that the paging flow fails.
The MSC server/VLR can use the measurement entity SGs Interface Paging Message
Rejected Times to count the number of SGsAP-PAGING-REJECT messages received by
the MME.
Figure 1 shows the key information elements (IEs) in an SGsAP-PAGING-REJECT
message.
Figure 1 Key IEs in an SGsAP-PAGING-REJECT message

Associated IEs
IE
Function
Message type
IMSI
SGs Cause
Reference Standards
For details, see 8.13 "SGsAP-PAGING-REJECT message" in 3GPP TS 29.118 V11.3.0.
SGsAP-SERVICE-REQUEST
Message Function
Associated IEs
Reference Standards
Message Function
The mobility management entity (MME) sends an SGsAP-SERVICE-REQUEST message in
response to an SGsAP-PAGING-REQUEST message, notifying the MSC server/VLR that
NAS signaling connection is available between the user equipment (UE) and MME, or NAS
signaling connection has been established after paging is complete. After the MME receives
an SGsAP-PAGING-REQUEST message:
If the UE is in the EMM-CONNECTED state, the MME directly sends an SGsAPSERVICE-REQUEST message to the MSC server/VLR.
If the UE is in the MM-IDLE state, the MME does not send an SGsAP-SERVICEREQUEST message to the MSC server/VLR until the UE is in the EMMCONNECTED state.
The service indicators contained in SGsAP-SERVICE-REQUEST and SGsAP-PAGINGREQUEST messages must be the same. To ensure that the MSC server/VLR correctly
generates call detail records (CDRs), the SGsAP-SERVICE-REQUEST message also
includes IMEISV, UE Time Zone, Mobile Station Classmark 2, TAI, and E-CGI.
The MSC server/VLR can use the measurement entity SGs Interface Paging Answered
Times to count the number of SGsAP-SERVICE-REQUEST messages received by the
MSC server/VLR.
Figure 1 shows the key information elements (IEs) in an SGsAP-SERVICE-REQUEST
message.
Figure 1 Key IEs in an SGsAP-SERVICE-REQUEST message
Associated IEs
IE
Function
Message type
IMSI
Service indicator
Specifies the CS service type.
IMEISV

optional.
UE Time Zone
Specifies the offset between Greenwich

Mean Time (GMT) and local time. This IE is
optional.
Specifies the priority information of a mobile

terminal. This IE is optional.
TAI

IE is optional.
E-CGI

Specifies a subscriber's evolved packet
UE EMM Mode
system mobility management (EMM) state.

Reference Standards
For details, see 8.17 "SGsAP-SERVICE-REQUEST message" in 3GPP TS 29.118 V11.3.0.
SGsAP-UE-UNREACHABLE
Message Function
Associated IEs
Reference Standards
Message Function
The mobility management entity (MME) sends an SGsAP-UE-UNREACHABLE message,
notifying the MSC server/VLR that the paging flow fails because the MME determines that
the user equipment (UE) is unreachable.
The MSC server/VLR can use the measurement entity MME Returning Subscriber
Unreachable Times to count the number of SGsAP-UE-UNREACHABLE messages received
by the MME.
Figure 1 shows the key information elements (IEs) in an SGsAP-UE-UNREACHABLE
message.
Figure 1 Key IEs in an SGsAP-UE-UNREACHABLE message
Associated IEs
IE
Function
Message type
IMSI
SGs cause
Reference Standards
For details, see 8.21 "SGsAP-UE-UNREACHABLE message" in 3GPP TS 29.118 V11.3.0.
Description of Associated Messages in the Fault Processing

Flow
SGsAP-STATUS
SGsAP-STATUS
Message Function
Associated IEs
Reference Standards
Message Function
The MSC server/VLR or mobility management entity (MME) sends an SGsAP-STATUS
message when an error occurs. For details about when the MSC server/VLR sends an
SGsAP-STATUS message to the MME, see the description in 4038 SGsAP-STATUS
Message Sent by MSC. For details about when the MME sends an SGsAP-STATUS
message to the MSC server/VLR, see the description in 4039 SGsAP-STATUS Message
Received by MSC.
The MSC server/VLR can use the measurement entity Number of SGsAP-STATUS
Message Send by MSC to count the number of SGsAP-STATUS messages sent by the
MSC server/VLR and use the measurement entity Number of SGsAP-STATUS Message
Received by MSC to count the number of SGsAP-STATUS messages received by the MSC
server/VLR.
Figure 1 shows the key information elements (IEs) in an SGsAP-STATUS message.
Figure 1 Key IEs in an SGsAP-STATUS message

Associated IEs
IE
Function
Message type
IMSI
Specifies a subscriber's IMSI. This IE is

optional.
SGs cause
Erroneous message
Specifies the error information.
Reference Standards
For details, see 8.18 "SGsAP-STATUS message" in 3GPP TS 29.118 V11.3.0.

Parent topic: Description of Associated Messages in the Fault Processing Flow
Description of Associated Messages in the Reset Flow

SGsAP-RESET-INDICATION
SGsAP-RESET-ACK
SGsAP-RESET-INDICATION
Message Function
Associated IEs
Reference Standards
Message Function
An SGsAP-RESET-INDICATION message is sent in either of the following scenarios:
When the VLR restarts and bit 0 of P448 is set to 1, the MSC server/VLR sends
an SGsAP-RESET-INDICATION message, notifying all interworking mobility
management entities (MMEs) that the SGs association information of subscribers
who register with the VLR is unreliable.
After sending the SGsAP-RESET-INDICATION message, the MSC server/VLR
starts the TN_WAIT_FOR_RESET_ACK timer to wait for an SGsAP-RESET-ACK
message from the MME.
When the MME recovers from a fault, it sends an SGsAP-RESET-INDICATION
message, notifying the MSC server/VLR that the SGs association information of
subscribers who register with the MME is unreliable.
After receiving the SGsAP-RESET-INDICATION message, the MSC server/VLR
generates 4040 SGsAP-RESET-INDICATION or SGsAP-RESET-ACK Message
Received by VLR.
The MSC server/VLR can use the measurement entity Number of Sent SGsAP-RESETINDICATION Messages to count the number of SGsAP-RESET-INDICATION messages
sent by the MSC server/VLR and use the measurement entity Number of Received SGsAPRESET-INDICATION Messages to count the number of SGsAP-RESET-INDICATION
messages received by the MSC server/VLR.
An indicator in an SGsAP-RESET-INDICATION message can specify whether the MSC
server/VLR or MME sends the message. Figure 1 shows the key IEs in an SGsAP-RESETINDICATION message.
Figure 1 Key IEs in an SGsAP-RESET-INDICATION message
Associated IEs
IE
Function
Message type
MME name
Specifies the domain name of an MME. This

IE is optional.
VLR name
Specifies the domain name of a VLR. This IE

is optional.
Reference Standards
For details, see 8.16 "SGsAP-RESET-INDICATION message" in 3GPP TS 29.118 V11.3.0.
Parent topic: Description of Associated Messages in the Reset Flow
SGsAP-RESET-ACK
Message Function
Associated IEs
Reference Standards
Message Function
An SGsAP-RESET-ACK message is sent in either of the following scenarios:
When the VLR restarts, the MSC server/VLR sends an SGsAP-RESETINDICATION message to all interworking mobility management entities (MMEs).
Then, the MME sends an SGsAP-RESET-ACK message, notifying that the SGs
association information of subscribers who register with the VLR is set to
unreliable on the MME.
After receiving the SGsAP-RESET-ACK message, the MSC server/VLR generates
4040 SGsAP-RESET-INDICATION or SGsAP-RESET-ACK Message Received by
VLR.
When the MME recovers from a fault, it sends an SGsAP-RESET-INDICATION
message. Then, the MSC server/VLR sends an SGsAP-RESET-ACK message,
notifying the MME that the SGs association information of subscribers who
register with the MME is set to unreliable on the MSC server/VLR. After sending
the SGsAP-RESET-ACK message, the MSC server/VLR generates 4040 SGsAPRESET-INDICATION or SGsAP-RESET-ACK Message Received by VLR.
The MSC server/VLR can use the measurement entity Number of Sent SGsAP-RESETACK Messages to count the number of SGsAP-RESET-ACK messages sent by the MSC
server/VLR and use the measurement entity Number of Received SGsAP-RESET-ACK
Messages to count the number of SGsAP-RESET-ACK messages received by the MSC
server/VLR.
An indicator in an SGsAP-RESET-ACK message can specify whether the MSC server/VLR
or MME sends the message. Figure 1 shows the key IEs in an SGsAP-RESETINDICATION message sent by the MME.
Figure 1 Key IEs in an SGsAP-RESET-ACK message sent by the MME
Associated IEs
IE
Function
Message type
MME name
Specifies the domain name of an MME. This

IE is optional.
VLR name
Specifies the domain name of a VLR. This IE

is optional.
Reference Standards
For details, see 8.15 "SGsAP-RESET-ACK message" in 3GPP TS 29.118 V11.3.0.
Parent topic: Description of Associated Messages in the Reset Flow
Description of Associated Messages in the Service Abort

Flow
SGsAP-SERVICE-ABORT-REQUEST
SGsAP-SERVICE-ABORT-REQUEST
Message Function
Associated IEs
Reference Standards
Message Function
The MSC server/VLR sends an SGsAP-SERVICE-ABORT-REQUEST message, instructing
the mobility management entity (MME) to stop the fallback flow and retain the SGs
association state when the calling party releases a voice call or supplementary service
before the called party is alerted in either of following scenarios:
The MSC server/VLR has sent an SGsAP-PAGING-REQUEST message to the
MME but has not received an SGsAP-SERVICE-REQUEST message from the
MME.
The MSC server/VLR has received an SGsAP-SERVICE-REQUEST message
from the MME after sending an SGsAP-PAGING-REQUEST message, but the UE
has not performed a location update on a CS network or not responded to the
paging request.
NOTE:
Bit 2 of P1180 determines whether the MSC server/VLR can send SGsAP-SERVICEABORT-REQUEST messages to the MME.
The MSC server/VLR can use the measurement entity Number of Sent SGsAP-SERVICEABORT-REQUEST Messages to count the number of SGsAP-SERVICE-ABORTREQUEST messages sent by the MSC server/VLR.
Figure 1 shows the key information elements (IEs) in an SGsAP-SERVICE-ABORTREQUEST message.
Figure 1 Key IEs in an SGsAP-SERVICE-ABORT-REQUEST message
Associated IEs
IE
Function
Message type
IMSI
Reference Standards
For details, see 8.24 "SGsAP-SERVICE-ABORT-REQUEST message" in 3GPP TS 29.118
V11.3.0.
Parent topic: Description of Associated Messages in the Service Abort Flow

Channel needed
CLI
E-CGI
eMLPP priority
Erroneous message
Global CN-Id
IMEISV
IMSI
LCS client identity
LCS indicator
Message Type
MME Name
New TMSI, or IMSI
Reject cause
Service indicator
SGs Cause
TAI
TMSI
TMSI status
UE EMM Mode
UE Time Zone
VLR name

Reference Standards
Information Element
(IE)
Description
Example
Specifies the addition

information, such as the CSRI
indicator, during the paging flow.
Value:
Additional paging
indicators
0: CS restoration
indicator (CSRI) is not
set
1: CS restoration
indicator (CSRI) is set message is used as an
example. In the message, csriIf the MSC server is required to enum-value is set to csri-is-set
send additional information, such (1), indicating that data
as the CSRI indicator, to the
restoration is required.
mobility management entity
(MME) during the paging flow,
the MSC server must include the
Additional paging indicators IE in
an SGsAP-PAGING-REQUEST
message.
Reference Standards
For details, see 9.4.25 "Additional paging indicators" in 3GPP TS 29.118 V11.3.0.
Channel needed
Reference Standards
Information Element
(IE)
Description
Example
Specifies the type of the channel

that is required for the paging
flow. If the MSC server/VLR is
required to notify the UE of the
required channel type, the MSC
server/VLR must include this IE
in an SGsAP-PAGINGREQUEST message. Bit 0 of
P1180 determines whether the
MSC server/VLR includes the
Channel needed IE in an
message. If the SGsAPPAGING-REQUEST message
does not contain the Channel
needed IE, the channel type
used by the UE is Any channel
by default.
Value:
Channel needed
0: Any channel
1: SDCCH
2: TCH/F (Full rate)
3: TCH/H or TCH/F
(Dual rate)
Bit 1 of P1180 determines how
the MSC server/VLR completes
the Channel needed IE.
When bit 1 of P1180 is
set to 0, the MSC
server/VLR sets the
Channel needed IE to
message is used as an
example. In the message,
channel-needed-value is set to
E1, indicating that the channel
type is SDCCH.
TCH/H or TCH/F
(Dual rate).
When bit 1 of P1180 is
set to 1, the MSC
server/VLR sets the
Channel needed IE to
TCH/F (Full rate).
Reference Standards
For details, see 9.4.23 "Channel needed" in 3GPP TS 29.118 V11.3.0.
CLI
Reference Standards
Information
Element
Description
(IE)
Example
Specifies a calling number in a

circuit switched (CS) mobile
terminated (MT) call. If the MSC
server implements the calling line
identification presentation (CLIP)
service, the MSC server must
include the CLI IE in an SGsAPPAGING-REQUEST message.
The CLI IE consists of the
mandatory parameter Calling
party BCD number information
and optional parameters Calling
party subaddress and Cause.
information species the call
source. This parameter consists
of the following parts:
Type of number
0: unknown
1: international
number
2: national
number
3: network
specific
number
4: dedicated
access, short
code
Other values:
Reserved
Numbering plan
identification
Calling line
identification
(CLI)
0: unknown
1:
ISDN/telephony
numbering plan
3: data
numbering plan
4: telex
numbering plan
8: national
numbering plan
9: private
numbering plan
Other values:
Reserved
Presentation indicator
0: Presentation
allowed
1: Presentation
restricted
2: Number not
available due
to interworking
3: Reserved
Screening indicator
0: Userprovided. not
screened
1: Userprovided,
verified and
passed
2: Userprovided,
verified and
failed
An SGsAP-PAGING-REQUEST message is
used as an example. In the message:
type-of-number is set to nationalnumber (2), indicating that the
calling number is a national number.
numbering-plan-identification is
set to isdn-telephony-numberingplan (1), indicating that numbering
plan is ISDN/Telephony numbering
plan.
presentat-indicator is set to
Presentation allowed (0),
indicating that a calling number can
be displayed on called party's
mobile terminal.
screening-indicator is set to
network-provided, indicating that
the screening indicator is provided
by the network.
3: Network
provided
Reference Standards
For details, see 9.4.1 "CLI" in 3GPP TS 29.118 V11.3.0.
E-CGI
Reference Standards
Information
Element (IE)
E-UTRAN Cell
Global Identity (ECGI)
Description
Example
Uniquely identifies the E-UTRAN

where the subscriber locates. The
An SGsAP-SERVICE-REQUEST
E-CGI IE contains the PLMN ID
message is used as an example.
and cell ID.
In the message, plmn specifies the
ID of PLMN to which a subscriber
belongs, and eci identifies the cell
where the subscriber locates.
Reference Standards
For details, see 9.4.3a "E-UTRAN Cell Global Identity" in 3GPP TS 29.118 V11.3.0.
eMLPP priority
Reference Standards
Information Element
(IE)
eMLPP priority
(enhanced Multi-Level
Precedence and
Preemption)
Description
Example
Specifies the call priority

information. If the MSC
server/VLR can process priority
information during Circuit
Switched Fallback (CSFB) calls
and the MSC server/VLR has
received a call request
containing the priority
information, the MSC
server/VLR must include the
eMLPP priority IE in an SGsAPPAGING-REQUEST message.
Bit 0 of P1156 determines
whether the MSC server/VLR
includes the eMLPP priority IE in example. In the message, callan SGsAP-PAGING-REQUEST Priority is set to call-prioritymessage.
level-1 (4), initiating that the call
priority is 1.
Value:
0:
1:
2:
3:
4:
5:
6:
7:
no priority applied
call priority level B
call priority level A
Reference Standards
For details, see 9.4.24 "eMLPP priority" in 3GPP TS 29.118 V11.3.0.


Reference Standards
Information
Element (IE)
Description
Example
Species which flow a

mobile terminal performs as
instructed by the MSC
server.
Value:
EPS location update
type
An SGsAP-LOCATION-UPDATEREQUEST message is used as an

1: IMSI attach
2: Normal location example.
In the message, eps-location-updateupdate
Other values: The type is set to normal-location-update (2),
indicating that the mobile terminal
mobile terminal
performs a common location update.
performs a
common location
update.
Reference Standards
For details, see 9.4.2 "EPS location update type" in 3GPP TS 29.118 V11.3.0.
Erroneous message
Reference Standards
Information
Element
Description Example
(IE)
Erroneous
message
Specifies
the error
information.
This IE is in
the typeAn SGsAP-STATUS message is used as an example.
length-value
(TLV)
format.
Reference Standards
For details, see 9.4.3 "Erroneous message" in 3GPP TS 29.118 V11.3.0.
Global CN-Id
Reference Standards
Information Element
(IE)
Description
Global CN-Id
Identifies a core network (CN)

node. The Global CN-Id IE
consists of PLMN ID and CN ID.
The PLMN ID consists of the
mobile country code (MCC) and
mobile network code (MNC).
The MSC server must include
this IE in an SGsAP-PAGINGexample. In the message:
REQUEST message when a
Values of mcc-dig-2,
radio access network (RAN) is
mcc-dig-1, and mccconnected to multiple MSC
dig-3 specify the MCC.
servers and the MSC server
Values of mnc-dig-3,
uses an IMSI to page a
mnc-dig-2, and mncsubscriber. Whether the MSC
dig-1 specify the MNC.
server includes the Global CN-Id
IE in an SGsAP-PAGINGThe value of cn-id
REQUEST message is
specifies the CN ID of
determined by bit 2 of P1156.
an MSC server.
Example
Reference Standards
For details, see 9.4.4 "Global CN-Id" in 3GPP TS 29.118 V11.3.0.
IMEISV
Reference Standards
Information Element
(IE)
Description
Example
Specifies the software version

of an international mobile
terminal.
IMEISV
If a mobility
management entity
(MME) supports the
Automatic Device
Detection (ADD)
function, the MME
must include the
IMEISV IE in an
An SGsAP-SERVICESGsAP-LOCATIONREQUEST message is used as
UPDATE-REQUEST
an example.
message.
If the MME can obtain imeisv is set to
IMEISV information, it 000000000000000, indicating
includes the IMEISV IE the software version of an
in SGsAP-SERVICE- international mobile terminal.
REQUEST and
SGsAP-UPLINKUNITDATA messages
sent to the MSC
server, ensuring that
the MSC server
correctly generates call
detail records (CDRs)
during calls.
Reference Standards
For details, see 9.4.5 "IMEISV" in 3GPP TS 29. 118 V11.3.0.

IMSI
Reference Standards
Information Element
Description
(IE)
Example
Identifies an international
mobile subscriber. The IMSI IE
contains the following
parameters:
type-of-identity:
Specifies the identity
used to identify a
subscriber.
IMSI
1: IMSI
2: IMEI
3: IMEISV
4: TMSI/PTMSI/MTMSI
5: TMGI and
optional
MBMS
Session
Identity
0: No
An SGsAP-SERVICE-REQUEST
Identity
message is used as an example. In
the message:
Other
values:
type-of-identity is set to
Reserved
iMSI (1), indicating that an
IMSI is used to identify a
odd-or-even-indic:
mobile subscriber.
Specifies whether the
IMSI length is an even
odd-or-even-indic is set to
or odd number.
odd-number-of-identitydigits (1), indicating that
0: even
the IMSI length is an odd
number of
identity digits
and also
when the
TMSI/PTMSI or
TMGI and
optional
MBMS
Session
Identity is
used
1: odd
number of
identity digits
number.
imsi-body is set to
470011159200555 that is
the subscriber's IMSI.
imsi-body: Specifies
an IMSI.
Reference Standards
For details, see 9.4.6 "IMSI" in 3GPP TS 29.118 V11.3.0 and 10.5.1.4 "Mobile Identity" in
3GPP TS 24.008 V12.2.0.

Reference Standards
Information
Element
Description
(IE)
Example
Specifies how a
subscriber is
detached from
an evolved
packet system
(EPS) service.
Value:
IMSI detach
from EPS
service type
1:
Network
initiated
IMSI
detach
from
An SGsAP-EPS-DETACH-INDICATION message is used as
EPS
an example. In the message, imsi-detach-from-eps-serviceservices type-value specifies how a subscriber is detached from an
2: UE EPS service.
initiated
IMSI
detach
from
EPS
services
3: EPS
services
not
allowed
Reference Standards
For details, see 9.4.7 "IMSI detach from EPS service type" in 3GPP TS 29.118 V11.3.0.


Reference Standards
Information
Element
Description
(IE)
Example
Species how a
subscriber is
detached from a
non-evolved
packet system
(EPS) service.
IMSI detach
from nonEPS service
type
1: Explicit
UE
initiated
IMSI
detach
from nonEPS
services
2:
An SGsAP-IMSI-DETACH-REQUEST message is used as
Combined an example.
UE
In the message, imsi-detach-from-non-eps-service-type is
initiated set to Implicit network initiated IMSI detach from EPS and
IMSI
non-EPS services, indicating that a subscriber performs an
detach
implicit attach from a non-EPS service.
from EPS
and nonEPS
services
3: Implicit
network
initiated
IMSI
detach
from EPS
and non-
EPS
services
Reference Standards
For details, see 9.4.8 "IMSI detach from non-EPS service type" in 3GPP TS 29.118
V11.3.0.
LCS client identity

Reference Standards
Information
Element (IE)
Description
Example
Species identity
information of the client
that sends an LCS
request. This IE is a
compound parameter.
Location service
(LCS) client
identity
During the MT
LCS service, the
MSC server can
include this IE in
an SGsAPPAGINGAn SGsAP-PAGING-REQUEST message is
REQUEST
used as an example. In the message, lcsmessage,
depending on the client-identity-value species identity
setting of bit 3 of information of the client that sends an LCS
request.
P698.
During the LCS
service in
emergency calls,
the MSC server
must include this
IE in an SGsAPPAGINGREQUEST
message.
Reference Standards
For details, see 9.4.9 "LCS client identity" in 3GPP TS 29.118 V11.3.0.

LCS indicator
Reference Standards
Information Element
(IE)
Description
Example
Specifies whether a message is

sent during the LCS service.
Value:
Location service (LCS)

indicator
1: MT-LR
Other values:
Undefined by the
protocol
The MSC server must include
this IE during the MT LCS
service in an SGsAP-PAGINGREQUEST message. Bit 3 of
P698 determines whether the
MSC server includes the LCS
indicator in an SGsAP-PAGINGREQUEST message during the
MT LCS service.
example. In the message, lcsindicator-value is set to MT-LR
(1), indicating that the message
is sent during the MT LCS
service.
Reference Standards
For details, see 9.4.10 "LCS indicator" in 3GPP TS 29.118 V11.3.0.

Reference Standards
Information Element
(IE)
Description
Example
An SGsAP-LOCATIONUPDATE-ACCEPT message is
used as an example.
Uniquely identifies a location

area (LA). The Location area
identifier IE consists of the
mobile country code (MCC),
mobile network code (MNC),
and location area code (LAC).
In the message:
mcc-dig-2, and mccdig-3 specify the MCC.
mnc-dig-1, and mncdig-2 specify the MNC.
The value of lac
specifies the LAC.
Reference Standards
For details, see 9.4.11 "Location area identifier" in 3GPP TS 29.118 V11.3.0.
Message Type
Reference Standards
Information Element
(IE)
Description
Example
Specifies the message sent

over the SGs interface.
Value:
Message Type
Unassigned: Unknown
message type
1: SGsAP-PAGINGREQUEST
2: SGsAP-PAGINGREJECT
6: SGsAP-SERVICEREQUEST
7: SGsAPDOWNLINK-UNITDATA
8: SGsAP-UPLINKUNITDATA
9: SGsAP-LOCATIONUPDATE-REQUEST
10: SGsAPLOCATION-UPDATEACCEPT
11: SGsAPLOCATION-UPDATEREJECT
12: SGsAP-TMSIREALLOCATIONCOMPLETE
13: SGsAP-ALERTREQUEST
14: SGsAP-ALERTIn a message, messagetype is
ACK
set to sgsap-alert-request (13),

15: SGsAP-ALERTindicating that an SGsAPREJECT
ALERT-REQUEST message is
16: SGsAP-UEsent over the SGs interface.
ACTIVITYINDICATION
17: SGsAP-EPSDETACH-INDICATION
18: SGsAP-EPSDETACH-ACK
19: SGsAP-IMSIDETACH-INDICATION
20: SGsAP-IMSIDETACH-ACK
21: SGsAP-RESETINDICATION
22: SGsAP-RESETACK
23: SGsAP-SERVICEABORT-REQUEST
26: SGsAP-MMINFORMATIONREQUEST
27: SGsAP-RELEASEREQUEST
29: SGsAP-STATUS
31: SGsAP-UEUNREACHABLE
Reference Standards
For details, see 9.2 "Message type" in 3GPP TS 29. 118 V11.3.0.
MME Name
Reference Standards
Information
Element
Description
(IE)
Mobility
management Species the domain name of an MME.
An SGsAP-SERVICE-UPDATE-REQUEST message is used as an example.
entity
(MME)
name
Reference Standards
For details, see 9.4.13 "MME name" in 3GPP TS 29.118 V11.3.0.

Reference Standards
Information
Element
Description
(IE)
Example
Specifies the priority

information of a subscriber,
based on which the MSC
server decides how to
process subscriber's
operations.
If the MME can obtain Mobile
Station Classmark 2
information, it includes the
IE in SGsAP-SERVICEREQUEST and SGsAPUPLINK-UNITDATA
messages sent to the MSC
server, ensuring that the MSC
server correctly generates
call detail records (CDRs)
during calls.
The Mobile Station Classmark
2 IE contains the following
parameters:
Revision level
Value:
0:
Reserved
for GSM
phase 1
1: Used by
GSM
phase 2
mobile
stations
2: Used by
mobile
stations
supporting
R99 or
later
versions of
the
protocol
3:
Reserved
for future
use
NOTE:
Revision level 3 is
the highest priority.
ES IND: Specifies
whether a mobile
terminal implements
the "Controlled Early
Classmark Sending"
operation.
0: The
mobile
terminal
does not
implement
the
"Controlled
Early
Classmark
Sending"
operation.
1: The
mobile
terminal
implements
the
"Controlled
Early
Classmark
Sending"
operation.
A5/1
0:
encryption
algorithm
A5/1
available
1:
encryption
algorithm
A5/1 not
available
RF Power Capability
PS capability
(pseudosynchronization
capability)
0: PS
capability
not present
1: PS
capability
present
Supplementary
Service Screening
Indicator
0: default
value of
phase 1
1:
capability
of handling
of ellipsis
notation
and phase
2 error
handling
Other
values:
Reserved
SM capability (MT
SMS pt to pt
capability)
Mobile
Station
Classmark
2
0: The
mobile
terminal
station
does not
support
mobile
terminated
(MT) pointto-point
SMS
messages.
1: The
mobile
An SGsAP-SERVICE-REQUEST message is
terminal
used as an example. In the message:
supports
revision-level is set to used-by-mobileMT pointstations-supporting-R99-or-laterto-point
versions-of-the-protocol (2), indicating
SMS
that he UE supports R99 or later.
messages.
es-ind is set to 1, indicating that the UE
Voice Broadcast
implements the "Controlled Early
Service (VBS)
Classmark Sending" operation.
notification reception
a5-1 and a5-2 are set to 0, indicating
0: No VBS
that the UE does not support A5/1 or
capability
A5/2 encryption algorithm. a5-3 is set
or
to 1, indicating that the UE supports
notification
A5/3 encryption algorithm.
is required.
rf-power-capability is set to 7,
1: VBS
indicating that the radio frequency
capabilities
capability is not involved.
and
ss-screening-indicator is set to 1,
notifications
indicating "capability of handling of
are
ellipsis notation and phase 2 error
required.
handling" is supported.
Voice Group Call

Service (VGCS)
notification reception
0: No
VGCS
capability
or
notification
is required.
1: VGCS
capabilities
and
notifications
are
required.
FC Frequency
Capability
0: The
mobile
terminal
does not
support the
E-GSM or
R-GSM
band.
1: The
mobile
terminal
supports
the E-GSM
or R-GSM
band.
CM3: Specifies the
Classmark 3
capability.
0: The MS
does not
support any
options that
are
indicated in
ps-capa, sm-capability, cm3, lcsvacap, and cmsp are set to 1, indicating

the corresponding capabilities are
supported.
vbs-notification-reception, vgcsnotification-reception, and fcfrequency-capability are set to 0,
indicating the corresponding
capabilities are not supported or not
required.
solsa is set to 0, indicating that the
SoLSA capability is not supported.
CM3
1: The MS
supports
options that
are
indicated in
classmark
3 IE
LCS VA capability
(LCS value added
location request
notification
capability)
0: location
request
notification
via CS
domain not
supported
1: location
request
notification
via CS
domain
supported
UCS2 treatment
0: The ME
has a
preference
for the
default
alphabet
over UCS2
1: The ME
has no
preference
between
the use of
the default
alphabet
and the use
of UCS2
SoLSA (Support of
Localized Service
Area)
0: The ME
does not
support
SoLSA
1: The ME
supports
SoLSA
CMSP (CM Service
Prompt)
0: "Network
initiated
MO CM
connection
request"
not
supported
1: "Network
initiated
MO CM
connection
request"
supported
for at least
one CM
protocol
A5/3: Specifies the
A5/3 encryption
algorithm capability.
0:
encryption
algorithm
A5/3 not
available
1:
encryption
algorithm
A5/3
available
A5/2: Specifies the
A5/2 encryption
algorithm capability.
0:
encryption
algorithm
A5/2 not
available
1:
Reserved
Reference Standards
For details, see 9.4.14a "Mobile Station Classmark 2" in 3GPP TS 29.118 V11.3.0.

Reference Standards
Information
Element
Description Example
(IE)
NAS
message
container
Encapsulates
SMS
message
contents,
such as CPDATA, CPACK, or CP- An SGsAP-UPLINK-UNITDATA message is used as an example.
ERROR
In the message:
messages,
protocol-discriminator is set to sms-messages (9),
sent
indicating that the message contains SMS message
between the
contents.
MSC server
transaction-identifier contains ti-value and ti-flag.
and visited
location
type-of-sms-msg is set to cp-data (1), indicating that
register
the SMS message type is CP-DATA.
(VLR).
cp-user-data contains the user information element.
Reference Standards
For details, see 9.4.15 "NAS message container" in 3GPP TS 29. 118 V11.3.0.

Reference Standards
Information Element
(IE)
New location area

identifier
Description
Example
Identifies the target location

area (LA) contained in an
SGsAP-LOCATION-UPDATE- An SGsAP-LOCATIONREQUEST message, requesting UPDATE-REQUEST message is
for an SGs combined location used as an example.
update or an IMSI attach. The
In the message:
consists of the mobile country
mcc-dig-2, and mcccode (MCC), mobile network
code (MNC), and location area
code (LAC).
mnc-dig-1, and mncdig-2 specify the MNC.
The value of lac
specifies the LAC.
Reference Standards
New TMSI, or IMSI

Reference Standards
Information Element
Description
(IE)
Example
Specifies whether a TMSI or

IMSI is used to identify a
subscriber.
New TMSI, or IMSI
If the IE contains an
IMSI, the MSC
server does not
allocate a TMSI for
the subscriber.
If the IE contains a
TMSI, the MSC
server uses the
TMSI to identify the
subscriber.
If the IE contains
neither a TMSI nor
an IMSI and the
subscriber has a
valid TMSI, the MSC
server continues
using the original
TMSI to identify the
subscriber.
An SGsAP-LOCATION-UPDATEACCEPT message is used as an

example.
In the message:
type-of-identity is set to
tMSI-or-PTMSI (4),
indicating that the MSC
server uses a TMSI either
new or original to identify a
subscriber.
odd-or-even-indic is set to
even-number-of-identitydigits (0), indicating that the
length of the TMSI or IMSI
is an even number.
tmsi-or-ptmsi specifies the
TMSI used by the
subscriber.
Reference Standards
For details, see 9.4.14 "Mobile identity" in 3GPP TS 29.118 V11.3.0.


Reference Standards
Information Element
(IE)
Old location area

identifier
Description
Example
Identifies the original location

area. The Old location area
identifier IE consists of the
mobile country code (MCC),
mobile network code (MNC),
and location area code (LAC). An SGsAP-LOCATIONUPDATE-REQUEST message is
If a mobile terminal does not
add the original LA information used as an example.
to an ATTACH REQUEST or
TRACKING AREA UPDATE
mcc-dig-2, and mccREQUEST message, the MME
must include the Old location
area identifier IE in an SGsAPmnc-dig-1, and mncLOCATION-UPDATE-REQUEST
dig-2 specify the MNC.
message.
The value of lac
specifies the LAC.
Reference Standards
Reject cause
Reference Standards
Information Element
(IE)
Description
Specifies the reason the MSC
server used to reject a request
sent by a subscriber.
Value:
02: IMSI unknown in
HLR
03: Illegal MS
04: IMSI unknown in
VLR
05: IMEI not accepted
06: Illegal ME
11: PLMN not allowed
12: Location Area not
allowed
13: Roaming not
allowed in this location
area
15: No Suitable Cells In
Location Area
17: Network failure
20: MAC failure
21: Synch failure
22: Congestion
23: GSM authentication
unacceptable
25: Not authorized for
this CSG
32: Service option not
supported
Example
Reject cause
Reference Standards
33: Requested service

option not subscribed
34: Service option
temporarily out of
An SGsAP-LOCATIONorder
UPDATE-REJECT message is
38: Call cannot be
used as an example.
identified
48-63: retry upon entry
into a new cell
95: Semantically
incorrect message
96: Invalid mandatory
information
97: Message type nonexistent or not
implemented
98: Message type not
compatible with the
protocol state
99: Information
element non-existent or
not implemented
100: Conditional IE
error
101: Message not
compatible with the
protocol state
111: Protocol error,
unspecified
Other values received
by a mobile terminal:
The reject cause value
is same as reject
cause value 34.
Other values received
by the network side:
The reject cause value
is same as reject
cause value 111.
For details, see 9.4.16 "Reject cause" in 3GPP TS 29.118 V11.3.0.

Service indicator
Reference Standards
Information Element
(IE)
Description
Example
Specifies the circuit switched

(CS) service type.
Value:
Service indicator
1: CS call indicator
2: SMS indicator
Other values: The
service is considered
as a CS voice call.
example.
In the message, serviceindicator-value is set to CS-callindicator (1), indicating that the
service is a CS voice call.
Reference Standards
For details, see 9.4.17 "Service indicator" in 3GPP TS 29.118 V11.3.0.
SGs Cause
Reference Standards
Information
Description
Element (IE)
Example
Specifies a failure
cause value.
Value:
SGs Cause
1: IMSI
detached for
EPS services
2: IMSI
detached for
EPS and nonEPS services
3: IMSI
unknown
4: IMSI
detached for
non-EPS
services
5: IMSI
implicitly
detached for
non-EPS
services
6: UE
unreachable
7: Message An SGsAP-PAGING-REJECT is used as an example.
In the message, sgs-cause-value is set to mobilenot
terminating-cs-fallback-call-rejected-by-the-user (13),
compatible
indicating that the SGs paging during a voice call fails
with the
protocol state because the Circuit Switched Fallback (CSFB)
subscriber rejects the call.
8: Missing
mandatory
information
element
9: Invalid
mandatory
information
10:
Conditional
information
element error
11:
Semantically
incorrect
message
12: Message
unknown
13: Mobile
terminating
CS fallback
call rejected
by the user
Reference Standards
For details, see 9.4.18 "SGs cause" in 3GPP TS 29. 118 V11.3.0.
TAI
Reference Standards
Information Element
(IE)
Description
Example
Tracking Area Identity

(TAI)
Uniquely identifies the tracking

area (TA) where a subscriber
locates. The TAI IE contains the
PLMN ID and tracking area
code (TAC).
An SGsAP-SERVICEREQUEST message is used as

an example.
In the message, plmn specifies
the ID of PLMN to which a
subscriber belongs, and tac
identifies the TA where the
subscriber locates.
Reference Standards
For details, see 9.4.21a "Tracking Area Identity" in 3GPP TS 29.118 V11.3.0.
TMSI
Reference Standards
Information Element
(IE)
TMSI
Description
Example
Specifies the TMSI that is used An SGsAP-PAGING-REQUEST

by a mobile terminal to
example. In the message tmsitemporarily identify itself.
body specifies a subscriber's
TMSI.
Reference Standards
For details, see 9.4.20 "TMSI" in 3GPP TS 29.118 V11.3.0.
TMSI status
Reference Standards
Information Element
(IE)
TMSI status
Description
Example
Notifies the MSC server/VLR

that whether a valid TMSI is
available.
Value of TMSI flag in the TMSI
status IE:
An SGsAP-LOCATIONUPDATE-REQUEST message is
used as an example.
In the message, tmsi-flag is set
0: no valid TMSI
to tmsi-flag-false (0), indicating
available
that a subscriber does not have
1: valid TMSI available
a valid TMSI.
Reference Standards
For details, see 9.4.21 "TMSI status" in 3GPP TS 29.118 V11.3.0.
UE EMM Mode
Reference Standards
Information Element
(IE)
Description
Example
Specifies the UE's EPS mobility

management (EMM) status
when the mobility management
entity (MME) notifies the MSC
server/VLR that the UE has
received an SGsAP-PAGINGREQUEST message.
Value:
0: EMM-IDLE
1: EMM-CONNECTED message is used as an
UE EMM (EPS Mobility
Management) Mode
If the MSC server/VLR receives example. In the message, uean SGsAP-SERVICE-REQUEST emm-mode-value is set to emmidle (0), indicating that the UE is
message in which UE EMM
Mode is not set to EMM-IDLE in the EMM-IDLE state.
or EMM-CONNECTED, the
MSC server can send an
SGsAP-STATUS message to the
MME. Bit 2 of P1149 determines
whether the MSC server/VLR
sends an SGsAP-STATUS
message to the MME.
Reference Standards
For details, see 9.4.21c "UE EMM mode" in 3GPP TS 29.118 V11.3.0.
UE Time Zone
Reference Standards
Information Element
(IE)
Description
UE Time Zone
Specifies the offset between the

Greenwich Mean Time (GMT)
and local time in steps of 15
minutes.
If the MME can obtain time zone An SGsAP-SERVICEinformation, it includes the UE REQUEST message is used as
Time Zone IE in SGsAPan example.
SERVICE-REQUEST and
time-zone is set to 0x0,
indicating that the offset
messages sent to the MSC
between the GMT and local
server, ensuring that the MSC
time is zero.
server correctly generates call
detail records (CDRs) during
calls.
Example
Reference Standards
For details, see 9.4.21b "UE Time Zone" in 3GPP TS 29. 118 V11.3.0.
VLR name
Reference Standards
Information
Element
Description
(IE)
Specifies the domain name of a visited location register (VLR).
VLR name An SGsAP-PAGING-REQUEST message is used as an example.
Reference Standards
For details, see 9.4.22 "VLR name" in 3GPP TS 29.118 V11.3.0.

MSOFTX3000 V200R010C10 Typical Signaling Flows User Manual 01 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

MSOFTX3000 V200R010C10 Typical Signaling Flows User Manual 01 PDF

Transféré par

Droits d'auteur :

Formats disponibles

Typical Signaling Flows User Manual

Basic 3G Call Flow

MAP_PROVIDE_ROAMING_NUMBER_RSP message carrying the MSRN to the

26. The caller and the callee start the conversation.

MO try call times

Wrong Dialing Times

Total Traffic of the

MSC Basic Services

MSC Basic Functions

MSC Basic Services

MSC Basic Functions

Call Completion Times Intra-MSC Calls

Total Traffic of the

Table 2 Measurement points on the terminating side

MSC Basic Services

MSC Basic Services

MSC Basic Services

MSC Basic Functions

LAI paging times (LAI)

MSC Basic Services

MSC Basic Services

MSC Basic Services

MSC Basic Functions

Total Traffic of the

Total Traffic of the

Parent topic: Intra-MSC Calls

Basic 2G Call Flow

P1, P2, P3, P4, P5, P6, P7

MO try call times

MSC Basic Services

MSC Basic Functions

MSC Basic Services

MSC Basic Functions

Wrong Dialing Times

Call Completion Times Intra-MSC Calls

Total Traffic of the

Average Call Setup

Total Traffic of the

Table 2 Measurement points on the terminating side

MSC Basic Services

MSC Basic Services

MSC Basic Services

MSC Basic Functions

LAI paging times (LAI)

MSC Basic Services

MSC Basic Services

MSC Basic Services

MSC Basic Functions

Total Traffic of the

Call Completion Times Directions

Total Traffic of the

Total Traffic of the

Parent topic: Intra-MSC Calls

Inter-MSC Call Flow (PRA)

Inter-MSC Call Flow (MS -> UE)

Total Traffic of the

Call Completion Times Outgoing Calls

Total Traffic of the

Total Traffic of the

Table 2 Measurement points on the terminating side

Total Traffic of the

Total Traffic of the

Total Traffic of the