Signalling interworking between ISDN supplementary services and MAP protocols

Specification: 29013

🟢Approvedv900
Rel-9
Relevance:7/10

Summary

This specification describes the interworking between the ISDN Application Service Element (ASE) protocol for supplementary services and the Mobile Application Part (MAP) protocol on MAP D-interface protocol for handling of supplementary services within the digital cellular telecommunications system (Phase 2+).

Specification Intelligence

This is a Technical Document in the Unknown Series series, focusing on Technical Document. The document is currently in approved by tsg and under change control and is under formal change control.

Classification

Type: Technical Document
Subject: Unknown Series
Series: 29.xxx
Target: Technical Implementers

Specifics

Status: Change Control

Version

900.0.0
Release 900
0 technical • 0 editorial

Full Document v900

3GPP TS 29.013 V9.0.0 (2009-12)
Technical Specification
3rd Generation Partnership Project;
Technical Specification Group Core Network and Terminals;
Signalling interworking between ISDN supplementary
services;
Application Service Element (ASE) and
Mobile Application Part (MAP) protocols
(Release 9)

 EMBED Word.Picture.6  	 EMBED Word.Picture.8  

The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP..
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification.
Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.


Keywords
3GPP, CN

3GPP
Postal address

3GPP support office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Internet
http://www.3gpp.org

Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© 2009, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TTA, TTC).
All rights reserved.

UMTS™ is a Trade Mark of ETSI registered for the benefit of its members
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
LTE™ is a Trade Mark of ETSI currently being registered for the benefit of its Members and of the 3GPP Organizational Partners
GSM® and the GSM logo are registered and owned by the GSM Association
Contents
 TOC \o "1-9" Foreword	 PAGEREF _Toc248819448 \h 4
1	Scope	 PAGEREF _Toc248819449 \h 4
2	References	 PAGEREF _Toc248819450 \h 5
3	Definitions and abbreviations	 PAGEREF _Toc248819451 \h 5
3.1	Definitions	 PAGEREF _Toc248819452 \h 5
3.2	Abbreviations	 PAGEREF _Toc248819453 \h 5
4	General	 PAGEREF _Toc248819454 \h 6
4.1	GSM CCBS Architecture Overview	 PAGEREF _Toc248819455 \h 6
4.2	GSM CCBS - ISDN CCBS ASE Interworking Overview	 PAGEREF _Toc248819456 \h 7
4.3	Overview on the use of CCBS procedures and parameters values	 PAGEREF _Toc248819457 \h 8
4.4	Mapping between MAP and SSAP application layer messages	 PAGEREF _Toc248819458 \h 8
4.4.1	MAP D-interface to SSAP interface mapping in HLR A	 PAGEREF _Toc248819459 \h 8
4.4.2	SSAP interface to MAP D-interface interface mapping in HLR A	 PAGEREF _Toc248819460 \h 8
5	Mapping between MAP message parameters and SSAP message parameters	 PAGEREF _Toc248819461 \h 9
5.1	CCBS Request Invocation	 PAGEREF _Toc248819462 \h 9
5.1.1	Encoding of called party subaddress information	 PAGEREF _Toc248819463 \h 11
5.2	CCBS Request Result	 PAGEREF _Toc248819464 \h 11
5.3	CCBS Request Error	 PAGEREF _Toc248819465 \h 12
6	Dialogue handling on the SSAP interface	 PAGEREF _Toc248819466 \h 13
6.1	Dialogue Beginning	 PAGEREF _Toc248819467 \h 13
6.1.1	CCBS Request Invocation	 PAGEREF _Toc248819468 \h 13
6.2	Dialogue Continuation	 PAGEREF _Toc248819469 \h 13
6.2.1	CCBS Request Result	 PAGEREF _Toc248819470 \h 13
6.2.2	CCBS Remote User Free Invocation	 PAGEREF _Toc248819471 \h 14
6.2.3	CCBS Suspend Invocation	 PAGEREF _Toc248819472 \h 14
6.2.4	CCBS Resume Invocation	 PAGEREF _Toc248819473 \h 15
6.3	Dialogue End	 PAGEREF _Toc248819474 \h 15
6.3.1	Normal dialogue end	 PAGEREF _Toc248819475 \h 15
6.3.2	CCBS Cancel Invocation (from A-side)	 PAGEREF _Toc248819476 \h 16
6.3.3	CCBS Cancel Invocation (from B-side)	 PAGEREF _Toc248819477 \h 16
6.3.4	CCBS Request Error	 PAGEREF _Toc248819478 \h 17
7	Addressing of SCCP layer messages on the SSAP interface	 PAGEREF _Toc248819479 \h 17
7.1	Use of SCCP	 PAGEREF _Toc248819480 \h 17
7.2	Addressing of messages at the originating PLMN	 PAGEREF _Toc248819481 \h 17
7.2.1	TC-BEGIN message from the originating network HLR	 PAGEREF _Toc248819482 \h 17
7.2.2	TC-CONTINUE, TC-END messages from the originating network HLR	 PAGEREF _Toc248819483 \h 18
7.3	Addressing of messages at the destination PLMN	 PAGEREF _Toc248819484 \h 18
7.3.1	TC-CONTINUE, TC-END messages from the destination network HLR	 PAGEREF _Toc248819485 \h 18
7.4	Number formats of the SCCP address parameters	 PAGEREF _Toc248819486 \h 19
7.4.1	Originating PLMN	 PAGEREF _Toc248819487 \h 19
7.4.2	Destination PLMN	 PAGEREF _Toc248819488 \h 19
Annex A (informative):	Change history	 PAGEREF _Toc248819489 \h 20

Foreword
This Technical Specification has been produced by the 3GPP.
This TS provides a detailed specification for interworking between the ISDN Supplementary Services ASE protocol and the Mobile Application Part (MAP) D interface protocol for handling of supplementary services within the 3GPP system.
The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of this TS, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows:
Version 3.y.z
where:
x	the first digit:
1	presented to TSG for information;
2	presented to TSG for approval;
3	Indicates TSG approved document under change control.
y	the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc.
z	the third digit is incremented when editorial only changes have been incorporated in the specification;
1	Scope
The scope of the present document is to provide a specification for interworking between the ISDN Application Service Element (ASE) protocol for supplementary services and the Mobile Application Part (MAP) protocol on MAP D-interface protocol for handling of supplementary services within the digital cellular telecommunications system (Phase 2+). This version of the specification includes the interworking for the Call Completion to Busy Subscriber (CCBS) service between the ISDN CCBS-ASE and MAP. 
The MAP protocol for CCBS service is specified in GSM 09.02. The ISDN CCBS-ASE protocol is specified in ETS 300 356‑18. The ISDN CCBS-ASE protocol is also commonly referred to as the SSAP protocol in GSM 03.93. This specification clarifies the interworking within the HLR between these protocols for the Call Completion to Busy Subscriber (CCBS) service.
Clause 4 describes the mapping between MAP application layer messages and SSAP application layer messages.
Clause 5 describes the mapping between MAP message parameters and SSAP message parameters.
Clause 6 describes the dialogue handling on the SSAP interface.
Clause 7 describes the SCCP layer addressing for messages on the SSAP interface.
2	References
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
References are either specific (identified by date of publication, edition number, version number, etc.) or non‑specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies.
[1]	GSM 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations and acronyms".
[2]	GSM 02.93: "Digital cellular telecommunications system (Phase 2+); Completion of calls to busy subscriber (CCBS) supplementary services - Stage 1".
[3]	GSM 03.93: "Digital cellular telecommunications system (Phase 2+); Technical Realisation of Completion of Calls to Busy Subscriber (CCBS); Stage 2”.
[4]	GSM 04.80: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface layer 3 supplementary services specification Formats and coding".
[5]	GSM 04.93: "Digital cellular telecommunications system (Phase 2+); Technical Realisation of Completion of Calls to Busy Subscriber (CCBS); Stage 3”.
[6]	GSM 09.02 "Digital cellular telecommunications system (Phase 2+); Mobile Application Part (MAP) specification".
[7]	GSM 09.07 : "Digital cellular telecommunications system (Phase 2+); General requirements on interworking between the Public Land Mobile Network (PLMN) and the Integrated Services Digital Network (ISDN) or Public Switched Telephone Network (PSTN)".
[8]	ETS 300 102-1 (1990): "Integrated Services Digital Network (ISDN); User-network interface layer 3 specifications for basic call control".
[9]	ETS 300 356-18: ”ISDN User Part (ISUP) version 2 for the international interface: Part 18: Completion of Calls to Busy Subscriber (CCBS) supplementary service".
[10]	ETS 300 358: ”Integrated Services Digital Network (ISDN); Completion of Calls to Busy Subscriber (CCBS) supplementary service; Functional capabilities and information flows".
3	Definitions and abbreviations
3.1	Definitions
For the purposes of this specification, the following definitions apply:
SSAP: Supplementary Service Application Part. SSAP is the protocol used for CCBS procedures on the interface between the originating and destination network. Communication across this interface is performed using SCCP Connectionless Signalling (Refer to ETS 300 358). The terms CCBS-ASE defined in ETS 300 356-18 for the ISDN CCBS service and SSAP defined in GSM 03.93 are the same and are used interchangeably in this specification. The SSAP interface is between the originating network entities (HLR A, OLE) and the destination network entities (HLR B, DLE).
3.2	Abbreviations
Abbreviations used in this specification are listed in GSM 01.04.
For the purposes of this specification, the following abbreviations apply:
ASE	Application Service Element
CCBS	Call Completion to Busy Subscriber
DLE	Destination Local Exchange
ISDN	Integrated Services Digital Network
MAP	Mobile Application Part
OLE	Originating Local Exchange
SCCP	Signalling Connection Control Part
SSAP	Supplementary Service Application Part
TC	Transaction Capabilities
4	General
4.1	GSM CCBS Architecture Overview
The stage 1 of the CCBS service is defined in GSM 02.93. 
The network architecture to support the CCBS service in GSM networks is defined in GSM 03.93. For convenience, the architecture is shown again in this specification. Figure 4.1.1 is an architectural overview of the CCBS service when interworking between the originating and the destination networks involved. The originating network may be a mobile network or a fixed network and the destination network may also be a mobile network or a fixed network.
The call related signalling (see ETS 300 356-18) for CCBS is performed on ISUP links on the following interfaces:
VMSC A - GMSC B;
VMSC A - DLE;
OLE - GMSC B;
whereas the specific CCBS procedures (see ETS 300 356-18) are performed via the SSAP protocol, which is signalled on the following interfaces:
HLR A - HLR B;
HLR A - DLE;
OLE - HLR B.
This specification only describes the MAP - SSAP protocol interworking.
EMBED Designer.Drawing.6
Figure 4.1: Architectural overview showing common point of interworking
4.2	GSM CCBS - ISDN CCBS ASE Interworking Overview 
The non-call related signalling procedures for CCBS between the originating network and the destination network are defined in ETS 300 356-18 as the ISDN CCBS-ASE. The GSM network also uses these signalling procedures for CCBS without any changes. The ISDN CCBS ASE protocol is supported in GSM networks in the HLR A (originating network) and HLR B (destination network). Therefore no protocol interworking for ISDN CCBS-ASE is needed for the CCBS service between GSM networks and ISDN networks. 
In GSM networks, the CCBS functionality is distributed across several network entities (see GSM 03.93) including the HLR, VLR, MSC and the MS. The HLR shall provide any necessary signalling interworking between the MAP protocol for call completion services on the MAP D-interface (between the VLR and the HLR) and ISDN CCBS-ASE protocol between the originating and destination networks.
The MAP protocol for CCBS service is specified in GSM 09.02. The ISDN CCBS-ASE protocol is specified in ETS 300 356‑18. This specification clarifies the interworking within the HLR between these protocols.
4.3	Overview on the use of CCBS procedures and parameters values
A GSM subscriber can roam while there is an active CCBS request. The called party address (MSISDN) information is used to initiate a dialogue with the destination network on the SSAP interface. The dialogue on the SSAP interface is opened and maintained while there is an active CCBS request (see ETS 300 356-18). However, the dialogues on the MAP D interface can be closed and reopened as necessary (see GSM 09.02 and GSM 03.93) and use the IMSI information for addressing.
4.4	Mapping between MAP and SSAP application layer messages 
The mapping of MAP messages on the D interface and SSAP messages between the originating and destination networks is described. The precise coding of these messages is given in GSM 09.02 and ETS 300 356-18.
4.4.1	MAP D-interface to SSAP interface mapping in HLR A
Table 4.1: Mapping of GSM 09.02 (MAP) operations to ETS 300 356-18 (SSAP) operations
MAP OPERATIONS
SSAP OPERATIONS
RegisterCCEntry
CcbsRequest
EraseCCEntry/ A GSM 03.93 Event (note 1)
CcbsCancel
RemoteUserFree Result/
CcbsSuspend
RemoteUserFree Error/ 

A GSM 03.93 Event (note 2)

StatusReport/
CcbsResume
A GSM 03.93 Event (note 3)

NOTE 1 	This event may be local to HLR A. See GSM 03.93 for a dynamic description of possible events in HLR A leading to a CCBS request being cancelled. The SSAP CcbsCancel operation can include a cause code parameter; this shall be set to the appropriate value corresponding to the actual dynamic event by HLR A (e.g. cCBS-T3-Timeout, cCBS-T4-Timeout).
NOTE 2 	This event may be local to HLR A. See GSM 03.93 for a dynamic description of possible events in HLR A leading to a CCBS request being suspended.
NOTE 3 	This event may be local to HLR A. See GSM 03.93 for a dynamic description of possible events in HLR A leading to a CCBS request being resumed.

4.4.2	SSAP interface to MAP D-interface interface mapping in HLR A
SSAP OPERATIONS
MAP OPERATIONS
CcbsRequest Result
RegisterCCEntry Result
CcbsRequest Error
RegisterCCEntry Error
RemoteUserFree
RemoteUserFree
CcbsCancel
SetReportingState/A GSM 03.93 Event (note 1)
NOTE 1	This event may be local to HLR A. See GSM 03.93 for a dynamic description of possible events in HLR A resulting from a CCBS request being cancelled. The SSAP CcbsCancel operation can include a cause code parameter(e.g. cCBS-T7-Timeout, cCBS-T9-Timeout).

5	Mapping between MAP message parameters and SSAP message parameters
The mapping between MAP message parameters and SSAP message parameters is described. The precise coding of these messages is given in GSM 09.02 and ETS 300 356-18.
The following messages on the SSAP interface do not contain any parameters:
-	RemoteUserFree;
-	Suspend;
-	Resume.
5.1	CCBS Request Invocation
 VLRA                          HLRA                 DESTINATION 
                                                   NETWORK B
+-+                          +-+                        +-+
| |                          | |                        | |
| |                          | |                        | |
| |   RegisterCCEntry        | |                        | |
| |------------------------->| |                        | |
| |   TC-BEGIN               | |                        | |
| |                          | |                        | |
| |                          | |  CcbsRequest           | |
| |                          | |----------------------->| |
| |                          | |  TC-BEGIN              | |
| |                          | |                        | |
| |                          | |                        | |

Figure 5.1: Signalling flow for CCBS Request Invocation
Table 5.1: Mapping of CCBS Request Invocation parameters
RegisterCCEntry PARAMETERS
CcbsRequest PARAMETERS
ss-Code
not present
ccbs-Feature 

- b-subscriberSubaddress			(note 1)
accessTransportParameter	(note 2)
translatedB-Number
calledPartynumber			(note 3)
serviceIndicator
not present
callInfo
not present
networkSignalInfo 

 - ISDN BC Tag, Length, Content	(note 4)
userServiceInf
networkSignalInfo 

 - HLC Tag, Length, Content		(note 5)
accessTransportParameter	(note 2)
networkSignalInfo 

 - LLC Tag, Length, Content		(note 6)
accessTransportParameter	(note 2)
 not present
retainSupported				(note 7)
 not present
callingPartyNumber			(note 8)
 not present
userServiceInfPrime			(note 9)
NOTE 1	CCBS-Feature contains the b-subscriberSubaddress parameter which is the called party subaddress. The GSM HLR A shall map the called party subaddress into the accessTransportParameter if received from the VLR. The entire called party subaddress information (i.e. called party subaddress IEI, LENGTH and CONTENT ) is mapped into the accessTransportParameter. See subclause 5.1.1. for details of the required encoding.
NOTE 2 	The CcbsRequest contains only one accessTransportParameter. This parameter contains information on the ISDN HLC, LLC and Subaddress.
NOTE 3 	The calledParty Number shall be in the international E.164 format.
NOTE 4 	The networkSignalInfo contains three information elements ISDN BC, HLC, LLC. The structure of this is defined in GSM 09.02 and the content in GSM 09.07. The ISDN BC information element CONTENT (i.e. without ISDN BC TAG, LENGTH ) is mapped into the userServiceInf parameter.
NOTE 5 	The networkSignalInfo contains three information elements ISDN BC, HLC, LLC. The structure of this is defined in GSM 09.02 and the content in GSM 09.07. The entire ISDN HLC information element (i.e. ISDN HLC TAG, LENGTH and CONTENT ) is mapped into the accessTransportParameter.
NOTE 6 	The networkSignalInfo contains three information elements ISDN BC, HLC, LLC. The structure of this is defined in GSM 09.02 and the content in GSM 09.07. The entire ISDN LLC information element (i.e. ISDN LLC TAG, LENGTH and CONTENT ) is mapped into the accessTransportParameter.
NOTE 7 	This information is local to the HLR A. This information element shall be coded by HLR A to reflect whether it supports CCBS Retention capability.
NOTE 8 	This information is local to HLR A. The HLR A provides callingPartyNumber if CLIR was not invoked (See the serviceIndicator parameter in GSM 09.02 and GSM 03.93). If sent, the A subscriber’s identity shall be the Basic MSISDN (i.e. the main MSISDN) and shall be in the international E.164 format.
NOTE 9 	The GSM HLR A shall not send the userServiceInfPrime 

5.1.1	Encoding of called party subaddress information
The CCBS-Feature parameter is received from the VLR and it may include the b-subscriberSubaddress parameter as defined in GSM 09.02. The Called Party Subaddress information requires additional processing in HLR to ensure correct encoding of this information on the SSAP interface. The HLR shall add two octets to the ISDN-SubaddressString received from the VLR as indicated in figure 5.2. 


NOTE 1 	Called Party Subaddress Information Element Identifier (IEI) is defined by ETS 300 102-1. Its value is "01110001". This information is not sent from the VLR and has to be derived locally in the HLR for interworking purposes.
NOTE 2 	This information has to be derived locally in the HLR for interworking purposes. 
NOTE 3 	This information is sent by the VLR. The ISDN-SubaddressString contents is defined in GSM 09.02.
Figure 5.2: Encoding of Called Party Subaddress information
5.2	CCBS Request Result
 VLRA                          HLRA                 DESTINATION 
                                                   NETWORK B
+-+                          +-+                        +-+
| |                          | |                        | |
| |                          | |                        | |
| |                          | |                        | |
| |                          | |  CcbsRequest-Result    | |
| |                          | |<-----------------------| |
| |                          | |  TC-CONTINUE           | |
| |                          | |                        | |
| |  RegisterCCEntry-Result  | |                        | |
| |<-------------------------| |                        | |
| |  TC-END                  | |                        | |
| |                          | |                        | |
| |                          | |                        | |

Figure 5.3: Signalling flow for CCBS Request Result
Table 5.2: Mapping of CCBS Request Result parameters
CcbsRequest_Result PARAMETERS
RegisterCCEntry_Result PARAMETERS
 retainSupported	(note 1)
not present
 not present
ccbs-Feature	(note 2)
NOTE 1 	This information is associated with each CCBS Request and indicates whether CCBS Retention is supported by the destination B network (see GSM 03.93). 
NOTE 2	This information is local to the HLR A. Some of information contained in ccbs-Feature (e.g. ccbs-index) is allocated by the HLR A. The ccbs-Feature information is sent to the MS (see GSM 03.93, GSM 04.93).

5.3	CCBS Request Error
 VLRA                          HLRA                 DESTINATION 
                                                   NETWORK B
+-+                          +-+                        +-+
| |                          | |                        | |
| |                          | |                        | |
| |                          | |                        | |
| |                          | |  CcbsRequest-Error     | |
| |                          | |<-----------------------| |
| |                          | |  TC-END                | |
| |                          | |                        | |
| |  RegisterCCEntry-Error   | |                        | |
| |<-------------------------| |                        | |
| |  TC-END                  | |                        | |
| |                          | |                        | |
| |                          | |                        | |
| |                          | |                        | |

Figure 5.4: Signalling flow for CCBS Request Error

Table 5.3: Mapping of CCBS Request Error parameters
CcbsRequest_Error PARAMETERS
RegisterCCEntry_Error PARAMETERS
 shortTermDenial/ longTermDenial (note 1)
shortTermDenial/ longTermDenial (note 2)
NOTE 1	For coding of these User Errors see ETS 300 356-18.
NOTE 2	For coding of these User Errors see GSM 09.02. This information is sent to the MS (see GSM 04.93, GSM 04.80).

6	Dialogue handling on the SSAP interface
The dialogue handling on the SSAP interface and the mapping between the corresponding TC transaction sublayer messages on the MAP D and SSAP interfaces is described. The diagrams show the general principle of dialogue handling. Specific message flows depend on the dynamics of the application in the network elements, see GSM 03.93 and GSM 09.02. 
6.1	Dialogue Beginning 
6.1.1	CCBS Request Invocation
 VLRA                          HLRA                 DESTINATION 
                                                   NETWORK B
+-+                          +-+                        +-+
| |                          | |                        | |
| |                          | |                        | |
| |   RegisterCCEntry        | |                        | |
| |------------------------->| |                        | |
| |   TC-BEGIN               | |                        | |
| |                          | |                        | |
| |                          | |  CcbsRequest           | |
| |                          | |----------------------->| |
| |                          | |  TC-BEGIN              | |
| |                          | |  SCCP                  | |
| |                          | |                        | |
| |                          | |                        | |
| |                          | |                        | |

Figure 6.1: Signalling flow for CCBS REQUEST INVOCATION
The CCBS Request invocation is carried by TC-BEGIN. The SCCP addressing parameters on the SSAP interface shall be as shown in table 7.1.
6.2	Dialogue Continuation
6.2.1	CCBS Request Result
 VLRA                          HLRA                 DESTINATION 
                                                   NETWORK B
+-+                          +-+                        +-+
| |                          | |                        | |
| |                          | |                        | |
| |                          | |                        | |
| |                          | |  CcbsRequest-Result    | |
| |                          | |<-----------------------| |
| |                          | |  TC-CONTINUE           | |
| |                          | |  SCCP                  | |
| |                          | |                        | |
| |                          | |                        | |
| |  RegisterCCEntry-Result  | |                        | |
| |<-------------------------| |                        | |
| |  TC-END                  | |                        | |
| |                          | |                        | |
| |                          | |                        | |
| |                          | |                        | |

Figure 6.2: Signalling flow for CCBS Request Result
The CCBS Request Result is carried by TC-CONTINUE. The SCCP addressing parameters on the SSAP interface shall be as shown in table 7.3.
6.2.2	CCBS Remote User Free Invocation
 VLRA                          HLRA                 DESTINATION 
                                                   NETWORK B
+-+                          +-+                        +-+
| |                          | |                        | |
| |                          | |                        | |
| |                          | |                        | |
| |                          | |  RemoteUserFree        | |
| |                          | |<--------------------_--| |
| |                          | |  TC-CONTINUE           | |
| |                          | |  SCCP                  | |
| |                          | |                        | |
| |                          | |                        | |
| |  RemoteUserFree          | |                        | |
| |<-------------------------| |                        | |
| |  TC-BEGIN                | |                        | |
| |                          | |                        | |
| |                          | |                        | |
| |                          | |                        | |

Figure 6.3: Signalling flow for Remote User Free Invocation 
The CCBS Remote User Free Invocation is carried by TC-CONTINUE. The SCCP addressing parameters on the SSAP interface shall be as shown in table 7.3.
6.2.3	CCBS Suspend Invocation
 VLRA                          HLRA                 DESTINATION 
                                                   NETWORK B
+-+                          +-+                        +-+
| |                          | |                        | |
| |  RemoteUserFree-Result   | |                        | |
| |------------------------->| |                        | |
| |  TC-END                  | |                        | |
| |                          | |                        | |
| |                          | |                        | |
| |                          | |  CcbsSuspend (note 1)  | |
| |                          | |----------------------->| |
| |                          | |  TC-CONTINUE           | |
| |                          | |  SCCP                  | |
| |                          | |                        | |
| |                          | |                        | |
| |                          | |                        | |

NOTE 1 	For conditions leading to a request being suspended, see GSM 03.93
Figure 6.4: Signalling flow for CCBS Suspend Invocation (RemoteUserFree_Result)

 VLRA                          HLRA                 DESTINATION 
                                                   NETWORK B
+-+                          +-+                        +-+
| |                          | |                        | |
| |  RemoteUserFree-Error    | |                        | |
| |------------------------->| |                        | |
| |  TC-END                  | |                        | |
| |                          | |                        | |
| |                          | |                        | |
| |                          | |  CcbsSuspend (note 1)  | |
| |                          | |----------------------->| |
| |                          | |  TC-CONTINUE           | |
| |                          | |  SCCP                  | |
| |                          | |                        | |
| |                          | |                        | |
| |                          | |                        | |

NOTE 1 	For conditions leading to a request being suspended, see GSM 03.93
Figure 6.5: Signalling flow for CCBS Suspend Invocation (RemoteUserFree_Error)
The CCBS Suspend Invocation is carried by TC-CONTINUE. The SCCP addressing parameters on the SSAP interface shall be as shown in table 7.2 
6.2.4	CCBS Resume Invocation
 VLRA                          HLRA                 DESTINATION 
                                                   NETWORK B
+-+                          +-+                        +-+
| |                          | |                        | |
| |  StatusReport            | |                        | |
| |------------------------->| |                        | |
| |  TC-BEGIN                | |                        | |
| |                          | |                        | |
| |                          | |                        | |
| |                          | |  CcbsResume  (note 1)  | |
| |                          | |----------------------->| |
| |                          | |  TC-CONTINUE           | |
| |                          | |  SCCP                  | |
| |                          | |                        | |
| |                          | |                        | |
| |                          | |                        | |

NOTE 1 	For conditions leading to a request being resumed, see GSM 03.93
Figure 6.6: Signalling flow for CCBS Resume Invocation
The CCBS Resume Invocation is carried by TC-CONTINUE. The SCCP addressing parameters on the SSAP interface shall be as shown in table 7.2.
6.3	Dialogue End
6.3.1	Normal dialogue end
 VLRA                          HLRA                 DESTINATION 
                                                   NETWORK B
+-+                          +-+                        +-+
| |                          | |                        | |
| |                          | |                        | |
| |                          | |                        | |
| |                          | | No component primitive | |
| |                          | |<-----------------------| |
| |                          | |  TC-END                | |
| |                          | |  SCCP                  | |
| |                          | |                        | |
| |                          | |                        | |
| |SetReportingState (note 1)| |                        | |
| |<-------------------------| |                        | |
| |  TC-BEGIN                | |                        | |
| |                          | |                        | |
| |                          | |                        | |
| |                          | |                        | |

NOTE 1 	If the monitoring function is active in VLR A and all outstanding CCBS Requests have been deactivated, the HLR A sends SetReportingState to deactivate the monitoring function (see GSM 03.93).
Figure 6.7: Signalling flow for normal dialogue end 
The normal ending of CCBS dialogue from the B-side is carried by TC-END. The SCCP addressing parameters on the SSAP interface shall be as shown in table 7.3.
6.3.2	CCBS Cancel Invocation (from A-side)
 VLRA                          HLRA                 DESTINATION 
                                                   NETWORK B
+-+                          +-+                        +-+
| |                          | |                        | |
| |                          | |                        | |
| |   EraseCCEntry (note 1)  | |                        | |
| |------------------------->| |                        | |
| |   TC-BEGIN               | |                        | |
| |                          | |                        | |
| |                          | |  CcbsCancel            | |
| |                          | |----------------------->| |
| |                          | |  TC-END   (note 1)     | |
| |                          | |  SCCP                  | |
| |                          | |                        | |
| |                          | |                        | |
| |                          | |                        | |

NOTE 1 	Where all outstanding CCBS Requests have been deactivated, CCBS Cancel is sent to each corresponding Destination Network B with the appropriate Destination Network B E.164 Called Party Address (see GSM 03.93, GSM 04.93).
Figure 6.8: Signalling flow for CCBS Cancel Invocation (from A-side)
The CCBS Cancel Invocation from the A-side is carried by TC-END. The SCCP addressing parameters on the SSAP interface shall be as shown in table 7.2.
6.3.3	CCBS Cancel Invocation (from B-side)
 VLRA                          HLRA                 DESTINATION 
                                                   NETWORK B
+-+                          +-+                        +-+
| |                          | |                        | |
| |                          | |                        | |
| |                          | |                        | |
| |                          | |  CcbsCancel            | |
| |                          | |<-----------------------| |
| |                          | |  TC-END                | |
| |                          | |  SCCP                  | |
| |                          | |                        | |
| |                          | |                        | |
| |SetReportingState (note 1)| |                        | |
| |<-------------------------| |                        | |
| |  TC-BEGIN                | |                        | |
| |                          | |                        | |
| |                          | |                        | |
| |                          | |                        | |

NOTE 1:	If the monitoring function is active in VLR A and all outstanding CCBS Requests have been deactivated, the HLR A sends SetReportingState to deactivate the monitoring function (see GSM 03.93).
Figure 6.9: Signalling flow for CCBS Cancel Invocation (from B-side)
The CCBS Cancel Invocation from the B-side is carried by TC-END. The SCCP addressing parameters on the SSAP interface shall be as shown in table 7.3.
6.3.4	CCBS Request Error
 VLRA                          HLRA                 DESTINATION 
                                                   NETWORK B
+-+                          +-+                        +-+
| |                          | |                        | |
| |                          | |                        | |
| |                          | |                        | |
| |                          | |  CcbsRequest-Error     | |
| |                          | |<-----------------------| |
| |                          | |  TC-END                | |
| |                          | |  SCCP                  | |
| |                          | |                        | |
| |                          | |                        | |
| |  RegisterCCEntry-Error   | |                        | |
| |<-------------------------| |                        | |
| |  TC-END                  | |                        | |
| |                          | |                        | |
| |                          | |                        | |
| |                          | |                        | |

Figure 6.10: Signalling flow for CCBS Request Error
The CCBS Request Error is carried by TC-END. The SCCP addressing parameters on the SSAP interface shall be as shown in table 7.3.
7	Addressing of SCCP layer messages on the SSAP interface
The SCCP layer addressing for messages on the SSAP interface is described. 
7.1	Use of SCCP 
Clarifications and restrictions on the use and coding of the main SCCP parameters impacted by CCBS on the SSAP interface are indicated. See ETS 300 356-18 and the associated references for the full specification on the use of SCCP on the SSAP interface. The SCCP routeing on the SSAP interface shall be based on the Global Title (GT) translation mechanism as for routeing on the international interface. GT addressing shall be used for inter and intra PLMN signalling. This allows any impact of other network features e.g. Mobile Number Portability to be minimised. 
7.2	Addressing of messages at the originating PLMN 
7.2.1	TC-BEGIN message from the originating network HLR 
The relevant SCCP parameters in the first message from the HLR A transporting TC-BEGIN are shown in table 7.1. All other SCCP parameters shall be as indicated in ETS 300 356-18.
Table 7.1: SCCP parameters used by HLR A for TC-BEGIN
SCCP PARAMETERS for the message
transporting TC-BEGIN
PARAMETER VALUE
CdPA-Called Party Address
E.164 number of the Called Party. This may be in either international or national E.164 format, see subclause 7.4.1. It is derived from the translatedB-Number parameter which is available from the CCBS application in HLRA, see RegisterCCEntry in GSM 09.02. 
CgPA-Calling Party Address
E.164 number of HLR A. This may be in either international or national E.164 format, see subclause 7.4.1.
SSN- Subsystem Number
0000 1011
(See ETS 300 356-18)
TT- Translation Type
0001 0001
(See ETS 300 356-18)
Other SCCP Parameters
See ETS 300 356-18

7.2.2	TC-CONTINUE, TC-END messages from the originating network HLR 
The relevant SCCP parameters in the subsequent messages from the HLR A transporting TC-CONTINUE and TC-END are shown in table 7.2. All other SCCP parameters shall be as indicated in ETS 300 356-18.
Table 7.2: SCCP parameters used by HLR A for TC-CONTINUE, TC-END
SCCP PARAMETERS for the message
transporting TC-CONTINUE, TC-END
PARAMETER VALUE
CdPA-Called Party Address
The Called Party Address is the E.164 address of the calling entity in the destination network that was received in the first response message from the destination network (note 1).
CgPA-Calling Party Address
E.164 number of HLR A. This may be in either international or national E.164 format as used in the message transporting TC-BEGIN, see subclause 7.4.1.
SSN- Subsystem Number
0000 1011
(See ETS 300 356-18)
TT- Translation Type
0001 0001 
(See ETS 300 356-18)
Other SCCP Parameters
See ETS 300 356-18
NOTE 1 	If the destination network is a GSM PLMN, this is E.164 number of HLR B.

7.3	Addressing of messages at the destination PLMN
7.3.1	TC-CONTINUE, TC-END messages from the destination network HLR 
The relevant SCCP parameters in the first and subsequent messages from the HLR B transporting TC-CONTINUE and TC-END are shown in table 7.3. All other SCCP parameters shall be as indicated in ETS 300 356-18.
Table 7.3: SCCP parameters for TC-CONTINUE, TC-END used by HLR B 
SCCP PARAMETERS for the message
transporting TC-CONTINUE, TC-END
PARAMETER VALUE
CdPA-Called Party Address
The Called Party Address is the E.164 address of the calling entity in the originating network that was received in the first message transporting TC-BEGIN from the originating network (note 1).
CgPA-Calling Party Address
E.164 number of HLR B. This may be in either international or national E.164 format, see subclause 7.4.2 (note 2) 
SSN- Subsystem Number
0000 1011
(See ETS 300 356-18)
TT- Translation Type
0001 0001 
(See ETS 300 356-18)
Other SCCP Parameters
See ETS 300 356-18
NOTE 1 	If the originating network is a GSM PLMN, this is E.164 number of HLR A.
NOTE 2 	The E.164 number of HLRB is used as this allows any impact of other network features to be minimised.

7.4	Number formats of the SCCP address parameters
The Called and Calling Party Address information in SCCP should be in international E.164 format. Optionally national format E.164 addresses may be used in SCCP for routeing of national traffic. For this, the HLR has to modify the addresses which are in international E.164 format to a national E.164 format. If a national format E.164 option is used, all involved network nodes in a given country (i.e. the originating network, any transit networks and the destination network) need support that option. As negotiation is not possible, the option selected by the originating network shall determine the addressing used for all messages which are a part of a single dialogue. 
7.4.1	Originating PLMN
The Called and Calling Party Address information in SCCP should be in international E.164 format.
The originating network HLR A may use the SCCP Called Party Address in national E.164 format if the called destination (as indicated by the translatedB-number) is in the same country as HLR A.
The originating network HLR A may use the SCCP Calling Party Address in national E.164 format if the called destination (as indicated by the translatedB-number) is in the same country as HLR A.
The originating network HLR A shall ensure that the SCCP Called and Calling Party Addresses are either both in international format or national format.
7.4.2	Destination PLMN
The Called and Calling Party Address information in SCCP should be in international E.164 format.
The destination network HLR B may use the SCCP Called Party Address in national E.164 format if the originating network is in the same country as HLR B.
The destination network HLR B may use the SCCP Calling Party Address in national E.164 format if the originating network is in the same country as HLR B.
The destination network HLR B shall ensure that the SCCP Called and Calling Party Addresses are either both in international format or national format.
Annex A (informative):
Change history
Change history
TSG SA#SpecVersionCRNew VersionSubject/CommentCN#04
29.013


R99
3.0.0
Approved at CN#04
CN#11
29.013
3.0.0

Rel-4
4.0.0
Approved at CN#11
CN#16
29.013
4.0.0

Rel-4
4.0.1
References updated
CN#16
29.013
4.0.1

Rel-5
5.0.0
Rel-5 created after CN#16
CN#26
29.013
5.0.0

Rel-6
6.0.0
Rel-6 created after CN#26
CT#36
29.013
6.0.0

Rel-7
7.0.0
Upgraded unchanged from Rel-6
CT#42
29.013
7.0.0

Rel-8
8.0.0
Upgraded unchanged from Rel-7
CT#46
29.013
8.0.0
0006
Rel-8
8.1.0
ISDN BC mapping
CT#46
29.013
8.1.0

Rel-9
9.0.0
Upgraded unchanged from Rel-8



































 STYLEREF ZA 3GPP TS 29.013 V9.0.0 (2009-12)
 PAGE 2
 STYLEREF ZGSM Release 9


3GPP




Version Control

Version Control

Toto je jediná verze této specifikace.

v900

Download & Access

Technical Details

AI Classification

Category: 7. Testování a interoperabilita
Subcategory: 7.1 Conformance Testing
Function: Test specification

Version Information

Release: Rel-9
Version: 900
Series: 29_series
Published: 2009-12

Document Info

Type: Technical Specification
TSG: Core Network and Terminals;
WGs:
CTSA

Keywords & Refs

Keywords:
UMTSLTEGSM

Partners

Contributors:
TTCARIBETSI+3

File Info

File: 29013-900
Processed: 2025-06-22

3GPP Spec Explorer - Enhanced specification intelligence