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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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. A 2G mobile subscriber calls another 2G mobile subscriber served by the same 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Basic 3G Call Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 3G mobile subscriber calls another 3G mobile subscriber served by the same 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 Description of the Signaling Flow 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). Description of Associated Measurement Entities 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

Total Traffic of the 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 Total Traffic of the Originated Calls Office Total Traffic of the Intra-MSC Calls Office Traffic Measurement Global Components For LAI UTRAN Subscriber Total Traffic of the Originated Calls Office

Table 2 Measurement points on the terminating side Measurement Point Measurement Entity Measurement Unit 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

Total Traffic of the Office Total Traffic of the Office

UTRAN Subscriber Terminated Calls

Total Traffic of the Office

Global Components Total Traffic of the Office Global Components

Parent topic: Intra-MSC Calls Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Basic 2G Call Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 2G mobile subscriber calls another 2G mobile subscriber served by the same 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 2G call. Figure 1 Intra-MSC call flow

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, P7 Callee: Q1, Q2, Q3, Q4, Q5 Description of the Signaling Flow 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. 18. The MGW returns a MOD REPLY message to the MSC/VLR and plays the 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. 21. The MGW returns a MOD REPLY message to the MSC/VLR and stops playing 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. 24. The caller and the callee start the conversation. 25. After a period of time, the MS-O starts the call release flow. For details, see Bearer Release Flow (TDM-enabled A Interface). Description of Associated Measurement Entities

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

P1

Call Attempts

GSM Subscriber Originated Calls

MO try call times (LAI)

Traffic Measurement Global Components For LAI Total Traffic of the 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 Call Completion Times Originated Calls Wrong Dialing Times

Call Completion Times Intra-MSC Calls P6

P7

Total Traffic of the 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 Total Traffic of the Office Total Traffic of the 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

Total Traffic of the Office

Table 2 Measurement points on the terminating side Measurement Point Measurement Entity Measurement Unit 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

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

Total Traffic of the Office Bearer Traffic Total Traffic of the 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

Total Traffic of the Office

GSM Subscriber Terminated Calls

Total Traffic of the Office

Answer Times 2G TERMINATED CALL ESTABLISH AVERAGE TIME

Parent topic: Intra-MSC Calls Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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) Parent topic: Voice Services Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Inter-MSC Call Flow (MS -> UE) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 2G mobile subscriber calls a 3G mobile subscriber. Early assignment is applied in the call. 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 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 Callee: Q1, Q2, Q3, Q4 Description of the Signaling Flow 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. Description of Associated Measurement Entities

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 Seizure Times

Outgoing Traffic in Trunk Office Directions

Bearer Traffic

Seizure Times

Outgoing Calls

Total Traffic of the Office

Alerting Message Received Times

Outgoing Traffic in Trunk Office Directions

Bearer Traffic

P1

P2

Measurement Type

Call Completion Times Outgoing Calls

Total Traffic of the Office

Answer Times

Outgoing Traffic in Trunk Office Directions

Bearer Traffic

Answer Times

Outgoing Calls

Total Traffic of the Office

P3

Table 2 Measurement points on the terminating side Measurement Point Measurement Entity Measurement Unit in Flowchart Seizure Times

Incoming Traffic in Trunk Office Directions

Bearer Traffic

Seizure Times

Incoming Calls

Total Traffic of the Office

3G TERMINATED CALL_ATTEMPT

UTRAN Subscriber Terminated Calls

Total Traffic of the 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

Total Traffic of the Office Total Traffic of the Office Global Components Total Traffic of the

Q3

Q4

ALERT

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

Parent topic: Inter-MSC Calls Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Inter-MSC Call Flow (MS -> PSTN) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 2G mobile subscriber calls a public switched telephone network (PSTN) subscriber. Early assignment is applied in the call. ISDN user part (ISUP) signaling is used between the MSCs. 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. Description of the Signaling Flow 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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 Total Traffic of the Office Total Traffic of the Office

Traffic Measurement Global Components For LAI GSM Subscriber Originated Calls Outgoing Traffic in Trunk Office Directions Outgoing Calls

Total Traffic of the Office Bearer Traffic Total Traffic of the Office

Alerting Message Received Times

P3

Call Completion Times Outgoing Calls Call Completion Times 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

Parent topic: Inter-MSC Calls Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Bearer Traffic Total Traffic of the Office Total Traffic of the Office Total Traffic of the Office Bearer Traffic Total Traffic of the Office Total Traffic of the Office Total Traffic of the Office Global Components Bearer Traffic Total Traffic of the Office

Inter-MSC Call Flow (UE -> UE, BICC Forward Fast Mode) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 3G mobile subscriber calls another 3G mobile subscriber served by different MSCs. Early assignment is applied in the call. 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

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 Callee: Q1, Q2, Q3, Q4 Description of the Signaling Flow 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. 18. MSC-T replies with a NTFY REPLY message. 19. MGW-O sends a NTFY REQ message to MSC-O, reporting the bearer establishment event on the caller side. 20. MSC-O replies with a NTFY REPLY message. 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. 26. MGW-T replies with a MOD REPLY message, indicating that the ringback tone is 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 Bearer Release Flow (ATM-enabled Iu Interface). 36. Bearer release on the RAN side of the callee is similar with that on the RAN side of the caller. Description of Associated Measurement Entities 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 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 Total Traffic of the Office Total Traffic of the Office

Traffic Measurement Global Components For LAI UTRAN Subscriber

Total Traffic of the

Seizure Times P2

Originated Calls Outgoing Traffic in Trunk Office Outgoing Calls

Total Traffic of the 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 Call Completion Times Mobile Office Directions Outgoing Traffic in Answer Times Trunk Office Call Completion Times

Answer Times Answer Times

P4

Bearer Traffic

Seizure Times

Call Completion Times Outgoing Calls

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

Total Traffic of the Office Total Traffic of the Office Total Traffic of the Office Global Components Bearer Traffic Bearer Traffic Total Traffic of the Office Total Traffic of the Office Total Traffic of the Office Global Components Bearer Traffic Total Traffic of the Office

Table 2 Measurement points on the terminating side Measurement Point Measurement Entity Measurement Unit in Flowchart

Measurement Type

Q1

Q2

Seizure Times

Incoming Calls

Total Traffic of the Office

3G TERMINATED CALL_ATTEMPT

UTRAN Subscriber Terminated Calls

Total Traffic of the 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

Call Completion Times Incoming Calls 3G TERMINATED ANSWER MT response times (LAI) 3G TERMINATED CALL ESTABLISH AVERAGE TIME Q4

3G INCOMING ANSWER Answer Times Answer Times

Total Traffic of the Office Global Components Total Traffic of the Office Bearer Traffic Total Traffic of the Office Total Traffic of the Office

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

Total Traffic of the Office

UTRAN Subscriber Total Traffic of the Terminated Incoming Office Calls Incoming Traffic in Trunk Office Bearer Traffic Directions Total Traffic of the Incoming Calls Office

Parent topic: Inter-MSC Calls Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Inter-MSC Call Flow (UE -> UE, BICC Forward Slow Mode) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 3G mobile subscriber calls another 3G mobile subscriber served by different MSCs. Early assignment is applied in the call. Bearer Independent Call Control (BICC) signaling is used between the MSCs. The call is established in forward slow 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

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 Callee: Q1, Q2, Q3, Q4 Description of the Signaling Flow 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 wait for follow-up messages. 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. 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. 6. MGW-T replies with an ADD REPLY message containing the termination information. 7. Bearer establishment on the RAN side of the callee is similar with that on the RAN 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).

10. MGW-O replies with a MOD REPLY message. 11. 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). 12. MSC-O replies with a NTFY REPLY message. 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. 16. 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). 17. MSC-T replies with a NTFY REPLY message. 18. 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 APM (Receiving bCI). 19. 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). 20. MGW-O replies with a MOD REPLY message. 21. MGW-O sends a TRC_IU/NB_UP_INIT_TOIP message to MGW-T, starting NB_UP initiation. 22. MGW-T replies with a TRC_IU/NB_UP_ACK_FRMIP message. 23. MGW-T sends a NTFY REQ message to MSC-T, reporting the bearer establishment event on the callee side. 24. MSC-T replies with a NTFY REPLY message. 25. MGW-O sends a NTFY REQ message to MSC-O, reporting the bearer establishment event on the caller side. 26. MSC-O replies with a NTFY REPLY message. 27. 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. 28. MSC-T sends a MOD REQ message containing signalsDescriptor to MGW-T, instructing MGW-T to play the ringback tone. 29. MGW-T replies with a MOD REPLY message, indicating that the ringback tone is played. 30. After the callee answers the phone, MSC-T sends an ANM message to MSC-O. 31. MSC-T sends a MOD REQ message to MGW-T, instructing MGW-T to stop playing the ringback tone. 32. MGW-T replies with a MOD REPLY message, indicating that the ringback tone is stopped. 33. 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. 34. 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. 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. 36. MSC-O replies with a Radio Link Control (RLC) message, releasing bearer resources. 37. MSC-O sends a SUB REQ message to MGW-O, instructing MGW-O to release termination resources on the CN side of the caller. 38. MGW-O replies with a SUB REPLY message. 39. MSC-T sends a SUB REQ message to MGW-T, instructing MGW-T to release termination resources on the CN side of the callee. 40. MGW-T replies with a SUB REPLY message. 41. Bearer resources are released on the RAN side of the caller. For details, see Bearer Release Flow (ATM-enabled Iu Interface). 42. Bearer release on the RAN side of the callee is similar with that on the RAN side of the caller. Description of Associated Measurement Entities 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 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

Total Traffic of the Office

Total Traffic of the Office Bearer Traffic

Seizure Times

Outgoing Calls

Total Traffic of the 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 Call Completion Times Mobile Office Directions Outgoing Traffic in Answer Times Trunk Office Call Completion Times

Answer Times Answer Times

P4

Total Traffic of the Office

Traffic Measurement Global Components For LAI

Call Completion Times Outgoing Calls

P3

Measurement Type

3G OUTGOING ANSWER

Outgoing Calls UTRAN Subscriber Originated Calls UTRAN Subscriber Originated Outgoing Calls

Total Traffic of the Office Total Traffic of the Office Total Traffic of the Office Global Components Bearer Traffic Bearer Traffic Total Traffic of the Office Total Traffic of the Office Total Traffic of the 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 Total Traffic of the Office

Table 2 Measurement points on the terminating side Measurement Point Measurement Entity Measurement Unit in Flowchart

Measurement Type

Q1

Q2

Q3

Seizure Times

Incoming Calls

Total Traffic of the Office

3G TERMINATED CALL_ATTEMPT

UTRAN Subscriber Terminated Calls

Total Traffic of the 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 Call Completion Times Incoming Calls 3G TERMINATED ANSWER MT response times (LAI) 3G TERMINATED CALL ESTABLISH AVERAGE TIME

Q4

3G INCOMING ANSWER

Total Traffic of the Office Total Traffic of the Office Global Components Total Traffic of the Office Bearer Traffic Total Traffic of the Office Total Traffic of the Office

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

Total Traffic of the Office

UTRAN Subscriber Total Traffic of the Terminated Incoming Office Calls

Answer Times

Incoming Traffic in Trunk Office Directions

Bearer Traffic

Answer Times

Incoming Calls

Total Traffic of the Office

Parent topic: Inter-MSC Calls Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Inter-MSC Call Flow (UE -> UE, BICC Backward Slow Mode) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 3G mobile subscriber calls another 3G mobile subscriber served by different MSCs. Early assignment is applied in the call. Bearer Independent Call Control (BICC) signaling is used between the MSCs. The call is established in backward slow 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

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 Callee: Q1, Q2, Q3, Q4 Description of the Signaling Flow 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 wait for follow-up messages. 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. 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. 6. MGW-T replies with an ADD REPLY message containing the termination information. 7. Bearer establishment on the RAN side of the callee is similar with that on the RAN 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). 9. MGW-T replies with a MOD REPLY message. 10. MGW-T sends a NTFY REQ message to MSC-T, 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). 11. MSC-T replies with a NTFY REPLY message. 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 APM (Initiating bCI). 13. MSC-O sends a MOD REQ message containing the bearer information that is carried in the APM message to MGW-O, transparently sending the tunnel request message sent by MGW-T. For details about the tunnel request message, see the bT-BearInfoTrans in MOD REQ (bT). 14. MGW-O replies with a MOD REPLY message. 15. MGW-O sends a NTFY REQ message to MSC-O, 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). 16. MSC-O replies with a NTFY REPLY message. 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 acceptance message, see the bT-BearInfoTrans in MOD REQ (bT). 19. MGW-T replies with a MOD REPLY message. 20. MGW-O sends a TRC_IU/NB_UP_INIT_TOIP message to MGW-T, starting NB_UP initiation. 21. MGW-T replies with a TRC_IU/NB_UP_ACK_FRMIP message. 22. MGW-T sends a NTFY REQ message to MSC-T, reporting the bearer establishment event on the callee side. 23. MSC-T replies with a NTFY REPLY message. 24. MGW-O sends a NTFY REQ message to MSC-O, reporting the bearer establishment event on the caller side. 25. MSC-O replies with a NTFY REPLY message. 26. 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.

27. MSC-T sends a MOD REQ message containing signalsDescriptor to MGW-T, instructing MGW-T to play the ringback tone. 28. MGW-T replies with a MOD REPLY message, indicating that the ringback tone is played. 29. After the callee answers the phone, MSC-T sends an ANM message to MSC-O. 30. MSC-T sends a MOD REQ message to MGW-T, instructing MGW-T to stop playing the ringback tone. 31. MGW-T replies with a MOD REPLY message, indicating that the ringback tone is stopped. 32. 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. 33. 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. 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 release cause value. 35. MSC-O replies with a Radio Link Control (RLC) message, releasing bearer resources. 36. MSC-O sends a SUB REQ message to MGW-O, instructing MGW-O to release termination resources on the CN side of the caller. 37. MGW-O replies with a SUB REPLY message. 38. MSC-T sends a SUB REQ message to MGW-T, instructing MGW-T to release termination resources on the CN side of the callee. 39. MGW-T replies with a SUB REPLY message. 40. Bearer resources are released on the RAN side of the caller. For details, see Bearer Release Flow (ATM-enabled Iu Interface). 41. Bearer release on the RAN side of the callee is similar with that on the RAN side of the caller. Description of Associated Measurement Entities 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 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

Total Traffic of the Office

Total Traffic of the Office Bearer Traffic

Seizure Times

Outgoing Calls

Total Traffic of the 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 Call Completion Times Mobile Office Directions Outgoing Traffic in Answer Times Trunk Office Call Completion Times

Answer Times Answer Times

P4

Total Traffic of the Office

Traffic Measurement Global Components For LAI

Call Completion Times Outgoing Calls

P3

Measurement Type

3G OUTGOING ANSWER MO response times

Outgoing Calls

Total Traffic of the Office Total Traffic of the Office Total Traffic of the Office Global Components Bearer Traffic Bearer Traffic Total Traffic of the Office Total Traffic of the Office

UTRAN Subscriber Originated Calls UTRAN Subscriber Total Traffic of the 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

Total Traffic of the Office

Table 2 Measurement points on the terminating side Measurement Point Measurement Entity Measurement Unit in Flowchart

Measurement Type

Q1

Q2

Q3

Seizure Times

Incoming Calls

Total Traffic of the Office

3G TERMINATED CALL_ATTEMPT

UTRAN Subscriber Terminated Calls

Total Traffic of the 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 Call Completion Times Incoming Calls 3G TERMINATED ANSWER MT response times (LAI) 3G TERMINATED CALL ESTABLISH AVERAGE TIME

Q4

3G INCOMING ANSWER

Total Traffic of the Office Total Traffic of the Office Global Components Total Traffic of the Office Bearer Traffic Total Traffic of the Office Total Traffic of the Office

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

Total Traffic of the Office

UTRAN Subscriber Total Traffic of the Terminated Incoming Office Calls

Answer Times

Answer Times

Incoming Traffic in Trunk Office Directions Incoming Calls

Parent topic: Inter-MSC Calls Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Bearer Traffic Total Traffic of the Office

Inter-MSC Call Flow (SIP UE->SIP UE) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 3G mobile subscriber calls another 3G mobile subscriber served by a different mobile switching center (MSC) server. Early assignment is applied in the call. 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 shows the signaling flow of an inter-MSC call between two 3G mobile subscribers.

Figure 1 Signaling Flow 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. Originating party: P1; P2; P3; P4 Terminating party: Q1; Q2; Q3; Q4 Description of the Signaling Flow

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. Description of Associated Measurement Entities Table 1 lists common measurement entities used on the originating side. Table 1 Measurement points on the originating side Measurement Point Measurement Entity Measurement Unit in Flowchart UTRAN Subscriber Originated Calls 3G OUTGOING CALL UTRAN Subscriber Call Attempts

Measurement Type Total Traffic of the Office Total Traffic of the

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

Total Traffic of the Office Bearer Traffic

Outgoing Calls

Total Traffic of the 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 Call Completion Times Mobile Office Directions Outgoing Traffic in Answer Times Trunk Office Directions Call Completion Times

Answer Times Answer Times P4

Global Components

Seizure Times

Call Completion Times Outgoing Calls

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

Total Traffic of the Office Total Traffic of the Office Total Traffic of the Office Global Components Bearer Traffic

Bearer Traffic Total Traffic of the Office Total Traffic of the Office Total Traffic of the Office Global Components Bearer Traffic

Average Call Setup Time

UTRAN Subscriber Originated Calls

Total Traffic of the Office

Table 2 Measurement points on the terminating side Measurement Point Measurement Entity Measurement Unit in Flowchart

Measurement Type

Q1

Q2

Q3

Seizure Times

Incoming Calls

Total Traffic of the Office

3G TERMINATED CALL_ATTEMPT

UTRAN Subscriber Terminated Calls

Total Traffic of the 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 Call Completion Times Incoming Calls 3G TERMINATED ANSWER MTC Answer Times (LAI) 3G TERMINATED CALL ESTABLISH AVERAGE TIME

Q4

3G INCOMING ANSWER CMN Answer Times Answer Times

Total Traffic of the Office Total Traffic of the Office Global Components Total Traffic of the Office Bearer Traffic Total Traffic of the Office Total Traffic of the Office

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

Total Traffic of the Office

UTRAN Subscriber Total Traffic of the Terminated Incoming Office Calls Incoming Traffic in Trunk Office Bearer Traffic Directions Total Traffic of the Incoming Calls Office

Parent topic: Inter-MSC Calls Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Inter-MSC Call Flow (PRA) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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.

Description of the Signaling Flow 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. 6. The caller and the callee start the conversation. 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. Description of Associated Measurement Entities Table 1 lists common measurement entities.

Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit in Flowchart Seizure Times

Outgoing Traffic in Trunk Office Directions

Bearer Traffic

Seizure Times

Outgoing Calls

Total Traffic of the Office

Alerting Message Received Times

Outgoing Traffic in Trunk Office Directions

Bearer Traffic

P1

P2

Measurement Type

Call Completion Times Outgoing Calls

Total Traffic of the Office

Answer Times

Outgoing Traffic in Trunk Office Directions

Bearer Traffic

Answer Times

Outgoing Calls

Total Traffic of the Office

P3

Parent topic: Inter-MSC Calls Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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) Parent topic: Voice Services Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Bearer Establishment Flow (TDM-enabled A Interface) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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. Description of the Signaling Flow 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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

Total Traffic of the Office

Parent topic: Bearer Establishment and Release Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Bearer Traffic

Bearer Establishment Flow (IP-enabled A Interface) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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. Description of the Signaling Flow

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 SETUP COMPLETE message. 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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

Total Traffic of the Office

Parent topic: Bearer Establishment and Release Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Bearer Traffic

Bearer Establishment Flow (ATM-enabled Iu Interface) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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) in non-peer-to-peer mode. That is, the MSC connects to the MGW over 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. Description of the Signaling Flow 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 SETUP COMPLETE message. 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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 WCDMA Assignment MSC Basic Services Channel Assignments

P6

Assignment Failure due to IUUP Failure

WCDMA Assignment MSC Basic Services

Average Duration of WCDMA Channel Assignment

WCDMA Assignment MSC Basic Services UTRAN Subscriber

Total Traffic of the

Assignment Failures

Originated Calls

Office

Assignment Failures

Incoming Calls in Mobile Office

Bearer Traffic

Parent topic: Bearer Establishment and Release Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Bearer Establishment Flow (IP-enabled Iu Interface) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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 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 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. Description of the Signaling Flow 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 SETUP COMPLETE message. 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. 8. The MGW sends a NTFY REQ message to the MSC, informing the MSC of the bearer establishment event. 9. The MSC replies with a NTFY REPLY message. 10. The RNC replies with a RAB ASSIGNMENT RESPONSE message, indicating that the RAB assignment is complete. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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 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 WCDMA Assignment MSC Basic Services Channel Assignments

P6

Assignment Failure due to IUUP Failure

WCDMA Assignment MSC Basic Services

Average Duration of WCDMA Channel Assignment

WCDMA Assignment MSC Basic Services

Assignment Failures Assignment Failures

UTRAN Subscriber Originated Calls Incoming Calls in Mobile Office

Parent topic: Bearer Establishment and Release

Total Traffic of the Office Bearer Traffic

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Bearer Release Flow (TDM-enabled A Interface) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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 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. Description of the Signaling Flow 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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

Parent topic: Bearer Establishment and Release Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Signaling and Interfaces

Bearer Release Flow (IP-enabled A Interface) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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 release (IP-enabled A interface). Figure 1 Signaling flow of bearer release (IP-enabled A interface)

As shown in Figure 1, P1 and P2 refer to the measurement points. Description of the Signaling Flow 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 Disconnect message to the MSC. 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 termination resources. 7. The MGW replies with a SUB REPLY message, indicating that IP termination resources are successfully released. 8. The MGW sends a NTFY REQ message to the MSC, informing the MSC of the bearer release event. 9. The MSC replies with a NTFY REPLY message. 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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

Parent topic: Bearer Establishment and Release Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Bearer Release Flow (ATM-enabled Iu Interface) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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) in non-peer-to-peer mode. That is, the MSC connects to the MGW over 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)

As shown in Figure 1, P1 and P2 refer to the measurement points. Description of the Signaling Flow 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 Disconnect message to the MSC. 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 termination resources. 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, which actively sends a Release message to request the release of radio resources. Later, 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 releases the call first. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point

in Flowchart

P1

P2

Measurement Entity Measurement Unit

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

Parent topic: Bearer Establishment and Release Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Bearer Release Flow (IP-enabled Iu Interface) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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 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 release (IP-enabled Iu interface). Figure 1 Signaling flow of bearer release (IP-enabled Iu interface)

As shown in Figure 1, P1 and P2 refer to the measurement points. Description of the Signaling Flow 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 Disconnect message to the MSC. 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 termination resources. 7. The MGW replies with a SUB REPLY message, indicating that IP termination resources are successfully released. 8. The MGW sends a NTFY REQ message to the MSC, informing the MSC of the bearer release event. 9. The MSC replies with a NTFY REPLY message. NOTE: After the UE releases the call, the MSC sends a Disconnect message to the peer UE, which actively sends a Release message to request the release of radio resources. Later, 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 releases the call first. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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

Parent topic: Bearer Establishment and Release Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Short Message Services SMMO SMMT Short Message Notification Parent topic: Basic Services Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

SMMO Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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 As shown in Figure 1, P1, P2, P3, P4 refers to the measurement points. Description of the 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point

in Flowchart

Measurement Entity Measurement Unit 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

SMMO Failures due to Short Message Protocol Data Errors Service

MSC Basic Services

SMMO Failures due to Short Message MO Service Barring Service

MSC Basic Services

SMMO Failures due to Short Message Unknown SMC Service

MSC Basic Services

SMMO Failures due to Short Message Invalid short message Service (SM) Entity Address

MSC Basic Services

SMMO Failures due to Short Message 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Parent topic: Short Message Services Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

SMMT Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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. Description of the Signaling Flow

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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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

LAI paging times (LAI)

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

SMMT Failures due to Short Message Illegal Subscribers Service

MSC Basic Services

SMMT Failures due to Short Message 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Parent topic: Short Message Services Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Flow of Notifying the SMC that a UE/MS Is Reachable Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

Description of the Signaling Flow 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. Description of Associated Measurement Entities None. Parent topic: Short Message Notification Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Flow of Notifying the SMC that the Memory of a UE/MS Is Usable Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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. Description of the Signaling Flow 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit in Flowchart P1 P2

Short Message Service Short Message SMMA Success Times Service SMMA Attempts

Parent topic: Short Message Notification Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Measurement Type MSC Basic Services MSC Basic Services

Fax Services Intra-MSC TS61 Fax Service Flow Inter-MSC TS61 Fax Service Flow Intra-MSC TS62 Fax Service Flow Inter-MSC TS62 Fax Service Flow Parent topic: Basic Services Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Intra-MSC TS61 Fax Service Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 2G mobile subscriber calls another 2G mobile subscriber served by the same MSC. Early assignment is applied in the call. 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. Description of the Signaling Flow 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. 10. After modifying the service type successfully, the MGW returns a MOD REPLY message to the MSC. 11. The MSC sends an ASSIGNMENT REQUEST message carrying CHANNEL 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 ASSIGNMENT COMPLETE message to the MSC. 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit in Flowchart P1

Alternate Speech/Data Bearer Service Applied Times

Parent topic: Fax Services Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Measurement Type MSC Special Services

Inter-MSC TS61 Fax Service Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 2G mobile subscriber calls a public switched telephone network (PSTN) subscriber. Early assignment is applied in the call. Time division multiplexing (TDM) bearer is used between the BSC and the MGW. ISDN user part (ISUP) signaling is used between the MSCs. 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

As shown in Figure 1, P1 refers to the measurement point. Description of the 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. 4. After modifying the service type successfully, the MGW returns a MOD REPLY 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. 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 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 ASSIGNMENT COMPLETE message to the MSC. 9. The MSC returns a MODIFY COMPLETE message to the MS-O. 10. The MSC sends a MOD REQ message, requesting the MGW to activate interworking function (IWF) and start bottom-layer negotiation. 11. The MGW returns a MOD REPLY message. 12. The MGW sends an NTFY REQ message to the MSC to report the bottom-layer negotiation result. 13. The MSC returns an NTFY REPLY message to the MGW. 14. The MS-O starts sending the fax, and the MS-T starts receiving the fax. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit in Flowchart P1

Alternate Speech/Data Bearer Service Applied Times

Parent topic: Fax Services Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Measurement Type MSC Special Services

Intra-MSC TS62 Fax Service Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 2G mobile subscriber calls another 2G mobile subscriber served by the same MSC. Early assignment is applied in the call. 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. 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

As shown in Figure 1, P1 refers to the measurement point. Description of the 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. 10. The MSC sends a MOD REQ message, requesting the MGW to activate interworking function (IWF) and start bottom-layer negotiation. 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. 13. The MGW sends an NTFY REQ message to the MSC to report the bottom-layer negotiation result. 14. Upon receipt of the NTFY REQ message, the MSC returns an NTFY REPLY message to the MGW. 15. The MS-O starts sending the fax, and the MS-T starts receiving the fax. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit in Flowchart P1

Alternate Speech/Data Bearer Service Applied Times

Parent topic: Fax Services Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Measurement Type MSC Special Services

Inter-MSC TS62 Fax Service Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 2G mobile subscriber calls a 2G mobile subscriber served by another MSC. Early assignment is applied in the call. Time division multiplexing (TDM) bearer is used between the BSC and the MGW. 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

As shown in Figure 1, P1, P2, P3 refers to the measurement points. Description of the 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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

MSC Special Services

P3

Parent topic: Fax Services Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Supplementary Services Basic Operations Number Presentation Call Completion Multi Party SS (MPTY) Call Forwarding USSD Call Restriction Parent topic: Typical Signaling Flows User Manual Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 server during location update.

The supplementary services are registered.

The supplementary services are subscribed on the HLR and the HLR brings the service status to the MSC server during location 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 server during location update.

The supplementary services are subscribed on the The supplementary HLR and the HLR services are provided. brings the service status to the MSC server during location update. The supplementary services are subscribed on the HLR and the HLR brings the service status to the MSC server during location 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 server during location 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 server during location 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Supplementary Service Registration Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

As shown in Figure 1, P1 refers to the measurement point. Description of the Signaling Flow 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Supplementary Service Activation Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

As shown in Figure 1, P1 refers to the measurement point. Description of the Signaling Flow The signaling flow of supplementary service activation 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 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit in Flowchart

Measurement Type

Mobile Application Illegal Supplementary Signaling and Part (MAP) Standard Service Operation Interfaces Operations Supplementary Service Status Error 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

Parent topic: Basic Operations Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Interfaces

Supplementary Service Deactivation Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

As shown in Figure 1, P1 refers to the measurement point. Description of the Signaling Flow The signaling flow of supplementary service deactivation 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 MAP_DEACTIVATE_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 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 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 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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 Service Subscription Violation

MAP Standard Operations

Signaling and Interfaces

Parent topic: Basic Operations

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Supplementary Service Query Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

As shown in Figure 1, P1 refers to the measurement point. Description of the Signaling Flow The signaling flow of supplementary service query 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 MAP_INTERROGATE_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 queried.

4. The HLR queries the related information and returns a MAP_INTERROGATE_SS_RSP message to the MSC/VLR. The MSC/VLR transparently forwards this message to the UE/MS. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit in Flowchart

P1

Measurement Type

Mobile Application Illegal Supplementary Signaling and Part (MAP) Standard Service Operation Interfaces Operations Supplementary Service Unavailable

MAP Standard Operations

Parent topic: Basic Operations Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Signaling and Interfaces

Supplementary Service Deregistration Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

As shown in Figure 1, P1 refers to the measurement point. Description of the Signaling Flow The signaling flow of supplementary service deregistration 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

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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit in Flowchart

P1

Measurement Type

Illegal Supplementary MAP Standard Service Operation Operations

Signaling and Interfaces

Supplementary Service Status Error

Signaling and Interfaces

MAP Standard Operations

Parent topic: Basic Operations Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Parent topic: Supplementary Services Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

CLIP Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 3G mobile subscriber calls another 3G mobile subscriber served by the same 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 As shown in Figure 1, P1 refers to the measurement point. Description of the 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

CLIR Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 3G mobile subscriber calls another 3G mobile subscriber served by the same 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 As shown in Figure 1, P1 refers to the measurement point. Description of the 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

COLP Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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 As shown in Figure 1, P1 refers to the measurement point. Description of the 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 requests the Mobile Station International ISDN Number (MSISDN) and subscription data of the caller from the HLR. 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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 Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd.

COLR Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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 As shown in Figure 1, P1 refers to the measurement point. Description of the 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 requests the Mobile Station International ISDN Number (MSISDN) and subscription data of the caller from the HLR. 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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 Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd.

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 Parent topic: Supplementary Services Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

CH Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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 As shown in Figure 1, P1, P2, P3, P4 refers to the measurement points. Description of the 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit in Flowchart P1

Invocation of Supplementary Services

Supplementary Services

Measurement Type

Bearer Traffic

P2

Implement of Supplementary Supplementary Services Services Successfully

Bearer Traffic

P3

Invocation of Supplementary Services

Supplementary Services

Bearer Traffic

P4

Implement of Supplementary Supplementary Services Services Successfully

Bearer Traffic

Parent topic: Call Completion Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

CW Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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 As shown in Figure 1, P1, P2, P3 refers to the measurement points. Description of the 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit in Flowchart Invocation of Supplementary Services

Measurement Type

Supplementary Services

Bearer Traffic

Implement of Supplementary Supplementary Services Services Successfully

Bearer Traffic

P2

Invocation of Supplementary Services

Supplementary Services

Bearer Traffic

P3

Implement of Supplementary Supplementary Services Services Successfully

Bearer Traffic

P1

Parent topic: Call Completion Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

CW Failure Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

Description of the 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. Description of Associated Measurement Entities None. Parent topic: Call Completion Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Parent topic: Supplementary Services Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Flow of Originating an Multi Party SS (MPTY) by the Controlling Party Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

As shown in Figure 1, P1, P2 refers to the measurement points. Description of the Signaling Flow

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). Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit in Flowchart

Measurement Type

P1

Invocation of Supplementary Services

Supplementary Services

Bearer Traffic

P2

Implement of Supplementary Supplementary Services Services Successfully

Bearer Traffic

Parent topic: Multi Party SS (MPTY) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Flow of Holding an MPTY Call by the Controlling Party Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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. 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

Description of the Signaling Flow 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. Description of Associated Measurement Entities None. Parent topic: Multi Party SS (MPTY) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Flow of Activating a Held MPTY Call by the Controlling Party Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A and C are 3G mobile subscribers served by the same MSC. B and D are fixed-line subscribers. Subscriber A is the controlling party, and subscribes to the call hold (CH) service 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

Description of the Signaling Flow 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. Description of Associated Measurement Entities None. Parent topic: Multi Party SS (MPTY) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Flow of Adding a Remote Party to an MPTY Call Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A and C are 3G mobile subscribers served by the same MSC. B and D are fixed-line subscribers. Subscriber A is the controlling party, and subscribes to the call hold (CH) service and the multiparty (MPTY) service. 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

Description of the Signaling Flow 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. Description of Associated Measurement Entities None. Parent topic: Multi Party SS (MPTY) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Flow of Splitting an MPTY Call Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A and C are 3G mobile subscribers served by the same MSC. B and D are fixed-line subscribers. Subscriber A is the controlling party, and subscribes to the call hold (CH) service and the multiparty (MPTY) service. 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

Description of the Signaling Flow 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. Description of Associated Measurement Entities None. Parent topic: Multi Party SS (MPTY) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MPTY Call Failure Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A and C are 3G mobile subscribers served by the same MSC. B and D are fixed-line subscribers. 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 an MPTY call failure. Figure 1 Signaling flow of an MPTY call failure

Description of the Signaling Flow 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. Description of Associated Measurement Entities None. Parent topic: Multi Party SS (MPTY) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Parent topic: Supplementary Services Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

CFU Flow of Forwarding a Call to a Mobile Subscriber Flow of Forwarding a Call to a Fixed-Line Subscriber Parent topic: Call Forwarding Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Flow of Forwarding a Call to a Mobile Subscriber Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

As shown in Figure 1, P1, P2 refers to the measurement points. Description of the Signaling Flow 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit in Flowchart P1 P2

Call Forwarding Traffic Call Forwarding Forward Call Attempts Traffic Forward Call Attempts

Parent topic: CFU Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Measurement Type Total Traffic of the Office Total Traffic of the Office

Flow of Forwarding a Call to a Fixed-Line Subscriber Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

As shown in Figure 1, P1 refers to the measurement point. Description of the Signaling Flow The signaling flow of forwarding a call to a fixed-line 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 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit in Flowchart P1

Forward Call Attempts

Call Forwarding Traffic

Parent topic: CFU Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Measurement Type Total Traffic of the Office

CFB NDUB Flow UDUB Flow Parent topic: Call Forwarding Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

NDUB Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A and B are 3G mobile subscribers. Subscriber C is a fixed-line subscriber. 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 As shown in Figure 1, P1 refers to the measurement point. Description of the Signaling Flow The NDUB signaling flow 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. 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit in Flowchart P1

Forward Call Attempts

Call Forwarding Traffic

Parent topic: CFB Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Measurement Type Total Traffic of the Office

UDUB Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A and B are 3G mobile subscribers. Subscriber C is a fixed-line subscriber. 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 As shown in Figure 1, P1 refers to the measurement point. Description of the Signaling Flow The UDUB signaling flow 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. 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 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. 7. 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 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit in Flowchart P1

Forward Call Attempts

Call Forwarding Traffic

Parent topic: CFB Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Measurement Type Total Traffic of the Office

CFNRy Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A and B are 3G mobile subscribers. Subscriber C is a fixed-line subscriber. 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

As shown in Figure 1, P1 refers to the measurement point. Description of the Signaling Flow The CFNRy signaling flow 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. 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 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 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. 7. 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 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit in Flowchart P1

Forward Call Attempts

Parent topic: Call Forwarding

Call Forwarding Traffic

Measurement Type Total Traffic of the Office

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

CFNRc Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A and B are 3G mobile subscribers. Subscriber C is a fixed-line subscriber. 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

As shown in Figure 1, P1 refers to the measurement point. Description of the Signaling Flow The CFNRc signaling flow 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. 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 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. 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit in Flowchart P1

Forward Call Attempts

Call Forwarding Traffic

Parent topic: Call Forwarding Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Measurement Type Total Traffic of the 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) Parent topic: Supplementary Services Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

User-Initiated USSD Flow (MS->MSC) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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)

Description of the Signaling Flow 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

contained in the Facility parameter. Description of Associated Measurement Entities None. Parent topic: USSD Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

User-Initiated USSD Flow (MS->MSC->HLR) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A mobile subscriber originates an unstructured supplementary service data (USSD) 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)

Description of the Signaling Flow The signaling flow of the user-initiated USSD operation (MS->MSC->HLR) is as follows: 1. After the connection between the MSC/VLR and the MS is set up, the MS sends 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: 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 contained in the Facility parameter. Description of Associated Measurement Entities None. Parent topic: USSD Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

User-Initiated USSD Flow (MS->MSC->HLR->USSD Center) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A mobile subscriber originates an unstructured supplementary service data (USSD) 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) Description of the Signaling Flow The signaling flow of the user-initiated USSD operation (MS->MSC->HLR->USSD center) 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. 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. 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 transparently transfers the message to the USSD center through 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 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: 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 contained in the Facility parameter. Description of Associated Measurement Entities None. Parent topic: USSD

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

USSD Center-Initiated USSD Flow (USSD Center->HLR>MSC->MS) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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) Description of the Signaling Flow 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. 3. The MS returns a Facility message to the MSC/VLR. The message contains the response to the USSD service request. 4. The MSC/VLR maps the response in the Facility message to the MAP_UNSTRUCTURED_SS_REQUEST_RSP message, and then transparently transfers the message to the USSD center through the HLR. 5. If the MS is required to perform other USSD operations, steps 1 to 4 are 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. Description of Associated Measurement Entities None. Parent topic: USSD Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Parent topic: Supplementary Services

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

BAOC Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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 As shown in Figure 1, P1 refers to the measurement point. Description of the 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.

Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit in Flowchart

P1

Measurement Type Total Traffic of the Office Total Traffic of the 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 Services Successfully

Bearer Traffic

Parent topic: Call Restriction Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

BOIC Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model The caller is a 3G mobile subscriber. 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 As shown in Figure 1, P1 refers to the measurement point. Description of the Signaling Flow The BOIC 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 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit in Flowchart

P1

Measurement Type Total Traffic of the Office Total Traffic of the 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 Services Successfully

Bearer Traffic

Parent topic: Call Restriction Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

BAIC Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model The caller is a 3G mobile subscriber. 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 As shown in Figure 1, P1 refers to the measurement point. Description of the Signaling Flow The BAIC signaling flow is as follows: 1. After accessing the network, UE-A sends a Setup message to the MSC/VLR. 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. Description of Associated Measurement Entities

Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit in Flowchart

P1

Measurement Type

3G TERMINATED CALL BARRING TIMES

UTRAN Subscriber Terminated Calls

Total Traffic of the Office

Call Barring Times

Intra-MSC Calls

Total Traffic of the Office

Invocation of Supplementary Services

Supplementary Services

Bearer Traffic

Implement of Supplementary Supplementary Services Services Successfully

Bearer Traffic

Parent topic: Call Restriction Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Value-added Services PPS MVPN Service VP Service Parent topic: Typical Signaling Flows User Manual Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

PPS->MS Call Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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. Description of the Signaling Flow 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points 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

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MS->PPS Call Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

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 Description of the Signaling Flow 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

MAP_SEND_ROUTING_INFORMATION_REQ message to HLRb serving the 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. 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 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. 8. The MSCa/VLR/SSP releases the call. Description of Associated Measurement Entities 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 in Flowchart

Measurement Unit Measurement Type

P1

Number of Sent InitialDP Messages

CAP Operations

IN Services

P2

Number of Received RequestReportBCSMEvent CAP Operations Messages

IN Services

P3

Number of Received CAP Operations ApplyCharging Messages

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

Table 2 Measurement points on the terminating side Measurement Point Measurement Entity Measurement Unit 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Measurement Type

IN Services

Bearer Traffic

IN Services

Bearer Traffic

IN Services

Bearer Traffic

PPS->Service Number Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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. Description of the Signaling Flow The PPS->service number signaling flow 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 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. 10. The MSCa/VLR/SSP releases the call. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point in Flowchart

Measurement Entity

Measurement Unit

P1

Number of Sent InitialDP Messages

CAP Operations IN Services

P2

Number of Received CAP Operations IN Services RequestReportBCSMEvent Messages

P3

Number of Received ConnectToResource Messages

CAP Operations IN Services

P4

Number of Received PromptAndCollectUserInformation Messages

CAP Operations IN Services

P5

Number of Sent PromptAndCollectUserInformationResult CAP Operations IN Services Messages Number of Received

Measurement Type

P6

DisconnectForwardConnection Messages

CAP Operations IN Services

P7

Number of Received CAP Operations IN Services RequestReportBCSMEvent Messages

P8

Number of Received ApplyCharging Messages

CAP Operations IN Services

P9

Number of Received Connect Messages

CAP Operations IN Services

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

CAP Operations IN Services

P14

Number of Sent EventReportBCSM Messages

CAP Operations IN Services

Parent topic: PPS Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

PPS Call Failure Owing to the Insufficient Balance of the Caller Account Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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 As shown in Figure 1, P1, P2, P3, P4, P5, P6, P7, P8, P9, P10 refers to the measurement point. Description of the Signaling Flow The signaling flow of a PPS call failure owing to the insufficient balance of the caller account 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 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 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. 6. The SCP sends a release call (RC) message, requesting the MSCa/VLR/SSP to release the call. 7. The MSCa/VLR/SSP releases the call. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity in Flowchart

Measurement Unit Measurement Type

P1

Number of Sent InitialDP Messages

CAP Operations

IN Services

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

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 Connecting number (WIN user TK outgoing) P7 Alerting Message Received Times Answering number (WIN user TK outgoing) P8 Answer Times

Parent topic: PPS Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Bearer Traffic

IN Services

Bearer Traffic

IN Services

Bearer Traffic

PPS Call Failure Owing to the Invalid Caller Account Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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. Description of the Signaling Flow The signaling flow of a PPS call failure owing to the invalid caller account 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 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 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. 4. The SCP sends a release call (RC) message, requesting the MSCa/VLR/SSP to 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Measurement Entity Point in Flowchart

Measurement Unit Measurement Type

P1

Number of Sent InitialDP Messages

CAP Operations

IN Services

P2

Number of Received RequestReportBCSMEvent CAP Operations 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

IN Services

PPS Call Failure Owing to the Insufficient Balance of the Callee Account Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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 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 Description of the Signaling Flow

The signaling flow of a PPS call failure owing to the insufficient balance of the callee account 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 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. 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 sends the MAP_SEND_ROUTING_INFORMATION_REQ message to HLRb again to obtain the mobile station roaming number (MSRN) of the callee. 4. The MSCa/VLR/SSP connects the call based on the MSRN. 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. 8. The MSCa/VLR/SSP releases the call. Description of Associated Measurement Entities 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

Table 1 Measurement points on the originating side Measurement Point Measurement Entity in Flowchart

Measurement Unit Measurement Type

P1

Number of Sent InitialDP Messages

CAP Operations

IN Services

P2

Number of Received RequestReportBCSMEvent CAP Operations Messages

IN Services

P3

Number of Received CAP Operations ApplyCharging Messages

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

Table 2 Measurement points on the terminating side Measurement Point Measurement Entity Measurement Unit 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

PPS Call Failure Owing to the Invalid Callee Account Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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. Description of the Signaling Flow

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. 5. SCPb sends a release call (RC) message, requesting the MSCa/VLR/SSP to release the call. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Measurement Entity Point in Flowchart P1

P2

Number of Sent InitialDP Messages

Measurement Unit Measurement Type CAP Operations

IN Services

Number of Received RequestReportBCSMEvent CAP Operations

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Parent topic: Value-added Services Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MVPN->MS Call Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

As shown in Figure 1, P1, P2, P3, P4, P5, P6, P7, P8, P9, P10 refers to the measurement point. Description of the Signaling Flow The signaling flow of the MVPN->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 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 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). 6. The caller and the callee start conversation. 7. 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. 8. The SCP sends a release call (RC) message, requesting the MSCa/VLR/SSP to release the call. 9. The MSCa/VLR/SSP releases the call. Description of Associated Measurement Entities

Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity in Flowchart

Measurement Unit Measurement Type

P1

Number of Sent InitialDP Messages

CAP Operations

IN Services

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

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

IN Services

MVPN->MVPN Call Flow Using a Long Number Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

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, P7, P8, P9, P10, P11, P12, P13, P14 Callee: Q1, Q2, Q3 Description of the Signaling Flow

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. 5. The MSCa/VLR/SSP connects the call based on the MSRN. 6. The caller and the callee start conversation. 7. 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. 8. The SCP sends a release call (RC) message, requesting the MSCa/VLR/SSP to release the call. 9. The MSCa/VLR/SSP releases the call. Description of Associated Measurement Entities 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 Measurement Point Measurement Entity in Flowchart

Measurement Unit Measurement Type

P1

Number of Sent InitialDP Messages

CAP Operations

IN Services

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

CAP Operations

IN Services

P6

Number of Sent InitialDP Messages

CAP Operations

IN Services

P7

Number of Received RequestReportBCSMEvent CAP Operations Messages

IN Services

P8

Number of Received CAP Operations ApplyCharging Messages

IN Services

P9

Number of Received Connect Messages

IN Services

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

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

Table 2 Measurement points on the terminating side Measurement Point Measurement Entity Measurement Unit 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: MVPN Service Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Description of the Signaling Flow Description of Associated Measurement Entities 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. Description of the Signaling Flow 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. Description of Associated Measurement Entities See MVPN->MVPN Call Flow Using a Long Number. Parent topic: MVPN Service Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MS->MVPN Call Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

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, P7, P8, P9 Callee: Q1, Q2, Q3 Description of the Signaling Flow The signaling flow of the MS->MVPN call is as follows: 1. On receiving the call originated by the 2G subscriber, the MSCa/VLR/SSP determines that the caller is not an MVPN subscriber, and therefore sends a

MAP_SEND_ROUTING_INFORMATION_REQ message to HLRb serving the 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. 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. 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. 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 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. 8. The MSCa/VLR/SSP releases the call. Description of Associated Measurement Entities 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 Measurement Point Measurement Entity in Flowchart

Measurement Unit Measurement Type

P1

Number of Sent InitialDP Messages

CAP Operations

IN Services

P2

Number of Received RequestReportBCSMEvent CAP Operations Messages

IN Services

P3

Number of Received CAP Operations ApplyCharging Messages

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

Table 2 Measurement points on the terminating side Measurement Point Measurement Entity Measurement Unit 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 Terminated Incoming IN Services 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 Terminated Incoming IN Services Trunk Calls Incoming Traffic in Trunk Office Bearer Traffic Directions

Parent topic: MVPN Service Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Parent topic: Value-added Services Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Basic Intra-MSC VP Call Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 3G subscriber calls another 3G subscriber served by the same MSC server. Early assignment is applied in the call. 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

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 Callee: Q1, Q2, Q3 Description of the Signaling Flow 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. 10. The MGW returns a MOD REPLY message to the MSC/VLR and plays the 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. 13. The MGW returns a MOD REPLY message to the MSC/VLR and stops playing 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. Description of Associated Measurement Entities 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

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

Total Traffic of the Office

UTRAN VP Subscriber Total Traffic of the Originated Calls Office UTRAN Subscriber Total Traffic of the Originated Calls Office

VP Call Failures due to No Support from Bearer Capability

UTRAN VP Subscriber Total Traffic of the Total Traffic of the Office OfficeOriginated Calls

Call Attempts

Intra-MSC Calls

Call Completion Times

UTRAN Subscriber Originated Calls

Call Completion Times Intra-MSC Calls P3

Measurement Type

Answer Times VP Call Completion Times Answer Times Answer Times

Total Traffic of the Office Total Traffic of the Office Total Traffic of the Office

Traffic Measurement Global Components For LAI UTRAN VP Subscriber Total Traffic of the Total Traffic of the Office OfficeOriginated Calls UTRAN Subscriber Total Traffic of the Originated Calls Office Total Traffic of the Intra-MSC Calls Office

P4

MO response times (LAI) Average Call Setup Time

Traffic Measurement Global Components For LAI UTRAN Subscriber Total Traffic of the Originated Calls Office UTRAN VP Subscriber Total Traffic of the VP Call Answer Times Total Traffic of the Office OfficeOriginated Calls

Table 2 Measurement points on the terminating side Measurement Point Measurement Entity Measurement Unit in Flowchart

Q1

Q2

Q3

3G TERMINATED CALL_ATTEMPT

Measurement Type

UTRAN Subscriber Total Traffic of the Terminated Calls Office UTRAN VP Subscriber Total Traffic of the VP Call Attempts Terminated Calls Office 3G TERMINATED UTRAN Subscriber Total Traffic of the ALERT Terminated Calls Office MO connect times Traffic Measurement Global Components (LAI) For LAI VP Call Completion UTRAN VP Subscriber Total Traffic of the Times Terminated Calls Office 3G TERMINATED UTRAN Subscriber Total Traffic of the ANSWER Terminated Calls Office MT response times Traffic Measurement Global Components (LAI) For LAI UTRAN VP Subscriber Total Traffic of the VP Call Answer Times Terminated Calls Office 3G TERMINATED UTRAN Subscriber Total Traffic of the CALL ESTABLISH Terminated Calls Office AVERAGE TIME

Parent topic: VP Service Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Basic Inter-MSC VP Call Flow Using BICC Signaling Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 3G subscriber calls another 3G subscriber served by another MSC server. Early assignment is applied in the call. 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

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 Callee: Q1, Q2, Q3

Description of the Signaling Flow 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. 7. The UE-O and the UE-T perform the H.245 negotiation and open the H.245 audio 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 between the UE-O and the UE-T are closed and the H.245 session is complete. 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. 9. The MSC-O sends a Radio Link Control (RLC) message to the MSC-T and 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.

Description of Associated Measurement Entities 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

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

Total Traffic of the Office UTRAN VP Subscriber Total Traffic of the Originated Calls Office Outgoing Traffic in Trunk Office

Call Completion Times Outgoing Calls

Bearer Traffic Total Traffic of the Office

VP Call Completion Times

UTRAN VP Subscriber Total Traffic of the Originated Calls Office

Answer Times

Outgoing Traffic in Trunk Office

Bearer Traffic

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

Outgoing Calls

Table 2 Measurement points on the terminating side Measurement Point Measurement Entity Measurement Unit 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

Total Traffic of the Office UTRAN VP Subscriber Total Traffic of the Terminated Calls Office UTRAN Subscriber Terminated Calls

Total Traffic of the Office

3G INCOMING CALL UTRAN Subscriber Total Traffic of the 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 Total Traffic of the Office

VP Call Completion Times

UTRAN VP Subscriber Total Traffic of the Terminated Calls Office

Alerting Message Received Times

Incoming Traffic in Trunk Office Directions

Call Completion Times Incoming Calls 3G TERMINATED ANSWER MT response times (LAI) 3G TERMINATED CALL ESTABLISH AVERAGE TIME Q3

Total Traffic of the Office

Bearer Traffic Total Traffic of the Office Total Traffic of the Office

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

Total Traffic of the Office

UTRAN Subscriber Total Traffic of the Terminated Incoming Office Calls Incoming Traffic in Answer Times Trunk Office Bearer Traffic Directions Total Traffic of the Answer Times Incoming Calls Office UTRAN VP Subscriber Total Traffic of the VP Call Answer Times Terminated Calls Office 3G INCOMING ANSWER

Parent topic: VP Service Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Basic Inter-MSC VP Call Flow Using ISUP Signaling Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 3G subscriber calls another 3G subscriber served by another MSC server. Early assignment is applied in the call. 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

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 Callee: Q1, Q2, Q3 Description of the Signaling Flow 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. 5. The UE-O and the UE-T perform the H.245 negotiation and open the H.245 audio 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 between the UE-O and the UE-T are closed and the H.245 session is complete. 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. 7. The MSC-O sends a Radio Link Control (RLC) message to the MSC-T and releases the bearer resource on the caller side. This message indicates that the peer end is free and is available for the next call. Description of Associated Measurement Entities 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

P1

Measurement Type

Seizure Times

Outgoing Traffic in Trunk Office

Bearer Traffic

Seizure Times

Outgoing Calls

Total Traffic of the Office

P2

P3

VP Call Attempts

UTRAN VP Subscriber Total Traffic of the Originated Calls Office

Alerting Message Received Times

Outgoing Traffic in Trunk Office

Call Completion Times Outgoing Calls

Bearer Traffic Total Traffic of the Office

VP Call Completion Times

UTRAN VP Subscriber Total Traffic of the Originated Calls Office

Answer Times

Outgoing Traffic in Trunk Office

Bearer Traffic

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

Outgoing Calls

Table 2 Measurement points on the terminating side Measurement Point Measurement Entity Measurement Unit 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

Total Traffic of the Office UTRAN VP Subscriber Total Traffic of the Terminated Calls Office UTRAN Subscriber Terminated Calls

Total Traffic of the Office

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

Alerting Message Received Times

Incoming Traffic in Trunk Office Directions

Call Completion Times Incoming Calls 3G TERMINATED ANSWER MT response times (LAI) 3G TERMINATED CALL ESTABLISH AVERAGE TIME Q3

Bearer Traffic Total Traffic of the Office Total Traffic of the Office

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

Total Traffic of the Office

UTRAN Subscriber Total Traffic of the Terminated Incoming Office Calls Incoming Traffic in Answer Times Trunk Office Bearer Traffic Directions Total Traffic of the Answer Times Incoming Calls Office UTRAN VP Subscriber Total Traffic of the VP Call Answer Times Terminated Calls Office 3G INCOMING ANSWER

Parent topic: VP Service Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Mobility Management Common Location Update Periodic Location Update Independent Location Update Combined Location Update Location Cancellation IMSI Detach Parent topic: Typical Signaling Flows User Manual Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 3G Common Location Update Parent topic: Mobility Management Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

2G Common Location Update 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Successful Intra-VLR Common Location Update (Only VLR Is Involved) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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. Description of the Signaling Flow 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Successful Intra-VLR Common Location Update (VLR and HLR Are Involved) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 2G subscriber initiates a location update in the same MSC/VLR area. The interaction with the VLR is also involved in the location update. Signaling Flow Figure 1 shows the signaling flow of a successful intra-VLR common location update, where 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) As shown in Figure 1, P1, P2 refers to the measurement point. Description of the Signaling Flow The signaling flow of a successful intra-VLR common location update (VLR and HLR are 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 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. 11. The MSC releases the channel. The location update is complete. 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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

Parent topic: 2G Common Location Update Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Unsuccessful Intra-VLR Common Location Update Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 2G subscriber initiates a location update in the same MSC/VLR area. 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

As shown in Figure 1, P1, P2 refers to the measurement point. Description of the Signaling Flow

The signaling flow of unsuccessful intra-VLR common location update 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 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. 6. The MSC releases the channel. The location update is complete. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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

Parent topic: 2G Common Location Update Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Successful Inter-VLR Common Location Update (Initiated Using IMSI) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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) As shown in Figure 1, P1, P2 refers to the measurement point. Description of the Signaling Flow The signaling flow of successful inter-VLR common location update (initiated by using IMSI) is as follows: 1. The MS sends a Location updating request message to the MSC. The message carries the 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 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. 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. 7. The HLR sends a MAP-INSERT-SUBSCRIBER-DATA_IND message, instructing the VLR to insert the updated location data of the subscriber. 8. After successfully inserting the updated location data of the subscriber, the VLR sends a MAP-INSERT-SUBSCRIBER-DATA_RSP message to the HLR. 9. The HLR sends a MAP_UPDATE_LOCATION_CNF message, notifying the VLR that the location update is successful. 10. The VLR sends a MAP_UPDATE_LOCATION_AREA_ACK message, notifying the MSC that the location update is successful. 11. The MSC/VLR initiates the encryption flow. This flow is optional. 12. The MSC sends a Location updating accept message, notifying the MS that the location update is successful. 13. The MSC releases the channel. The location update is complete. 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. 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. Description of Associated Measurement Entities Table 1 lists common measurement entities.

Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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 Parent topic: 2G Common Location Update Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Successful Inter-VLR Common Location Update (Initiated Using TMSI) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 2G subscriber initiates a location outside the home VLR. The location update is initiated by using the temporary mobile subscriber identifier (TMSI). Signaling Flow Figure 1 shows the signaling flow of successful inter-VLR common location update (initiated by using TMSI). Figure 1 Signaling flow of successful inter-VLR common location update (initiated by using

TMSI) As shown in Figure 1, P1, P2 refers to the measurement point. Description of the Signaling Flow The signaling flow of successful inter-VLR common location update (initiated by using TMSI) is as follows: 1. The MS sends a Location updating request message to the MSC. The message carries the TMSI 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 VLR checks the subscriber data and finds that the subscriber is roaming from 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 authentication flow. This flow is optional. 4. The VLR sends a MAP_UPDATE_LOCATION_REQ message, requesting the HLR to perform a location update. 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. 7. The HLR sends a MAP-INSERT-SUBSCRIBER-DATA_IND message, instructing the VLR to insert the updated location data of the subscriber. 8. After successfully inserting the updated location data of the subscriber, the VLR sends a MAP-INSERT-SUBSCRIBER-DATA_RSP message to the HLR. 9. The HLR sends a MAP_UPDATE_LOCATION_CNF message, notifying the VLR that the location update is successful. 10. The VLR sends a MAP_UPDATE_LOCATION_AREA_ACK message, notifying the MSC that the location update is successful. 11. The MSC/VLR initiates the encryption flow. This flow is optional. 12. The MSC sends a Location updating accept message, notifying the MS that the location update is successful. 13. The MSC releases the channel. The location update is complete. 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. 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. Description of Associated Measurement Entities Table 1 lists common measurement entities.

Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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 Parent topic: 2G Common Location Update Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Unsuccessful Inter-VLR Common Location Update Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 2G subscriber initiates a location outside the home VLR. 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

As shown in Figure 1, P1, P2 refers to the measurement point. Description of the Signaling Flow The signaling flow of unsuccessful inter-VLR common location update is as follows: 1. The MS sends a Location updating request message to the MSC. The message carries the temporary mobile subscriber identifier (TMSI) 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 VLR checks the subscriber data and finds that the subscriber is roaming from 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 authentication flow. This flow is optional. 4. The VLR sends a MAP_UPDATE_LOCATION_REQ message, requesting the HLR to perform a location update. 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. 7. The HLR sends a MAP-INSERT-SUBSCRIBER-DATA_IND message, instructing the VLR to insert the updated location data of the subscriber. 8. After successfully inserting the updated location data of the subscriber, the VLR sends a MAP-INSERT-SUBSCRIBER-DATA_RSP message to the HLR. 9. The HLR sends a MAP_UPDATE_LOCATION_CNF message, notifying the VLR that the location update is successful. 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. 14. The MSC releases the channel. The location update is complete. 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.

Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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

Parent topic: 2G Common Location Update Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MSC Basic Functions

3G Common Location Update 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Successful Intra-VLR Common Location Update (Only VLR Is Involved) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 3G 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. Description of the Signaling Flow 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 carries the temporary mobile subscriber identifier (TMSI)/international mobile subscriber identity (IMSI) of the UE, 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 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 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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: 3G Common Location Update

MSC Basic Functions

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Successful Intra-VLR Common Location Update (VLR and HLR Are Involved) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 3G subscriber initiates a location update in the same MSC/VLR area. The interaction with the VLR is also involved in the location update. Signaling Flow Figure 1 shows the signaling flow of a successful intra-VLR common location update, where 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) As shown in Figure 1, P1, P2 refers to the measurement point. Description of the Signaling Flow The signaling flow of a successful intra-VLR common location update (VLR and HLR are involved) is as follows: 1. The UE 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 UE, 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 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 UE that the location update is successful. 11. The MSC releases the channel. The location update is complete. 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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

Parent topic: 3G Common Location Update Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MSC Basic Functions

Unsuccessful Intra-VLR Common Location Update Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 3G subscriber initiates a location update in the same MSC/VLR area. 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

As shown in Figure 1, P1, P2 refers to the measurement point. Description of the Signaling Flow The signaling flow of unsuccessful intra-VLR common location update is as follows:

1. The UE 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 UE, 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 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. 6. The MSC releases the channel. The location update is complete. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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

Parent topic: 3G Common Location Update Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Successful Inter-VLR Common Location Update (Initiated Using IMSI) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 3G subscriber initiates a location outside the home VLR. 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 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) As shown in Figure 1, P1, P2 refers to the measurement point. Description of the Signaling Flow The signaling flow of successful inter-VLR common location update (initiated by using IMSI) is as follows: 1. The UE sends a Location updating request message to the MSC. The message carries the IMSI of the UE, 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 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. 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. 7. The HLR sends a MAP-INSERT-SUBSCRIBER-DATA_IND message, instructing the VLR to insert the updated location data of the subscriber. 8. After successfully inserting the updated location data of the subscriber, the VLR sends a MAP-INSERT-SUBSCRIBER-DATA_RSP message to the HLR. 9. The HLR sends a MAP_UPDATE_LOCATION_CNF message, notifying the VLR that the location update is successful. 10. The VLR sends a MAP_UPDATE_LOCATION_AREA_ACK message, notifying the MSC that the location update is successful. 11. The MSC/VLR initiates the encryption flow. This flow is optional. 12. The MSC sends a Location updating accept message, notifying the UE that the location update is successful. 13. The MSC releases the channel. The location update is complete. NOTE: When the UE 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 UE and then uses the IMSI to perform the location update. 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. Description of Associated Measurement Entities

Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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 Parent topic: 3G Common Location Update Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Successful Inter-VLR Common Location Update (Initiated Using TMSI) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 2G subscriber initiates a location outside the home VLR. The location update is initiated by using the temporary mobile subscriber identifier (TMSI). Signaling Flow Figure 1 shows the signaling flow of successful inter-VLR common location update (initiated by using TMSI). Figure 1 Signaling flow of the successful inter-VLR common location update (initiated by

using TMSI) As shown in Figure 1, P1, P2 refers to the measurement point. Description of the Signaling Flow The signaling flow of successful inter-VLR common location update (initiated by using TMSI) is as follows: 1. The UE sends a Location updating request message to the MSC. The message carries the TMSI of the UE, 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 VLR checks the subscriber data and finds that the subscriber is roaming from 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 authentication flow. This flow is optional. 4. The VLR sends a MAP_UPDATE_LOCATION_REQ message, requesting the HLR to perform a location update. 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. 7. The HLR sends a MAP-INSERT-SUBSCRIBER-DATA_IND message, instructing the VLR to insert the updated location update of the subscriber. 8. After successfully inserting the updated location data of the subscriber, the VLR sends a MAP-INSERT-SUBSCRIBER-DATA_RSP message to the HLR. 9. The HLR sends a MAP_UPDATE_LOCATION_CNF message, notifying the VLR that the location update is successful. 10. The VLR sends a MAP_UPDATE_LOCATION_AREA_ACK message, notifying the MSC that the location update is successful. 11. The MSC/VLR initiates the encryption flow. This flow is optional. 12. The MSC sends a Location updating accept message, notifying the UE that the location update is successful. 13. The MSC releases the channel. The location update is complete. NOTE: When the UE 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 UE and then uses the IMSI to perform the location update. 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. Description of Associated Measurement Entities

Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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 Parent topic: 3G Common Location Update Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Unsuccessful Inter-VLR Common Location Update Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model A 3G subscriber initiates a location outside the home VLR. 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

As shown in Figure 1, P1, P2 refers to the measurement point. Description of the Signaling Flow The signaling flow of unsuccessful inter-VLR common location update is as follows: 1. The UE sends a Location updating request message to the MSC. The message carries the temporary mobile subscriber identifier (TMSI) of the UE, 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 VLR checks the subscriber data and finds that the subscriber is roaming from 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 authentication flow. This flow is optional. 4. The VLR sends a MAP_UPDATE_LOCATION_REQ message, requesting the HLR to perform a location update. 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. 7. The HLR sends a MAP-INSERT-SUBSCRIBER-DATA_IND message, instructing the VLR to insert the updated location data of the subscriber. 8. After successfully inserting the updated location data of the subscriber, the VLR sends a MAP-INSERT-SUBSCRIBER-DATA_RSP message to the HLR. 9. The HLR sends a MAP_UPDATE_LOCATION_CNF message, notifying the VLR that the location update is successful. 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. 14. The MSC releases the channel. The location update is complete. 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.

Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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

Parent topic: 3G Common Location Update Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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. Parent topic: Mobility Management Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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. Parent topic: Mobility Management Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Parent topic: Mobility Management Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Successful Combined Location Update Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

As shown in Figure 1, P1, P2 refers to the measurement point. Description of the Signaling Flow

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. 4. 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 MSC sends a Location updating accept message, notifying the UE that the 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. Description of Associated Measurement Entities Table 1 lists common measurement entities.

Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Unsuccessful Combined Location Update Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

As shown in Figure 1, P1, P2 refers to the measurement point. Description of the Signaling Flow

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. 4. 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 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Parent topic: Mobility Management Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Cancel Location Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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 Description of the 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 MAP_CANCEL_LOCATION_RSP message to the HLR. Description of Associated Measurement Entities None. Parent topic: Location Cancellation

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Parent topic: Mobility Management Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Explicit IMSI Detach Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

As shown in Figure 1, P1 refers to the measurement point. Description of the Signaling Flow 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MSC Basic Functions

Security Management Authentication and Encryption Parent topic: Typical Signaling Flows User Manual Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Authentication and Encryption 2G Authentication and Encryption 3G Authentication and Encryption Parent topic: Security Management Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

2G Authentication and Encryption 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Successful Authentication Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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. Description of the Signaling Flow 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Unsuccessful Authentication Due to Network Denial Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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 As shown in Figure 1, P1, P2 refers to the measurement point. Description of the Signaling Flow The signaling flow of unsuccessful authentication of a 2G subscriber due to network denial is as follows: 1. On receiving a location update, call, or supplementary service request, the MSC/VLR sends an Authentication request message carrying authentication sets to the MS. 2. 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 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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

Parent topic: 2G Authentication and Encryption Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

3G Authentication and Encryption 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. Successful Authentication Unsuccessful Authentication Due to Network Denial Unsuccessful Authentication Due to UE Denial Parent topic: Authentication and Encryption Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Successful Authentication Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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. Description of the Signaling Flow The successful authentication flow of a 3G 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 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. 5. On receiving the authentication request, the MS sends the random number (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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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: 3G Authentication and Encryption Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Unsuccessful Authentication Due to Network Denial Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model The authentication on a 3G 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 3G subscriber due to network denial. Figure 1 Signaling flow of unsuccessful authentication of a 3G subscriber due to network

denial As shown in Figure 1, P1, P2 refers to the measurement point. Description of the Signaling Flow The signaling flow of unsuccessful authentication of a 3G subscriber due to network denial is as follows: 1. On receiving a location update, call, or supplementary service request, the 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 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 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. 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. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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

Parent topic: 3G Authentication and Encryption Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Unsuccessful Authentication Due to UE Denial Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model The authentication on a 3G subscriber fails because of UE denial when the subscriber attempts a service access. Signaling Flow Figure 1 shows the signaling flow of unsuccessful authentication of a 3G subscriber due to network denial. Figure 1 Signaling flow of unsuccessful authentication of a 3G subscriber due to UE denial

As shown in Figure 1, P1, P2 refers to the measurement point. Description of the Signaling Flow The signaling flow of unsuccessful authentication of a 3G subscriber due to UE denial is as follows: 1. On receiving a location update, call, or supplementary service request, the 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 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. 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. 5. At the same time, the MSC/VLR sends a location update request or service reject message to the UE. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit in Flowchart

Measurement Type

P1

AUTH Requests

Authentication

MSC Basic Functions

P2

Negative AUTH Responses by Subscribers

Authentication

MSC Basic Functions

Parent topic: 3G Authentication and Encryption Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Parent topic: Typical Signaling Flows User Manual Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Purge MS Flow Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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 Description of the 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. Description of Associated Measurement Entities None.

Parent topic: Subscriber Data Management Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Handover Management UMTS Handover GSM Handover GSM-UMTS Handover Parent topic: Typical Signaling Flows User Manual Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

3G Intra-MSC Handover Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

As shown in Figure 1, P1, P2, P3, P4 refers to the measurement points. Description of the Signaling Flow 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.

Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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

Inter-RNC HOs due to Handover between 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 Local MSC Handover MSC Basic Services 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

Local MSC Handover MSC Basic Services

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

Successful Intra-MSC Handover between 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 Local MSC Handover MSC Basic Services Handover Times Parent topic: UMTS Handover Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

3G Inter-MSC Handover (A->B) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

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 Callee: Q1, Q2, Q3, Q4, Q5 Description of the Signaling Flow

The signaling flow of 3G inter-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 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. 13. 3G-MSC-A sends an IU RELEASE COMMAND message, instructing RNC-A to 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. Description of Associated Measurement Entities 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

P1

Measurement Type

Requested Inter-MSC Handover between Handovers 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

Inter-RNC HOs due to Handover between Resource Optimization WCDMA RNCs

P2

P3

P4

P5

MSC Basic Services MSC Basic Services

Basic Outgoing Handover Requests

Local MSC Handover MSC Basic Services

Out LAI HO times (LAI)

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 Handover between Ciphering and Integrity WCDMA RNCs Protection Algorithms

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

Local MSC Handover MSC Basic Services

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

Table 2 Measurement points on the terminating side Measurement Point Measurement Entity Measurement Unit in Flowchart Q1

Q2

Q3

Q4

Q5

Measurement Type

Basic Incoming Handover Requests

Local MSC Handover MSC Basic Services

Successful Basic Outgoing Handover Requests

Handover between WCDMA RNCs

IN LAI HO times (LAI)

Traffic Measurement Global Components For LAI

MSC Basic Services

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 Handover between Ciphering and Integrity WCDMA RNCs Protection Algorithms

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

Local MSC Handover MSC Basic Services

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

Local MSC Handover MSC Basic Services

Parent topic: UMTS Handover Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

3G Subsequent Inter-MSC Handback (A->B->A) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

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 Callee: Q1, Q2, Q3, Q4, Q5 Description of the Signaling Flow 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 initiate a handover. The message carries mandatory information elements (IEs) such as Relocation Type, CAUSE, SourceID, and TargetID. 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 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. 8. A new channel is established, and the subscriber continues the conversation or 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 message to 3G-MSC-B. 12. 3G-MSC-A sends a release (REL) message, instructing 3G-MSC-B to release the inter-MSC trunk resources. Description of Associated Measurement Entities Table 1ists common measurement entities used on the originating side. Table 2lists common measurement entities used on the terminating side. Table 1 Measurement points on the originating side Measurement Point Measurement Entity Measurement Unit in Flowchart

P1

P2

Measurement Type

Requested Inter-MSC Handover between Handovers 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

Inter-RNC HOs due to Handover between Resource Optimization WCDMA RNCs

MSC Basic Services

Requests for Subsequent Handover Local MSC Handover MSC Basic Services (Local Office is MSCb) Out LAI HO times

Traffic Measurement

(LAI)

P3

P4

P5

For LAI

Global Components

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 Handover between Ciphering and Integrity WCDMA RNCs Protection Algorithms

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

Local MSC Handover MSC Basic Services

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 Subsequent Handovers to MSCa (Local Office is MSCa)

Local MSC Handover MSC Basic Services

Out LAI HO success times (LAI)

Traffic Measurement Global Components For LAI

Table 2 Measurement points on the terminating side Measurement Point Measurement Entity Measurement Unit in Flowchart Requests for

Measurement Type

Q1

Q2

Subsequent Handover Local MSC Handover MSC Basic Services to MSCa (Local Office is MSCa) Requested Inter-MSC Handover between HOs to RNC WCDMA RNCs IN LAI HO times (LAI)

Q3

Q4

Q5

MSC Basic Services

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 Handover between Ciphering and Integrity WCDMA RNCs Protection Algorithms

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

Local MSC Handover MSC Basic Services

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 Subsequent Handover Times (Local Office is MSCb)

Traffic Measurement Global Components For LAI Handover between MSC Basic Services WCDMA RNCs Local MSC Handover MSC Basic Services

Parent topic: UMTS Handover Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

3G Subsequent Inter-MSC Handover to a Third Party (A->B>B') Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

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, P7 Callee:

Q1, Q2, Q3, Q4, Q5 Description of the Signaling Flow 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 initiate a handover. The message carries mandatory information elements (IEs) such as Relocation Type, CAUSE, SourceID, and TargetID. 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 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 MAP_PREPARE_HANDOVER_RSP message to 3G-MSC-A only after receiving 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 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'. 7. 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'. 8. 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, 3G-

MSC-B' sends an address complete message (ACM) message to 3G-MSC-A. 9. 3G-MSC-A sends a MAP_PREPARE_SUBSEQUENT_HANDOVER_RSP 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 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. 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 direction between endpoints in the context, and then connects the peer endpoint to the new endpoint. 13. 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. 14. 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. 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. 16. 3G-MSC-A sends a release (REL) message, instructing 3G-MSC-B to release 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. 18. 3G-MSC-B sends an IU RELEASE COMMAND message, instructing RNC-B to release the terrestrial and radio resources. 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.

Description of Associated Measurement Entities 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

P1

P2

Requested Inter-MSC Handover between Handovers 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

Inter-RNC HOs due to Handover between Resource Optimization WCDMA RNCs

MSC Basic Services

Requests for Subsequent Handover Local MSC Handover MSC Basic Services (Local Office is MSCb) Out LAI HO times (LAI)

P3

P4

Measurement Type

Traffic Measurement Global Components For LAI

Requests for Subsequent Handover Local MSC Handover MSC Basic Services to MSCc (Local Office is MSCa) 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 Handover between Ciphering and Integrity WCDMA RNCs Protection Algorithms

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

Local MSC Handover MSC Basic Services

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)

Local MSC Handover MSC Basic Services

Successful Inter-MSC Handover between HOs from RNC WCDMA RNCs

P7

MSC Basic Services

MSC Basic Services

Successful Subsequent Handover Local MSC Handover MSC Basic Services Times (Local Office is MSCb) Out LAI HO success times (LAI)

Traffic Measurement Global Components For LAI

Table 2 Measurement points on the terminating side Measurement Point Measurement Entity Measurement Unit in Flowchart Q1

Q2

Basic Incoming Handover Requests

Local MSC Handover MSC Basic Services

Requested Inter-MSC Handover between HOs to RNC WCDMA RNCs IN LAI HO times (LAI)

Measurement Type

MSC Basic Services

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

Q3

Q4

Q5

Handover between WCDMA RNCs

MSC Basic Services

HO Failures due to Unsupported Handover between Ciphering and Integrity WCDMA RNCs Protection Algorithms

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

Local MSC Handover MSC Basic Services

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 Incoming Handover Requests

Traffic Measurement Global Components For LAI Handover between MSC Basic Services WCDMA RNCs Local MSC Handover MSC Basic Services

Parent topic: UMTS Handover Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Intra-MSC Handover 2G Inter-MSC Handover (A->B) 2G Subsequent Inter-MSC Handback (A->B->A) 2G Subsequent Inter-MSC Handover to a Third Party (A->B->B') Parent topic: Handover Management Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

2G Intra-MSC Handover Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model An intra-MSC handover is performed for a 2G mobile subscriber. Signaling Flow Figure 1 shows the signaling flow of 2G intra-MSC handover. Figure 1 Signaling flow of 2G intra-MSC handover

As shown in Figure 1, P1, P2, P3, P4 refers to the measurement points. Description of the Signaling Flow The signaling flow of 2G intra-MSC handover is as follows: 1. BSC-A sends a HANDOVER REQUIRED message, requesting 2G-MSC-A to initiate a handover. The message carries mandatory information elements (IEs)

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. 8. A new channel is established, and the subscriber continues the conversation or 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. Description of Associated Measurement Entities Table 1lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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

Local MSC Handover MSC Basic Services

Out LAI HO times (LAI)

Traffic Measurement Global Components For LAI

Intra-MSC Handover to Cell Requested Times

GSM Cell Handover

IN LAI HO times (LAI) 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

Handover Failure due to Encryption GSM Cell Handover Algorithm Not Supported

MSC Basic Services

Handover Failure due to Speech Version GSM Cell Handover Unavailability

MSC Basic Services

Handover Failure due 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

A to B HO Failed due to Encryption Handover between Algorithm Not GSM Cells Supported

MSC Basic Services

A to B HO Failed due Handover between to Speech Version GSM Cells Unavailable

MSC Basic Services

Handover Failures Responded by the Source or Target

Local MSC Handover 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 Local MSC Handover MSC Basic Services Handover Times P4

Successful Intra-MSC Handover from Cell GSM Cell Handover Times

MSC Basic Services

Successful Intra-MSC Handover to Cell GSM Cell Handover Times

MSC Basic Services

A to B HO Succeeded

Handover between GSM Cells

Parent topic: GSM Handover Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MSC Basic Services

2G Inter-MSC Handover (A->B) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model An inter-MSC handover is performed for a 2G mobile subscriber. The controlling MSC is 2G-MSC-A and the target MSC is 2G-MSC-B. Signaling Flow Figure 1 shows the signaling flow of 2G inter-MSC handover. Figure 1 Signaling flow of 2G inter-MSC handover

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 Callee: Q1, Q2, Q3, Q4 Description of the Signaling Flow

The signaling flow of 2G inter-MSC handover is as follows: 1. BSC-A sends a HANDOVER REQUIRED message, requesting 2G-MSC-A to initiate a handover. The message carries mandatory information elements (IEs) such as Handover Type, Cause, SourceID, and TargetID. 2. On receiving the HANDOVER REQUIRED message, 2G-MSC-A queries the 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, 2G-MSC-A constructs a MAP_PREPARE_HANDOVER_REQ 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 MAP_PREPARE_HANDOVER_RSP message to 2G-MSC-A only after receiving the responses from BSC-B and VLR-B. 4. After allocating radio resources, BSC-B sends a HANDOVER REQUEST ACKNOWLEDGE message to 2G-MSC-B. 5. After VLR-B allocates the handover number, 2G-MSC-B sends a MAP_PREPARE_HANDOVER_RSP message to notify 2G-MSC-A that the handover preparation is complete. The message carries the handover number, which can be used by 2G-MSC-A to establish a speech channel to 2G-MSC-B. 6. 2G-MSC-A analyzes the handover number and selects an outgoing route based on the handover number. If the routing is successful, 2G-MSC-A sends an IAM message to 2G-MSC-B. 7. If 2G-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 2G-MSC-B receives the IAM message. At the same time, 2GMSC-B sends an address complete message (ACM) message to 2G-MSC-A. 8. After an inter-MSC circuit is set up, 2G-MSC-A constructs a HANDOVER COMMAND message by using the contents resolved from the MAP_PREPARE_HANDOVER_RSP message, and then sends the message to 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 switched to the channel. As the current handover is a speech handover, a speech

channel must be established in advance. 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 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. BSC-B sends a HANDOVER COMPLETE message to notify 2G-MSC-B that the inter-MSC handover is complete. 12. 2G-MSC-B transparently transfers the HANDOVER COMPLETE message through a MAP_SEND_END_SIGNAL_REQ message, notifying 2G-MSC-A that the inter-MSC handover is complete. 13. 2G-MSC-A sends a CLEAR COMMAND message, instructing BSC-A to release the terrestrial and radio resources. 14. After releasing the terrestrial and radio resources, BSC-A sends a CLEAR COMPLETE message to 2G-MSC-A. 15. 2G-MSC-B sends an answer message (ANM) message to 2G-MSC-A. The handover is complete. 16. After the conversion ends, 2G-MSC-A sends a release (REL) message to 2GMSC-B to release the call and the inter-MSC circuit. 17. 2G-MSC-A sends a MAP_SEND_END_SIGNAL_RSP message, instructing 2GMSC-B to release the inter-MSC Mobile Application Part (MAP) resources. 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. Description of Associated Measurement Entities 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

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 due to Uplink Quality

GSM Cell Handover

MSC Basic Services

Handover from Cell due to O&M Interference

GSM Cell Handover

MSC Basic Services

Basic Outgoing Handover Requests

Local MSC Handover MSC Basic Services

Out LAI HO times (LAI)

Traffic Measurement Global Components For LAI

P1

P2

P3

P4

Handover Failure due to Radio Resource GSM Cell Handover Unavailability

MSC Basic Services

Handover Failure due to Encryption GSM Cell Handover Algorithm Not Supported

MSC Basic Services

Handover Failure due to Speech Version GSM Cell Handover Unavailability

MSC Basic Services

Handover Failure due to Terrestrial GSM Cell Handover Resource Unavailability

MSC Basic Services

Handover Failures Responded by the Source or Target

Local MSC Handover MSC Basic Services

Out LAI HO success times (LAI)

Traffic Measurement Global Components For LAI

Successful Basic Outgoing Handover

Local MSC Handover MSC Basic Services

Requests Successful Inter-MSC Handover from Cell GSM Cell Handover Times

MSC Basic Services

Table 2 Measurement points on the terminating side Measurement Point Measurement Entity Measurement Unit in Flowchart Q1

Q2

Q3

Q4

Measurement Type

Basic Incoming Handover Requests

Local MSC Handover MSC Basic Services

Inter-MSC Handover to Cell Requested Times

GSM Cell Handover

IN LAI HO times (LAI)

Traffic Measurement Global Components For LAI

MSC Basic Services

Handover Failure due to Radio Resource GSM Cell Handover Unavailability

MSC Basic Services

Handover Failure due to Encryption GSM Cell Handover Algorithm Not Supported

MSC Basic Services

Handover Failure due to Speech Version GSM Cell Handover Unavailability

MSC Basic Services

Handover Failure due to Terrestrial GSM Cell Handover Resource Unavailability

MSC Basic Services

Handover Failures Responded by the Source or Target

Local MSC Handover MSC Basic Services

IN LAI HO success times (LAI)

Traffic Measurement Global Components For LAI

Successful Inter-MSC Handover to Cell GSM Cell Handover Times

MSC Basic Services

Successful Basic Incoming Handover Requests

Local MSC Handover MSC Basic Services

Parent topic: GSM Handover Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

2G Subsequent Inter-MSC Handback (A->B->A) Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

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 Callee: Q1, Q2, Q3, Q4 Description of the Signaling Flow 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 initiate a handover. The message carries mandatory information elements (IEs) such as Handover Type, Cause, SourceID, and TargetID. 2. 2G-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, 2G-MSC-B sends a MAP_PREPARE_SUBSEQUENT_HANDOVER_REQ message to 2G-MSC-A. The message carries information such as MSC ID of the target MSC and target LAI/GCI. 3. 2G-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 2G-MSC-A 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. 5. 2G-MSC-A sends a MAP_PREPARE_SUBSEQUENT_HANDOVER_RSP 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 requirement for access to the new radio channel is met but actually the MS is not switched to the channel. As the current handover is a speech handover, a speech channel must be established in advance.

8. A new channel is established, and the subscriber continues the conversation or 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 the radio resources. 11. After releasing the radio resources, BSC-B sends a CLEAR COMPLETE message to 23G-MSC-B. 12. 2G-MSC-A sends a release (REL) message, instructing 2G-MSC-B to release the inter-MSC trunk resources. Description of Associated Measurement Entities 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

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 due to Uplink Quality

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 MSC Handover MSC Basic Services (Local Office is MSCb) Out LAI HO times (LAI)

Traffic Measurement Global Components For LAI

P3

P4

Handover Failure due GSM Cell Handover to Radio Resource Unavailability

MSC Basic Services

Handover Failure due to Encryption GSM Cell Handover Algorithm Not Supported

MSC Basic Services

Handover Failure due to Speech Version GSM Cell Handover Unavailability

MSC Basic Services

Handover Failure due to Terrestrial GSM Cell Handover Resource Unavailability

MSC Basic Services

Handover Failures Responded by the Source or Target

Local MSC Handover MSC Basic Services

Out LAI HO success times (LAI)

Traffic Measurement Global Components For LAI

Successful Subsequent Handover Local MSC Handover MSC Basic Services Times (Local Office is MSCb) Successful Inter-MSC Handover from Cell GSM Cell Handover Times

MSC Basic Services

Table 2 Measurement points on the terminating side Measurement Point Measurement Entity Measurement Unit in Flowchart

Q1

Q2

Measurement Type

Requests for Subsequent Handover Local MSC Handover MSC Basic Services 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

Handover Failure due to Radio Resource GSM Cell Handover Unavailability

MSC Basic Services

Handover Failure due to Encryption GSM Cell Handover Algorithm Not Supported

MSC Basic Services

Handover Failure due to Speech Version GSM Cell Handover Unavailability

MSC Basic Services

Handover Failure due to Terrestrial GSM Cell Handover Resource Unavailability

MSC Basic Services

Handover Failures Responded by the Source or Target

Local MSC Handover MSC Basic Services

IN LAI HO success times (LAI)

Traffic Measurement Global Components For LAI

Successful Inter-MSC Handover to Cell GSM Cell Handover Times Successful Subsequent Handovers to MSCa (Local Office is MSCa)

MSC Basic Services

Local MSC Handover MSC Basic Services

Parent topic: GSM Handover Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

2G Subsequent Inter-MSC Handover to a Third Party (A->B>B') Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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

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 Description of the Signaling Flow 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 initiate a handover. The message carries mandatory information elements (IEs) such as Handover Type, Cause, SourceID, and TargetID. 2. 2G-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, 2G-MSC-B sends a MAP_PREPARE_SUBSEQUENT_HANDOVER_REQ message to 2G-MSC-A. The message carries information such as MSC ID of the target MSC and target LAI/GCI. 3. 2G-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 2G-MSC-A 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 MAP_PREPARE_HANDOVER_RSP message to 2G-MSC-A only after receiving 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 MAP_PREPARE_HANDOVER_RSP message to notify 2G-MSC-A that the handover preparation is complete. The message carries the handover number, which can be used by 2G-MSC-A to establish a speech channel to 2G-MSC-B'. 7. 2G-MSC-A analyzes the handover number and selects an outgoing route based on the handover number. If the routing is successful, 2G-MSC-A sends an IAM message to 2G-MSC-B'. 8. If 2G-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 2G-MSC-B' receives the IAM message. At the same time, 2GMSC-B' sends an address complete message (ACM) message to 2G-MSC-A. 9. 2G-MSC-A sends a MAP_PREPARE_SUBSEQUENT_HANDOVER_RSP 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 requirement for access to the new radio channel is met but actually the MS is not switched to the channel. As the current handover is a speech handover, a speech channel must be established in advance. 12. 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 direction between endpoints in the context, and then connects the peer endpoint to the new endpoint. 13. A new channel is established, and the subscriber continues the conversation or 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 through a MAP_SEND_END_SIGNAL_REQ message, notifying 2G-MSC-A that the inter-MSC handover is complete. 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. 16. 2G-MSC-A sends a release (REL) message, instructing 2G-MSC-B to release the inter-MSC circuit. 17. 2G-MSC-A sends a MAP_SEND_END_SIGNAL_RSP message, instructing 2GMSC-B to release the inter-MSC Mobile Application Part (MAP) resources. 18. 2G-MSC-B sends a CLEAR COMMAND message, instructing BSC-B to release the terrestrial and radio resources. 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. Description of Associated Measurement Entities 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

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 due to Uplink Quality

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 MSC Handover MSC Basic Services (Local Office is MSCb) Out LAI HO times (LAI)

P3

Traffic Measurement Global Components For LAI

Requests for Subsequent Handover Local MSC Handover MSC Basic Services to MSCc (Local Office is MSCa) Handover Failure due to Radio Resource GSM Cell Handover Unavailability

MSC Basic Services

Handover Failure due to Encryption GSM Cell Handover Algorithm Not Supported

MSC Basic Services

P4

Handover Failure due GSM Cell Handover to Speech Version Unavailability Handover Failure due to Terrestrial GSM Cell Handover Resource Unavailability

P5

P6

MSC Basic Services

MSC Basic Services

Handover Failures Responded by the Source or Target

Local MSC Handover MSC Basic Services

Successful Subsequent Handovers to MSCc (Local Office is MSCa)

Local MSC Handover MSC Basic Services

Out LAI HO success times (LAI)

Traffic Measurement Global Components For LAI

Successful Subsequent Handover Local MSC Handover MSC Basic Services Times (Local Office is MSCb) Successful Inter-MSC Handover from Cell GSM Cell Handover Times

MSC Basic Services

Table 2 Measurement points on the terminating side Measurement Point Measurement Entity Measurement Unit in Flowchart Q1

Q2

Measurement Type

Basic Incoming Handover Requests

Local MSC Handover MSC Basic Services

Inter-MSC Handover to Cell Requested Times

GSM Cell Handover

IN LAI HO times (LAI)

Traffic Measurement Global Components For LAI

Handover Failure due to Radio Resource GSM Cell Handover Unavailability

MSC Basic Services

MSC Basic Services

Q3

Q4

Handover Failure due to Encryption GSM Cell Handover Algorithm Not Supported

MSC Basic Services

Handover Failure due to Speech Version GSM Cell Handover Unavailability

MSC Basic Services

Handover Failure due to Terrestrial GSM Cell Handover Resource Unavailability

MSC Basic Services

Handover Failures Responded by the Source or Target

Local MSC Handover MSC Basic Services

IN LAI HO success times (LAI)

Traffic Measurement Global Components For LAI

Successful Inter-MSC Handover to Cell GSM Cell Handover Times Successful Basic Incoming Handover Requests

MSC Basic Services

Local MSC Handover MSC Basic Services

Parent topic: GSM Handover Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Intra-MSC Handover from 2G to 3G Inter-MSC Handover from 3G to 2G Inter-MSC Handover from 2G to 3G Parent topic: Handover Management Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Intra-MSC Handover from 3G to 2G Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model An intra-MSC handover is performed for a 3G mobile subscriber. 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

As shown in Figure 1, P1, P2, P3, P4 refers to the measurement points. Description of the Signaling Flow The signaling flow of intra-MSC handover from 3G to 2G 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 handover request, 3G-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, 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 REQUEST ACKNOWLEDGE message to 3G-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 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. 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. Description of Associated Measurement Entities

Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit in Flowchart

P1

P2

P3

Measurement Type

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

Inter-RNC HOs due to Handover between 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

Intra-MSC Handover to Cell Requested Times

GSM Cell Handover

IN LAI HO times (LAI)

Traffic Measurement Global Components For LAI

MSC Basic Services

Handover Failure due to Radio Resource GSM Cell Handover Unavailability

MSC Basic Services

Handover Failure due to Encryption GSM Cell Handover Algorithm Not Supported

MSC Basic Services

Handover Failure due to Speech Version GSM Cell Handover Unavailability

MSC Basic Services

Handover Failure due 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 Unsupported Ciphering Handover between and Integrity WCDMA RNCs Protection Algorithms

MSC Basic Services

Handover Failures Responded by the Source or Target

P4

MSC Basic Services

Local MSC Handover MSC Basic Services

Successful Intra-MSC Handover between HOs from RNC WCDMA RNCs

MSC Basic Services

Successful Intra-MSC 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

Successful Intra-MSC Local MSC Handover MSC Basic Services Handover Times Parent topic: GSM-UMTS Handover Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Intra-MSC Handover from 2G to 3G Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model An intra-MSC handover is performed for a 2G mobile subscriber. 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

As shown in Figure 1, P1, P2, P3, P4 refers to the measurement points. Description of the Signaling Flow The signaling flow of intra-MSC handover from 2G to 3G is as follows: 1. BSC-A sends a HANDOVER REQUIRED message, requesting 3G-MSC-A to

initiate a handover. The message carries mandatory information elements (IEs) such as Handover Type, Cause, SourceID, and TargetID. 2. On receiving the handover request, 3G-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 RELOCATION REQUEST message, requesting RNC-B to allocate required radio resources. 3. After allocating radio resources and a circuit, RNC-B sends a RELOCATION REQUEST ACKNOWLEDGE message to 3G-MSC-A. The message carries the information about the allocated radio resources and circuit. 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. 8. 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-A that the handover is complete. 9. 3G-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 3G-MSC-A. Description of Associated Measurement Entities Table 1 lists common measurement entities. Table 1 Measurement points Measurement Point Measurement Entity Measurement Unit 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 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

Local MSC Handover MSC Basic Services

Out location area identity (LAI) HO times (LAI)

Traffic Measurement Global Components For LAI

Requested Intra-MSC Local MSC Handover MSC Basic Services HOs to RNC IN LAI HO times (LAI)

P3

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

Handover Failure due to Radio Resource GSM Cell Handover Unavailability Handover Failure due to Encryption

MSC Basic Services

Algorithm Not Supported

P4

GSM Cell Handover

MSC Basic Services

Handover Failure due to Code Conversion GSM Cell Handover Unavailability

MSC Basic Services

Handover Failures Responded by the Source or Target

Local MSC Handover 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 Local MSC Handover MSC Basic Services Handover Times Successful Intra-MSC Handover between HOs to RNC WCDMA RNCs

MSC Basic Services

Successful Intra-MSC Handover from Cell GSM Cell Handover Times

MSC Basic Services

Parent topic: GSM-UMTS Handover Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Inter-MSC Handover from 3G to 2G Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities 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 2G-MSC-B. 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

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 Callee: Q1, Q2, Q3, Q4 Description of the Signaling Flow

The signaling flow of inter-MSC handover from 3G to 2G 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 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 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. 4. After allocating radio resources, BSC-B sends a HANDOVER REQUEST ACKNOWLEDGE message to 2G-MSC-B. 5. After VLR-B allocates the handover number, 2G-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 2G-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 2G-MSC-B. 7. If 2G-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 2G-MSC-B receives the IAM message. At the same time, 2GMSC-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/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. 10. 2G-MSC-B transparently transfers the HANDOVER DETECT message to 3GMSC-A through a MAP_PROCESS_ACCESS_SIGNALLING message. On

receiving the message, 3G-MSC-A requests MGW-A 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. BSC-B sends a HANDOVER COMPLETE message to notify 2G-MSC-B that the inter-MSC handover is complete. 12. 2G-MSC-B transparently transfers the HANDOVER COMPLETE message through a MAP_SEND_END_SIGNAL_REQ message, notifying 3G-MSC-A that the inter-MSC handover is complete. 13. 3G-MSC-A sends an IU RELEASE COMMAND message, instructing RNC-A to 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. 2G-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 2GMSC-B to release the call and the inter-MSC circuit. 17. 3G-MSC-A sends a MAP_SEND_END_SIGNAL_RSP message, instructing 2GMSC-B to release the inter-MSC Mobile Application Part (MAP) resources. Description of Associated Measurement Entities 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

P1

Measurement Type

Requested Inter-MSC Handover between Handovers from RNC WCDMA RNCs

MSC Basic Services

Inter-RNC HOs due to Handover between Radio Resource WCDMA RNCs Reason

MSC Basic Services

Inter-RNC HOs due to Handover between O&M Interventio WCDMA RNCs

MSC Basic Services

Inter-RNC HOs due to Handover between Resource Optimization WCDMA RNCs

MSC Basic Services

P2

P3

P4

Basic Outgoing Handover Requests

Local MSC Handover MSC Basic Services

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 Ciphering and Integrity WCDMA RNCs Protection Algorithms

MSC Basic Services

Handover Failures Responded by the Source or Target

Local MSC Handover MSC Basic Services

Out LAI HO success times (LAI)

Traffic Measurement Global Components For LAI

Successful Basic Outgoing Handover Requests

Local MSC Handover MSC Basic Services

Successful Inter-MSC Handover between HOs from RNC WCDMA RNCs

MSC Basic Services

Table 2 Measurement points on the terminating side Measurement Point Measurement Entity Measurement Unit in Flowchart Q1

Q2

Measurement Type

Basic Incoming Handover Requests

Local MSC Handover MSC Basic Services

Inter-MSC Handover to Cell Requested Times

GSM Cell Handover

IN LAI HO times (LAI)

Traffic Measurement Global Components For LAI

Handover Failure due

MSC Basic Services

to Radio Resource Unavailability

Q3

Q4

GSM Cell Handover

MSC Basic Services

Handover Failure due to Encryption GSM Cell Handover Algorithm Not Supported

MSC Basic Services

Handover Failure due to Speech Version GSM Cell Handover Unavailability

MSC Basic Services

Handover Failure due to Terrestrial GSM Cell Handover Resource Unavailability

MSC Basic Services

Handover Failures Responded by the Source or Target

Local MSC Handover MSC Basic Services

IN LAI HO success times (LAI)

Traffic Measurement Global Components For LAI

Successful Inter-MSC Handover to Cell GSM Cell Handover Times Successful Basic Incoming Handover Requests

MSC Basic Services

Local MSC Handover MSC Basic Services

Parent topic: GSM-UMTS Handover Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Inter-MSC Handover from 2G to 3G Service Model Signaling Flow Description of the Signaling Flow Description of Associated Measurement Entities Service Model An inter-MSC handover is performed for a 2G mobile subscriber. The controlling MSC is 2G-MSC-A and the target MSC is 3G-MSC-B. 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

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 Callee: Q1, Q2, Q3, Q4 Description of the Signaling Flow

The signaling flow of inter-MSC handover from 2G to 3G is as follows: 1. BSC-A sends a HANDOVER REQUIRED message, requesting 2G-MSC-A to initiate a handover. The message carries mandatory information elements (IEs) such as Handover Type, Cause, SourceID, and TargetID. 2. On receiving the HANDOVER REQUIRED message, 2G-MSC-A queries the 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, 2G-MSC-A constructs a MAP_PREPARE_HANDOVER_REQ message by using the IEs contained in the HANDOVER 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. 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 2G-MSC-A that the handover preparation is complete. The message carries the handover number, which can be used by 2G-MSC-A to establish a speech channel to 3G-MSC-B. 6. 2G-MSC-A analyzes the handover number and selects an outgoing route based on the handover number. If the routing is successful, 2G-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 2G-MSC-A. 8. After an inter-MSC circuit is set up, 3G-MSC-A constructs a HANDOVER COMMAND message by using the contents resolved from the MAP_PREPARE_HANDOVER_RSP message, and then sends the message to 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. 10. 3G-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 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 2G-MSC-A that the inter-MSC handover is complete. 13. 2G-MSC-A sends a CLEAR COMMAND message, instructing BSC-A to release the terrestrial and radio resources. 14. After releasing the terrestrial and radio resources, BSC-A sends a CLEAR COMPLETE message to 2G-MSC-A. 15. 3G-MSC-B sends an answer message (ANM) message to 2G-MSC-A. The handover is complete. 16. After the conversion ends, 2G-MSC-A sends a release (REL) message to 3GMSC-B to release the call and the inter-MSC circuit. 17. 2G-MSC-A sends a MAP_SEND_END_SIGNAL_RSP message, instructing 3GMSC-B to release the inter-MSC Mobile Application Part (MAP) resources. Description of Associated Measurement Entities 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

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 due to Uplink Quality

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

Local MSC Handover MSC Basic Services

Out LAI HO times (LAI)

Traffic Measurement Global Components For LAI

Handover Failure due to Radio Resource GSM Cell Handover Unavailability

MSC Basic Services

Handover Failure due to Encryption GSM Cell Handover Algorithm Not Supported

MSC Basic Services

Handover Failure due to Code Conversion GSM Cell Handover Unavailability

MSC Basic Services

Handover Failures Responded by the Source or Target

Local MSC Handover MSC Basic Services

Out LAI HO success times (LAI)

Traffic Measurement Global Components For LAI

Successful Basic Outgoing Handover Requests

Local MSC Handover MSC Basic Services

Successful Inter-MSC Handover from Cell GSM Cell Handover Times

MSC Basic Services

Table 2 Measurement points on the terminating side Measurement Point Measurement Entity Measurement Unit in Flowchart Q1

Q2

Measurement Type

Basic Incoming Handover Requests

Local MSC Handover MSC Basic Services

Successful Basic Outgoing Handover Requests

Handover between WCDMA RNCs

IN LAI HO times (LAI)

Traffic Measurement Global Components For LAI

MSC Basic Services

Q3

Q4

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 Handover between Ciphering and Integrity WCDMA RNCs Protection Algorithms

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

Local MSC Handover MSC Basic Services

IN LAI HO success times (LAI) Successful Inter-MSC HOs to RNC

Traffic Measurement Global Components For LAI Handover between MSC Basic Services WCDMA RNCs

Successful Basic Incoming Handover Requests

Local MSC Handover MSC Basic Services

Parent topic: GSM-UMTS Handover Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Parent topic: Typical Signaling Flows User Manual Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Um/Uu Interface Protocol Scenario Description Message List Scenario Description 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. This message is sent by the network to notify the MS/UE that 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

MSMSC

CALL PROCEEDING

MSC>MS

CALL CONFIRMED

MS>MSC

CONNECT

MSMSC

CONNECT MSMSC

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. This message is sent by the network to notify the MS/UE that 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. This message is sent by the network to notify the MS/UE that 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

MSMSC

RELEASE

MSMSC

RELEASE COMPLETE

MSMSC

FACILITY

MSMSC

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. This message is sent, from the network to the MS/UE or 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. This message is sent, from the network to the MS/UE or conversely, to indicate that the sender has released the transaction identifier and the receiver should also release the transaction identifier. This message is sent, from the network to the MS/UE or 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. This message is sent by the network to notify the MS/UE that the sending of the DTMF tone has been stopped.

Parent topic: Um/Uu Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Common Part of Messages 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. Parent topic: Um/Uu Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Registration Messages at the MM Sublayer IMSI DETACH INDICATION LOCATION UPDATING ACCEPT LOCATION UPDATING REJECT LOCATION UPDATING REQUEST Parent topic: Um/Uu Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 ignored. A message received with skip 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

LOCATION UPDATING ACCEPT 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 shows the main IEs of the message. Figure 1 LOCATION UPDATING ACCEPT message

Associated IEs Information Element (IE)

Description

Protocol Discriminator

Identifies the L3 protocol to which the L3 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. For details, see Protocol Discriminator.

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. For details, see Skip indicator.

Message Type

Indicates the type of the message. For a LOCATION UPDATING ACCEPT message, the message type is LOCATION UPDATING ACCEPT. For details, see Message Type.

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

Provides identity information of the MS/UE. For details, see Mobile Identity.

Reference Standards For details, see 9.2.13 "Location updating accept" in 3rd Generation Partnership Project (3GPP) TS24008-830. Parent topic: Description of Registration Messages at the MM Sublayer Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd.

LOCATION UPDATING REJECT 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 Information Element (IE)

Protocol Discriminator

Description Identifies the L3 protocol to which the L3 message belongs. In a LOCATION UPDATING REJECT message, Protocol Discriminator takes the value 5, indicating that the message belongs to the mobility management (MM) protocol.

For details, see Protocol Discriminator.

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. For details, see Skip indicator.

Message Type

Indicates the type of the message. For a LOCATION UPDATING REJECT message, the message type is LOCATION UPDATING REJECT. For details, see Message Type.

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. Parent topic: Description of Registration Messages at the MM Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

LOCATION UPDATING REQUEST 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

Protocol Discriminator

Identifies the L3 protocol to which the L3 message belongs. In a LOCATION UPDATING REQUEST message, Protocol Discriminator takes the value 5, indicating that the message belongs to the mobility management (MM) protocol. For details, see Protocol Discriminator.

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. For details, see Skip indicator.

Message Type

Indicates the type of the message. For a LOCATION UPDATING REQUEST message, the message type is LOCATION UPDATING REQUEST. For details, see Message Type.

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.

Location Area Identification

Provides unambiguous identification of location areas where the MS/UE is staying. For details, see Location Area Identification.

Mobile Station Classmark 1

Includes classmark1 corresponding to the frequency band in use. For details, see Mobile Station Classmark 1.

Mobile Identity

Provides identity information of the MS/UE. For details, see Mobile Identity.

Mobile Station Classmark 2

Includes classmark2 corresponding to the frequency band in use. For details, see Mobile Station Classmark 2.

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. Parent topic: Description of Registration Messages at the MM Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Security Messages at the MM Sublayer AUTHENTICATION REJECT AUTHENTICATION REQUEST AUTHENTICATION RESPONSE AUTHENTICATION FAILURE IDENTITY REQUEST IDENTITY RESPONSE Parent topic: Um/Uu Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

AUTHENTICATION REJECT 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 Information Element (IE)

Description

Protocol Discriminator

Identifies the L3 protocol to which the L3 message belongs. In an AUTHENTICATION REJECT message, Protocol Discriminator takes the value 5, indicating that the message belongs to the mobility management (MM) protocol. For details, see Protocol Discriminator. Indicates whether the message should be ignored. A message received with skip

Skip indicator

Message Type

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. For details, see Skip indicator. Indicates the type of the message. For an AUTHENTICATION REJECT message, the message type is AUTHENTICATION REJECT. For details, see Message Type.

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

AUTHENTICATION REQUEST 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 Information Element (IE)

Protocol Discriminator

Description Identifies the L3 protocol to which the L3 message belongs. In an AUTHENTICATION REQUEST message, Protocol Discriminator takes the value 5, indicating that the message belongs to the mobility management (MM)

protocol. For details, see Protocol Discriminator.

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. For details, see Skip indicator.

Message Type

Indicates the type of the message. For an AUTHENTICATION REQUEST message, the message type is AUTHENTICATION REQUEST. For details, see Message Type.

Ciphering Key Sequence Number

Indicates the sequence number of the ciphering key. For details, see Ciphering Key Sequence 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. Parent topic: Description of Security Messages at the MM Sublayer Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd.

AUTHENTICATION RESPONSE 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 Information Element (IE)

Protocol Discriminator

Description Identifies the L3 protocol to which the L3 message belongs. In an AUTHENTICATION RESPONSE message, Protocol Discriminator takes the value 5, indicating that the message belongs to the mobility management (MM) protocol.

For details, see Protocol Discriminator.

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. For details, see Skip indicator.

Message Type

Indicates the type of the message. For an AUTHENTICATION RESPONSE message, the message type is AUTHENTICATION RESPONSE. For details, see Message Type.

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. Parent topic: Description of Security Messages at the MM Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

AUTHENTICATION FAILURE 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 Information Element (IE)

Description

Protocol Discriminator

Identifies the L3 protocol to which the L3 message belongs. In an AUTHENTICATION FAILURE message, Protocol Discriminator takes the value 5, indicating that the message belongs to the mobility management (MM) protocol. For details, see Protocol Discriminator.

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. For details, see Skip indicator.

Message Type

Indicates the type of the message. For an AUTHENTICATION FAILURE message, the message type is AUTHENTICATION FAILURE. For details, see Message Type.

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. Parent topic: Description of Security Messages at the MM Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Protocol Discriminator

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 management (MM) protocol. For details, see Protocol Discriminator. 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. For details, see Skip indicator.

Message Type

Indicates the type of the message. For an IDENTITY REQUEST message, the message type is IDENTITY REQUEST. For details, see Message Type.

Identity type

Specifies which identity is requested from the MS/UE. For details, see Identity type.

Spare Half Octet

Reserved for future use. It is half-octet long. For details, see Spare Half Octet.

Reference Standards For details, see 9.2.10 "Identity request" in 3rd Generation Partnership Project (3GPP) TS24008-830. Parent topic: Description of Security Messages at the MM Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 1 shows the main IEs of the message. Figure 1 IDENTITY RESPONSE message

Associated IEs Information Element (IE)

Description Identifies the L3 protocol to which the L3

Protocol Discriminator

message belongs. In an IDENTITY RESPONSE message, Protocol Discriminator takes the value 5, indicating that the message belongs to the mobility management (MM) protocol. For details, see Protocol Discriminator.

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. For details, see Skip indicator.

Message Type

Indicates the type of the message. For an IDENTITY RESPONSE message, the message type is IDENTITY RESPONSE. For details, see Message Type.

Mobile Identity

Provides identity information of the MS/UE. For details, see Mobile Identity.

Reference Standards For details, see 9.2.11 "Identity response" in 3rd Generation Partnership Project (3GPP) TS24008-830. Parent topic: Description of Security Messages at the MM Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Connection Management Messages at the MM Sublayer CM SERVICE ACCEPT CM SERVICE REQUEST Parent topic: Um/Uu Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Protocol Discriminator

Identifies the L3 protocol to which the L3 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. For details, see Protocol Discriminator. Indicates whether the message should be

Skip indicator

Message Type

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. For details, see Skip indicator. Indicates the type of the message. For a CM SERVICE ACCEPT message, the message type is CM SERVICE ACCEPT. For details, see Message Type.

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Protocol Discriminator

Identifies the L3 protocol to which the L3 message belongs. In a CM SERVICE REQUEST message, Protocol Discriminator takes the value 5, indicating that the message belongs to the mobility management (MM) protocol. For details, see Protocol Discriminator.

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. For details, see Skip indicator.

Message Type

Indicates the type of the message. For a CM SERVICE REQUEST message, the message type is CM SERVICE REQUEST. For details, see Message Type.

CM service type

Specifies which service is requested from the network. For details, see CM service type.

Ciphering Key Sequence Number

Indicates the sequence number of the ciphering key. For details, see Ciphering Key Sequence Number.

Mobile Station Classmark 2

Includes classmark2 corresponding to the frequency band in use. For details, see Mobile Station Classmark 2.

Mobile Identity

Provides identity information of the MS/UE. For details, see 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Call Establishment Messages at the CC Sublayer ALERTING CALL PROCEEDING CALL CONFIRMED CONNECT CONNECT ACKNOWLEDGE SETUP MODIFY MODIFY COMPLETE MODIFY REJECT Parent topic: Um/Uu Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Protocol Discriminator

Identifies the L3 protocol to which the L3 message belongs. In an ALERTING message, Protocol Discriminator takes the value 3, indicating that the message belongs to the call controller (CC) protocol. For details, see Protocol Discriminator.

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

Indicates the type of the message. For an ALERTING message, the message type is ALERTING. For details, see Message Type.

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Protocol Discriminator

Identifies the L3 protocol to which the L3 message belongs. In a CALL PROCEEDING message, Protocol Discriminator takes the value 3, indicating that the message belongs to the call controller (CC) protocol. For details, see Protocol Discriminator.

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

Indicates the type of the message. For a CALL PROCEEDING message, the message type is CALL PROCEEDING. For details, see Message Type.

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. Parent topic: Description of Call Establishment Messages at the CC Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Protocol Discriminator

Identifies the L3 protocol to which the L3 message belongs. In a CALL CONFIRMED message, Protocol Discriminator takes the value 3, indicating that the message belongs to the call controller (CC) protocol. For details, see Protocol Discriminator.

Transaction identifier

Distinguishes a message flow 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

Indicates the type of the message. For a CALL CONFIRMED message, the message type is CALL CONFIRMED. For details, see Message Type.

Reference Standards For details, see 9.3.2 "Call confirmed" in 3rd Generation Partnership Project (3GPP) TS24008-830. Parent topic: Description of Call Establishment Messages at the CC Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Protocol Discriminator

Identifies the L3 protocol to which the L3 message belongs. In a CONNECT message, Protocol Discriminator takes the value 3, indicating that the message belongs to the call controller (CC) protocol. For details, see Protocol Discriminator.

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

Indicates the type of the message. For a CONNECT message, the message type is CONNECT. For details, see Message Type.

Facility

Conveys supplementary service related information. For details, see Facility.

Progress indicator

Describes a mid-call event. For details, see 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. Parent topic: Description of Call Establishment Messages at the CC Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Protocol Discriminator

Identifies the L3 protocol to which the L3 message belongs. In a CONNECT ACKNOWLEDGE message, Protocol Discriminator takes the value 3, indicating that the message belongs to the call controller (CC) protocol. For details, see Protocol Discriminator.

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

Indicates the type of the message. For a CONNECT ACKNOWLEDGE message, the message type is CONNECT ACKNOWLEDGE. For details, see Message Type.

Reference Standards For details, see 9.3.6 "Connect acknowledge" in 3rd Generation Partnership Project (3GPP) TS24008-830. Parent topic: Description of Call Establishment Messages at the CC Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Protocol Discriminator

Identifies the L3 protocol to which the L3 message belongs. In a SETUP message, Protocol Discriminator takes the value 3, indicating that the message belongs to the call controller (CC) protocol. For details, see Protocol Discriminator.

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

Indicates the type of the message. For a SETUP message, the message type is SETUP. For details, see Message Type.

Repeat indicator

Indicates how the associated repeated information elements should be interpreted when included in a message. For details, see Repeat indicator.

Bearer capability

Describes the supported bearer capability. For details, see 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. Parent topic: Description of Call Establishment Messages at the CC Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Protocol Discriminator

Identifies the L3 protocol to which the L3 message belongs. In a MODIFY message, Protocol Discriminator takes the value 3, indicating that the message belongs to the call controller (CC) protocol. For details, see Protocol Discriminator.

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

Indicates the type of the message. For a MODIFY message, the message type is MODIFY.

For details, see Message Type. Bearer capability

Describes the supported bearer capability. For details, see Bearer capability.

Reference Standards For details, see 9.3.13 "Modify" in 3rd Generation Partnership Project (3GPP) TS24008830. Parent topic: Description of Call Establishment Messages at the CC Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Protocol Discriminator

Identifies the L3 protocol to which the L3 message belongs. In a MODIFY COMPLETE message, Protocol Discriminator takes the value 3, indicating that the message belongs to the call controller (CC) protocol. For details, see Protocol Discriminator.

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

Indicates the type of the message. For a MODIFY COMPLETE message, the message type is MODIFY COMPLETE.

For details, see Message Type. Bearer capability

Describes the supported bearer capability. For details, see Bearer capability.

Reference Standards For details, see 9.3.14 "Modify complete" in 3rd Generation Partnership Project (3GPP) TS24008-830. Parent topic: Description of Call Establishment Messages at the CC Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description Identifies the L3 protocol to which the L3 message belongs. In a MODIFY REJECT message, Protocol Discriminator takes the

Protocol Discriminator

value 3, indicating that the message belongs to the call controller (CC) protocol. For details, see Protocol Discriminator.

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

Indicates the type of the message. For a MODIFY REJECT message, the message type is MODIFY REJECT. For details, see Message Type.

Bearer capability

Describes the supported bearer capability. For details, see 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. Parent topic: Description of Call Establishment Messages at the CC Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Call Clearing Messages at the CC Sublayer DISCONNECT RELEASE RELEASE COMPLETE Parent topic: Um/Uu Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Information Element (IE)

Description

Protocol Discriminator

Identifies the L3 protocol to which the L3 message belongs. In a DISCONNECT message, Protocol Discriminator takes the value 3, indicating that the message belongs to the call controller (CC) protocol. For details, see Protocol Discriminator.

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

Indicates the type of the message. For a DISCONNECT message, the message type is DISCONNECT. For details, see Message Type.

Cause

Indicates the reason why the end-to-end connection is cleared. For details, see Cause.

Progress indicator

Describes a mid-call event. For details, see 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Information Element (IE)

Description

Protocol Discriminator

Identifies the L3 protocol to which the L3 message belongs. In a RELEASE message, Protocol Discriminator takes the value 3, indicating that the message belongs to the call controller (CC) protocol. For details, see Protocol Discriminator.

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

Indicates the type of the message. For a RELEASE message, the message type is RELEASE. For details, see Message Type.

Cause

Indicates the reason why the transaction identifier is released. For details, see Cause.

Reference Standards For details, see 9.3.18 "Release" in 3rd Generation Partnership Project (3GPP) TS24008830. Parent topic: Description of Call Clearing Messages at the CC Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RELEASE COMPLETE 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 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 Information Element (IE)

Description

Protocol Discriminator

Identifies the L3 protocol to which the L3 message belongs. In a RELEASE COMPLETE message, Protocol Discriminator takes the value 3, indicating that the message belongs to the call controller (CC) protocol. For details, see Protocol Discriminator. Distinguishes a few message flows for a

Transaction identifier

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

Indicates the type of the message. For a RELEASE COMPLETE message, the message type is RELEASE COMPLETE. For details, see Message Type.

Cause

Indicates the reason why the transaction identifier is released. For details, see Cause.

Reference Standards For details, see 9.3.19 "Release complete" in 3rd Generation Partnership Project (3GPP) TS24008-830. Parent topic: Description of Call Clearing Messages at the CC Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Supplementary Service Control Messages at the CC Sublayer HOLD FACILITY HOLD ACKNOWLEDGE RETRIEVE RETRIEVE ACKNOWLEDGE REGISTER Parent topic: Um/Uu Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Protocol Discriminator

Identifies the L3 protocol to which the L3 message belongs. In a HOLD message, Protocol Discriminator takes the value 3, indicating that the message belongs to the call controller (CC) protocol. For details, see Protocol Discriminator. Distinguishes a few message flows for a given protocol discriminator and a given

Transaction identifier

Message Type

session announcement protocol (SAP). Such a message flow is called a transaction. For details, see Skip indicator. Indicates the type of the message. For a HOLD message, the message type is HOLD. For details, see Message Type.

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Protocol Discriminator

Identifies the L3 protocol to which the L3 message belongs. In a FACILITY message, Protocol Discriminator takes the value B, indicating that the message belongs to the supplementary service (SS) protocol. For details, see Protocol Discriminator. Distinguishes a few message flows for a

Transaction identifier

given protocol discriminator and a given session announcement protocol (SAP). Such a message flow is called a transaction. For details, see Skip indicator.

Message Type

Indicates the type of the message. For a FACILITY message, the message type is FACILITY. For details, see Message Type.

Facility

Conveys supplementary service related information. For details, see Facility.

Reference Standards For details, see 9.3.9 "Facility" in 3rd Generation Partnership Project (3GPP) TS24008830. Parent topic: Description of Supplementary Service Control Messages at the CC Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Protocol Discriminator

Identifies the L3 protocol to which the L3 message belongs. In a HOLD ACKNOWLEDGE message, Protocol Discriminator takes the value 3, indicating that the message belongs to the call controller (CC) protocol. For details, see Protocol Discriminator. Distinguishes a few message flows for a

Transaction identifier

Message Type

given protocol discriminator and a given session announcement protocol (SAP). Such a message flow is called a transaction. For details, see Skip indicator. Indicates the type of the message. For a HOLD ACKNOWLEDGE message, the message type is HOLD ACKNOWLEDGE. For details, see Message Type.

Reference Standards For details, see 9.3.10 "Hold Acknowledge" in 3rd Generation Partnership Project (3GPP) TS24008-830. Parent topic: Description of Supplementary Service Control Messages at the CC Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Message Type

Indicates the type of the message. For a RETRIEVE message, the message type is RETRIEVE. For details, see Message Type.

Parent topic: Description of Supplementary Service Control Messages at the CC Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RETRIEVE ACKNOWLEDGE 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 Information Element (IE)

Description

Message Type

Indicates the type of the message. For a RETRIEVE ACKNOWLEDGE message, the message type is RETRIEVE ACKNOWLEDGE. For details, see Message Type.

Parent topic: Description of Supplementary Service Control Messages at the CC Sublayer Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Protocol Discriminator

Identifies the L3 protocol to which the L3 message belongs. In a REGISTER message, Protocol Discriminator takes the value 11, indicating that the message belongs to the call independent supplementary service (SS) protocol. For details, see Protocol Discriminator.

Transaction identifier

Distinguishes a message flow 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

Indicates the type of the message. For a REGISTER message, the message type is REGISTER. For details, see Message Type.

Facility

Conveys supplementary service related information. For details, see Facility.

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. Parent topic: Description of Supplementary Service Control Messages at the CC Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Miscellaneous Messages at the CC Sublayer NOTIFY START DTMF START DTMF ACKNOWLEDGE STOP DTMF STOP DTMF ACKNOWLEDGE Parent topic: Um/Uu Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Protocol Discriminator

Identifies the L3 protocol to which the L3 message belongs. In a NOTIFY message, Protocol Discriminator takes the value 3, indicating that the message belongs to the call controller (CC) protocol. For details, see Protocol Discriminator.

Transaction identifier

Distinguishes a message flow 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. Indicates the type of the message. For a NOTIFY message, the message type is

Message Type

Notification indicator

NOTIFY. For details, see Message Type. 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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. For details, see Protocol Discriminator.

Transaction identifier

Distinguishes a message flow 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

Indicates the type of the message. For a START DTMF message, the message type is START DTMF. For details, see Message Type.

Reference Standards For details, see 9.3.24 "Start DTMF" in 3rd Generation Partnership Project (3GPP) TS24008-830. Parent topic: Description of Miscellaneous Messages at the CC Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

START DTMF ACKNOWLEDGE 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) Identifies the L3 protocol to which the L3 message belongs. In a START DTMF ACKNOWLEDGE message, Protocol Discriminator Protocol Discriminator takes the value 3, indicating that the message belongs to the call controller (CC) protocol. For details, see Protocol Discriminator.

Transaction identifier

Distinguishes a message flow 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

Indicates the type of the message. For a START DTMF ACKNOWLEDGE message, the message type is START DTMF ACKNOWLEDGE. For details, see Message Type.

Reference Standards For details, see 9.3.25 "Start DTMF Acknowledge" in 3rd Generation Partnership Project (3GPP) TS24008-830. Parent topic: Description of Miscellaneous Messages at the CC Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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) Identifies the L3 protocol to which the L3 message belongs. In a

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

Transaction identifier

Distinguishes a message flow 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

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

Reference Standards For details, see 9.3.29 "Stop DTMF" in 3rd Generation Partnership Project (3GPP) TS24008-830. Parent topic: Description of Miscellaneous Messages at the CC Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

STOP DTMF ACKNOWLEDGE 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)

Identifies the L3 protocol to which the L3 message belongs. In a STOP DTMF ACKNOWLEDGE message, Protocol Discriminator Protocol Discriminator takes the value 3, indicating that the message belongs to the call controller (CC) protocol. For details, see Protocol Discriminator.

Transaction identifier

Distinguishes a message flow 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

Indicates the type of the message. For a STOP DTMF ACKNOWLEDGE message, the message type is STOP DTMF ACKNOWLEDGE. For details, see Message Type.

Reference Standards For details, see 9.3.30 "Stop DTMF acknowledge" in 3rd Generation Partnership Project (3GPP) TS24008-830. Parent topic: Description of Miscellaneous Messages at the CC Sublayer Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated IEs Protocol Discriminator Message Type Skip indicator Transaction identifier Priority Level Ciphering Key Sequence Number Location Area Identification Mobile Identity Mobile Station Classmark 1 Mobile Station Classmark 2 Spare Half Octet Authentication parameter RAND Authentication Parameter AUTN (UMTS authentication challenge only) Authentication Response parameter CM service type Identity type Location updating type Reject cause Cause Connected number Facility Low layer compatibility Progress indicator Repeat indicator Bearer capability Called party BCD number

Calling party BCD number Parent topic: Um/Uu Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Protocol Discriminator Description of the IE Reference Standards Description of the IE 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 management (MM) protocol. 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. Protocol Discriminator

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Message Type Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the type of the message. The following are message types used for mobility management: international mobile subscriber identity (IMSI) DETACH INDICATION LOCATION UPDATING ACCEPT LOCATION UPDATING REJECT LOCATION UPDATING REQUEST AUTHENTICATION REJECT AUTHENTICATION REQUEST AUTHENTICATION RESPONSE AUTHENTICATION FAILURE 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 ACKNOWLEDGE RETRIEVE REJECT DISCONNECT RELEASE RELEASE COMPLETE CONGESTION CONTROL NOTIFY STATUS STATUS ENQUIRY START dual tone multiple frequency (DTMF) STOP DTMF STOP DTMF ACKNOWLEDGE START DTMF ACKNOWLEDGE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Skip indicator Description of the IE Reference Standards Description of the IE Information Element (IE)

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

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Transaction identifier Description of the IE Reference Standards Description of the IE 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 identifier

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Priority Level Description of the IE Reference Standards Description of the IE Information Element (IE) Description 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 3 call priority level 2 call priority level 1 call priority level 0 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Ciphering Key Sequence Number Description of the IE Reference Standards Description of the IE Information Element (IE) Description

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 Project (3GPP) TS24008-830. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd.

Location Area Identification Description of the IE Reference Standards Description of the IE Information Element (IE) Description 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 Project (3GPP) TS24008-830. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Mobile Identity Description of the IE Reference Standards Description of the IE Information Element (IE) Description 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Mobile Station Classmark 1 Description of the IE Reference Standards Description of the IE 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 Project (3GPP) TS24008-830. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Mobile Station Classmark 2 Description of the IE Reference Standards Description of the IE 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 For details, see 10.5.1.6 "Mobile Station Classmark 2" in 3rd Generation Partnership Project (3GPP) TS24008-830. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Spare Half Octet Description of the IE Reference Standards Description of the IE Information Element (IE)

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Authentication parameter RAND Description of the IE Reference Standards Description of the IE Information Element (IE) Description 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 Project (3GPP) TS24008-830. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Authentication Parameter AUTN (UMTS authentication challenge only) Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Authentication Response parameter Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

CM service type Description of the IE Reference Standards Description of the IE Information Element Description (IE) Specifies which service is requested from the network. This IE takes the following values:

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Identity type Description of the IE Reference Standards Description of the IE Information Element (IE) Description Specifies which identity is requested from the MS/UE. This IE takes the following values:

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Location updating type Description of the IE Reference Standards Description of the IE 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

A LOCATION UPDATING REQUEST message is considered as an 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd.

Reject cause Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the reason why a request from the MS/UE is rejected by the network. This IE takes the following values:

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Cause Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Connected number Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Facility Description of the IE Reference Standards Description of the IE Information Element (IE)

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Low layer compatibility Description of the IE Reference Standards Description of the IE Information Element (IE)

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

Low layer compatibility

A SETUP message is considered as an example here. In this 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Progress indicator Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Repeat indicator Description of the IE Reference Standards Description of the IE 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

A SETUP message is considered as an example here. In this 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Bearer capability Description of the IE Reference Standards Description of the IE 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.

Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Called party BCD number Description of the IE Reference Standards Description of the IE 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 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

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Calling party BCD number Description of the IE Reference Standards Description of the IE 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 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 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.

Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

A Interface Protocol Description of the A Interface Protocol Description of the Common Part of Messages 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 Associated IEs Parent topic: Appendix - Protocol Compliance Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the A Interface Protocol Scenario Description Protocol Stack Message List Scenario Description 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. This message is sent from the MSC server to the BSS 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. This message is sent from the MSC server to the BSS 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. This message is sent from the target BSS to the MSC server via the relevant SCCP connection. It indicates that the correct MS has successfully accessed the target cell. This message is sent from the target BSS to the MSC 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. This message is sent from the MSC server to the BSS to instruct the BSS to select another core network. This message applies only to the 2G MOCN flow. This message is sent from the MSC server to the BSS to 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Common Part of Messages 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.

A LOCATION UPDATING REQUEST message is considered as an 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

A LOCATION UPDATING REQUEST message is considered as an 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. Parent topic: A Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Assignment Messages ASSIGNMENT REQUEST ASSIGNMENT COMPLETE ASSIGNMENT FAILURE Parent topic: A Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 the main IEs of the message. Figure 1 ASSIGNMENT REQUEST message

Associated IEs Information Element (IE)

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. For details, see Message Type.

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Message Type

Identifies the message being sent. It is a single-octet IE and mandatory in all messages. In an ASSIGNMENT COMPLETE message, Message Type takes the fixed value 2. For details, see Message Type.

radio resource (RR) Cause

Indicates the reason passed from the radio interface to the MSC transparently. For details, see RR Cause.

Circuit Identity Code

Defines the terrestrial channel over which the call will pass. For details, see Circuit Identity Code. 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. Parent topic: Description of Assignment Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Message Type

Identifies the message being sent. It is a single-octet IE and mandatory in all messages. In an ASSIGNMENT FAILURE Message, Message Type takes the fixed value 3. For details, see Message Type.

Cause

Indicates the reason why an assignment failure was encountered. For details, see Cause.

radio resource (RR) Cause

Indicates the reason passed from the radio interface to the MSC transparently. For details, see RR Cause.

Reference Standards For details, see 3.2.1.3 "ASSIGNMENT FAILURE" in 3rd Generation Partnership Project (3GPP) TS48008-840. Parent topic: Description of Assignment Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Cipher Mode Control Messages CIPHER MODE COMMAND CIPHER MODE COMPLETE Parent topic: A Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Message Type

Identifies the message being sent. It is a single-octet IE and mandatory in all messages. In a CIPHER MODE COMMAND message, Message Type takes the fixed value 83. For details, see Message 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. 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 Project (3GPP) TS48008-840. Parent topic: Description of Cipher Mode Control Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Message Type

Identifies the message being sent. It is a single-octet IE and mandatory in all messages. In a CIPHER MODE COMPLETE message, Message Type takes the fixed value 85. For details, see Message Type.

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 Project (3GPP) TS48008-840.

Parent topic: Description of Cipher Mode Control Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Paging Messages PAGING PAGING RESPONSE Parent topic: A Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Message Type

Description Identifies the message being sent. It is a single-octet IE and mandatory in all messages. In a PAGING message, Message Type takes the fixed value 82.

For details, see Message Type. 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Protocol Discriminator

Identifies the L3 protocol to which the L3 message belongs. For details, see Protocol Discriminator.

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. For details, see Skip indicator.

Message Type

Identifies the message being sent. It is a single-octet IE and mandatory in all messages. In a PAGING RESPONSE message, Message Type takes the fixed value 39. For details, see Message Type.

Ciphering Key Sequence Number

Indicates the sequence number of the ciphering key. For details, see Ciphering Key Sequence Number.

Spare Half Octet

Reserved for future use. It is half-octet long. For details, see Spare Half Octet.

Mobile Station Classmark 2

Includes classmark2 corresponding to the frequency band in use. For details, see Classmark Information Type 2.

Mobile Identity

Provides identity information of the MS. For details, see Mobile Identity.

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

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Handover Management Messages HANDOVER REQUEST HANDOVER REQUIRED HANDOVER REQUEST ACKNOWLEDGE HANDOVER COMMAND HANDOVER COMPLETE HANDOVER DETECT Parent topic: A Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Message Type

Identifies the message being sent. It is a single-octet IE and mandatory in all messages. In a HANDOVER REQUEST message, Message Type takes the fixed value 16. For details, see Message Type.

Channel Type

Provides information such as channel rate, channel type, and permitted speech version. For details, see Channel Type.

Encryption Information

Contains the user data encryption information used to control any encryption equipment at the BSS. The encryption information includes the permitted A5 algorithm(s). For details, see Encryption Information.

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.

Circuit Identity Code

Identifies a circuit between SPCs. For details, see Circuit Identity Code.

Cell Identifier (Target)

Identifies the target cell. For details, see Cell Identifier.

Cause

Indicates the reason for a handover to have occurred. For details, see Cause.

Speech Version (Used)

Indicates the speech version being used by the BSS. For details, see Speech Version.

Chosen Encryption Algorithm (Serving)

Indicates the encryption algorithm being used by the BSS. For details, see Chosen Encryption Algorithm.

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Message Type

Identifies the message being sent. It is a single-octet IE and mandatory in all messages. In a HANDOVER REQUIRED message, Message Type takes the fixed value 17. For details, see Message Type.

Cause

Indicates the reason for a handover to have occurred. For details, see Cause. 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)

Indicates the speech version being used by the BSS. This IE is included only when the channel is used for speech service. For details, see Speech Version.

Reference Standards For details, see 3.2.1.9 "HANDOVER REQUIRED" in 3rd Generation Partnership Project (3GPP) TS48008-840. Parent topic: Description of Handover Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Message Type

Identifies the message being sent. It is a single-octet IE and mandatory in all messages. In a HANDOVER REQUEST ACKNOWLEDGE message, Message Type

takes the fixed value 18. For details, see Message Type. 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.

Chosen Encryption Algorithm

Indicates the encryption algorithm being used by the target BSS. For details, see Chosen Encryption Algorithm.

Reference Standards For details, see 3.2.1.10 "HANDOVER REQUEST ACKNOWLEDGE" in 3rd Generation Partnership Project (3GPP) TS48008-840. Parent topic: Description of Handover Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Message Type

Indicates the type of message. For a HANDOVER COMMAND message, the message type is bssmap-Handover-Command. For details, see Message Type.

Layer 3 Information

Provides radio channel information. For details, see Layer 3 Information.

Cell Identifier

Identifies a cell. For details, see Cell Identifier.

Reference Standards For details, see 3.2.1.11 "HANDOVER COMMAND" in 3rd Generation Partnership Project (3GPP) TS48008-840. Parent topic: Description of Handover Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Message Type

Indicates the type of message. For a HANDOVER COMPLETE message, the message type is bssmap-Handover-Complete. For details, see Message Type.

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.

For details, see RR Cause. Reference Standards For details, see 3.2.1.12 "HANDOVER COMPLETE" in 3rd Generation Partnership Project (3GPP) TS48008-840. Parent topic: Description of Handover Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Message Type

Indicates the type of message. For a HANDOVER DETECT message, the message type is bssmap-Handover-Detect. For details, see Message Type.

Reference Standards For details, see 3.2.1.40 "HANDOVER DETECT" in 3rd Generation Partnership Project (3GPP) TS48008-840. Parent topic: Description of Handover Management Messages

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Resource Release Messages CLEAR COMMAND CLEAR COMPLETE Parent topic: A Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 shows the main IEs of the message. Figure 1 CLEAR COMMAND message

Associated IEs Information Element (IE)

Description

Message Type

Indicates the type of message. For a CLEAR COMMAND message, the message type is bssmap-Clear-Command.

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.

Cause

Indicates the reason why resources are released. Generally, resource release is initiated for call control purposes. For details, see Cause.

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 shows the main IEs of the message. Figure 1 CLEAR COMPLETE message

Associated IEs Information Element (IE)

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

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated IEs Message Type Encryption Information Channel Type Cell Identifier Priority Classmark Information Type 2 Circuit Identity Code RR Cause Layer 3 Information Cell Identifier List Classmark Information Type 1 Chosen Channel Chosen Encryption Algorithm Current Channel Type 1 Cause Speech Version eMLPP Priority IMSI TMSI Layer 3 Header Information CSFB Indication Redirect Attempt Flag Parent topic: A Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Message Type Description of the IE Reference Standards Description of the IE Information Element (IE)

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Encryption Information Description of the IE Reference Standards Description of the IE Information Element (IE)

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:

Encryption Information

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Channel Type Description of the IE Reference Standards Description of the IE Information Element (IE)

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.

Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Cell Identifier Description of the IE Reference Standards Description of the IE Information Element (IE)

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Priority Description of the IE Reference Standards Description of the IE Information Element (IE)

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Classmark Information Type 2 Description of the IE Reference Standards Description of the IE 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 For details, see 10.5.1.6 "Mobile Station Classmark 2" in 3rd Generation Partnership Project (3GPP) TS24008-830. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Circuit Identity Code Description of the IE Reference Standards Description of the IE Information Element (IE)

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.

Circuit Identity Code

An ASSIGNMENT REQUEST message is considered as an 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RR Cause Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the reason for a message to have been sent.

Radio Resource (RR) Cause

An ASSIGNMENT COMPLETE message is considered as an example here. In this example, rr-cause is 0, indicating that sending of that message is a normal event and does not result from any errors.

Reference Standards For details, see 3.2.2.22 "Mobile Station Classmark 1" in 3rd Generation Partnership Project (3GPP) TS48008-840. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Layer 3 Information Description of the IE Reference Standards Description of the IE Information Element (IE)

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Cell Identifier List Description of the IE Reference Standards Description of the IE 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.

Cell Identifier List

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.

Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Classmark Information Type 1 Description of the IE Reference Standards Description of the IE 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.

A LOCATION UPDATING REQUEST message is considered as an 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 For details, see 10.5.1.5 "Mobile Station Classmark 1" in 3rd Generation Partnership Project (3GPP) TS24008-830. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Chosen Channel Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Chosen Encryption Algorithm Description of the IE Reference Standards Description of the IE 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 Project (3GPP) TS24008-840. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Current Channel Type 1 Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Cause Description of the IE Reference Standards Description of the IE 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 For details, see 3.2.2.5 "Cause" in 3rd Generation Partnership Project (3GPP) TS48008840. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Speech Version Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

eMLPP Priority Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

IMSI Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

TMSI Description of the IE Reference Standards Description of the IE Information Element (IE)

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Layer 3 Header Information Description of the IE Reference Standards Description of the IE 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.

An ASSIGNMENT REQUEST message is considered as an 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

CSFB Indication Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Redirect Attempt Flag 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.

Redirect Attempt Flag

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Iu-CS Interface Protocol Description of the Iu-CS Interface Protocol Description of the Common Part of Messages 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 Associated IEs Parent topic: Appendix - Protocol Compliance Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Iu-CS Interface Protocol Scenario Description Protocol Stack Message List Scenario Description 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. This message is sent by the MSC to 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

This message is sent by the MSC to 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. This message is sent by the MSC to the source RNC to inform that resources for the relocation are allocated in the target RNC. This message is sent by the MSC to 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. This message is sent by the MSC to inform the RNC of the permanent NAS UE identity and additional information of a subscriber. This message is sent by the MSC to 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Common Part of Messages Table 1 IEs carried in the common part of messages 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). Parent topic: Iu-CS Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the User Identity Messages COMMON ID Parent topic: Iu-CS Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Message Type

Uniquely identifies the message being sent. In a COMMON ID message, Message type is COMMON ID. For details, see Message Type.

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Messages Used in the RAB Assignment Flow RAB ASSIGNMENT REQUEST RAB ASSIGNMENT RESPONSE Parent topic: Iu-CS Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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

Provides the detailed information about the RABs to be released. For details, see RABs To Be Released Item IEs.

Cause

Contains the cause of the release of a RAB. For details, see Cause.

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

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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

Provides the detailed information about the established or modified RABs. For details, see RABs Setup Or Modified Item IEs.

RAB ID

Indicates the ID of a RAB. For details, see RAB ID.

RABs Released List

Provides a list of the released RABs. For details, see RABs Released List.

RABs Released Item IEs

Provides the detailed information about the 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

Provides the detailed information about the 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. For details, see Cause.

Reference Standards For details, see 9.1.4 "RAB ASSIGNMENT RESPONSE" in 3rd Generation Partnership Project (3GPP) 25413-801. Parent topic: Description of the Messages Used in the RAB Assignment Flow Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Encryption Mode Messages SECURITY MODE COMMAND SECURITY MODE COMPLETE Parent topic: Iu-CS Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

SECURITY MODE COMMAND 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 Information Element (IE)

Description

Message Type

Uniquely identifies the message being sent. In a SECURITY MODE COMMAND message, Message type is SECURITY MODE COMMAND. For details, see Message Type.

Integrity Protection Information

Contains the integrity protection information, including the key and available algorithms. For details, see Integrity Protection Information.

Encryption Information

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

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 Project (3GPP) 25413-801. Parent topic: Description of the Encryption Mode Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Information Element (IE)

Description

Message Type

Uniquely identifies the message being sent. In a SECURITY MODE COMPLETE message, Message type is SECURITY MODE COMPLETE. For details, see Message Type.

Chosen Integrity Protection Algorithm

Indicates the integrity protection algorithm being used by the RNC. For details, see Chosen Integrity Protection Algorithm.

Chosen Encryption Algorithm

Indicates the encryption algorithm being used by the RNC. For details, see Chosen Encryption Algorithm.

Reference Standards For details, see 9.1.27 "SECURITY MODE COMPLETE" in 3rd Generation Partnership Project (3GPP) 25413-801. Parent topic: Description of the Encryption Mode Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Paging Messages PAGING Paging response Parent topic: Iu-CS Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 main IEs of the message.

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. For details, see Message Type.

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. For details, see Permanent NAS UE Identity.

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Protocol Discriminator

Indicates the Layer 3 protocol to which the Layer 3 messages belong. For details, see Protocol Discriminator.

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. For details, see Skip indicator.

Message Type

Uniquely identifies a message. Message Type occupies one byte. In a PAGING RESPONSE message, Message Type is 39. For details, see Message Type.

Ciphering Key Sequence Number

Indicates the sequence number of the ciphering key. For details, see Ciphering Key Sequence Number.

Spare Half Octet

Indicates the reserved half Octet. For details, see Spare Half Octet.

Mobile Station Classmark 2

Indicates Classmark2 of the UE. For details, see Classmark Information Type 2.

Mobile Identity

Identifies a UE. For details, see Mobile Identity.

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Messages Used in the Relocation Flow RELOCATION REQUIRED RELOCATION COMMAND RELOCATION REQUEST RELOCATION REQUEST ACKNOWLEDGE RELOCATION DETECT RELOCATION COMPLETE Parent topic: Iu-CS Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description Uniquely identifies the message being sent. In a RELOCATION REQUIRED message,

Message Type

Message type is RELOCATION REQUIRED. For details, see Message Type.

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. For details, see Cause.

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Information Element (IE)

Description

Message Type

Uniquely identifies the message being sent. In a RELOCATION COMMAND message, Message type is RELOCATION COMMAND. For details, see Message Type.

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

L3 Information

Contains the radio interface message. For details, see L3 Information.

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

Provides the detailed information about the 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. For details, see RAB ID.

Reference Standards For details, see 9.1.12 "RELOCATION COMMAND" in 3rd Generation Partnership Project (3GPP) 25413-801. Parent topic: Description of the Messages Used in the Relocation Flow Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Message Type

Uniquely identifies the message being sent. In a RELOCATION REQUEST message, Message type is RELOCATION REQUEST. For details, see Message Type.

Permanent NAS UE Identity

Identifies a UE in the universal terrestrial radio access network (UTRAN) and the CN. For details, see Permanent NAS UE Identity.

Cause

Indicates the cause of the relocation. For details, see Cause.

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

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

Provides the detailed information about the RABs to be established. For details, see RABs To Be Setup Item IEs.

Transport Layer Address

Indicates the address of the transport layer. For details, see Transport Layer Address.

Iu Transport Association

Indicates the association between a radio access bearer (RAB) and the corresponding transport bearer. For details, see Iu Transport Association.

Integrity Protection Information

Contains the integrity protection information. For details, see Integrity Protection Information.

Encryption Information

Contains the data encryption information. For details, see 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.

Parent topic: Description of the Messages Used in the Relocation Flow Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Message Type

Uniquely identifies the message being sent. In 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 Transparent Container.

RABs Setup List

Provides a list of the established RABs. For details, see RABs Setup List.

RABs Setup Item IEs

Provides the detailed information about the established RABs. For details, see RABs Setup Item IEs.

RABs Failed To Setup List

Provides the detailed information about the RABs that are not successfully established. For details, see RABs Failed To Setup List.

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

Provides the detailed information about the RABs to be established. For details, see RABs To Be Setup Item IEs.

Transport Layer Address

Indicates the address of the transport layer. For details, see Transport Layer Address.

Iu Transport Association

Indicates the association between a radio access bearer (RAB) and the corresponding transport bearer. For details, see Iu Transport Association.

Integrity Protection Information

Contains the integrity protection information. For details, see Integrity Protection Information.

Encryption Information

Contains the data encryption information. For details, see Encryption Information. Identifies an Iu connection between the CN

Iu Signalling Connection Identifier

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. Parent topic: Description of the Messages Used in the Relocation Flow Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Message Type

Uniquely identifies the message being sent. In a RELOCATION DETECT message, Message type is RELOCATION DETECT. For details, see Message Type.

Reference Standards For details, see 9.1.13 "RELOCATION DETECT" in 3rd Generation Partnership Project (3GPP) 25413-801. Parent topic: Description of the Messages Used in the Relocation Flow Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 shows the main IEs of the message.

Figure 1 RELOCATION COMPLETE message Associated IEs Information Element (IE)

Description

Message Type

Uniquely identifies the message being sent. In a RELOCATION COMPLETE message, Message type is RELOCATION COMPLETE. For details, see Message Type.

Reference Standards For details, see 9.1.14 "RELOCATION COMPLETE" in 3rd Generation Partnership Project (3GPP) 25413-801. Parent topic: Description of the Messages Used in the Relocation Flow Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Release Messages IU RELEASE COMMAND IU RELEASE COMPLETE Parent topic: Iu-CS Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Information Element (IE)

Description

Message Type

Uniquely identifies the message being sent. In a IU RELEASE COMMAND message, Message type is IU RELEASE COMMAND. For details, see Message Type.

Cause

Indicates the cause of the release. For details, see Cause.

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Message Type

Uniquely identifies the message being sent. In a IU RELEASE COMPLETE message, Message type is IU RELEASE COMPLETE. For details, see Message Type.

Uniquely identifies a RAB for a UE. At present, RAB ID is radio access bearer (RAB) ID set to 1.

For details, see RAB ID. RABs Released List

Provides a list of released RABs. For details, see RABs Released List.

RABs Released Item IEs

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated IEs Cause Chosen Encryption Algorithm Chosen Integrity Protection Algorithm CN Domain Indicator Encryption Information First Setup Or Modify Item Global CN-ID Integrity Protection Information Iu Transport Association Key Status L3 Information Message Type MS Classmark 2 MS Classmark 3 NAS Synchronisation Indicator Paging Area ID Paging Cause Permanent NAS UE Identity RAB ID RAB Parameters RABs Failed To Release Item IEs RABs Failed To Release List RABs Failed To Setup Item IEs RABs Failed To Setup List RABs Released Item IEs RABs Released List

RABs Setup Item IEs RABs Setup List RABs Setup Or Modified Item IEs RABs Setup Or Modified List RABs To Be Released Item IEs RABs To Be Released List RABs To Be Setup Item IEs RABs To Be Setup List RABs To Be Setup Or Modified Item IEs RABs To Be Setup Or Modified List Relocation Type SNA Access Information Source ID Source RNC To Target RNC Transparent Container Iu Signalling Connection Identifier Target ID Target RNC To Source RNC Transparent Container Temporary UE Identity Transport Layer Address Transport Layer Information UP Mode Versions User Plane Information User Plane Mode End Of CSFB Parent topic: Iu-CS Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Cause Description of the IE Reference Standards Description of the IE 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 For details, see 9.2.1.4 "Cause" in 3rd Generation Partnership Project (3GPP) TS25413801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Chosen Encryption Algorithm Description of the IE Reference Standards Description of the IE 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 Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Chosen Integrity Protection Algorithm Description of the IE Reference Standards Description of the IE Information Element (IE)

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 Partnership Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

CN Domain Indicator Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Encryption Information Description of the IE Reference Standards Description of the IE 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.

Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

First Setup Or Modify Item Description of the IE Reference Standards Description of the IE 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 For details, see 9.1.3 "RAB ASSIGNMENT REQUEST" in 3rd Generation Partnership Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd.

Global CN-ID Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Integrity Protection Information Description of the IE Reference Standards Description of the IE 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 Project (3GPP) TS25413-801.

Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Iu Transport Association Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the association between a radio access bearer (RAB) and the corresponding transport bearer.

Iu Transport Association

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Key Status Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

L3 Information Description of the IE Reference Standards Description of the IE Information Element (IE)

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.

Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Message Type Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MS Classmark 2 Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MS Classmark 3 Description of the IE Reference Standards Description of the IE Information Element (IE)

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

NAS Synchronisation Indicator Description of the IE Reference Standards Description of the IE 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 Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Paging Area ID Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Paging Cause Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the cause for paging a UE.

Paging Cause

pagingCause: Indicates the reason for the paging. The PAGING message is considered as an example here. In this 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Permanent NAS UE Identity Description of the IE Reference Standards Description of the IE Information Element (IE) Description 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RAB ID Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RAB Parameters Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RABs Failed To Release Item IEs Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Provides the detailed information about the RABs that are not successfully released.

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 For details, see 9.1.4 "RAB ASSIGNMENT RESPONSE" in 3rd Generation Partnership Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RABs Failed To Release List Description of the IE Reference Standards Description of the IE 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 successfully released. 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 For details, see 9.1.4 "RAB ASSIGNMENT RESPONSE" in 3rd Generation Partnership Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RABs Failed To Setup Item IEs Description of the IE Reference Standards Description of the IE Information Element (IE) Description 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 For details, see 9.1.11 "RELOCATION REQUEST ACKNOWLEDGE" in 3rd Generation Partnership Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RABs Failed To Setup List Description of the IE Reference Standards Description of the IE 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. The RELOCATION REQUEST ACKNOWLEDGE message is considered as an example here. The message indicates that the RABs Failed To Setup List contains only one rAB-FailedItem. Reference Standards For details, see 9.1.11 "RELOCATION REQUEST ACKNOWLEDGE" in 3rd Generation Partnership Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RABs Released Item IEs Description of the IE Reference Standards Description of the IE 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. The IU RELEASE COMPLETE message is considered as an 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 Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RABs Released List Description of the IE Reference Standards Description of the IE 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. The IU RELEASE COMPLETE message is considered as an example here. The message indicates that the RABs Released List contains only one rAB-ReleasedItem. Reference Standards For details, see 9.1.4 "RAB ASSIGNMENT RESPONSE" in 3rd Generation Partnership Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RABs Setup Item IEs Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Provides the detailed information about the established RABs.

RABs Setup Item IEs

rAB-ID: RABID. For details, see RAB ID. The RELOCATION REQUEST ACKNOWLEDGE message is 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 For details, see 9.1.11 "RELOCATION REQUEST ACKNOWLEDGE" in 3rd Generation Partnership Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RABs Setup List Description of the IE Reference Standards Description of the IE 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. The RELOCATION REQUEST ACKNOWLEDGE message is considered as an example here. The message indicates that the RABs Setup List contains only one rAB-SetupItem. Reference Standards For details, see 9.1.11 "RELOCATION REQUEST ACKNOWLEDGE" in 3rd Generation Partnership Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RABs Setup Or Modified Item IEs Description of the IE Reference Standards Description of the IE 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 example here. In this example, rAB-ID is 1, which indicates that the ID of the RAB for the UE is 1.

Reference Standards For details, see 9.1.4 "RAB ASSIGNMENT RESPONSE" in 3rd Generation Partnership Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RABs Setup Or Modified List Description of the IE Reference Standards Description of the IE 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 For details, see 9.1.4 "RAB ASSIGNMENT RESPONSE" in 3rd Generation Partnership Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RABs To Be Released Item IEs Description of the IE Reference Standards Description of the IE 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 ID of the RAB for the UE is 1.

Reference Standards For details, see 9.1.3 "RAB ASSIGNMENT REQUEST" in 3rd Generation Partnership Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RABs To Be Released List Description of the IE Reference Standards Description of the IE Information Element Description (IE) Provides a list of the RABs to be released.

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 For details, see 9.1.3 "RAB ASSIGNMENT REQUEST" in 3rd Generation Partnership Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RABs To Be Setup Item IEs Description of the IE Reference Standards Description of the IE 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). For details, see RAB ID. 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. The RELOCATION REQUEST message is considered as an example here. In this example, rAB-ID is 1, which indicates that the ID of the RAB for the UE is 1.

Reference Standards For details, see 9.1.10 "RELOCATION REQUEST" in 3rd Generation Partnership Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RABs To Be Setup List Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Provides a list of the RABs to be established.

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 For details, see 9.1.10 "RELOCATION REQUEST" in 3rd Generation Partnership Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RABs To Be Setup Or Modified Item IEs Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Provides the detailed information about the RABs to be established or modified.

RABs To Be Setup Or Modified Item IEs

The radio access bearer (RAB) ASSIGNMENT REQUEST message is considered as an example here. Reference Standards For details, see 9.1.3 "RAB ASSIGNMENT REQUEST" in 3rd Generation Partnership Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RABs To Be Setup Or Modified List Description of the IE Reference Standards Description of the IE 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 established or modified. 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 For details, see 9.1.3 "RAB ASSIGNMENT REQUEST" in 3rd Generation Partnership Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Relocation Type Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

SNA Access Information Description of the IE Reference Standards Description of the IE 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. pLMNidentity: Identifies a PLMN. 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Source ID Description of the IE Reference Standards Description of the IE 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

pLMNidentity: Identifies a PLMN. rNC_ID: Indicates the ID of the RNC. The RELOCATION REQUIRED message is considered as an 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Source RNC To Target RNC Transparent Container Description of the IE Reference Standards Description of the IE 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. 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.28 "Source RNC To Target RNC Transparent Container" in 3rd Generation Partnership Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Iu Signalling Connection Identifier Description of the IE Reference Standards Description of the IE Information Element (IE)

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. The RELOCATION REQUEST message is considered as an 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 Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Target ID Description of the IE Reference Standards Description of the IE 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 considered as an example here. The message indicates that the 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Target RNC To Source RNC Transparent Container Description of the IE Reference Standards Description of the IE Information Element (IE)

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 Generation Partnership Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Temporary UE Identity Description of the IE Reference Standards Description of the IE 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. The PAGING message is considered as an example here. In this 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Transport Layer Address Description of the IE Reference Standards Description of the IE 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).

Transport Layer Address transportLayerAddress: Indicates the address to be used in the transport layer. The RELOCATION REQUEST message is considered as an example here. Reference Standards For details, see 9.2.2.1 "Transport Layer Address" in 3rd Generation Partnership Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Transport Layer Information Description of the IE Reference Standards Description of the IE Information Element (IE) Description 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 For details, see 9.1.3 "RAB ASSIGNMENT REQUEST" in 3rd Generation Partnership Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

UP Mode Versions Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

User Plane Information Description of the IE Reference Standards Description of the IE 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. The RELOCATION REQUEST message is considered as an 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 For details, see 9.1.3 "RAB ASSIGNMENT REQUEST" in 3rd Generation Partnership Project (3GPP) TS25413-801. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

User Plane Mode Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

End Of CSFB Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

C/D Interface Protocol Description of C/D Interface Protocol Description of the Common Part of Messages 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 Associated IEs Parent topic: Appendix - Protocol Compliance Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of C/D Interface Protocol Scenario Description Protocol Stack Message List Scenario Description 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 This message is sent HLRstation roaming numb >MSC/VLR MSC/VLR. This message is sent MSC/VLRacknowledge the >HLR MAP_PROVIDE_ROA MSC/VLR- This message is sent >HLR request the location u This message is sent HLRacknowledge the MAP >MSC/VLR message. HLRThis message is sent >MSC/VLR cancel a location upda This message is sent MSC/VLR- acknowledge the MAP

>HLR

message.

HLRThis message is sent >MSC/VLR insert the subscriber d This message is sent MSC/VLRMAP_INSERT_SUBSCRIBER_DATA_RSP acknowledge the >HLR MAP_INSERT_SUBS This message is sent MSC/VLRMAP_PURGE_MS_REQ location information of >HLR deletes the subscribe HLRThis message is sent MAP_PURGE_MS_CNF >MSC/VLR acknowledge the MAP MSC/VLR- This message is sent MAP_SEND_AUTHENTICATION_INFO_REQ >HLR authentication set from This message is sent HLRMAP_SEND_AUTHENTICATION_INFO_CNF acknowledge the >MSC/VLR MAP_SEND_AUTHEN MSC/VLR- This message is sent MAP_AUTHENTICATION_FAILURE_REPORT_REQ >HLR report the authenticat This message is sent HLRacknowledge the MAP_AUTHENTICATION_FAILURE_REPORT_CNF >MSC/VLR MAP_AUTHENTICATI message. MSC/VLR- This message is sent MAP_READY_FOR_SHORT_MESSAGE_REQ >HLR of the subscriber reac This message is sent HLRMAP_READY_FOR_SHORT_MESSAGE_CNF acknowledge the >MSC/VLR MAP_READY_FOR_S HLRThis message is sent MAP_PROVIDE_SUBSCRIBER_INFO_IND >MSC/VLR information of the sub This message is sent MSC/VLRMAP_PROVIDE_SUBSCRIBER_INFO_RSP acknowledge the >HLR MAP_PROVIDE_SUB This message is sent MSC/VLRMAP_PROCESS_UNSTRUCTURED_SS_REQUEST_REQ unstructured supplem >HLR operation from the HL This message is sent HLRacknowledge the MAP_PROCESS_UNSTRUCTURED_SS_REQUEST_CNF >MSC/VLR MAP_PROCESS_UN message. HLRThis message is sent 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 MSC/VLR- This message is sent acknowledge the >HLR MAP_UNSTRUCTURE

This message is sent HLRthe HLR) to request a >MSC/VLR subscriber, in connect MSC/VLR- This message is sent >HLR register data related t HLRThis message is sent >MSC/VLR acknowledge the MAP MSC/VLR- This message is sent >HLR activate a supplement HLRThis message is sent >MSC/VLR acknowledge the MAP MSC/VLR- This message is sent >HLR deactivate a suppleme HLRThis message is sent >MSC/VLR acknowledge the MAP MSC/VLR- This message is sent >HLR interrogate a supplem This message is sent HLRacknowledge the MAP >MSC/VLR message. MSC/VLR- This message is sent >HLR supplementary service HLRThis message is sent >MSC/VLR acknowledge the MAP

Parent topic: C/D Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Common Part of Messages Reference Standards Table 1 IEs carried in the common part of messages 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 The MAP_SEND_ROUTING_INFORMATION_REQ message is 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. Parent topic: C/D Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of MSRN Management Messages MAP_SEND_ROUTING_INFORMATION_REQ MAP_SEND_ROUTING_INFORMATION_CNF MAP_PROVIDE_ROAMING_NUMBER_IND MAP_PROVIDE_ROAMING_NUMBER_RSP Parent topic: C/D Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_SEND_ROUTING_INFORMATION_REQ 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 Partnership Project (3GPP) TS29002-870. Parent topic: Description of MSRN Management Messages Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd.

MAP_SEND_ROUTING_INFORMATION_CNF 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 shows the main IEs of the message. Figure 1 MAP_SEND_ROUTING_INFORMATION_CNF message

Associated IEs

Information Element (IE)

Description

Invoke Id

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

Mobile Station International ISDN Number (MSISDN)

Indicates the MSISDN of the subscriber. For details, see MSISDN.

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 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 For details, see 10.1 "MAP_SEND_ROUTING_INFORMATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of MSRN Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_PROVIDE_ROAMING_NUMBER_IND 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

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

Indicates the IMSI of the subscriber. international mobile subscriber identity (IMSI) For details, see IMSI. Mobile Station International ISDN Number (MSISDN)

Indicates the MSISDN of the subscriber. For details, see 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.

Call Reference Number

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 Partnership Project (3GPP) TS29002-870. Parent topic: Description of MSRN Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_PROVIDE_ROAMING_NUMBER_RSP 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 shows the main IEs of the message. Figure 1 MAP_PROVIDE_ROAMING_NUMBER_RSP message

Associated IEs Information Element (IE)

Description

Invoke Id

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

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 For details, see 10.2 "MAP_PROVIDE_ROAMING_NUMBER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of MSRN Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Location Management Messages MAP_UPDATE_LOCATION_REQ MAP_UPDATE_LOCATION_CNF MAP_CANCEL_LOCATION_IND MAP_CANCEL_LOCATION_RSP Parent topic: C/D Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_UPDATE_LOCATION_REQ 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 Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue.

For details, see Invoke Id. Indicates the IMSI of the subscriber. international mobile subscriber identity (IMSI) For details, see IMSI. 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.

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 Reference Standards For details, see 8.1.2 "MAP_UPDATE_LOCATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Location Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_UPDATE_LOCATION_CNF 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

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

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 For details, see 8.1.2 "MAP_UPDATE_LOCATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Location Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_CANCEL_LOCATION_IND 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 Uniquely identifies an operation in a Mobile Application Part

Invoke Id

(MAP) dialogue. For details, see Invoke Id.

Indicates the IMSI of the subscriber. international mobile subscriber identity (IMSI) For details, see IMSI. 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 Project (3GPP) TS24008-870. Parent topic: Description of Location Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_CANCEL_LOCATION_RSP 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

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

Reference Standards For details, see 8.1.3 "MAP_CANCEL_LOCATION service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Location Management Messages

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Subscriber Data Management Messages MAP_INSERT_SUBSCRIBER_DATA_IND MAP_INSERT_SUBSCRIBER_DATA_RSP MAP_PURGE_MS_REQ MAP_PURGE_MS_CNF Parent topic: C/D Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_INSERT_SUBSCRIBER_DATA_IND 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 Information Element (IE)

Description

Invoke Id

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

international mobile subscriber identity (IMSI)

Indicates the IMSI of the subscriber. For details, see IMSI.

Mobile Station International Indicates the MSISDN of the subscriber. ISDN Number (MSISDN) For details, see 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

Indicates all the Operator Determined Barring categories that 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 Partnership Project (3GPP) TS24008-870. Parent topic: Description of Subscriber Data Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 main IEs of the message. Figure 1 MAP_INSERT_SUBSCRIBER_DATA_RSP message

Associated IEs Information Element (IE)

Description

Invoke Id

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

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

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. Regional Subscription Response

Indicates the regional subscription response. For details, see Regional Subscription Response.

Supported Customized Applications for Mobile network Enhanced Logic (CAMEL) Phases

Indicates which phases of CAMEL are supported in the VLR. For details, see Supported CAMEL Phases.

Reference Standards For details, see 8.8.1 "MAP_INSERT_SUBSCRIBER_DATA service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Subscriber Data Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Invoke Id

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

IMSI

Indicates the IMSI of the subscriber. For details, see IMSI.

VLR number

Indicates the VLR number of the subscriber. For details, see VLR number.

Reference Standards For details, see 8.1.6 "MAP_PURGE_MS service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Subscriber Data Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Invoke Id

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

Reference Standards For details, see 8.1.6 "MAP_PURGE_MS service" in 3rd Generation Partnership Project (3GPP) TS29002-870.

Parent topic: Description of Subscriber Data Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Authentication Messages MAP_SEND_AUTHENTICATION_INFO_REQ MAP_SEND_AUTHENTICATION_INFO_RSP MAP_AUTHENTICATION_FAILURE_REPORT_REQ MAP_AUTHENTICATION_FAILURE_REPORT_RSP Parent topic: C/D Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_SEND_AUTHENTICATION_INFO_REQ 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. For details, see Invoke Id.

International mobile Indicates the IMSI number of the subscriber. subscriber identity For details, see IMSI. (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 Partnership Project (3GPP) TS29002-870. Parent topic: Description of Authentication Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 shows the main IEs of the message. Figure 1 MAP_SEND_AUTHENTICATION_INFO_RSP message

Associated IEs Information Element (IE)

Description

Invoke Id

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

AuthenticationSetList

Indicates a list of authentication sets. For details, see AuthenticationSetList.

Reference Standards For details, see 8.5.2 "MAP_SEND_AUTHENTICATION_INFO service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Authentication Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_AUTHENTICATION_FAILURE_REPORT_REQ 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. For details, see Invoke Id.

international Indicates the IMSI of the subscriber. mobile subscriber For details, see IMSI. 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. For details, see VLR number.

Reference Standards For details, see 8.5.3 "MAP_AUTHENTICATION_FAILURE_REPORT service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Authentication Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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. For details, see Invoke Id.

Reference Standards For details, see 8.5.3 "MAP_AUTHENTICATION_FAILURE_REPORT service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Authentication Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of SMS Management Messages MAP_READY_FOR_SHORT_MESSAGE_REQ MAP_READY_FOR_SHORT_MESSAGE_RSP Parent topic: C/D Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_READY_FOR_SHORT_MESSAGE_REQ 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 main IEs of the message. Figure 1 MAP_READY_FOR_SHORT_MESSAGE_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. International Indicates the IMSI of the subscriber. mobile subscriber For details, see IMSI. 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 Project (3GPP) TS29002-870. Parent topic: Description of SMS Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 1 shows the main IEs of the message. Figure 1 MAP_READY_FOR_SHORT_MESSAGE_RSP message

Associated IEs Information Element (IE)

Description

Invoke Id

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

Reference Standards For details, see 12.4 "MAP-READY-FOR-SM service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of SMS Management Messages Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd.

Description of SS Management Messages MAP_PROCESS_UNSTRUCTURED_SS_REQUEST_REQ MAP_PROCESS_UNSTRUCTURED_SS_REQUEST_CNF MAP_PROVIDE_SUBSCRIBER_INFO_IND MAP_PROVIDE_SUBSCRIBER_INFO_RSP MAP_UNSTRUCTURED_SS_REQUEST_IND MAP_UNSTRUCTURED_SS_REQUEST_RSP MAP_UNSTRUCTURED_SS_NOTIFY_IND MAP_REGISTER_SS_REQ MAP_REGISTER_SS_RSP MAP_ACTIVATE_SS_REQ MAP_ACTIVATE_SS_RSP MAP_DEACTIVATE_SS_REQ MAP_DEACTIVATE_SS_RSP MAP_INTERROGATE_SS_REQ MAP_INTERROGATE_SS_RSP MAP_ERASE_SS_REQ MAP_ERASE_SS_RSP Parent topic: C/D Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 shows the main IEs of the message. Figure 1 MAP_PROCESS_UNSTRUCTURED_SS_REQUEST_REQ message

Associated IEs Information Element (IE)

Description

Invoke Id

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

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 For details, see MSISDN. (MSISDN) Reference Standards For details, see 11.9 "MAP_PROCESS_UNSTRUCTURED_SS_REQUEST service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of SS Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_PROCESS_UNSTRUCTURED_SS_REQUEST_CNF 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 shows the main IEs of the message. Figure 1 MAP_PROCESS_UNSTRUCTURED_SS_REQUEST_CNF message

Associated IEs Information Element (IE)

Description

Invoke Id

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

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.

Parent topic: Description of SS Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_PROVIDE_SUBSCRIBER_INFO_IND 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

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

International Indicates the IMSI of the subscriber. mobile subscriber For details, see IMSI. 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. Parent topic: Description of SS Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 the main IEs of the message. Figure 1 MAP_PROVIDE_SUBSCRIBER_INFO_RSP 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. 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. Parent topic: Description of SS Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_UNSTRUCTURED_SS_REQUEST_IND 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

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

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.

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 Partnership Project (3GPP) TS29002-870. Parent topic: Description of SS Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_UNSTRUCTURED_SS_REQUEST_RSP 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

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

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.

Reference Standards For details, see 11.10 "MAP_UNSTRUCTURED_SS_REQUEST service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of SS Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_UNSTRUCTURED_SS_NOTIFY_IND 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 Uniquely identifies an operation in a Mobile Application Part (MAP)

Invoke Id

dialogue. For details, see Invoke Id.

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.

Alerting Pattern

Indicates the alerting pattern. For details, see Alerting Pattern.

Reference Standards For details, see 11.11 "MAP_UNSTRUCTURED_SS_NOTIFY service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of SS Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue.

For details, see Invoke Id. 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. Parent topic: Description of SS Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

Forwarding information

Indicates the call forwarding data. 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 For details, see 11.1 "MAP_REGISTER_SS service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of SS Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

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.

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.3 "MAP_ACTIVATE_SS service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of SS Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

Forwarding information

Indicates the call forwarding data. For details, see Forwarding information.

Call barring

Indicates the call barring information.

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.3 "MAP_ACTIVATE_SS service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of SS Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_DEACTIVATE_SS_REQ 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

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

SS-Code

Indicates the supplementary service code to be registered by the subscriber. For details, see SS-Code.

Basic service

Indicates the basic service to be registered by the subscriber. For details, see Basic service.

Reference Standards For details, see 11.4 "MAP_DEACTIVATE_SS service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of SS Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

Forwarding information

Indicates the call forwarding data. For details, see Forwarding information.

Call barring information

Indicates the 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 Project (3GPP) TS29002-870. Parent topic: Description of SS Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_INTERROGATE_SS_REQ 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

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

SS-Code

Indicates the supplementary service code registered by the subscriber. For details, see SS-Code.

Long FTN Supported

Indicates that the mobile station supports long forwarded-to numbers. For details, see Long FTN Supported.

Basic service

Indicates the basic service registered by the subscriber. For details, see Basic service.

Reference Standards For details, see 11.5 "MAP_INTERROGATE_SS service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of SS Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 shows the main IEs of the message.

Figure 1 MAP_INTERROGATE_SS_RSP message Associated IEs Information Element (IE)

Description

Invoke Id

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

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 For details, see 11.5 "MAP_INTERROGATE_SS service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of SS Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

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.

Reference Standards For details, see 11.2 "MAP_ERASE_SS service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of SS Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

Forwarding

Indicates the call forwarding data.

information

For details, see Forwarding information.

Reference Standards For details, see 11.2 "MAP_ERASE_SS service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of SS Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated IEs Access Type Alert Reason Alert Reason Indicator Alerting Pattern AuthenticationSetList Basic service Basic service Group LIST Bearer service List Call barring information Call barring information List Call Reference Number 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 information List Forwarding Reason GMSC Address

GMSC or gsmSCF Address GSM Bearer Capability HLR number IMSI Interrogation Type Invoke Id Location Information Long FTN Supported MC-Subscription Data MSC Address MSC Number MSISDN MSRN Network Signal Info No reply condition time Number of Forwarding Number of requested vectors Operator Determined Barring General data Operator Determined Barring HPLMN data Provider error Rand Re-attempt Regional Subscription Data 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 Parent topic: C/D Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Access Type Description of the IE Reference Standards Description of the IE 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 For details, see 8.5.3 "MAP_AUTHENTICATION_FAILURE_REPORT service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Alert Reason Description of the IE Reference Standards Description of the IE 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 For details, see 12.4 "MAP-READY-FOR-SM service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Alert Reason Indicator Description of the IE Reference Standards Description of the IE 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

The MAP_READY_FOR_SHORT_MESSAGE_REQ message is 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 For details, see 12.4 "MAP-READY-FOR-SM service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Alerting Pattern Description of the IE Reference Standards Description of the IE 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 For details, see 11.10 "MAP_UNSTRUCTURED_SS_REQUEST service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

AuthenticationSetList Description of the IE Reference Standards Description of the IE 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.

AuthenticationSetList

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 For details, see 8.5.2 "MAP_SEND_AUTHENTICATION_INFO service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Basic service Description of the IE Reference Standards Description of the IE 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 For details, see 11.1 "MAP_REGISTER_SS service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Basic service Group LIST Description of the IE Reference Standards Description of the IE 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 For details, see 11.5 "MAP_INTERROGATE_SS service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Bearer service List Description of the IE Reference Standards Description of the IE 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

For details, see 8.8.1 "MAP_INSERT_SUBSCRIBER_DATA service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Call barring information Description of the IE Reference Standards Description of the IE 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 For details, see 11.3 "MAP_ACTIVATE_SS service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Call barring information List Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates a list of extensible call barring information. It consists of the following subordinate IEs: ss-Code callBarringFeatureList

Call barring information 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 For details, see 8.8.1 "MAP_INSERT_SUBSCRIBER_DATA service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd.

Call Reference Number Description of the IE Reference Standards Description of the IE 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 considered as an example here. In this example, callReferenceNumber is 17 10 5A 13 A0 74, which indicates that the call reference number is allocated by the GMSC. Reference Standards For details, see 10.1 "MAP_SEND_ROUTING_INFORMATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Cancellation Type Description of the IE Reference Standards Description of the IE 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 For details, see 8.1.3 "MAP_CANCEL_LOCATION service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Category Description of the IE Reference Standards Description of the IE 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 For details, see 8.8.1 "MAP_INSERT_SUBSCRIBER_DATA service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

CLI restriction Info Description of the IE Reference Standards Description of the IE 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 For details, see 11.5 "MAP_INTERROGATE_SS service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

CUG information List Description of the IE Reference Standards Description of the IE 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 For details, see 8.8.1 "MAP_INSERT_SUBSCRIBER_DATA service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

EMLPP default priority Description of the IE Reference Standards Description of the IE 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 For details, see 11.1 "MAP_REGISTER_SS service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

EMLPP Info Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the EMLPP information.

Enhanced multi-level precedence and preemption (EMLPP) Info

maximumentitledPriority defaultPriority The MAP_INTERROGATE_SS_RSP message is considered as an 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 For details, see 11.5 "MAP_INTERROGATE_SS service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

eMLPP Subscription Data Description of the IE Reference Standards Description of the IE Information Element Description (IE) Indicates the eMLPP subscription data, including:

Enhanced multi-level precedence and preemption (eMLPP) Subscription Data

maximumentitledPriority defaultPriority The MAP-INSERT-SUBSCRIBER-DATA_RSP message is considered as an 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 For details, see 8.8.1 "MAP_INSERT_SUBSCRIBER_DATA service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Failure cause Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the reason for which an authentication failure occurs. Values: Wrong user response Wrong network signature

Failure cause

The MAP_INTERROGATE_SS_RSP message is considered as an example here. In this example, failureCause is wrongUserResponse. Reference Standards For details, see 8.5.3 "MAP_AUTHENTICATION_FAILURE_REPORT service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Forwarded-to number with subaddress Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the forwarded-to number.

Forwarded-to number with subaddress

nature-of-address-indicator number The MAP_REGISTER_SS_REQ message is considered as an 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 For details, see 11.1 "MAP_REGISTER_SS service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Forwarding Data Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the call forwarding data, including:

Forwarding Data forwardedToNumber nature-of-address-indicator 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 For details, see 10.1 "MAP_SEND_ROUTING_INFORMATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870.

Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Forwarding feature LIST Description of the IE Reference Standards Description of the IE 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 nature-of-address-indicator content The MAP_INTERROGATE_SS_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.

Reference Standards For details, see 11.5 "MAP_INTERROGATE_SS service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Forwarding information Description of the IE Reference Standards Description of the IE 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 nature-of-address-indicator content forwardingOptions forwarding-reason The MAP_REGISTER_SS_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 For details, see 11.1 "MAP_REGISTER_SS service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Forwarding information List Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates a list of call forwarding information.

Forwarding information List

forwardindFeatureList

bearerService forwardedToNumber nature-of-address-indicator 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 For details, see 8.8.1 "MAP_INSERT_SUBSCRIBER_DATA service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Forwarding Reason Description of the IE Reference Standards Description of the IE 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 The MAP_SEND_ROUTING_INFORMATION_REQ message is considered as an example here. In this example, forwardingReason is notReachable, which indicates that the call is forwarded because the subscriber is not reachable.

Reference Standards For details, see 10.1 "MAP_SEND_ROUTING_INFORMATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

GMSC Address Description of the IE Reference Standards Description of the IE 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 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 86139025, which indicates that the GMSC address is 86139025. Reference Standards For details, see 10.2 "MAP_PROVIDE_ROAMING_NUMBER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

GMSC or gsmSCF Address Description of the IE Reference Standards Description of the IE 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

nature-of-address-indicator content The MAP_SEND_ROUTING_INFORMATION_REQ 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 86139025, which indicates that the GMSC address is 86139025.

Reference Standards For details, see 10.1 "MAP_SEND_ROUTING_INFORMATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

GSM Bearer Capability Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the GSM bearer capability.

GSM Bearer Capability

protocolId signalInfo The MAP_PROVIDE_ROAMING_NUMBER_IND message is 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 For details, see 10.2 "MAP_PROVIDE_ROAMING_NUMBER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

HLR number Description of the IE Reference Standards Description of the IE 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

nature-of-address-indicator content The MAP_UPDATE_LOCATION_CNF message is considered as an example here. In this example, nature-of-address-indicator is international-number, which indicates that the number address nature is international; content is 861310751099, which indicates the HLR number is 861310751099.

Reference Standards For details, see 8.1.2 "MAP_UPDATE_LOCATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

IMSI Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the IMSI number of the subscriber.

International mobile content subscriber identity (IMSI) The MAP_PROVIDE_ROAMING_NUMBER_IND message is considered as an example here. In this example, content is 460000000030183, which indicates the IMSI is 460000000030183. Reference Standards For details, see 10.2 "MAP_PROVIDE_ROAMING_NUMBER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Interrogation Type Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the interrogation type. Values: Basic call Forwarding

Interrogation Type

The MAP_SEND_ROUTING_INFORMATION_REQ message is considered as an example here. In this example, interrogationType is basicCall, indicates that the interrogation type is basic call. Reference Standards For details, see 10.1 "MAP_SEND_ROUTING_INFORMATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Invoke Id Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue.

Invoke Id

The MAP_SEND_ROUTING_INFORMATION_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 For details, see 10.1 "MAP_SEND_ROUTING_INFORMATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Location Information Description of the IE Reference Standards Description of the IE 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-of-address-indicator: Indicates the number address nature. content: Inidcates the VLR number. The MAP_SEND_ROUTING_INFORMATION_CNF message is considered as an example here. In this example, 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 For details, see 10.1 "MAP_SEND_ROUTING_INFORMATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Long FTN Supported Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates whether to support the long forwarded-to number.

The MAP_REGISTER_SS_REQ message is considered as an 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 For details, see 11.1 "MAP_REGISTER_SS service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MC-Subscription Data Description of the IE Reference Standards Description of the IE 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). The MAP_INSERT_SUBSCRIBER_DATA_RSP message is considered as an example here. In this example, nbrSB is 0x2 and nbrUser is 0x01. Reference Standards For details, see 8.8.1 "MAP_INSERT_SUBSCRIBER_DATA service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Associated IEs

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MSC Address Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the MSC address.

nature-of-address-indicator content

MSC Address

The MAP_UPDATE_LOCATION_REQ message is considered as an example here. In this example, nature-of-address-indicator is international-number, which indicates that the number address nature is international; content is 861310751315, which indicates that the MSC address is 861310751315. Reference Standards For details, see 8.1.2 "MAP_UPDATE_LOCATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MSC Number Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the number of the MSC at which the subscriber resides.

nature-of-address-indicator content

MSC Number

The MAP_PROVIDE_ROAMING_NUMBER_IND 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 86139025, which indicates that the MSC number is 86139025. Reference Standards For details, see 10.2 "MAP_PROVIDE_ROAMING_NUMBER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MSISDN Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the MSISDN of the subscriber.

Mobile Station International ISDN Number (MSISDN)

nature-of-address-indicator content The MAP_SEND_ROUTING_INFORMATION_REQ message is 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 For details, see 10.1 "MAP_SEND_ROUTING_INFORMATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MSRN Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the MSRN allocated by the MSC serving the callee.

mobile station roaming number (MSRN)

content The MAP_SEND_ROUTING_INFORMATION_CNF message is considered as an example here. In this example, content is 86139025399, which indicates the newly allocated MSRN. Generally, this MSRN is in the same number segment as the MSC/VLR number.

Reference Standards For details, see 10.1 "MAP_SEND_ROUTING_INFORMATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Network Signal Info Description of the IE Reference Standards Description of the IE 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. The MAP_SEND_ROUTING_INFORMATION_REQ message is 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 For details, see 10.1 "MAP_SEND_ROUTING_INFORMATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

No reply condition time Description of the IE Reference Standards Description of the IE 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. The MAP_REGISTER_SS_REQ message is considered as an example here. In this example, noReplyConditionTime is 0x05.

Reference Standards For details, see 11.1 "MAP_REGISTER_SS service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Number of Forwarding Description of the IE Reference Standards Description of the IE 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. The MAP_SEND_ROUTING_INFORMATION_REQ message is considered as an example here. In this example, numberOfForwarding is 0x01.

Reference Standards For details, see 10.1 "MAP_SEND_ROUTING_INFORMATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Number of requested vectors Description of the IE Reference Standards Description of the IE 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 considered as an example here. In this example, numberOfRequestedVectors is 0x05.

Reference Standards For details, see 8.5.2 "MAP_SEND_AUTHENTICATION_INFO service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Operator Determined Barring General data Description of the IE Reference Standards Description of the IE Information Element (IE)

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 For details, see 8.8.1 "MAP_INSERT_SUBSCRIBER_DATA service" in 3rd Generation

Partnership Project (3GPP) TS24008-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Operator Determined Barring HPLMN data Description of the IE Reference Standards Description of the IE Information Element (IE)

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 The MAP_INSERT_SUBSCRIBER_DATA_IND message is considered as an example here. Reference Standards For details, see 8.8.1 "MAP_INSERT_SUBSCRIBER_DATA service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Provider error Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates a protocol-related error.

Provider error

The MAP_PROVIDE_ROAMING_NUMBER_IND message is considered as an example here. In this example, ie-provider-error is duplicated-invoke-id, which indicates the repeated invoking IDs exist.

Reference Standards For details, see 10.2 "MAP_PROVIDE_ROAMING_NUMBER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Rand Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the random number used for authentication.

Rand

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

Reference Standards For details, see 8.5.3 "MAP_AUTHENTICATION_FAILURE_REPORT service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Re-attempt Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates whether the failure occurs in a normal authentication attempt or in an authentication re-attempt.

Re-attempt

The MAP_AUTHENTICATION_FAILURE_REPORT_REQ message is 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 For details, see 8.5.3 "MAP_AUTHENTICATION_FAILURE_REPORT service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Regional Subscription Data Description of the IE Reference Standards Description of the IE Information Element Description (IE) Indicates the regional subscription area in which the subscriber is allowed to roam. Regional Subscription Data The MAP_INSERT_SUBSCRIBER_DATA_IND message is considered as an example here. In this example, regionalSubscriptionData is 00 00. Reference Standards For details, see 8.8.1 "MAP_INSERT_SUBSCRIBER_DATA service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Regional Subscription Response Description of the IE Reference Standards Description of the IE 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

Regional Subscription Response

The MAP_INSERT_SUBSCRIBER_DATA_RSP message is considered as an example here. In this example, regionalSubscriptionResponse is networkNodeAreaRestricted, indicates the reason for inserting the regional subscription data.

Reference Standards For details, see 8.8.1 "MAP_INSERT_SUBSCRIBER_DATA service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

ReleaseResourcesSupported Description of the IE Reference Standards Description of the IE Information Element (IE)

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 considered as an example here. In this example, releaseResourcesSupported is NULL, which indicates that the VMSC supports the MAP_RELEASE_RESOURCES service. Reference Standards For details, see 10.2 "MAP_PROVIDE_ROAMING_NUMBER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Requested information Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Requesting node type Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the type of the requesting node, include VLR and SGSN.

Requesting node type

The MAP_SEND_AUTHENTICATION_INFO_REQ message is considered as an example here. In this example, requestingNodeType is vlr, which indicates the VLR at the CS domain requests the authentication set.

Reference Standards For details, see 8.5.2 "MAP_SEND_AUTHENTICATION_INFO service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Roaming Number Description of the IE Reference Standards Description of the IE 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 considered as an example here. In this example, content is 86139025553, which indicates the MSRN allocated by the MSC serving the callee is 86139025553. Reference Standards For details, see 10.2 "MAP_PROVIDE_ROAMING_NUMBER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Roaming Restriction Due To Unsupported Feature Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates that the MSC/VLR performs roaming restriction because of unsupported features.

Roaming Restriction Due To Unsupported The MAP_INSERT_SUBSCRIBER_DATA_IND message is considered Feature as an example here. In this example, roamingRestrictionDueToUnsupportedFeature is NULL. Reference Standards For details, see 8.8.1 "MAP_INSERT_SUBSCRIBER_DATA service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Segmentation prohibited indicator Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates whether the new VLR allows segmentation of the response at Mobile Application Part (MAP) user level.

Segmentation prohibited indicator

The MAP_SEND_AUTHENTICATION_INFO_REQ message is considered as an example here. In this example, segmentationProhibited is NULL, which indicates the new VLR allows segmentation of the response at MAP user level.

Reference Standards For details, see 8.5.2 "MAP_SEND_AUTHENTICATION_INFO service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

SS-Code Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the supplementary service code registered by the mobile subscriber.

SS-Code The MAP_REGISTER_SS_REQ message is considered as an example here. In this example ss-Code is allSS. Reference Standards For details, see 11.1 "MAP_REGISTER_SS service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

SS-Data Description of the IE Reference Standards Description of the IE 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-Code: Indicates the supplementary service code. 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 For details, see 11.3 "MAP_ACTIVATE_SS service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

SS-Data List Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates a list of extensible SS-Data parameters.

SS-Data List ss-Code: Indicates the supplementary service code. ss-Status: Indicates the supplementary service status. a-bit: Indicates whether the supplementary service is activated. The MAP_INSERT_SUBSCRIBER_DATA_IND message is considered as an example here. In this example, ss-Code is allSS and a-bit is notactive. Reference Standards For details, see 8.8.1 "MAP_INSERT_SUBSCRIBER_DATA service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

SS-Status Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the status of the supplementary service.

SS-Status a-bit: Indicates whether the supplementary service is activated. The MAP_INTERROGATE_SS_RSP message is considered as an example here. In this example, a-bit is not-active. Reference Standards For details, see 11.5 "MAP_INTERROGATE_SS service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Subscriber State Description of the IE Reference Standards Description of the IE 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. The MAP_SEND_ROUTING_INFORMATION_CNF message is considered as an example here. In this example, assumedIdle is NULL, which indicates that the subscriber is in the idle state. Reference Standards For details, see 10.1 "MAP_SEND_ROUTING_INFORMATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Subscriber Status Description of the IE Reference Standards Description of the IE 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. The MAP_SEND_ROUTING_INFORMATION_CNF message is considered as an example here. In this example, subscriberStatus is service granted.

Reference Standards For details, see 8.8.1 "MAP_INSERT_SUBSCRIBER_DATA service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Supported CAMEL Phases Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates which phases of CAMEL are supported

Supported Customized Applications for Mobile network Enhanced Logic (CAMEL) Phases

phase4 The MAP_SEND_ROUTING_INFORMATION_REQ message is considered as an example here. In this example, phase4 is 0x01, which indicate the CAMEL phase 4 is supported.

Reference Standards For details, see 10.1 "MAP_SEND_ROUTING_INFORMATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Suppress T-CSI Description of the IE Reference Standards Description of the IE 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 The MAP_SEND_ROUTING_INFORMATION_REQ message is considered as an example here. In this example, suppress-T-CSI is NULL, which indicates that the T-CSI information is suppressed. Reference Standards For details, see 10.1 "MAP_SEND_ROUTING_INFORMATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Suppression of Announcement Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates that the call failure announcement is suppressed.

Suppression of Announcement

The MAP_SEND_ROUTING_INFORMATION_REQ message is considered as an example here. In this example, suppressionOfAnnouncement is NULL, which indicates the call failure announcement is suppressed as long as the Suppression of Announcement IE is contained.

Reference Standards For details, see 10.1 "MAP_SEND_ROUTING_INFORMATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Teleservice List Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates a list of teleservices.

Teleservice List

TELE-SERVICE-04: Indicates a type of teleservice. The MAP_INSERT_SUBSCRIBER_DATA_IND message is considered as an example here. In this example, TELE-SERVICE-04 is emergencyCalls, which indicates the emergency call service is supported. Reference Standards For details, see 8.8.1 "MAP_INSERT_SUBSCRIBER_DATA service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

TMSI Description of the IE Reference Standards Description of the IE Information Element (IE)

Description

Indicates the TMSI of the subscriber. temporary mobile subscriber identifier The MAP_READY_FOR_SHORT_MESSAGE_REQ message is (TMSI) considered as an example here. In this example, tmsi is 60 38 00 07. Reference Standards For details, see 12.4 "MAP-READY-FOR-SM service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

User error Description of the IE Reference Standards Description of the IE 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 For details, see 10.2 "MAP_PROVIDE_ROAMING_NUMBER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

USSD Data Coding Scheme Description of the IE Reference Standards Description of the IE Information Element (IE)

Description

Indicates the coding scheme of the USSD data. 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 For details, see 11.9 "MAP_PROCESS_UNSTRUCTURED_SS_REQUEST service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

USSD String Description of the IE Reference Standards Description of the IE Information Element (IE) Unstructured Supplementary Service Data (USSD) String

Description Indicates the USSD character string. 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 For details, see 11.9 "MAP_PROCESS_UNSTRUCTURED_SS_REQUEST service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

VLR CAMEL Subscription Info Description of the IE Reference Standards Description of the IE 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 Applications for Mobile 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. The MAP_INSERT_SUBSCRIBER_DATA_RSP 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 000000, which indicates that the specific gsmSCF address is 000000. Reference Standards For details, see 8.8.1 "MAP_INSERT_SUBSCRIBER_DATA service" in 3rd Generation Partnership Project (3GPP) TS24008-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

VLR number Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the number of the VLR at which the subscriber resides.

nature-of-address-indicator content

VLR number

The MAP_UPDATE_LOCATION_REQ message is considered as an example here. In this example, nature-of-address-indicator is international-number, which indicates that the number address nature is international; content is 861310751315, which indicates that the specific VLR number is 861310751315. Reference Standards For details, see 8.1.2 "MAP_UPDATE_LOCATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

address of the VMSC Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the number of the VMSC at which the subscriber resides.

visited mobile switching center (VMSC) address

nature-of-address-indicator: Indicates the number address nature. content: Indicates the specific VMSC number. 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 139000, which indicates that the VMSC address is 139000.

Reference Standards For details, see 10.1 "MAP_SEND_ROUTING_INFORMATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

E/Nc Interface Protocol (Handover Management of MAP) Description of the E/Nc Interface Protocol Description of the Common Part of Messages Description of Handover Management Messages Description of Associated IEs Parent topic: Appendix - Protocol Compliance Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the E/Nc Interface Protocol Scenario Description Protocol Stack Message List Scenario Description 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)

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 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 This message is sent by MSC 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 This message is sent by MSC 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 This message is sent by MSC MSC-BMAP_PREPARE_SUBSEQUENT_HANDOVER_REQ that a handover or relocation >MSC-A third MSC is required. This message is sent by MSC 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) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Common Part of Messages Reference Standards Table 1 IEs carried in the common part of messages 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. Identifies the functions of messages. It corresponds to the operation code in the Transaction Capability Application Part (TCAP) component.

Operation code The MAP_PREPARE_HANDOVER_REQ message is considered as an example here. In this example, ie-map-operation-code is prepare-handover. Reference Standards For details, see 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: E/Nc Interface Protocol (Handover Management of MAP) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Handover Management Messages MAP_PREPARE_HANDOVER_REQ MAP_PREPARE_HANDOVER_RSP MAP_PROCESS_ACCESS_SIGNALLING MAP_SEND_END_SIGNAL_REQ MAP_PREPARE_SUBSEQUENT_HANDOVER_REQ MAP_PREPARE_SUBSEQUENT_HANDOVER_RSP MAP_SEND_END_SIGNAL_RSP MAP_U_ABORT_REQ Parent topic: E/Nc Interface Protocol (Handover Management of MAP) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_PREPARE_HANDOVER_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 the main IEs of the message. Figure 1 MAP_PREPARE_HANDOVER_REQ message

Associated IEs Information Element Description (IE) Invoke Id

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue.

For details, see Invoke Id. 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. International mobile subscriber identity (IMSI)

Indicates the IMSI of the subscriber. For details, see IMSI.

Integrity Protection 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. For details, see Encryption Information.

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. For details, see RAB ID.

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 Partnership Project (3GPP) TS29002-870. Parent topic: Description of Handover Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

AN-APDU

Indicates an application protocol data unit of the access network. For details, see AN-APDU.

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. For details, see User error.

Provider error

Indicates a provider error. For details, see Provider error.

Reference Standards For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Handover Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_PROCESS_ACCESS_SIGNALLING 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

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

AN-APDU

Indicates the application protocol data unit of the access network. For details, see 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 Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Handover Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_SEND_END_SIGNAL_REQ 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

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

AN-APDU

Indicates the application protocol data unit of the access network. For details, see AN-APDU.

Reference Standards For details, see 8.4.2 "MAP_SEND_END_SIGNAL service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Handover Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 the main IEs of the message. Figure 1 MAP_PREPARE_SUBSEQUENT_HANDOVER_REQ message

Associated IEs Information Element

(IE)

Description

Invoke Id

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

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

Indicates the application protocol data unit of the access network. For details, see 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 Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Handover Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_PREPARE_SUBSEQUENT_HANDOVER_RSP 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

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id. Indicates an application protocol data unit of the access network.

AN-APDU

For details, see AN-APDU.

User error

Indicates a user error. For details, see User error.

Provider error

Indicates a provider error. For details, see Provider error.

Reference Standards For details, see 8.4.5 "MAP_PREPARE_SUBSEQUENT_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Handover Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_SEND_END_SIGNAL_RSP 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 the main IEs of the message.

Figure 1 MAP_SEND_END_SIGNAL_RSP message Associated IEs Information Element Description (IE) Invoke Id

Uniquely identifies an operation in a MAP dialogue. For details, see Invoke Id.

Reference Standards For details, see 8.4.2 "MAP_SEND_END_SIGNAL service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Handover Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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.

Parent topic: Description of Handover Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated IEs Allowed GSM Algorithms Allowed UMTS Algorithms AN-APDU Chosen Radio Resource Information Encryption Information Handover Number HO-NumberNotRequired Integrity Protection Information 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 Diagnostic information

User error Parent topic: E/Nc Interface Protocol (Handover Management of MAP) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Allowed GSM Algorithms Description of the IE Reference Standards Description of the IE 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

For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Allowed UMTS Algorithms Description of the IE Reference Standards Description of the IE 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 The MAP_PREPARE_HANDOVER_REQ message is considered as 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 For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

AN-APDU Description of the IE Reference Standards Description of the IE 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. The MAP_PREPARE_HANDOVER_REQ message is considered as an example here. In this example, accessNetworkProtocolId is ts3G-48006, which indicates that the access network protocol is ts3G-48006. Reference Standards For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870.

Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Chosen Radio Resource Information Description of the IE Reference Standards Description of the IE 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 For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Encryption Information Description of the IE Reference Standards Description of the IE Information Element Description (IE) Indicates the encryption information. Encryption Information

The MAP_PREPARE_HANDOVER_REQ message is considered as 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 For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Handover Number Description of the IE Reference Standards Description of the IE Information Element Description (IE) Indicates the number allocated by the target MSC and used for routing a call between MSCs during handover.

Handover Number

nature-of-address-indicator content The MAP_PREPARE_HANDOVER_RSP message is considered as an example here. In this example, nature-of-address-indicator is international-number, which indicates that the number address nature is international; content is 13907558888, which indicates the handover number is 13907558888.

Reference Standards For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

HO-NumberNotRequired Description of the IE Reference Standards Description of the IE Information Element Description (IE) Indicates that no handover number is required. The MAP_PREPARE_HANDOVER_REQ message is considered as 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 For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Integrity Protection Information Description of the IE Reference Standards Description of the IE Information Element Description (IE) Indicates the integrity protection information used by the source MSC. Integrity Protection Information

The MAP_PREPARE_HANDOVER_REQ message is considered as 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 For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Iu-Available Codecs List Description of the IE Reference Standards Description of the IE Information Element Description (IE) Indicates the codecs available for the Iu interface.

Iu-Available Codecs List

The MAP_PREPARE_HANDOVER_RSP message is considered as 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 For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Iu-Currently Used Codec Description of the IE Reference Standards Description of the IE Information Element Description (IE) Indicates the codecs that currently used by the Iu interface. Iu-Currently Used Codec

The MAP_PREPARE_HANDOVER_REQ message is considered as an example here. In this example, iuCurrentlyUsedCodec is 00, indicates that the codec currently used by the Iu interface is 00.

Reference Standards For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Iu-Selected Codec Description of the IE Reference Standards Description of the IE Information Element Description (IE) Indicates the codecs that are selected the Iu interface. Iu-Selected Codec

The MAP_PREPARE_HANDOVER_RSP message is considered as an example here. In this example, iuSelectedCodec is 01, indicates that the codec selected by the Iu interface is 01.

Reference Standards For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Iu-Supported Codecs List Description of the IE Reference Standards Description of the IE Information Element Description (IE) Indicates a list of codecs supported by the Iu interface.

Iu-Supported Codecs List

iuSupportedCodecsList codec1 The MAP_PREPARE_HANDOVER_REQ message is considered as an example here. In this example, codec1 is 00, indicates that the codec supported by the Iu interface is 00.

Reference Standards For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RAB ID Description of the IE Reference Standards Description of the IE Information Element Description (IE) Indicates the radio access identifier. Radio Access Bearer (RAB) ID The MAP_PREPARE_HANDOVER_REQ message is considered as an example here. In this example, rab-Id is 0x01. Reference Standards For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Radio Resource Information Description of the IE Reference Standards Description of the IE 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. The MAP_PREPARE_HANDOVER_REQ message is considered as an example here. In this example, radioResourceInformation is 00 00 00.

Reference Standards For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Radio Resource List Description of the IE Reference Standards Description of the IE 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

The MAP_PREPARE_HANDOVER_REQ message is considered as 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 For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Relocation Number List Description of the IE Reference Standards Description of the IE 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

The MAP_PREPARE_HANDOVER_RSP message is considered as an example here. In this example, content is 8613907554567, which indicates that the handover number allocated by the target MSC is 8613907554567. Reference Standards For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Selected GSM Algorithm Description of the IE Reference Standards Description of the IE 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 For details, see 8.4.3 "MAP_PROCESS_ACCESS_SIGNALLING service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Selected RAB ID Description of the IE Reference Standards Description of the IE 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 For details, see 8.4.3 "MAP_PROCESS_ACCESS_SIGNALLING service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Selected UMTS Algorithms Description of the IE Reference Standards Description of the IE 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 The MAP_PREPARE_HANDOVER_RSP message is considered as 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 For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Target Cell Id Description of the IE Reference Standards Description of the IE 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 The MAP_PREPARE_HANDOVER_REQ message is considered as an example here. In this example, targetCellId is 46 00 00 77 55. Reference Standards For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Target MSC Number Description of the IE Reference Standards Description of the IE Information Element Description (IE) Indicates the number of the MSC to which a call has to be handed over.

Target MSC Number

nature-of-address-indicator 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 For details, see 8.4.5 "MAP_PREPARE_SUBSEQUENT_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Target RNC Id Description of the IE Reference Standards Description of the IE 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

The MAP_PREPARE_HANDOVER_REQ message is considered as an example here. In this example, targetRNCId is 46 00 00 77 55 00 44.

Reference Standards For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

User error Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates a user error.

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 For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Provider error Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates a provider error.

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 For details, see 8.4.1 "MAP_PREPARE_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

User reason Description of the IE Reference Standards Description of the IE 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 For details, see 7.3.4 "MAP_U_ABORT service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Diagnostic information Description of the IE Reference Standards Description of the IE 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 For details, see 7.3.4 "MAP_U_ABORT service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

User error Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates a user error.

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 For details, see 8.4.5 "MAP_PREPARE_SUBSEQUENT_HANDOVER service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

G Interface Protocol Description of the G Interface Protocol Description of the Common Part of Messages Description of Associated Messages Description of Associated IEs Parent topic: Appendix - Protocol Compliance Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the G Interface Protocol Scenario Description Protocol Stack Message List Scenario Description 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)

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

Parent topic: G Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Common Part of Messages Reference Standards Table 1 IEs carried in the common part of messages Information Element Description (IE) Identifies a Mobile Application Part (MAP) dialog. Dialogue ID

The MAP_SEND_IDENTIFICATION_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 The MAP_SEND_IDENTIFICATION_REQ message is considered as an example here. In this example, ie-map-operation-code is send-identification. Reference Standards For details, see 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: G Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated Messages MAP_SEND_IDENTIFICATION_REQ MAP_SEND_IDENTIFICATION_RSP Parent topic: G Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_SEND_IDENTIFICATION_REQ 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 Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue.

For details, see Invoke id. temporary mobile subscriber identifier (TMSI)

Indicates the TMSI of the subscriber. 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 Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_SEND_IDENTIFICATION_RSP 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 shows the main IEs of the message. Figure 1 MAP_SEND_IDENTIFICATION_RSP 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. Indicates the IMSI number of the subscriber. International mobile subscriber identity (IMSI) For details, see IMSI. 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 For details, see 8.1.4 "MAP_SEND_IDENTIFICATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated IEs Authentication set Current Security Context IMSI Invoke id MSC Number Number of requested vectors Previous Location Area Id Segmentation prohibited indicator TMSI Parent topic: G Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Authentication set Description of the IE Reference Standards Description of the IE 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 For details, see 8.1.4 "MAP_SEND_IDENTIFICATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Current Security Context Description of the IE Reference Standards Description of the IE 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 For details, see 8.1.4 "MAP_SEND_IDENTIFICATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

IMSI Description of the IE Reference Standards Description of the IE Information Element (IE)

Description

International mobile Indicates the IMSI number of the subscriber. subscriber identity (IMSI) Reference Standards For details, see 8.1.4 "MAP_SEND_IDENTIFICATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Invoke id Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Uniquely identifies an operation in a Mobile Application Part (MAP) 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 For details, see 8.1.4 "MAP_SEND_IDENTIFICATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MSC Number Description of the IE Reference Standards Description of the IE 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 For details, see 8.1.4 "MAP_SEND_IDENTIFICATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Number of requested vectors Description of the IE Reference Standards Description of the IE 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

The MAP_SEND_IDENTIFICATION_REQ message is considered as an example here. In this example, numberOfRequestedVectors is 0x5, which indicates the serving VLR can receive a maximum of five authentication sets from the PVLR..

Reference Standards For details, see 8.1.4 "MAP_SEND_IDENTIFICATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Previous Location Area Id Description of the IE Reference Standards Description of the IE Information Element Description (IE) Indicates the ID of the previous location area. Previous Location Area Id

The MAP_SEND_IDENTIFICATION_REQ message is considered as an example here. In this example, previous-LAI is 4600007788, which indicates the previous location area ID is 4600007788.

Reference Standards For details, see 8.1.4 "MAP_SEND_IDENTIFICATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Segmentation prohibited indicator Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates whether the new VLR allows segmentation of the response at Mobile Application Part (MAP) user level.

Segmentation prohibited indicator

The MAP_SEND_IDENTIFICATION_REQ message is considered 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 For details, see 8.1.4 "MAP_SEND_IDENTIFICATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

TMSI Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the TMSI of the subscriber.

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 For details, see 8.1.4 "MAP_SEND_IDENTIFICATION service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

E Interface Protocol Description of the E Interface Protocol Description of the Common Part of Messages Description of Associated Messages Description of Associated IEs Parent topic: Appendix - Protocol Compliance Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the E Interface Protocol Scenario Description Protocol Stack Message List Scenario Description 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)

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 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Common Part of Messages Reference Standards Table 1 IEs carried in the common part of messages Information Element Description (IE) Identifies a Mobile Application Part (MAP) dialog. Dialogue ID

The MAP_MO_FORWARD_SHORT_MESSAGE_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 The MAP_MO_FORWARD_SHORT_MESSAGE_REQ message is considered as an example here. In this example, ie-mapoperation-code is mo-forward-sm. Reference Standards For details, see 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: E Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated Messages MAP_MO_FORWARD_SHORT_MESSAGE_REQ MAP_MO_FORWARD_SHORT_MESSAGE_CNF MAP_P_ABORT_IND MAP_MT_FORWARD_SHORT_MESSAGE_IND MAP_MT_FORWARD_SHORT_MESSAGE_RSP Cp data Cp ACK Parent topic: E Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_MO_FORWARD_SHORT_MESSAGE_REQ 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

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

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 service relay sub-layer protocol. For details, see SM RP UI.

Reference Standards For details, see section 12.2 "MAP-MO-FORWARD-SHORT-MESSAGE service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_MO_FORWARD_SHORT_MESSAGE_CNF 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

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

Reference Standards For details, see section 12.2 "MAP-MO-FORWARD-SHORT-MESSAGE service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_MT_FORWARD_SHORT_MESSAGE_IND 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

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

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 service relay sub-layer protocol. For details, see SM RP UI.

Reference Standards For details, see section 12.9 "MAP-MT-FORWARD-SHORT-MESSAGE service" in 3rd Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MAP_MT_FORWARD_SHORT_MESSAGE_RSP 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

Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue. For details, see Invoke Id.

User error

(Optional IE) Indicates the reason for the failure of sending short messages. For details, see User error.

Reference Standards For details, see section 12.9 "MAP-MT-FORWARD-SHORT-MESSAGE service" in 3rd

Generation Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 shows the main IEs of the message. 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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 main IEs of the message. Figure 1 CP ACK 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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated IEs IMSI Invoke Id SM RP DA SM RP OA User error Message type SM RP UI Parent topic: E Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

IMSI Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the IMSI of the subscriber who receives the multicast tunnel (MT) short messages.

International mobile subscriber identity (IMSI) The MAP_MO_FORWARD_SHORT_MESSAGE_REQ message is considered as an example here. In this example, content is 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 Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Invoke Id Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Uniquely identifies an operation in a Mobile Application Part (MAP) dialogue.

Invoke Id

The MAP_MO_FORWARD_SHORT_MESSAGE_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 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

SM RP DA Description of the IE Reference Standards Description of the IE 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)

The MAP_MO_FORWARD_SHORT_MESSAGE_REQ message is considered as an example here. In this example, number is 86139075555, which indicates that the SMC number is 86139075555. 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

SM RP OA Description of the IE Reference Standards Description of the IE 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)

The MAP_MO_FORWARD_SHORT_MESSAGE_REQ message is considered as an example here. In this example, content is 8613907551605, which indicates the number of the subscriber who sends the short message. 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

User error Description of the IE Reference Standards Description of the IE 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 Partnership Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Message type Description of the IE Reference Standards Description of the IE 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 For details, see 9.3.2 "Protocol element repertoire at Short Message (SM) Relay Layer (RL)" in 3rd Generation Partnership Project (3GPP) TS23040-830. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

SM RP UI Description of the IE Reference Standards Description of the IE 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 Project (3GPP) TS29002-870. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Sv Interface Protocol Description of the Sv Interface Protocol Description of the Common Part of Messages Description of Handover Management Messages Description of Associated IEs Parent topic: Appendix - Protocol Compliance Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Sv Interface Protocol Scenario Description Protocol Stack Message List Scenario Description 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

This message is sent from th 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

This message is sent from th MME/SGSN to the MSC serv MME/SGSN- interface in response to the

>MSC server GTP_MSG_SRVCC_PS_TO message during the SRVCC procedure.

This message is sent from th 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.

This message is sent from th 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 message during the SRVCC procedure. Parent topic: Sv Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Common Part of Messages Table 1 describes the information elements (IEs) carried in the common part of messages. Table 1 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.

Parent topic: Sv Interface Protocol

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Handover Management Messages GTP_MSG_SRVCC_PS_TO_CS_REQ GTP_MSG_SRVCC_PS_TO_CS_RSP GTP_MSG_SRVCC_PS_TO_CS_COMP_NTF GTP_MSG_SRVCC_PS_TO_CS_COMP_ACK GTP_MSG_SRVCC_PS_TO_CS_CANCEL_NTF GTP_MSG_SRVCC_PS_TO_CS_CANCEL_ACK Parent topic: Sv Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

GTP_MSG_SRVCC_PS_TO_CS_REQ 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 Information Element (IE)

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. For details, see IMSI.

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: The UE is emergency attached and

it is UICCless. The UE is emergency attached and the IMSI is not authenticated. The MSISDN is defined in 3rd Generation Partnership Project (3GPP) TS 23.003 [4]. For details, see MSISDN.

STN-SR

This IE is included in the GTP_MSG_SRVCC_PS_TO_CS_REQ 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.

Parent topic: Description of Handover Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

GTP_MSG_SRVCC_PS_TO_CS_RSP 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 Information Element (IE)

Description

Cause

This IE specifies whether the GTP_MSG_SRVCC_PS_TO_CS_REQ message is accepted. If Cause is not Request accepted, the

GTP_MSG_SRVCC_PS_TO_CS_REQ message is rejected. It is mandatory. For details, see Cause.

SRVCC Cause

This IE specifies why the GTP_MSG_SRVCC_PS_TO_CS_REQ 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 GTP_MSG_SRVCC_PS_TO_CS_RSP 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. Parent topic: Description of Handover Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

GTP_MSG_SRVCC_PS_TO_CS_COMP_NTF 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 Information Element (IE)

Description This IE indicates the international mobile subscriber identity (IMSI) of the subscriber. It is optional. It is included in the GTP_MSG_SRVCC_PS_TO_CS_COMP_NTF 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. For details, see IMSI. Reference Standards For details, see 5.2.4 "SRVCC PS to CS Complete Notification" in 3GPP 29.280 V9.3.0. Parent topic: Description of Handover Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

GTP_MSG_SRVCC_PS_TO_CS_COMP_ACK 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 Information Element (IE)

Cause

Description This IE specifies whether the GTP_MSG_SRVCC_PS_TO_CS_REQ message is accepted. If Cause is not Request accepted, the GTP_MSG_SRVCC_PS_TO_CS_REQ message is rejected. It is mandatory.

For details, see Cause. 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. Parent topic: Description of Handover Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

GTP_MSG_SRVCC_PS_TO_CS_CANCEL_NTF 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 Information Element (IE)

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 GTP_MSG_SRVCC_PS_TO_CS_CANCEL_NTF 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. For details, see IMSI.

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. Parent topic: Description of Handover Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

GTP_MSG_SRVCC_PS_TO_CS_CANCEL_ACK 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 Information Element (IE)

Description

Cause

This IE specifies whether the GTP_MSG_SRVCC_PS_TO_CS_CANCEL_NTF message is accepted. If Cause is not Request accepted, the GTP_MSG_SRVCC_PS_TO_CS_CANCEL_NTF message is rejected. It is mandatory. For details, see Cause.

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. Parent topic: Description of Handover Management Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated IEs STN-SR Source to Target Transparent Container Target to Source Transparent Container MM Context for E-UTRAN SRVCC SRVCC Cause Target RNC ID Target GCI TEID-C Sv Flags IMSI MSISDN IP Address Cause Parent topic: Sv Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

STN-SR Description of the IE Reference Standards Description of the IE Information Element (IE)

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

Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Source to Target Transparent Container Description of the IE Reference Standards Description of the IE Information Element (IE)

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

Source to Target Transparent Container 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 Source to Target Transparent Container 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Target to Source Transparent Container Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MM Context for E-UTRAN SRVCC Description of the IE Reference Standards Description of the IE Information Element (IE)

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 GTP_MSG_SRVCC_PS_TO_CS_REQ message is used as an example here. In this example, meanings of each parameter are 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]. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

SRVCC Cause Description of the IE Reference Standards Description of the IE Information Element (IE)

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 GTP_MSG_SRVCC_PS_TO_CS_CANCEL_NTF message is used as an example here. 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.

1

Unspecified.

2

Handover/Relocation canceled by source system.

3

Handover /Relocation Failure with Target system.

4

Handover/Relocation Target not allowed.

5

Unknown Target ID.

6

Target Cell not available.

7

No Radio Resources Available in Target Cell.

8

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Target RNC ID Description of the IE Reference Standards Description of the IE IE

Description If the target side of a handover is a 3G network, the GTP_MSG_SRVCC_PS_TO_CS_REQ 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 GTP_MSG_SRVCC_PS_TO_CS_REQ message is used as an example here. 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Target GCI Description of the IE Reference Standards Description of the IE IE

Description If the target side of a handover is a 2G network, the GTP_MSG_SRVCC_PS_TO_CS_REQ 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 GTP_MSG_SRVCC_PS_TO_CS_REQ message 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]. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

TEID-C Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Identifies the Tunnel Endpoint Identifier for Control Plane (TEID-C).

TEID-C

The GTP_MSG_SRVCC_PS_TO_CS_REQ message is used as an example here. 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Sv Flags Description of the IE Reference Standards Description of the IE 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 GTP_MSG_SRVCC_PS_TO_CS_CANCEL_ACK message is used as an example here. In this example, meanings of each parameter are 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

IMSI Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Identifies the international mobile subscriber identity (IMSI) of the subscriber.

IMSI

The IMSI IE in the GTP_MSG_SRVCC_PS_TO_CS_REQ message is used as an example here. 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 For details, see 3rd Generation Partnership Project (3GPP) 29.274 [3]. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MSISDN Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Identifies the mobile station international ISDN number (MSISDN) of the subscriber.

MSISDN

The MSISDN IE in the GTP_MSG_SRVCC_PS_TO_CS_REQ message is used as an example here. 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 For details, see 3rd Generation Partnership Project (3GPP) 29.274 [3]. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

IP Address Description of the IE Reference Standards Description of the IE Information Element (IE)

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 GTP_MSG_SRVCC_PS_TO_CS_REQ message is used as an example here. 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Cause Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Specifies whether the GTP_MSG_SRVCC_PS_TO_CS_REQ message is accepted.

cause: specifies whether the GTP_MSG_SRVCC_PS_TO_CS_REQ 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. 0: The SRVCC PS to CS 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: 1: The SRVCC PS to CS handover rejection is caused by PDN Connection IE Error. 0: The SRVCC PS to CS handover rejection is not caused by PDN Connection IE Error. The Cause 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: 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 For details, see 3rd Generation Partnership Project (3GPP) 29.274 [3]. Parent topic: Description of Associated IEs

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

H.248 Protocol Description of the H.248 Protocol Extended 3GPP-based H.248 Protocol Description of the Common Part of Messages Description of Associated Messages Description of Associated IEs Parent topic: Appendix - Protocol Compliance Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the H.248 Protocol Scenario Description 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. Scenario Description 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

MGCMGW

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

MGCMGW

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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.248–supported 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. Parent topic: H.248 Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Common Part of Messages 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. Parent topic: H.248 Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated Messages 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 Parent topic: H.248 Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

H.248 message header

Every H.248 message contains a 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.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

H.248 message header

Every H.248 message contains a 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.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

H.248 message header

Every H.248 message contains a 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.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

H.248 message header

Every H.248 message contains a 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.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

H.248 message header

Every H.248 message contains a 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.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

H.248 message header

Every H.248 message contains a 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.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Information Element (IE)

Description

H.248 message header

Every H.248 message contains a 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.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

H.248 message header

Every H.248 message contains a header. For details, see H.248 Message Header. One or more transactions constitute an H.248 message.

transactions

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

It describes the parameters in commands. For details, see descriptor.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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

It describes the parameters in commands. For details, see descriptor.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

H.248 message header

Every H.248 message contains a 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

It describes the parameters in commands. For details, see descriptor.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

H.248 message header

Every H.248 message contains a 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. A termination receives or sends streams.

termination

For details, see termination.

descriptor

It describes the parameters in commands. For details, see descriptor.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

H.248 message header

Every H.248 message contains a 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.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated IEs H.248 Message Header transactions actions context command termination descriptor termStateDescr localControlDescriptor localDescriptor remoteDescriptor signalsDescriptor eventsDescriptor observedEventsDescriptor auditDescriptor serviceChange statisticsDescriptor errorDescriptor Parent topic: H.248 Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

H.248 Message Header Description of the IE 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. Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

transactions Description of the IE 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). Description of the IE 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. Parent topic: Description of Associated IEs

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

actions Description of the IE 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. Description of the IE 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. For details, see 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

context Description of the IE 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. Description of the IE 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 Union-Telecommunication Standardization Sector (ITU-T) H.248.1. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

command Description of the IE 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. Description of the IE 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. terminationID: For details, see termination. 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. terminationID: For details, see termination. 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. terminationID: For details, see termination.

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. terminationID: For details, see termination. 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. terminationID: For details, see termination. errorDescriptor: For details, see errorDescriptor.

terminationID: For details, see termination. termStateDescr: For details, see termStateDescr. localControlDescriptor: For details, see

localControlDescriptor. Reference Standards For details about the command, see section 7 "Commands" in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) H.248.1. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

termination Description of the IE 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. Description of the IE 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 Telecommunication Union-Telecommunication Standardization Sector (ITU-T) H.248.1. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

descriptor Description of the IE 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 Description of the IE

Information Element (IE)

Description

ADD REQ descriptor

mediaDescriptor: Lists media stream specifications. streams: Lists Remote/Local/LocalControl Descriptors for streams. localControlDescriptor: For details, see localControlDescriptor. localDescriptor: For details, see localDescriptor. eventsDescriptor: For details, see eventsDescriptor.

ADD REPLY descriptor

terminationAudit: Returns termination information. mediaDescriptor: Lists media stream specifications. localDescriptor: For details, see localDescriptor.

NTFY REQ

descriptor

observedEventsDescriptor: For details, see observedEventsDescriptor.

ADD REPLY (IP termination) descriptor

mediaDescriptor: Lists media stream specifications. termStateDescr: For details, see termStateDescr. streams: Lists Remote/Local/LocalControl Descriptors for streams. localControlDescriptor: For details, see localControlDescriptor. localDescriptor: For details, see localDescriptor. eventsDescriptor: For details, see eventsDescriptor.

MOD REQ descriptor

mediaDescriptor: Lists media stream specifications. streams: Lists Remote/Local/LocalControl Descriptors for streams. remoteDescriptor: For details, see remoteDescriptor. eventsDescriptor: For details, see eventsDescriptor. 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

termStateDescr: For details, see termStateDescr. localControlDescriptor: For details, see localControlDescriptor.

ServiceChange REQ descriptor

serviceChangeParms: For details, see serviceChange. Reference Standards For details about contexts, see section 7.1 "Contexts" in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) H.248.1. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

termStateDescr Description of the IE Reference Standards The termStateDescr contains the termination properties that are defined in packages and are not stream specific. Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

localControlDescriptor Description of the IE 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. Description of the IE 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) localControlDescriptor

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) localControlDescriptor

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.

localControlDescriptor

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) localControlDescriptor

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) localControlDescriptor

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 International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

localDescriptor Description of the IE 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). Description of the IE 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.

name: The name sdp-a indicates zero or more session attribute lines. sdpString: The value vsel:UMTS-AMR indicates that the codec used is UMTS-AMR.

name: The name sdp-a indicates zero or more session 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.

name: The name sdp-c indicates the connection set up for a 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 name: The name sdp-a indicates zero or more session 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.

name: The name sdp-c indicates the connection set up for a

media session. sdpString: The value IN IP4 $ indicates an INTERNET connection without knowing the Internet Protocol version 4 (IPv4) address.

name: The name sdp-m indicates the media type, that is, media name and transport 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).

name: The name sdp-a indicates zero or more session 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

name: The name sdp-a indicates zero or more session attribute lines.

sdpString: The value ptime:20 indicates 20 ms of packet time.

name: The name sdp-a indicates zero or more session 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

name: The name sdp-a indicates zero or more session attribute lines. sdpString: The value maxPTime:20 indicates that the maximum packet time is 20 ms.

name: The name sdp-c indicates the connection set up for a 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

name: The name sdp-m indicates the media type, that is, media name and transport address. 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.

name: The name sdp-a indicates zero or more session 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 International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

remoteDescriptor Description of the IE 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). Description of the IE Information Element (IE)

MOD REQ (IP termination applied to the A interface) remoteDescriptor

Description

name: The name sdp-c indicates the connection set up for a 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.

name: The name sdp-m indicates the media type, that is, media name and transport address. 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

signalsDescriptor Description of the IE Reference Standards Description of the IE 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 Telecommunication Union-Telecommunication Standardization Sector (ITU-T) H.248.1. For details about tonegen, see Annex E "Basic packages" in ITU-T H.248.1. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

eventsDescriptor Description of the IE 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. Description of the IE 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.

eventParameterName: The value gB-BNCChange:Ox1(1) indicates that the MGC requests the MGW to report the BNCChange event with the ID of 1.

tag: The value stag indicates an encoding format. gB-BNCChange: The value bearer-ModificationFailure(1) indicates that the MGC requests the MGW to report the result of bearer-ModificationFailure in the BNCChange event.

eventParameterName: The value gB-BNCChange:Ox1(1) indicates that the MGC requests the MGW to report the BNCChange event with the ID of 1. tag: The value stag indicates an encoding format. 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 International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd.

observedEventsDescriptor Description of the IE 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. Description of the IE Information Element (IE) Description

requestID: The requestID is 0, which is the same as

NTFY REQ observedEventsDescriptor

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

auditDescriptor Description of the IE 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. Description of the IE 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 Telecommunication Union-Telecommunication Standardization Sector (ITU-T) H.248.1. Parent topic: Description of Associated IEs

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

serviceChange Description of the IE Reference Standards The serviceChange includes the serviceChangeMethod field and the reason field. Description of the IE 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 International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) H.248.1. For details about the serviceChange, see section 5.2 in ITU-T H.248.8. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

statisticsDescriptor Description of the IE 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. Description of the IE 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 statisticsDescriptor 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 International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) H.248.1. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

errorDescriptor Description of the IE 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.) Description of the IE 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 Telecommunication Union-Telecommunication Standardization Sector (ITU-T) H.248.1. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Q.AAL2 Protocol Description of the Q.AAL2 Protocol Description of the Common Part of Messages Description of Associated Messages Description of Associated IEs Parent topic: Appendix - Protocol Compliance Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Q.AAL2 Protocol Scenario Description 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. Scenario Description 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. Figure 3 IE Structure

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Common Part of Messages 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.

Parent topic: Q.AAL2 Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated Messages ERQ ECF REL RLC Parent topic: Q.AAL2 Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Indicates the header information of the Q.AAL2 message. Q.ATM Adaptation Layer Type Every Q.AAL2 message contains a header. 2 (AAL2) message 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.

establishConfirm-Param

Indicates the parameter carried in the ECF message. For details, see establishConfirm-Param.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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.

releaseRequest-Param

Indicates the parameter carried in the REL message. For details, see releaseRequest-Param.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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.

releaseCofirm-Param

Indicates the parameter carried in the RLC message. For details, see releaseConfirm-param.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated IEs Q.AAL2 Message Header message message_compatibility establishRequestParam establishConfirm-Param releaseRequest-Param releaseConfirm-param connection-element-identifier originating-signaling-association-identifier aal2-service-endpoint-address link-characteristics served-user-generated-reference cause Parent topic: Q.AAL2 Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Q.AAL2 Message Header Description of the IE 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. Description of the IE 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. Parent topic: Description of Associated IEs

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

message Description of the IE Reference Standards The message consists of the message compatibility field and the parameters field. Description of the IE 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. message-compatibility: For details, see message_compatibility. establishConfirm-param: For details, see establishConfirm-Param.

releaserequest: It is used by the RNC to request the MGW to release an AAL2 connection. message-compatibility: For details, see message_compatibility. 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. message-compatibility: For details, see message_compatibility. 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

message_compatibility Description of the IE 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. Description of the IE Information Element Description (IE)

ERQ message_compatibility

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

establishRequestParam Description of the IE Reference Standards The establishRequestParam contains parameters carried in the ERQ message. Description of the IE 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. aal2–service-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 Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q.2630.1. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd.

establishConfirm-Param Description of the IE Reference Standards The establishConfirm-Param contains parameters carried in the ECF message. Description of the IE 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 the ATM Adaptation Layer (AAL) type 2 signaling protocol messages" in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q.2630.1. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

releaseRequest-Param Description of the IE Reference Standards The releaseRequest-Param contains parameters carried in the REL message. Description of the IE 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 the ATM Adaptation Layer (AAL) type 2 signaling protocol messages" in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q.2630.1. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

releaseConfirm-param Description of the IE Reference Standards The releaseConfirm-param contains parameters carried in the RLC message. Description of the IE 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 the ATM Adaptation Layer (AAL) type 2 signaling protocol messages" in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q.2630.1. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

connection-element-identifier Description of the IE 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. Description of the IE 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 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. 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

originating-signaling-association-identifier Description of the IE Reference Standards The originating-signaling-association-identifier indicates the signaling association identifier of the originating ATM Adaptation Layer Type 2 (AAL2) node. Description of the IE Information Element (IE)

Description

compatibility: The parameter compatibility is similar with message compatibility. For details, see message_compatibility.

establish request (ERQ) originating-signalingassociationidentifier

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 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 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

aal2-service-endpoint-address Description of the IE 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. Description of the IE Information Element (IE)

Description

compatibility: The parameter compatibility is similar with message compatibility. For details, see message_compatibility.

Establish request (ERQ) originating-signalingassociationidentifier

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 the unrecognized parameter is reserved. 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 when general actions are performed. 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 Standardization Sector (ITU-T) Q.2630.1. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

link-characteristics Description of the IE Reference Standards The link-characteristics contains attributes related to ATM Adaptation Layer Type 2 (AAL2) links. Description of the IE Information Element (IE)

Description

compatibility: The parameter compatibility is similar with message compatibility. For details, see message_compatibility. 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

Establish request (ERQ) link-characteristics

the unrecognized parameter is reserved. 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 when general actions are performed. 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 International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q.2630.1. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

served-user-generated-reference Description of the IE Reference Standards The served-user-generated-reference uniquely identifies the radio access bearer (RAB) management and control module on the MGW side. Description of the IE Information Element (IE)

Description

compatibility: The parameter compatibility is similar with message compatibility. For details, see message_compatibility.

Establish request (ERQ) served-usergeneratedreference

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 the unrecognized parameter is reserved. 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 when general actions are performed.

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 Standardization Sector (ITU-T) Q.2630.1. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

cause Description of the IE Reference Standards The cause describes why an ATM Adaptation Layer Type 2 (AAL2) connection is released or fails to be established. Description of the IE Information Element (IE)

Description

compatibility: The parameter compatibility is similar with message compatibility. For details, see message_compatibility.

Release (REL) cause

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 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 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

IU_UP/NB_UP Protocol Description of the IU_UP/NB_UP Protocol Description of the Common Part of Messages Description of Associated Messages Description of Associated IEs Parent topic: Appendix - Protocol Compliance Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the IU_UP/NB_UP Protocol Scenario Description 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. Scenario Description 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. Figure 4 IE Structure

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Common Part of Messages There is no common part in IU_UP/NB_UP messages. Parent topic: IU_UP/NB_UP Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated Messages TRC_IU/NB_UP_INIT (Sent by RNC) TRC_IU/NB_UP_INIT (Sent by MGW) TRC_IU/NB_UP_INIT_TOIP TRC_IU/NB_UP_ACK_FRMIP TRC_IU/NB_UP_TA (Received) TRC_IU/NB_UP_TA (Sent) Parent topic: IU_UP/NB_UP Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

TRC_IU/NB_UP_INIT_TOIP 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 Information Element (IE)

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 part of IU_UP/NB_UP messages. For details, see framePayloadPart.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

TRC_IU/NB_UP_ACK_FRMIP 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 Information Element (IE)

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 check information of IU_UP/NB_UP messages. For details, see frameChecksumPart.

framePayLoadPart

Indicates the frame payload part of IU_UP/NB_UP messages.

For details, see framePayloadPart. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

frameControlPart

Indicates the frame control information of IU_UP/NB_UP messages. For details, see frameControlPart.

frameChecksumPart

Indicates the frame check information of IU_UP/NB_UP messages. For details, see frameChecksumPart.

framePayLoadPart

Indicates the frame payload part of IU_UP/NB_UP messages. For details, see framePayloadPart.

Parent topic: Description of Associated Messages

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

TRC_IU/NB_UP_TA (Sent) 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 Information Element (IE)

Description

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.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated IEs IU_UP/NB_UP Message Header frameControlPart frameChecksumPart framePayloadPart RFC (RAB sub-Flow Combination Indicator) Parent topic: IU_UP/NB_UP Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

IU_UP/NB_UP Message Header Description of the IE The IU_UP/NB_UP message header consists of information about contexts, terminations, and channels. Description of the IE Information Element (IE)

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.

Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

frameControlPart Description of the IE Reference Standards The Frame Control part consists of the protocol data unit (PDU) Type field, the ackNack field, and the Frame Number field. Description of the IE 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. PDU type 1 is defined to transfer user data over the IU_UP/NB_UP in support mode for pre-defined 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. The other values are as follows: ack: indicates that the frame is a positive

acknowledgement of a control procedure frame. Nack: indicates that the frame is a negative acknowledgement of a control procedure frame.

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. The values are as follows: 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. The values are as follows: 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 The other values are as follows: procedure: indicates that the frame is a control procedure frame. Nack: indicates that the frame is a negative acknowledgement of a control procedure frame.

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

frameChecksumPart Description of the IE Reference Standards The Frame Checksum part consists of the Header cyclic redundancy code (CRC) field and the Payload CRC field. Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

framePayloadPart Description of the IE Reference Standards The Frame Payload part consists of radio access bearer (RAB) sub Flow Combination (RFC) information and related control information. Description of the IE 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. The values are as follows: 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: 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. PDU type 1 is defined to transfer user data over the IU_UP/NB_UP in support mode for pre-defined 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 1≤n≤80: indicates that the sending time is n×500 μs delayed. 129≤n≤208: 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.

Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RFC (RAB sub-Flow Combination Indicator) Description of the IE Reference Standards RAB sub-Flow Combination (RFC) is a combination of the Radio Access Bearer (RAB) subflows. Description of the IE 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. lengthOfSubflow2 Byte: The value 53 indicates that the length of sub-flow 2 is 53 bits. lengthOfSubflow3 Byte: The value 0 indicates that the length of sub-flow 3 is 0 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. lengthOfSubflow1 Byte: The value 49 indicates that the length of sub-flow 1 is 49 bits. lengthOfSubflow2 Byte: The value 54 indicates that the length of sub-flow 2 is 54 bits. lengthOfSubflow3 Byte: The value 0 indicates that the length of sub-flow 3 is 0 bits. The AMR codec mode for the corresponding RFC is 5.15 kbit/s. The calculation formula is as follows: (49 + 54 + 0) bits/AMR codec packet time 20 ms = 5.15 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 byte. RFCI: The value 2 indicates that the identifier assigned to this RFC is 2. lengthOfSubflow1 Byte: The value 55 indicates that the length

of sub-flow 1 is 55 bits. lengthOfSubflow2 Byte: The value 63 indicates that the length of sub-flow 2 is 63 bits. lengthOfSubflow3 Byte: The value 0 indicates that the length of sub-flow 3 is 0 bits. The AMR codec mode for the corresponding RFC is 5.9 kbit/s. The calculation formula is as follows: (55 + 63 + 0) bits/AMR codec packet time 20 ms = 5.9 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 byte. RFCI: The value 3 indicates that the identifier assigned to this RFC is 3. lengthOfSubflow1 Byte: The value 58 indicates that the length of sub-flow 1 is 58 bits. lengthOfSubflow2 Byte: The value 76 indicates that the length of sub-flow 2 is 76 bits. lengthOfSubflow3 Byte: The value 0 indicates that the length of sub-flow 3 is 0 bits. The AMR codec mode for the corresponding RFC is 6.7 kbit/s. The calculation formula is as follows: (58 + 76 + 0) bits/AMR codec packet time 20 ms = 6.7 kbit/s

TRC_IU/NB_UP_TA

(Sent by RNC) RAB sub-Flow Combination (RFC)

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 byte. RFCI: The value 4 indicates that the identifier assigned to this RFC is 4. lengthOfSubflow1 Byte: The value 61 indicates that the length of sub-flow 1 is 61 bits. lengthOfSubflow2 Byte: The value 87 indicates that the length of sub-flow 2 is 87 bits. lengthOfSubflow3 Byte: The value 0 indicates that the length of sub-flow 3 is 0 bits. The AMR codec mode for the corresponding RFC is 7.4 kbit/s. The calculation formula is as follows: (61 + 87 + 0) bits/AMR codec packet time 20 ms = 7.4 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 byte. RFCI: The value 5 indicates that the identifier assigned to this RFC is 5. lengthOfSubflow1 Byte: The value 75 indicates that the length

of sub-flow 1 is 75 bits. lengthOfSubflow2 Byte: The value 84 indicates that the length of sub-flow 2 is 84 bits. lengthOfSubflow3 Byte: The value 0 indicates that the length of sub-flow 3 is 0 bits. The AMR codec mode for the corresponding RFC is 7.95 kbit/s. The calculation formula is as follows: (75 + 84 + 0) bits/AMR codec packet time 20 ms = 7.95 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 byte. RFCI: The value 8 indicates that the identifier assigned to this RFC is 8. lengthOfSubflow1 Byte: The value 39 indicates that the length of sub-flow 1 is 39 bits. lengthOfSubflow2 Byte: The value 0 indicates that the length of sub-flow 2 is 0 bits. lengthOfSubflow3 Byte: The value 0 indicates that the length of sub-flow 3 is 0 bits. 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. LI: The value oneByte indicates that the length of the subflow is 1 byte. RFCI: The value 9 indicates that the identifier assigned to this RFC is 9. lengthOfSubflow1 Byte: The value 0 indicates that the length of sub-flow 1 is 0 bits. lengthOfSubflow2 Byte: The value 0 indicates that the length of sub-flow 2 is 0 bits. lengthOfSubflow3 Byte: The value 0 indicates that the length of sub-flow 3 is 0 bits. 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

IPBCP Protocol Description of the IPBCP Protocol Description of the Common Part of Messages Description of Associated Messages Description of Associated IEs Parent topic: Appendix - Protocol Compliance Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the IPBCP Protocol Scenario Description 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. Scenario Description 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. Figure 4 IE Structure

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. For details, see bT-TunnelInd-DATA.

Confused

MGW>MGW

Responds to the Request message after the Request message is received but not processed.

Rejected

MGW>MGW

Responds to the Request message after the Request 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Common Part of Messages There is no common part in IP Bearer Control Protocol (IPBCP) messages. Parent topic: IPBCP Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated Messages ADD REQ (bT) MOD REQ (bT) NTFY REQ (bT) IAM (APP) APM (Initiating bCI) APM (Receiving bCI) Parent topic: IPBCP Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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. For details, see bT-TunnelInd-DATA.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

bearer-Control-Info

Indicates the tunneled bearer control information. For details, see bearer-Control-Info.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

bearer-Control-Info

Indicates the tunneled bearer control information. For details, see bearer-Control-Info.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated IEs bT-TunOpt bT-TunnelInd bT-BearInfoTrans bT-TunnelInd-DATA action-indicator bearer-Control-Tunnel bearer-Control-Info Parent topic: IPBCP Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

bT-TunOpt Description of the IE Reference Standards The TunOpt, representing tunneling options, indicates when the MGW sends the tunneled information to an MGC. Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

bT-TunnelInd Description of the IE Reference Standards The TunnelInd, representing tunnel indication, indicates the event that the MGW sends the tunneled information. Description of the IE 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 For details about the Bearer Control Tunneling Package, see Annex A in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q.1950. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

bT-BearInfoTrans Description of the IE Reference Standards The BearInfoTrans, representing bearer information transport, is used by the MGC to send the tunneled information to the MGW. Description of the IE Information Element (IE)

Description

ADD REQ (bT) (Receiver) bT-BearInfoTrans

name: The value bit, representing bearer information transport, indicates that the tunneled information is sent. 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

name: The value bit, representing bearer information transport, indicates that the tunneled information is sent. value: The value bT-bit-DATA indicates the tunneled information. For details about the related parameters, see bT-TunnelInd-DATA.

MOD REQ (bT) (Sender) bT-BearInfoTrans

name: The value bit, representing bearer information transport, indicates that the tunneled information is sent and the related termination goes into the accepting negotiation response state. value: The value bT-bit-DATA indicates the tunneled information. For details about the related parameters, see bT-TunnelInd-DATA. Reference Standards For details about the Bearer Control Tunneling Package, see Annex A in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q.1950. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

bT-TunnelInd-DATA Description of the IE Reference Standards The bT-TunnelInd-DATA indicates the tunneled information. Description of the IE Information Element (IE)

Description

tag: The value stag indicates an encoding format. 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 Standardization Sector (ITU-T) Q.1990. For details about SDP, see Internet Engineering Task Force (IETF) RFC 2327. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

action-indicator Description of the IE Reference Standards The action-indicator indicates the bearer establishment mode. Description of the IE 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 Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q.765.5. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

bearer-Control-Tunnel Description of the IE Reference Standards The bearer-Control-Tunnel indicates the information related to bearer control tunneling. Description of the IE 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 Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q.765.5. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

bearer-Control-Info Description of the IE Reference Standards The bearer-Control-Info indicates the tunneled bearer control information. Description of the IE 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 bearer-Control-Info: The tunneled bearer control information is sent between MGCs by means of BICC messages. For details about the related parameters, see bT-TunnelInd-DATA.

APM (Receiving bCI) bearer-Control-Info

bearer-Control-Info: The tunneled bearer control information is sent 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 Standardization Sector (ITU-T) Q.765.5. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

RTP/RTCP Protocol Description of the RTP/RTCP Protocol Description of the Common Part of Messages Description of Associated Messages Description of Associated IEs Parent topic: Appendix - Protocol Compliance Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the RTP/RTCP Protocol Scenario Description 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.

Scenario Description 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/MGWMGW For details, see rtcpSR.

extension report (XR) packet

The extended report (XR) packet provides statistics BSC/RNC/MGWMGW For details, see rtcpXRVoIP.

RR packet

The receiver report (RR) packet provides statistics BSC/RNC/MGWMGW For details, see rtcpRR.

SDES packet

The source description (SDES) packet describes the BSC/RNC/MGWMGW For details, see rtcpSDES.

BYE packet

BSC/RNC/MGWMGW transmission.

asymmetric digital The application-defined (APP) packet is intended for subscriber line experimental use as new applications and new (ADSL) Port BSC/RNC/MGWMGW 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/MGWMGW local end.

RTCP_RCV_MSG

BSC/RNC/MGWMGW the local end.

Function

Reference Standards For details about RTP/RTCP, see IETF RFC 3550. Parent topic: RTP/RTCP Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Common Part of Messages There is no common part in Real-Time Transport Protocol (RTP)/Real-time Transport Control Protocol (RTCP) messages. Parent topic: RTP/RTCP Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated Messages RTCP_SEND_MSG RTCP_RCV_MSG Parent topic: RTP/RTCP Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

ip (ip header)

For details, see ip.

udp (udp header)

For details, see udp.

rtcp (rtcp packet)

For details, see rtcp.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

ip (ip header)

For details, see ip.

udp (udp header)

For details, see udp.

rtcp (rtcp packet)

For details, see rtcp.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated IEs ip udp rtcp rtcpSR rtcpXRVoIP rtcpSDES rtcpRR rtcpAPP Parent topic: RTP/RTCP Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

ip Description of the IE Reference Standards The ip header includes the IP version, IP packet length, and IP address. Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

udp Description of the IE Reference Standards The udp header includes the User Datagram Protocol (UDP) port number and UDP packet length. Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

rtcp Description of the IE 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. Description of the IE 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.

ucbit2Version: The value 2 indicates RTP version 2. ucbit1PadFlag: The value 0 indicates that no padding is added after the payload. 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)

ucbit2Version: The value 2 indicates RTP version 2. ucbit1PadFlag: The value 0 indicates that no padding is added after the payload. 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.

ucbit2Version: The value 2 indicates RTP version 2. ucbit1PadFlag: The value 0 indicates that no padding is added after the payload. 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.

ucbit2Version: The value 2 indicates RTP version 2. ucbit1PadFlag: The value 0 indicates that no padding is added after the payload.

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

rtcpSR Description of the IE Reference Standards The rtcpSR report provides statistics about data packets sent and received by the sender. Description of the IE 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 udwSsrc: The value 3685759387 identifies the synchronization source of the SR sent by the remote end. RtcpRcvrpt: indicates the reception of packets.

udwSsrc: The value 3685259243 identifies the 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

rtcpXRVoIP Description of the IE Reference Standards The rtcpXRVoIP report provides metrics for monitoring voice over IP (VoIP) calls. Description of the IE Information Element (IE)

Description

udwSsrc: synchronization source identifier. The value 3685259243 identifies the synchronization source of the 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. The other values are as follows: 2: enhanced 1: disabled 0: unspecified bit2JBA: jitter buffer adaptive. The value 0 indicates unknown. The other values are as follows: 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

rtcpSDES Description of the IE 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). Description of the IE Information Element (IE)

Description

RTCP_SEND_MSG rtcpSDES

RTCP_RCV_MSG rtcpSDES

udwSsrc: synchronization source identifier. The value 3685259243 identifies the synchronization source of the sender report (SR). cname: The value [email protected] indicates the CNAME identifier.

udwSsrc: The value 3685759387 identifies the synchronization source of the SR sent by the remote end. cname: The value [email protected] indicates the CNAME identifier.

Reference Standards For details about the rtcpSDES item, see section 6.5 "Source Description RTCP Packet" in RFC 3550. Parent topic: Description of Associated IEs

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

rtcpRR Description of the IE Reference Standards The rtcpRR report provides statistics only on the data packets received by the receiver (such as MGW). Description of the IE Information Element (IE)

Description

udwSsrc: synchronization source identifier. The value 2563960243 identifies the synchronization source of the receiver report (RR). RtcpRcvrpt: indicates the reception of packets. 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

rtcpAPP Description of the IE 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. Description of the IE Information Element (IE)

Description

udwSsrc: synchronization source identifier. The value 2563960243 identifies the synchronization source of the 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.

The other values are as follows: 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

CAP Protocol Description of the CAP Protocol Description of the Common Part of Messages Description of Associated Messages Description of Associated IEs Parent topic: Appendix - Protocol Compliance Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the CAP Protocol Scenario Description Protocol Stack Message Structure Message List Scenario Description 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

This message is used to request the MSC to play an announcement to the subscriber.

SCP -> MSC

This message is used to request the MSC to 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Common Part of Messages The CAMEL Application Part (CAP) messages do not contain any common part. Parent topic: CAP Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated Messages 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 Parent topic: CAP Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 main IEs of the message.

Figure 1 Initial DP message

Associated IEs Information Element (IE)

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

Indicates the location information. For details, see locationInformation.

international mobile subscriber identity (IMSI)

Identifies a mobile subscriber. For details, see IMSI.

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

Indicates the MSC address. 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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 main IEs of the message. Figure 1 Request Report BCSM Event (RRBE) message

Associated IEs Information Element (IE)

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. For details, see 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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 1 shows the main IEs of the message. Figure 1 CONNECT message

Associated IEs Information Element (IE)

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

Indicates the alerting pattern. For details, see Alerting Pattern.

Reference Standards For details, see 4.6.2.6 "Connect" in 3rd Generation Partnership Project (3GPP) 23.078. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 main IEs of the message.

Figure 1 Apply Charging message Associated IEs Information Element (IE)

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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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

Indicates the party to be charged in a call. leg1 refers to the caller and leg2 refers to the callee. For details, see PartyToCharge.

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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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. For details, see PartyToCharge.

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 Project (3GPP) 23.078. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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. Parent topic: Description of Associated Messages

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

eventTypeBCSM

Indicates the type of the event to the reported. For details, see eventTypeBCSM. Indicates the call information related to the

specified event.

eventSpecificInformationBCSM

If the event is RouteSelectFailure, the IE eventSpecificInformationBCSM 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 eventSpecificInformationBCSM is empty. If the event is O-Disconnect or TDisconnect, the IE eventSpecificInformationBCSM contains the release cause (if available). If the event type is O-NotReachable or T-NotReachable, the IE eventSpecificInformationBCSM contains the release cause (if available). For details, see eventSpecificInformationBCSM.

legID

Indicates the party whose call events shall be 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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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. It is an optional IE. If this IE is not present, 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

Indicates the information to be sent. The values are inbandInfo and tone. 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. It contains the following IEs:

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

disconnectFromIPForbidden

subscriber after the announcement is 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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

None

None

Reference Standards For details, see 4.6.4.4 "Specialized Resource Report" in 3rd Generation Partnership Project (3GPP) 23.078. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Project (3GPP) 23.078. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated IEs ipSSPCapabilities Alerting Pattern AppendFreeFormat Data Application Timer bearcapability BillingCharging Characteristics CallActive CalledPartyNumber CallingPartyNumber CallingPartys Category CallReference Number CallResult cancelDigit Collected Info Destination Routing Address disconnectFromIPForbidden endOfReplyDigit errorTreatment eventSpecificInformationBCSM eventTypeBCSM firstDigitTimeOut FreeFormatData Generic Number IMSI inbandInfo informationToSend

interDigitTimeOut interruptableAnnInd iPRoutingAddress legID locationInformation LocationNumber MaxCallPeriod Duration maximumNbOfDigits minimumNbOfDigits Monitor Mode MSCAddress Original Called Party ID PartyToCharge PlayTone Redirecting Party ID Redirection Information releaseIfdurationExceeded requestAnnouncementComplete resourceAddress sendCalculationToSCPIndication serviceInteractionIndicatorsTwo ServiceKey startDigit SubscriberState Tariff Switch Interval timeIfNoTariffSwitch timeIfTariffSwitch timeZone

tone Parent topic: CAP Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

ipSSPCapabilities Description of the IE Reference Standards Description of the IE Information Element (IE)

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 considered as an example here. In this 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Alerting Pattern Description of the IE Reference Standards Description of the IE Information Element (IE)

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 For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

AppendFreeFormat Data Description of the IE Reference Standards Description of the IE Information Element (IE)

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.

AppendFreeFormat Data AppendFreeFormatData: indicates how the MSC processes multiple FCIs that are sent in a flow. The Furnish Charging Information is considered as an example here. In this example, the value of AppendFreeFormat Data is Overwrite, indicating that the previous FCI is overwritten by the next FCI. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Application Timer Description of the IE Reference Standards Description of the IE Information Element (IE)

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 For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

bearcapability Description of the IE Reference Standards Description of the IE Information Element (IE)

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 For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

BillingCharging Characteristics Description of the IE Reference Standards Description of the IE Information Element (IE)

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.

BillingCharging Characteristics

The Apply Charging is considered as an example here. In this example, the value of maxCallPeriodDuration is 600, indicating that the maximum call duration is 60 seconds. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

CallActive Description of the IE Reference Standards Description of the IE Information Element (IE)

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 considered as an example here. In this example, the value of CallActive is FALSE, indicating that the call is released. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

CalledPartyNumber Description of the IE Reference Standards Description of the IE Information Element (IE)

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 For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

CallingPartyNumber Description of the IE Reference Standards Description of the IE Information Element (IE)

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 For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

CallingPartys Category Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the caller category.

The Initial detection point (DP) message is considered as an example here. In this example, the value of CallingPartys Category is ordinary subscriber, indicating that the caller is an ordinary subscriber.

CallingPartys Category

Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

CallReference Number Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Identify a call. This IE provides the call reference number allocated by the GMSC/MSC for the call.

CallReference Number The Initial detection point (DP) message is considered as an example here. In this example, the call reference number is 16 02 66 09 05 82. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

CallResult Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the charging information requested by the SCF in the Apply Charging message.

CallResult The Apply Charging Report message is considered as an example here. In this 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 For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd.

cancelDigit Description of the IE Reference Standards Description of the IE Information Element (IE)

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 message is considered as an example here. In this example, the value of cancelDigit is oB, indicating that the entered characters are discarded if the asterisk (*) is received. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Collected Info Description of the IE Reference Standards Description of the IE Information Element (IE)

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

The Prompt And Collect User Information message is considered as an example here. In this example, the value of maximumNbOfDigits is 16, indicating that the maximum number of valid digits to be collected is 16. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Destination Routing Address Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the number to which the call is routed. It is a mandatory IE.

Destination Routing Address The Connect message is considered as an example here. In this example, the destination routing address is 8613466784401 (international number). Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

disconnectFromIPForbidden Description of the IE Reference Standards Description of the IE Information Element (IE)

disconnectFromIPForbidden

Description Indicates whether to release the connection between the special resource and the subscriber after the announcement is 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 considered as an example here. In this example, the value of disconnectFromIPForbidden is TRUE, indicating that disconnecting the subscriber from the special resource is permitted. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

endOfReplyDigit Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the digit string used to signal the end of input. It is an optional IE.

endOfReplyDigit

The Prompt And Collect User Information message is considered as an example here. In this example, the value of endOfReplyDigit is 0C, indicating that the input is complete when the pound key (#) is received. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

errorTreatment Description of the IE Reference Standards Description of the IE Information Element (IE)

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

The Prompt And Collect User Information message is considered as an example here. 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 For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

eventSpecificInformationBCSM Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the call information related to the specified event.

eventSpecificInformationBCSM

If the event is RouteSelectFailure, the IE eventSpecificInformationBCSM 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 eventSpecificInformationBCSM is empty. If the event is O-Disconnect or TDisconnect, the IE eventSpecificInformationBCSM contains the release cause (if available). If the event type is O-NotReachable or T-NotReachable, the IE eventSpecificInformationBCSM contains the release cause (if 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 For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

eventTypeBCSM Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the type of the event to the reported.

eventTypeBCSM

The Event Report basic call state model (BCSM) message is considered as an example here. In this example, the value of eventTypeBCSM is tDisconnect, indicating the call release event. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

firstDigitTimeOut Description of the IE Reference Standards Description of the IE Information Element (IE)

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

firstDigitTimeOut

The Prompt And Collect User Information message is considered as an example here. 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 For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078.

Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

FreeFormatData Description of the IE Reference Standards Description of the IE Information Element (IE)

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 considered as an example here. In this example, the content to be inserted to the CAMEL CDR is 80 01 30. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Generic Number Description of the IE Reference Standards Description of the IE Information Element (IE)

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 For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

IMSI Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Identifies a mobile subscriber.

international mobile subscriber identity (IMSI) The Initial detection point (DP) message is considered as an example here. In this example, the IMSI is 460077552000446. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

inbandInfo Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the inband information. This IE contains the following IEs: 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.

inbandInfo

The Play Announcement message is considered as an example here. In this example, the announcement is repeated twice, the duration is 16 seconds, and there is no interval between two successive

announcements. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

informationToSend Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the information to be sent. The values are as follows: inbandInfo: indicates the inband information tone: indicates the tone.

informationToSend

The Play Announcement message is considered as an example here. In this example, the inband information is sent. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

interDigitTimeOut Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the duration of the inter-digit timer. It is an optional IE. If this IE is not present, 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

The Prompt And Collect User Information message is considered as an example here. In this example, the value of interDigitTimeOut is 5, indicating that the timer expires if the interval between two digits exceeds five seconds.

Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

interruptableAnnInd Description of the IE Reference Standards Description of the IE Information Element (IE)

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

The Prompt And Collect User Information message is considered as an example here.

In this example, the value of interruptableAnnInd is TRUE, indicating that the announcement is interrupted after the first valid digit is received by the MSC. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

iPRoutingAddress Description of the IE Reference Standards Description of the IE Information Element (IE)

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 For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

legID Description of the IE Reference Standards Description of the IE Information Element (IE)

Description 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 must be explicitly given.

The Request Report basic call state model (BCSM) Event message is considered as an example here. In this example, the value of legID is 2, indicating that the call events of the callee shall be reported to the SCF. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078.

Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

locationInformation Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the location information.

locationInformation

The Initial detection point (DP) message is considered as an example here. In this example, the VLR number is 861310752051. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

LocationNumber Description of the IE Reference Standards Description of the IE Information Element (IE)

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 For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MaxCallPeriod Duration Description of the IE Reference Standards Description of the IE Information Element (IE)

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.

MaxCallPeriod Duration

The Apply Charging message is considered as an example here. In this example, the maximum call duration is 120 seconds. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd.

maximumNbOfDigits Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the maximum number of valid digits to be collected.

maximumNbOfDigits The Prompt And Collect User Information message is considered as an example here. In this example, the value of maximumNbOfDigits is 16, indicating that the maximum number of valid digits to be collected is 16. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

minimumNbOfDigits Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the minimum number of valid digits to be collected.

minimumNbOfDigits The Prompt And Collect User Information message is considered as an example here. In this example, the value of minimumNbOfDigits is 1, indicating that the minimum number of valid digits to be collected is 1. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Monitor Mode Description of the IE Reference Standards Description of the IE Information Element (IE)

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.

The Request Report basic call state model (BCSM) Event message is considered as an example here. In this example, the value of Monitor Mode is interrupted, indicating that the event is reported as a request. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MSCAddress Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the MSC address.

MSCAddress The Initial detection point (DP) message is considered as an example here. In this example, the MSC address is 861310752051. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Original Called Party ID Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the original called number. This IE is present when the call is forwarded.

Original Called Party ID

The Connect message is considered as an example here. In this example, the original called number is 8613907521124. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

PartyToCharge Description of the IE Reference Standards Description of the IE Information Element (IE)

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

PartyToCharge The Apply Charging message is considered as an example here. In this example, the value of PartyToCharge is leg1, indicating that the call is paid by the caller. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

PlayTone Description of the IE Reference Standards Description of the IE Information Element (IE)

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

The Apply Charging message is considered as an example here. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Redirecting Party ID Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the redirecting number from which the route is forwarded.

Redirecting Party ID

The Connect message is considered as an example here. In this example, the redirecting number is 8613907521124. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Redirection Information Description of the IE Reference Standards Description of the IE 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 For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

releaseIfdurationExceeded Description of the IE Reference Standards Description of the IE Information Element (IE)

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.

releaseIfdurationExceeded

The Apply Charging message is considered as an example here. In this example, the value of releaseIfdurationExceeded is 1, indicating the call is released after the maximum call duration is reached. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

requestAnnouncementComplete Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates whether to send the Special Resource Report (specialized resource report (SRR)) after the tone or announcement is complete.

requestAnnouncementComplete

The Play Announcement message is considered as an example here. In this example, the value of requestAnnouncementComplete is TRUE, indicating that the MSC sends the SRR after the tone or announcement is complete.

Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

resourceAddress Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the physical address of the GSM specialized resource function (gsmSRF).

resourceAddress The Connect To Resource message is considered as an example here. In this example, the value of resourceAddress is none, indicating that the MSC has the gsmSRF function. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

sendCalculationToSCPIndication Description of the IE Reference Standards Description of the IE Information Element (IE)

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.

sendCalculationToSCPIndication

The Apply Charging message is considered as an example here. In this example, the 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 For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

serviceInteractionIndicatorsTwo Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates whether to set up the connection between the caller and the GSM specialized resource function (gsmSRF).

serviceInteractionIndicatorsTwo

The Connect To Resource message is considered as an example here. In this example, the bidirectional connection is set up. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

ServiceKey Description of the IE Reference Standards Description of the IE Information Element (IE)

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

The Initial detection point (DP) message is considered as an example here. In this example, the service key is 1. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

startDigit Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the start digit string that denotes the start of the valid digits to be collected. It is an optional IE.

startDigit

The Prompt And Collect User Information message is considered as an example here. In this example, the value of startDigit is 0, indicating that the start digit string is 0. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

SubscriberState Description of the IE Reference Standards Description of the IE Information Element (IE)

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

The Initial detection point (DP) message is considered as an example here. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Tariff Switch Interval Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the tariff switch interval, that is, the time interval at which the tariff is switched.

Tariff Switch Interval

The Apply Charging message is considered as an example here. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

timeIfNoTariffSwitch Description of the IE Reference Standards Description of the IE Information Element (IE)

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.

timeIfNoTariffSwitch

The Apply Charging Report message is considered as an example here. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

timeIfTariffSwitch Description of the IE Reference Standards Description of the IE Information Element (IE)

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.

The Apply Charging Report message is considered as an example here. In this 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 For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078.

Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

timeZone Description of the IE Reference Standards Description of the IE Information Element (IE)

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

The Initial detection point (DP) message is considered as an example here. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

tone Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the tone information. It contains the following information: ToneID: identifies a tone. Duration: indicates the duration of the tone. It is an optional IE.

tone

The Play Announcement message is considered as an example here. In this example, the tone ID is 0x100001f and the tone duration is 15 seconds. Reference Standards For details, see 5.1 "Data types" in 3rd Generation Partnership Project (3GPP) 29.078. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

ISUP Protocol Description of the ISUP Protocol Description of the Common Part of Messages Description of Associated Messages Description of Associated IEs Parent topic: Appendix - Protocol Compliance Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the ISUP Protocol Scenario Description Protocol Stack Message Structure Message List Scenario Description 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)

This message is sent in the backward direction indicating that 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)

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.

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Common Part of Messages Table 1 describes the IEs carried in the common part of messages. Table 1 IEs carried in the common part of messages 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. Parent topic: ISUP Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated Messages IAM APM ACM ANM INR INF CPG CON SAM REL RLC SUS RES Parent topic: ISUP Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 shows the main IEs of the message.

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

Provides the information about the characteristics of the 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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Backward call indicators

Provides the information about 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 2.1 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and Table 21/Q.763 in ITU-T Q-763. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 call indicators

Provides the information about 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 2.2 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and Table 22/Q.763 in ITU-T Q-763. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Element (IE) Description Information request indicators

Identifies the optional parameters requested in a message. For details, see Information Request Indicators.

Reference Standards For details, see 2.27 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and Table 31/Q.763 in ITU-T Q-763. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Information indicators

Identifies the optional parameters included in a message. For details, see Information Indicators.

Reference Standards For details, see 2.26 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and Table 30/Q.763 in ITU-T Q-763. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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 For details, see 2.5 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and Table 23/Q.763 in ITU-T Q-763. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 main IEs of the message.

Figure 1 CON message Associated IEs Information Element (IE)

Description

Backward call indicators

Provides the information about 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 2.16 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and Table 27/Q.763 in ITU-T Q-763. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE) Description

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 For details, see 2.39 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and Table 35/Q.763 in ITU-T Q-763. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE) Description Cause indicators

Indicates the reason for sending the message. For details, see Cause Indicators.

Reference Standards For details, see 2.34 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and Table 33/Q.763 in ITU-T Q-763. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 For details, see 2.35 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and Table 34/Q.763 in ITU-T Q-763. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 For details, see 2.40 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and Table 38/Q.763 in ITU-T Q-763. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 For details, see 2.37 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and Table 38/Q.763 in ITU-T Q-763. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated IEs 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 Parent topic: ISUP Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Called Party Number Description of the IE Reference Standards Description of the IE Information Element (IE)

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

For details, see 3.14 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and 3.9 in ITU-T Q-763. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Propagation Delay Counter Description of the IE Reference Standards Description of the IE Information Element (IE)

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 For details, see 3.58 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and 3.42 in ITU-T Q-763. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Transmission Medium Requirement Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the type of transmission medium required for the 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. The IAM is considered as an example here. In this example, Transmission medium requirement is speech, which indicates that voice calls need to be supported.

Reference Standards For details, see 3.73 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and 3.54 in ITU-T Q-763. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Subsequent Number Description of the IE Reference Standards Description of the IE Information Element (IE)

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 For details, see 3.70 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and 3.51 in ITU-T Q-763. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Backward Call Indicators Description of the IE Reference Standards Description of the IE Information Element (IE)

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

Backward call indicators

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. The IAM is considered as an example here. In this example, 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 For details, see 3.4 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and 3.5 in ITU-T Q-763. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Nature of Connection Indicators Description of the IE Reference Standards Description of the IE Information Element (IE)

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. The IAM is considered as an example here. In this example, 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 For details, see 3.50 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and 3.35 in ITU-T Q-763. Parent topic: Description of Associated IEs

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Forward Call Indicators Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the characteristics of the connection, signaling path, and calling party sent in the forward direction. This IE is sent in the forward direction and carried in the IAM.

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. The IAM is considered as an example here. In this example, 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 For details, see 3.35 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and 3.23 in ITU-T Q-763. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Optional Forward Call Indicators Description of the IE Reference Standards Description of the IE Information Element (IE) Description Indicates the characteristics of the connection, signaling path, and called party sent in the forward direction This IE is sent in the forward direction and carried in the IAM.

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 For details, see 3.54 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and 3.38 in ITU-T Q-763. Parent topic: Description of Associated IEs

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Event Information Description of the IE Reference Standards Description of the IE Information Element (IE)

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 For details, see 3.33 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and 3.21 in ITU-T Q-763. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Generic Notification Indicator Description of the IE Reference Standards Description of the IE Information Element (IE)

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 For details, see 3.38 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and 3.25 in ITU-T Q-763. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Information Indicators Description of the IE Reference Standards Description of the IE Information Element (IE) Description 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 For details, see 3.42 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and 3.28 in ITU-T Q-763. Parent topic: Description of Associated IEs

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Information Request Indicators Description of the IE Reference Standards Description of the IE 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 For details, see 3.43 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and 3.29 in ITU-T Q-763. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Cause Indicators Description of the IE Reference Standards Description of the IE Information Element (IE)

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 For details, see 3.17 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762, 3.12 in ITU-T Q-763, and ITU-T Q-850. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Calling Party Number Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Identifies the calling party. Generally, this IE is carried in the IAM. It is optional.

Calling party number

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 For details, see 3.15 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and 3.10 in ITU-T Q-763. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Calling Party's Category Description of the IE Reference Standards Description of the IE Information Element (IE)

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. The IAM is considered as an example here. In this example, Calling party's category is ordinary-calling-subscriber(10), which indicates that the calling party is an ordinary subscriber.

Reference Standards For details, see 3.16 in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q-762 and 3.11 in ITU-T Q-763. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

BICC Protocol Description of the BICC Protocol Description of the Common Part of Messages Description of Associated Messages Description of Associated IEs Parent topic: Appendix - Protocol Compliance Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the BICC Protocol Scenario Description Protocol Stack Message Structure Message List Scenario Description 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 MSCMSC 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 MSCMSC BICC Message (APM)

This message is sent in either direction to convey application information using the Application Transport mechanism.

Address Complete MSCMSC 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 MSCMSC BICC (ANM)

This message is sent in the backward direction to indicate that the call has been answered.

Parent topic: BICC Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Common Part of Messages Table 1 describes the IEs carried in the common part of messages. Table 1 IEs carried in the common part of messages 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. Parent topic: BICC Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated Messages IAM APM ACM ANM Parent topic: BICC Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 1 shows the main IEs of the message.

Figure 1 IAM message Associated IEs Information Element (IE)

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

Provides information sent in the forward direction to 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

Provides information sent in the forward direction to 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

Provides information sent in the forward direction to 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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description Provides information sent in either direction to allow the peer-to-peer communication of

application transport parameter

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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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 For details, see International Telecommunication Union-Telecommunication Standardization

Sector (ITU-T) Q.1902.2 and Q.1902.3. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 shows the main IEs of the message.

Figure 1 ANM message Associated IEs Information Element (IE)

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.

Reference Standards For details, see ITU-T Q.1902.2. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated IEs called party number propagation delay counter transmission medium requirement location number backward call indicators nature of connection indicators forward call indicators optional forward call indicators user service information call reference application transport parameter cause indicators calling party number calling party's category Parent topic: BICC Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

called party number Description of the IE Reference Standards Description of the IE Information Element (IE)

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

propagation delay counter Description of the IE Reference Standards Description of the IE Information Element (IE)

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.

propagation delay counter An IAM message is considered as an example here. In this 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

transmission medium requirement Description of the IE Reference Standards Description of the IE Information Element (IE)

transmission medium requirement

Description Indicates the type of transmission medium required for the 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

location number Description of the IE Reference Standards Description of the IE Information Element (IE)

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

nature of address indicator: indicates the nature of location number, for example, international number, national number, subscriber number, or unknown 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. numbering plan indicator: indicates the numbering plan used for location 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 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

backward call indicators Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Provides information relating to the characteristics of the connection, signaling path, and called party sent in the backward direction. This IE consists of the following fields:

backward call indicators

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

nature of connection indicators Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Provides information relating to the transmission path used on a connection. This IE is sent in the forward direction and mandatory in an IAM message. It consists of the following fields:

nature of connection indicators

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.

An IAM message is considered as an example here. In this 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 Union-Telecommunication Standardization Sector (ITU-T) Q.1902.3. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd.

forward call indicators Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Provides information relating to the characteristics of the connection, signaling path, and calling party. This IE is sent in the forward direction and mandatory in an IAM message. It consists of the following fields:

forward call indicators

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.

An IAM message is considered as an example here. In this 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

optional forward call indicators Description of the IE Reference Standards Description of the IE Information Element (IE) Description Provides information relating to the characteristics of the 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.

An IAM message is considered as an example here. In this 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 Union-Telecommunication Standardization Sector (ITU-T) Q.1902.3. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

user service information Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the bearer capability required by the calling party. This IE is sent in the forward direction and optional in an IAM message. It consists of the following fields: information transfer capability coding standard information transfer rate transfer mode

user service information

An IAM message is considered as an example here. In this 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

call reference Description of the IE Reference Standards Description of the IE Information Element (IE)

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.

An IAM message is considered as an example. In this 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

application transport parameter Description of the IE Reference Standards Description of the IE Information Element (IE)

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

An IAM message is considered as an example. In this 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

cause indicators Description of the IE Reference Standards Description of the IE Information Element (IE)

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

calling party number Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Identifies the calling party. This IE is optional in an IAM message. It consists of the following fields:

calling party number

nature of address indicator: indicates the nature of calling 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 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. numbering plan indicator: indicates the numbering plan used for the calling number. number incomplete indicator: indicates whether the delivered calling number is complete or incomplete.

An IAM message is considered as an example here. In this 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

calling party's category Description of the IE Reference Standards Description of the IE Information Element (IE)

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.

calling party's category An IAM message is considered as an example here. In this 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

SIP Protocol Description of the SIP Protocol Description of the Common Part of Messages Description of Associated Messages Description of Associated IEs Parent topic: Appendix - Protocol Compliance Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the SIP Protocol Scenario Description Protocol Stack Message Structure Message List Description of the SIP-I Protocol Protocols with which the SIP complies Scenario Description 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

The Session Initiation Protocol (SIP) "Replaces" Header

IETF RFC 3892

The Session Initiation Protocol (SIP) 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Common Part of Messages Reference Standards Table 1 describes the IEs carried in the common part of messages. Table 1 IEs carried in the common part of messages 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. Parent topic: SIP Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated Messages INVITE PRACK ACK BYE OPTIONS CANCEL Parent topic: SIP Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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. For details, see Request-Line and Message Header.

From

Indicates the originator of the request. For details, see Request-Line and Message Header.

To

Indicates the receipt of the request. For details, see Request-Line and Message Header.

command sequence (CSeq)

Indicates the command sequence. For details, see Request-Line and Message Header.

Max-Forwards

Indicates the maximum number of times the request can be forwarded before it arrives at the destination. For details, see Request-Line and Message Header.

Session-Expires

Indicates the time at which the request expires. For details, see Request-Line and Message Header.

Contact

Indicates the address for direction communication. For details, see Request-Line and Message Header.

Allow

Indicates the request types supported by the server. For details, see Request-Line and Message Header.

Content-Length

Indicates the length of the message body. For details, see Request-Line and Message Header.

Content-Type

Indicates the media type of the message body. For details, see Request-Line and Message 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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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. For details, see Request-Line and Message Header. Indicates the originator of the request.

From

For details, see Request-Line and Message Header. To

Indicates the receipt of the request. For details, see Request-Line and Message Header.

CSeq

Indicates the command sequence. For details, see Request-Line and Message Header.

Max-Forwards

Indicates the maximum number of times the request can be forwarded before it arrives at the destination. For details, see Request-Line and Message Header.

RAck

Indicates the sequence number of the PRACK message that maps a reliable provisional response message 1XX. For details, see Request-Line and Message Header.

Content-Length

Indicates the length of the message body. For details, see Request-Line and Message Header.

Reference Standards For details, see 4 "UAC Behavior" in RFC3262. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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 Session Initiation Protocol (SIP) session. For details, see Request-Line and Message Header.

From

Indicates the originator of the request. For details, see Request-Line and Message Header.

To

Indicates the receipt of the request. For details, see Request-Line and Message Header. Indicates the command sequence.

command sequence (CSeq)

For details, see Request-Line and Message Header.

Max-Forwards

Indicates the maximum number of times the request can be forwarded before it arrives at the destination. For details, see Request-Line and Message Header.

Content-Length

Indicates the length of the message body. For details, see Request-Line and Message Header.

Reference Standards For details, see 17.1.1.3 "Construction of the ACK Request" in RFC3261. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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 Session Initiation Protocol (SIP) session. For details, see Request-Line and Message Header.

From

Indicates the originator of the request. For details, see Request-Line and Message Header.

To

Indicates the receipt of the request. For details, see Request-Line and Message Header.

Command sequence (CSeq)

Indicates the command sequence. For details, see Request-Line and Message Header.

Max-Forwards

Indicates the maximum number of times the request can be forwarded before it arrives at the destination. For details, see Request-Line and Message Header.

Reason

Indicates the reason of session release. For details, see Request-Line and Message Header.

Content-Length

Indicates the length of the message body. For details, see Request-Line and Message Header.

Reference Standards For details, see 15.1 "Terminating a Session with a BYE Request" in RFC3261. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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. For details, see Request-Line and Message Header.

From

Indicates the originator of the request. For details, see Request-Line and Message Header.

To

Indicates the receipt of the request. For details, see Request-Line and Message Header.

Command sequence (CSeq)

Indicates the command sequence. For details, see Request-Line and Message

Header.

Max-Forwards

Indicates the maximum number of times the request can be forwarded before it arrives at the destination. For details, see Request-Line and Message Header.

Content-Length

Indicates the length of the message body. For details, see Request-Line and Message Header.

Reference Standards For details, see 11 "Querying for Capabilities" in RFC3261. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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 Session Initiation Protocol (SIP) session. For details, see Request-Line and Message Header.

From

Indicates the originator of the request. For details, see Request-Line and Message Header.

To

Indicates the receipt of the request. For details, see Request-Line and Message Header.

Command sequence (CSeq)

Indicates the command sequence. For details, see Request-Line and Message

Header.

Max-Forwards

Indicates the maximum number of times the request can be forwarded before it arrives at the destination. For details, see Request-Line and Message Header.

Reason

Indicates the reason of session release. For details, see Request-Line and Message Header.

Content-Length

Indicates the length of the message body. For details, see Request-Line and Message Header.

Reference Standards For details, see 16.10 "CANCEL Processing" in RFC3261. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated IEs Request-Line and Message Header Message Body 1 Message Body 2 183 180 200 FOR INVITE Parent topic: SIP Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Indicates the ID of the SIP session. 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

Indicates the originator of the request. 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 ;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. Indicates the command sequence.

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. Indicates the reason of session release. 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description Indicates the version number of the SDP protocol.

v

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 = The o IE in the SDP body is considered as an example here. In this example,

o

: Indicates the host to which the user logs in and from which the user originates the session. : Indicates the globally unique sequence number of the session. : IN stands for Internet Network. : The value can be Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6). : Indicates the address of the originator. Indicates the name of the session.

s

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 =

c

The c IE in the SDP body is considered as an example here. In this example, : IN stands for Internet Network. : The value can be IPv4 and IPv6. : Indicates the multicast address that can receive the session.

t

Indicates the start time and end time of the association of the session. Generally, the t IE is in the following format: t = 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 = The m IE in the SDP body is considered as an example here. In this example,

m

: The value can be audio, video, or data. : 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, is set to 8952.

: 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 = : 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Message Body 2 Description of the IE Reference Standards Description of the IE Information Element (IE)

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Via

Indicates the path through which a request message is transmitted. For details, see Request-Line and Message Header.

Call-ID

Identifies a SIP call. For details, see Request-Line and Message Header.

From

Indicates the originator of the request. For details, see Request-Line and Message Header.

To

Indicates the recipient of the request. For details, see Request-Line and Message Header.

Command sequence (CSeq)

Indicates the command sequence. For details, see Request-Line and Message Header.

Max-Forwards

Indicates the maximum number of times the request can be forwarded before it reaches the destination. For details, see Request-Line and Message Header.

RSeq

Indicates the sequence of the temporary response message 1XX. For details, see Request-Line and Message Header.

Content-Length

Indicates the length of the message body of the request message. For details, see Request-Line and Message Header.

Reference Standards For details, see 4 "Overview of Operation" in RFC3261. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Via

Indicates the path through which a request message is transmitted. For details, see Request-Line and Message Header.

Call-ID

Identifies a SIP call. For details, see Request-Line and Message Header.

From

Indicates the originator of the request. For details, see Request-Line and Message

Header. To

Indicates the recipient of the request. For details, see Request-Line and Message Header.

Command sequence (CSeq)

Indicates the command sequence. For details, see Request-Line and Message Header.

Max-Forwards

Indicates the maximum number of times the request can be forwarded before it reaches the destination. For details, see Request-Line and Message Header.

RSeq

Indicates the sequence of the temporary response message 1XX. For details, see Request-Line and Message Header.

Content-Length

Indicates the length of the message body of the request message. For details, see Request-Line and Message Header.

Reference Standards For details, see 4 "Overview of Operation" in RFC3261. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Via

Indicates the path through which a request is transmitted. For details, see Request-Line and Message Header.

Call-ID

Identifies a Session Initiation Protocol (SIP) call. For details, see Request-Line and Message Header.

From

Indicates the originator of the request. For details, see Request-Line and Message Header.

To

Indicates the recipient of the request. For details, see Request-Line and Message Header.

Command sequence (CSeq)

Indicates the command sequence. For details, see Request-Line and Message Header.

Max-Forwards

Indicates the maximum number of times the request can be forwarded before it reaches the destination. For details, see Request-Line and Message Header.

Content-Length

Indicates the length of the message body of the request message. For details, see Request-Line and Message Header.

Reference Standards For details, see 4 "Overview of Operation" in RFC3261. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

M2UA Protocol Description of the M2UA Protocol Description of the Common Part of Messages Description of Associated Messages Description of Associated IEs Parent topic: Appendix - Protocol Compliance Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the M2UA Protocol Scenario Description Protocol Stack Message Structure Message List Scenario Description 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

Table 1 List of common M2UA messages Message

Direction

Function

MSCSG

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

The message is used to release a channel.

SG -> MSC

The message is sent in response to a Release Request message.

SG -> MSC

The message is used to 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

The message is sent in response to a State Request message.

Data

Establish Request

Release Confirm

Release Indication

State Request

State Confirm

State Indication

SG -> MSC

The message is sent from the 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

The message is used to indicate to a remote M2UA peer that the adaptation layer is ready to receive traffic or maintenance messages.

MSC SG

The message is used to indicate to a remote M2UA peer that the adaptation layer 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

The message is used to acknowledge an ASP Up message received from a remote M2UA peer.

MSC SG

The message is used to acknowledge an ASP Down message received from a remote M2UA peer.

MSC SG

The message is sent in 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

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

SG -> MSC

The message is used to acknowledge an ASP Active message received from a remote M2UA peer.

SG -> MSC

The message is used to acknowledge an ASP Inactive message received from a 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

The message is used to provide an autonomous indication of M2UA events to an M2UA peer.

Parent topic: M2UA Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Common Part of Messages Table 1 describes the IEs carried in the common part of messages. Table 1 IEs carried in the common part of messages Information Element (IE)

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 message is considered as an example here. 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. The ASP Up message is considered as an example here. In this example, 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. The ASP Up message is considered as an example here. In this example, Message Length is 8, which indicates that the length of the message is 8. Parent topic: M2UA Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated Messages Data Establish Release State Error Notify ASP Up ASP Active ASP Inactive Parent topic: M2UA Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 shows the main IEs of the message.

Figure 1 Data message Associated IEs Information Element (IE)

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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Information Element (IE)

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. Parent topic: Description of Associated Messages

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 shows the main IEs of the message.

Figure 1 Error message Associated IEs Information Element (IE)

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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 shows the main IEs of the message.

Figure 1 Notify message Associated IEs Information Element (IE)

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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 shows the main IEs of the message.

Figure 1 ASP Up message Associated IEs Information Element (IE)

Description

None

None

Reference Standards For details, see 3.3.2.1 "ASP Up (ASPUP)" in RFC3331. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 shows the main IEs of the message.

Figure 1 ASP Active message Associated IEs Information Element (IE)

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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

None

None

Reference Standards For details, see 3.3.2.9 "ASP Inactive (ASPIA)" in RFC3331. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated IEs Protocol Data Error Code Status Type Traffic Mode Type Parent topic: M2UA Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Protocol Data Description of the IE Reference Standards Description of the IE Information Element (IE)

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Error Code Description of the IE Reference Standards Description of the IE Information Element (IE)

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 12: 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 20: not used in M2UA

21: not used in M2UA 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Status Type Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the type of the Notify message. 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) When Status Type is set to 2, Status Information can be set to any of the 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Traffic Mode Type Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the traffic mode of operation of the 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

M3UA Protocol Description of the M3UA Protocol Description of the Common Part of Messages Description of Associated Messages Description of Associated IEs Parent topic: Appendix - Protocol Compliance Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the M3UA Protocol Scenario Description Protocol Stack Message Structure Message List Scenario Description 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 Table 1 List of common M3UA messages 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

The message is 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 unreachable.

Destination Available (DAVA) SG -> MSC

The message is 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 reachable (and not restricted), or in response to a DAUD message if appropriate.

Destination State Audit (DAUD)

The message is sent from the ASP to the SGP to audit the availability/congestion state of SS7 routes from the SG to one or more affected destinations.

Destination Unavailable (DUNA)

MSC -> SG

Signaling Congestion (SCON) SG -> MSC

The message is sent from the SGP in an SG to all concerned ASPs to indicate that the SG has determined 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

The message is used to indicate to a remote M3UA peer that the adaptation layer is ready to receive any ASPSM/ASPTM messages for all routing keys that the ASP is configured to serve.

MSC -> SG

The message is used to indicate to a remote M3UA peer that the adaptation layer is not ready to receive Data, SSNM, or ASPTM messages.

SG -> MSC

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

SG -> MSC

The message is used to acknowledge an ASP Down message received from a remote M3UA peer. The message is sent by the 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

The message is sent by the 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

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

SG -> MSC

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

Parent topic: M3UA Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Common Part of Messages Table 1 describes the IEs carried in the common part of messages. Table 1 IEs carried in the common part of messages Information Element (IE)

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 message is considered as an example here. 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 7: reserved for other SIGTRAN

Message Class

adaptation layers 8: reserved for other SIGTRAN 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. 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 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

Message Type: Indicates the type of an M3UA message. The ASP Up message is considered as an example here. In this example, 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. The ASP Up message is considered as an example here. In this example, Message Length is 8, which indicates that the length of the message is 8. Parent topic: M3UA Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated Messages Notify ASP Up ASP Active ASP Inactive Parent topic: M3UA Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 shows the main IEs of the message.

Figure 1 Notify message Associated IEs Information Element (IE)

Description

Status Type

Indicates the type of the Notify message. For details, see Status Type.

Reference Standards For details, see 3.8.2 "Notify" in RFC3332. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 main IEs of the message.

Figure 1 ASP Up message Associated IEs Information Element (IE)

Description

None

None

Reference Standards For details, see 3.5.1 "ASP Up" in RFC3332. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 shows the main IEs of the message.

Figure 1 ASP Active message Associated IEs Information Element (IE)

Description

Traffic Mode Type

Indicates the traffic mode of operation of the ASP within an AS. For details, see Traffic Mode Type.

Reference Standards For details, see 3.7.1 "ASP Active" in RFC3332. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 shows the main IEs of the message.

Figure 1 ASP Inactive message Associated IEs Information Element (IE)

Description

None

None

Reference Standards For details, see 3.7.3 "ASP Inactive" in RFC3332. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated IEs Traffic Mode Type Status Type Parent topic: M3UA Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Traffic Mode Type Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the traffic mode of operation of the 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Status Type Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the type of the Notify message. 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) When Status Type is set to 2, Status Information can be set to any of the 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

SCCP Protocol Description of the SCCP Protocol Description of the Common Part of Messages Description of Associated Messages Description of Associated IEs Parent topic: Appendix - Protocol Compliance Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the SCCP Protocol Scenario Description Protocol Stack Message Structure Message List Scenario Description 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

The primitive is used by SCCP to inform SCCP User that SCCP data is being delivered to SCCP User in a connectionless service.

SCCP User -> SCCP

The primitive is used by SCCP User to request SCCP to establish a signaling connection.

SCCP -> SCCP User

The primitive is used by 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

The primitive is used by SCCP on the originating side to confirm to the caller that a signaling connection has been established.

SCCP User -> SCCP

The primitive is used by SCCP User to request SCCP to reject a signaling connection request or disconnect a signaling connection.

SCCP -> SCCP User

The primitive is used by SCCP to request SCCP User to reject a signaling connection request or disconnect a signaling connection. The primitive is used by SCCP User to request SCCP 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

The primitive is used by SCCP to notify SCCP User that the SCCP data is being delivered in a connectionoriented service.

SCCP -> MTP

The primitive is used by 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

The primitive is used by MTP to inform SCCP of the total inability of providing the MTP service to the specified destination.

MTP -> SCCP

The primitive is used by MTP 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.

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Common Part of Messages Table 1 describes the IEs carried in the common part of messages. Table 1 IEs carried in the common part of messages Information Element (IE)

Description Indicates the type of an Signaling Connection Control Part (SCCP) message.

Message Type

Message Type: Indicates the type of an 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. The N-STATE-IND primitive is considered as an example here. In this example, 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

Parent topic: SCCP Protocol

Message Content: Indicates the contents of an SCCP message. The N-STATE-IND primitive is considered as an example here. In this example, Message Content is the contents of the N-STATE-IND primitive.

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated Messages SCCP User Primitive MTP Service Primitive Parent topic: SCCP Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

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

The primitive is used by MTP to inform SCCP of the ability of providing the MTP service to the specified destination. For details, see MTP-RESUME-IND.

MTP-STATUS-IND

The primitive is used by MTP 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. For details, see MTP-STATUS-IND.

Reference Standards For details, see 7.2 "MTP-primitives and parameters" in International Telecommunication

Union-Telecommunication Standardization Sector (ITU-T) Q.711. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated IEs MTP-PAUSE-IND MTP-RESUME-IND MTP-STATUS-IND N-PCSTATE N-STATE Protocol Class Service Information Octet User Data Reason Calling/Called Address Parent topic: SCCP Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MTP-PAUSE-IND Description of the IE Reference Standards Description of the IE Information Element (IE)

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 as an example here. In this example, 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 Union-Telecommunication Standardization Sector (ITU-T) Q.711. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MTP-RESUME-IND Description of the IE Reference Standards Description of the IE Information Element (IE)

Description The primitive is used by Message Transfer Part (MTP) to inform Signaling Connection Control Part (SCCP) of the ability of providing the MTP service to the specified destination.

MTP-RESUME-IND

Affected destination point code (DPC): Indicates the affected SPs. The MTP-RESUME-IND primitive is considered as an example here. In this 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 For details, see 7.2 "Services provided by the SCCP" in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q.711. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MTP-STATUS-IND Description of the IE Reference Standards Description of the IE information element (IE)

Description The primitive is used by Message Transfer Part (MTP) to inform Signaling Connection Control Part (SCCP) of the status of a signaling point (SP) of the destination.

MTP-STATUS-IND Affected destination point code (DPC): Indicates the affected SPs. The MTP-STATUS-IND primitive is considered as an example here. In this example, Affected DPC is 0x123456, which indicates that the SP 0x123456 is unavailable. Reference Standards For details, see 7.2 "Services provided by the SCCP" in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q.711. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

N-PCSTATE Description of the IE Reference Standards Description of the IE information element (IE)

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 International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q.711. Parent topic: Description of Associated IEs

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

N-STATE Description of the IE Reference Standards Description of the IE information element (IE)

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 International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q.711.

Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Protocol Class Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Service Information Octet Description of the IE Reference Standards Description of the IE information element (IE)

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:

Service Information Octet

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

User Data Description of the IE Reference Standards Description of the IE information element (IE)

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Reason Description of the IE Reference Standards Description of the IE information element (IE)

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 considered as an example here. In this example, 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Calling/Called Address Description of the IE Reference Standards Description of the IE information element (IE)

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 Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q.711. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

PRA Protocol Description of the PRA Protocol Description of the Common Part of Messages Description of Associated Messages Description of Associated IEs Parent topic: Appendix - Protocol Compliance Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the PRA Protocol Scenario Description Protocol Stack Message Structure Message List Scenario Description 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Common Part of Messages Table 1 describes the IEs carried in the common part of messages. Table 1 IEs carried in the common part of messages 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. Parent topic: PRA Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated Messages ALERTING CALL PROCEEDING CONNECT CONNECT ACKNOWLEDGE DISCONNECT RELEASE RELEASE COMPLETE SETUP SETUP ACKNOWLEDGE Parent topic: PRA Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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. For details, see Message type.

Progress indicator

Indicates an event that has occurred during the life of a call. For details, see Progress indicator.

Reference Standards For details, see 3.1.1 "ALERTING" in ITU-T Q.931. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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. Figure 1 CONNECT message

Associated IEs information element (IE)

Description

Progress indicator

Indicates an event that has occurred during the life of a call. For details, see Progress indicator.

Reference Standards For details, see 3.1.3 "CONNECT" in ITU-T Q.931.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 shows the main IEs of the message. Figure 1 DISCONNECT message

Associated IEs Information Element (IE) Description Cause

Indicates the cause for the message. For details, see Cause.

Reference Standards For details, see 3.1.5 "DISCONNECT" in ITU-T Q.931. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 the main IEs of the message.

Figure 1 RELEASE message Associated IEs Information Element (IE)

Description

Cause

Indicates the cause for the message. For details, see Cause.

Reference Standards For details, see 3.1.9 "RELEASE" in ITU-T Q.931. Parent topic: Description of Associated Messages

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 main IEs of the message. Figure 1 RELEASE COMPLETE message

Reference Standards For details, see 3.1.10 "RELEASE COMPLETE" in ITU-T Q.931. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Information Element (IE)

Description

Bearer capability

Indicate a requested bearer service to be provided by the network.

For details, see Bearer capability. Calling party number

Indicates a caller number. For details, see Calling party number.

Called party number

Indicates a callee number. For details, see Called party number.

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.14 "SETUP" in ITU-T Q.931. Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 1 shows the main IEs of the message. Figure 1 SETUP ACKNOWLEDGE message

Associated IEs Information Element (IE) Description Channel identification

Indicates a channel within the interface controlled by the signaling procedures. For details, see Channel identification.

Reference Standards For details, see 3.3.10 "SETUP ACKNOWLEDGE" in ITU-T Q.931.

Parent topic: Description of Associated Messages Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated IEs Bearer capability Call reference Called party number Called party subaddress Calling party number Calling party subaddress Cause Channel identification Date/time Display High layer compatibility Keypad facility Low layer compatibility Message type Network-specific facilities Progress indicator Protocol discriminator Repeat indicator Sending complete Signal Transit network selection Parent topic: PRA Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Bearer capability Description of the IE Reference Standards Description of the IE Information Element (IE)

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. Parent topic: Description of Associated IEs

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Call reference Description of the IE Reference Standards Description of the IE Information Element (IE)

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. The SETUP message is considered as an example here. In 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Called party number Description of the IE Reference Standards Description of the IE Information Element (IE)

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. The SETUP message is considered as an example here. In 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Called party subaddress Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the subaddress of the callee. The maximum length of the IE is 23 octets.

Called party subaddress

Odd even indicator: Indicates whether the subaddress is an odd or even. Type of subaddress: Indicates the type of the subaddress. The SETUP message is considered as an example here. In 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Calling party number Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Identifies the caller of a call.

Calling party number

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. The SETUP message is considered as an example here. In 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Calling party subaddress Description of the IE Reference Standards Description of the IE Information Element (IE)

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.

Calling party subaddress

Odd even indicator: Indicates whether the subaddress is an odd or even. Type of subaddress: Indicates the type of the subaddress. The SETUP message is considered as an example here. In 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.11 "Calling party address" in ITU-T Q.931. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Cause Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the cause for the message.

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Channel identification Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Identifies a channel.

Channel identification

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. The SETUP message is considered as an example here. In 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Date/time Description of the IE Reference Standards Description of the IE Information Element (IE)

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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Display Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Provides information that may be displayed to the user.

Display

Display information: Indicates the information displayed. The SETUP message is considered as an example here. In 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

High layer compatibility Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the high layer compatibility used by the call. This IE is transparently transmitted through two integrated services digital network (ISDN) entities.

High layer compatibility

coding standard: Indicates the coding standard adopted. high layer characteristic identification: Indicates the identification of the high layer characteristic. The SETUP message is considered as an example here. In this example, coding standard is itu-t-standardized coding, which indicates that the protocol type is International Telecommunication Union-Telecommunication 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Keypad facility Description of the IE Reference Standards Description of the IE Information Element (IE)

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. The SETUP message is considered as an example here. In 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Low layer compatibility Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates the bearer capability. It contains bearer related information, for example, transmission information, transmission rate mode, and codec information.

Low layer compatibility Information transfer capability: Indicates the transmission compatibility. Negotiation indicator: Indicates the compatibility negotiation. Transfer mode: Indicates the transmission mode. The SETUP message is considered as an example here. In 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. Parent topic: Description of Associated IEs

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Message type Description of the IE Reference Standards Description of the IE Information Element (IE)

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. The SETUP message is considered as an example here. In 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Network-specific facilities Description of the IE Reference Standards Description of the IE Information Element (IE)

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.

Network-specific facilities Length of network identification: Indicates the length of the network facility information. Network specific facility specification: Indicates the information about the network-specific facilities. The SETUP message is considered as an example here. In 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 Union-Telecommunication Standardization Sector (ITU-T) Q.931. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Progress indicator Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Indicates an event that has occurred during the life of a call. 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Protocol discriminator Description of the IE Reference Standards Description of the IE Information Element (IE)

Protocol discriminator

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. The SETUP message is considered as an example here. In 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Repeat indicator Description of the IE Reference Standards Description of the IE Information Element (IE)

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. The SETUP message is considered as an example here. In 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Sending complete Description of the IE Reference Standards Description of the IE Information Element (IE)

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. The SETUP message is considered as an example here. In 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Signal Description of the IE Reference Standards Description of the IE Information Element (IE)

Description It is used to convey information to a user regarding tones and alerting signals.

Signal

signal value: Indicates the value of the signal. The SETUP message is considered as an example here. In 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 Standardization Sector (ITU-T) Q.931. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Transit network selection Description of the IE Reference Standards Description of the IE Information Element (IE)

Description Identifies one requested transit network. A message can contain multiple such IEs.

Transit network selection

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. The SETUP message is considered as an example here. In 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

SGs Interface Protocol Description of the SGs Interface Protocol Description of the Common Part of Messages 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 Associated IEs Parent topic: Appendix - Protocol Compliance Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the SGs Interface Protocol Scenario Description Protocol Stack Message List Reference Standards Scenario Description 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

The MME sends this message to the MSC 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

The MME sends this message to the MSC server/VLR, notifying the MSC server/VLR of the IMSI detach initiated by the UE.

SGsAP-IMSIDETACH-ACK

MSC server/VLR>MME

The MSC server sends this message in 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

The MME sends this message to the MSC server/VLR to request a location update or IMSI attach flow.

MSC server/VLR>MME

The MSC server sends this message in response to an SGsAP-LOCATION-UPDATEREQUEST message, indicating that a location update or IMSI attach flow succeeds.

SGsAP-LOCATIONUPDATE-REJECT

MSC server/VLR>MME

The MSC server sends this message in 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

The MME sends this message in response to an SGsAP-PAGING-REQUEST message, notifying the MSC server/VLR of a failure in paging the UE.

MME->MSC server/VLR

The MSC server sends this message in 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

The MME sends this message in response to 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of the Common Part of Messages 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.

An SGsAP-PAGING-REQUEST 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.

Parent topic: SGs Interface Protocol

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated Messages in the Alert Flow SGsAP-ALERT-REQUEST SGsAP-ALERT-ACK SGsAP-ALERT-REJECT SGsAP-UE-ACTIVITY-INDICATION Parent topic: SGs Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies a message.

IMSI

Specifies a subscriber's IMSI.

Reference Standards For details, see 8.1 "SGsAP-ALERT-ACK message" in 3GPP TS 29.118 V11.3.0. Parent topic: Description of Associated Messages in the Alert Flow Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies a message.

IMSI

Specifies a subscriber's 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. Parent topic: Description of Associated Messages in the Alert Flow Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies a message.

IMSI

Specifies a subscriber's IMSI.

Reference Standards For details, see 8.20 "SGsAP-UE-ACTIVITY-INDICATION message" in 3GPP TS 29.118 V11.3.0. Parent topic: Description of Associated Messages in the Alert Flow Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated Messages in SMS SGsAP-UPLINK-UNITDATA SGsAP-DOWNLINK-UNITDATA SGsAP-RELEASE-REQUEST Parent topic: SGs Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

SGsAP-UPLINK-UNITDATA 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

Uniquely identifies a message.

IMSI

Specifies a subscriber's 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.

Mobile Station Classmark 2

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies a message.

IMSI

Specifies a subscriber's IMSI.

NAS message container

Specifies SMS message contents.

Reference Standards

For details, see 8.4 "SGsAP-DOWNLINK-UNITDATA message" in 3GPP TS 29.118 V11.3.0. Parent topic: Description of Associated Messages in SMS Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies a message.

IMSI

Specifies a subscriber's 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. Parent topic: Description of Associated Messages in SMS

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 Parent topic: SGs Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies a message.

IMSI

Specifies a subscriber's 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies a message.

IMSI

Specifies a subscriber's IMSI.

Reference Standards For details, see 8.5 "SGsAP-EPS-DETACH-ACK message" in 3GPP TS 29.118 V11.3.0.

Parent topic: Description of Associated Messages in Location Updates Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies a message.

IMSI

Specifies a subscriber's IMSI.

MME name

Specifies the domain name of an MME.

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. Parent topic: Description of Associated Messages in Location Updates Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies a message.

IMSI

Specifies a subscriber's IMSI.

Reference Standards For details, see 8.7 "SGsAP-IMSI-DETACH-ACK message" in 3GPP TS 29.118 V11.3.0.

Parent topic: Description of Associated Messages in Location Updates Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies a message.

IMSI

Specifies a subscriber's IMSI.

Reference Standards For details, see 8.19 "SGsAP-TMSI-REALLOCATION-COMPLETE message" in 3GPP TS 29.118 V11.3.0. Parent topic: Description of Associated Messages in Location Updates

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies a message.

IMSI

Specifies a subscriber's IMSI.

MME name

Specifies the domain name of an MME.

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. This IE is optional.

IMEISV

Specifies the software version of an international 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.11 "SGsAP-LOCATION-UPDATE-REQUEST message" in 3GPP TS 29.118 V11.3.0. Parent topic: Description of Associated Messages in Location Updates Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies a message.

IMSI

Specifies a subscriber's 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. Parent topic: Description of Associated Messages in Location Updates Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies a message.

IMSI

Specifies a subscriber's IMSI.

Reject cause

Specifies a cause value used by the MSC server/VLR to reject a service request sent by the UE.

Location area identifier

Identifies the location area (LA) in which the 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. Parent topic: Description of Associated Messages in Location Updates Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated Messages in the Paging Flow SGsAP-PAGING-REQUEST SGsAP-PAGING-REJECT SGsAP-SERVICE-REQUEST SGsAP-UE-UNREACHABLE Parent topic: SGs Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

SGsAP-PAGING-REQUEST 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

Uniquely identifies a message.

IMSI

Specifies a subscriber's 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. This IE is optional.

Location area identifier

Identifies the location area (LA) in which the 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies a message.

IMSI

Specifies a subscriber's IMSI.

SGs Cause

Specifies a failure cause value.

Reference Standards For details, see 8.13 "SGsAP-PAGING-REJECT message" in 3GPP TS 29.118 V11.3.0. Parent topic: Description of Associated Messages in the Paging Flow Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies a message.

IMSI

Specifies a subscriber's IMSI.

Service indicator

Specifies the CS service type.

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.

Mobile Station Classmark 2

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. Specifies a subscriber's evolved packet

UE EMM Mode

system mobility management (EMM) state. This IE is optional.

Reference Standards For details, see 8.17 "SGsAP-SERVICE-REQUEST message" in 3GPP TS 29.118 V11.3.0. Parent topic: Description of Associated Messages in the Paging Flow Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies a message.

IMSI

Specifies a subscriber's IMSI.

SGs cause

Specifies a failure cause value.

Reference Standards For details, see 8.21 "SGsAP-UE-UNREACHABLE message" in 3GPP TS 29.118 V11.3.0. Parent topic: Description of Associated Messages in the Paging Flow Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated Messages in the Fault Processing Flow SGsAP-STATUS Parent topic: SGs Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies a message.

IMSI

Specifies a subscriber's IMSI. This IE is optional.

SGs cause

Specifies a failure cause value.

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated Messages in the Reset Flow SGsAP-RESET-INDICATION SGsAP-RESET-ACK Parent topic: SGs Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies a message.

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies a message.

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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated Messages in the Service Abort Flow SGsAP-SERVICE-ABORT-REQUEST Parent topic: SGs Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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

Uniquely identifies a message.

IMSI

Specifies a subscriber's 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 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Description of Associated IEs Additional paging indicators Channel needed CLI E-CGI eMLPP priority EPS location update type Erroneous message Global CN-Id IMEISV IMSI IMSI detach from EPS service type IMSI detach from non-EPS service type LCS client identity LCS indicator Location area identifier Message Type MME Name Mobile Station Classmark 2 NAS message container New location area identifier New TMSI, or IMSI Old location area identifier Reject cause Service indicator SGs Cause TAI

TMSI TMSI status UE EMM Mode UE Time Zone VLR name Parent topic: SGs Interface Protocol Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Additional paging indicators Description of the IE Reference Standards Description of the IE 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 An SGsAP-PAGING-REQUEST 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Channel needed Description of the IE Reference Standards Description of the IE 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 SGsAP-PAGING-REQUEST 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

An SGsAP-PAGING-REQUEST 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

CLI Description of the IE Reference Standards Description of the IE 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. Calling party BCD number 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

E-CGI Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

eMLPP priority Description of the IE Reference Standards Description of the IE 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 An SGsAP-PAGING-REQUEST whether the MSC server/VLR message is used as an 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 4 call priority level 3 call priority level 2 call priority level 1 call priority level 0 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.

Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

EPS location update type Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Erroneous message Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Global CN-Id Description of the IE Reference Standards Description of the IE 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). An SGsAP-PAGING-REQUEST The MSC server must include message is used as an 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

IMEISV Description of the IE Reference Standards Description of the IE 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.

Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

IMSI Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

IMSI detach from EPS service type Description of the IE Reference Standards Description of the IE 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.

Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

IMSI detach from non-EPS service type Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

LCS client identity Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

LCS indicator Description of the IE Reference Standards Description of the IE 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.

An SGsAP-PAGING-REQUEST message is used as an 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Location area identifier Description of the IE Reference Standards Description of the IE Information Element (IE)

Description

Example

An SGsAP-LOCATIONUPDATE-ACCEPT message is used as an example.

Location area identifier

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: Values of mcc-dig-1, mcc-dig-2, and mccdig-3 specify the MCC. Values of mnc-dig-3, 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Message Type Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

MME Name Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Mobile Station Classmark 2 Description of the IE Reference Standards Description of the IE 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 Mobile Station Classmark 2 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

NAS message container Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

New location area identifier Description of the IE Reference Standards Description of the IE 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: New location area identifier Values of mcc-dig-1, consists of the mobile country mcc-dig-2, and mcccode (MCC), mobile network dig-3 specify the MCC. code (MNC), and location area Values of mnc-dig-3, code (LAC). 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

New TMSI, or IMSI Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Old location area identifier Description of the IE Reference Standards Description of the IE 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 Values of mcc-dig-1, TRACKING AREA UPDATE mcc-dig-2, and mccREQUEST message, the MME dig-3 specify the MCC. must include the Old location Values of mnc-dig-3, 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 For details, see 9.4.11 "Location area identifier" in 3GPP TS 29.118 V11.3.0. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Reject cause Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Service indicator Description of the IE Reference Standards Description of the IE 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.

An SGsAP-PAGING-REQUEST message is used as an 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

SGs Cause Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

TAI Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

TMSI Description of the IE Reference Standards Description of the IE Information Element (IE)

TMSI

Description

Example

Specifies the TMSI that is used An SGsAP-PAGING-REQUEST message is used as an 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

TMSI status Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

UE EMM Mode Description of the IE Reference Standards Description of the IE 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 An SGsAP-PAGING-REQUEST 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

UE Time Zone Description of the IE Reference Standards Description of the IE 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, SGsAP-UPLINK-UNITDATA 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

VLR name Description of the IE Reference Standards Description of the IE 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. Parent topic: Description of Associated IEs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.