3bl61719aaaapbzza 08 en

All rights reserved.
Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
COVER SHEET
MOBILE COMMUNICATION GROUP
Title
External call scenarios : basic calls
Classification
Alcatel-Lucent 5060 Wireless Call Server GSM/UMTS CS CORE NETWORK SYSTEM DOCUMENTATION TECHNICAL REQUIREMENT SPECIFICATION
Edition Date Change Note
03 11 February 2008 Update
04 March 2009 Update
05 September Update
06/07 June 2010 Update
08 March 2011 Update
3BL 61719 AAAA PBZZA
EDITION
08
RELEASED
En
1/3
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
Originator(s) Approval(s)
B. Landais
ABSTRACT REVIEW HISTORY
This document specifies the basic call procedures and scenarios supported by the 5060 WCS. Reviewed on 2009-03-15 ACE meeting #53944
Ed.01 on 01/2005 Ed.02 on 12/2005
Creation Modification to take into account the following changes : - connection model for intra-MSC intra-MGW MS to MS call with only one H.248 context - alignment of data calls on recent 3GPP corrections / clarifications - clarifications on tone / announcement sending - decision not to support 3GATM and VoATM bearers within the CSCN Modification to integrate : - RDS 5317 : Call Mediation Node (CMN) - RDS 5914 : Completion of BICC basic functions - RDS 6068 : Toll Connection Successful Rate Improvement Based on Prepaging - RDS 7499 : Late IAM support - RDS 8025 : Restricted usage of Taudio - Replacement of data call establishment scenarios by a reference to the TRS Circuit Switched Data in GSM/UMTS - Miscenallaneous clarifications and corrections - Removal of 3GATM and VoATM procedures Modification to integrate : - RDS 10203 : End to end continuity with interconnects Updated for releases W4.49/W5.0: - RDS 8197a : 3 Stage Disconnect sequence for Nokia handsets 100 & Nokia 1600b handsets - RDS 11777: BICC APM segmentation - RDS 11324(&a): Reduce Call setup time(MO assignment parallel with termination call) - RDS 8242: Iu-cs over IP (WCS) - RDS 6569: Codec algorithms for interconnect bearers Updated for releases W4.32 SP2: RDS13186: TMO AoIP Phase 1 RDS 13186a: TMO AoIP Phase 2
Ed.03 Pr01 09/2007
Ed.03 Pr02 02/2008 Ed.04 Pr01 03/2009
Ed.05 09/2009
EDITION
08
RELEASED
En
2/3
Ed.06/07 08/2010
Updated for Release R5.0 and R5.1 by introducing the following RDS: - 12951a Support IVVR service - 14756 Call Progress Tone for Early Alerting - 13186b TMO AoIP - 10893a AoIP commercial - 7256 AMR-WB codec on 3G access - 14077 EAR (Early Audible Ringing) GMSC and Combined MSC - 12969 Delay MT call when parallel Location Update - 13170 Optimized MGW selection - 14221 Supporting and managing ALCAP termination on 754x MGW And PR: D76342 Updated for R5.1.1 by introducing RDS16018 AoIP trunk support for octetaligned RTP packets per RFC 4867.
Ed. 08 03/2011
Mnemonic
INTERNAL REFERENCED DOCUMENTS

None.
END OF COVERSHEET
EDITION
08
RELEASED
En
3/3
Basic calls
External call scenarios:
Alcatel-Lucent 5060 Wireless Call Server
TECHNICAL REQUIREMENT SPECIFICATION
EDITION
08
RELEASED
En
1/149
CONTENTS
1 2
SCOPE OF THE DOCUMENT ................................................................................................... 9 GENERAL PRINCIPLES............................................................................................................ 9 2.1 MSC LAYERED ARCHITECTURE AND INTERFACES ....................................................................................... 9 2.2 IP BEARER ESTABLISHMENT & RELEASE IN BICC CORE NETWORK................................................................ 10 2.2.1 Overview of IP bearer establishment........................................................................................ 10 2.2.2 IP bearer establishment ........................................................................................................... 11 2.2.3 BICC bearer establishement procedures .................................................................................. 12 2.2.4 Recommended IP bearer setup procedure................................................................................ 26 2.2.5 Nb Framing protocol initialisation (3GIP bearer)...................................................................... 26 2.2.6 Bearer establishment notifications ........................................................................................... 26 2.2.7 IP bearer release..................................................................................................................... 27 2.3 AAL2 BEARER ESTABLISHMENTMODIFICATION & RELEASE ON IUCS INTERFACE ........................................... 27 2.3.1 AAL2 bearer establishment ...................................................................................................... 27 2.3.2 AAL2 bearer modification ....................................................................................................... 29 2.3.3 AAL2 bearer release ............................................................................................................... 29 2.4 IP BEARER ESTABLISHMENT & RELEASE ON IUCS INTERFACE (RDS 8242) ...................................................... 29 2.4.1 Introduction ............................................................................................................................ 29 2.4.2 IuoIP bearer establishment ...................................................................................................... 30 2.4.3 IuoIP bearer release ................................................................................................................ 32 2.5 IP BEARER ESTABLISHMENT & RELEASE ON A INTERFACE (RDS 13186/13186A, RDS10893A, RDS16018) .... 32 2.5.1 Introduction ............................................................................................................................ 32 2.5.2 AoIP bearer establishment....................................................................................................... 33 2.5.3 AoIP bearer release................................................................................................................. 34 2.5.4 AoIP trunk support for octet-aligned RTP packets per RFC 4867 (RDS16018)............................ 34 2.6 CALL ESTABLISHMENT ....................................................................................................................... 35 2.6.1 Call control protocols.............................................................................................................. 35 2.6.2 Pre-Paging (RDS 6068) ........................................................................................................... 36 2.6.3 Codec negotiation .................................................................................................................. 36 2.6.4 Early/late access bearer assignment (mobile originating call) ................................................... 40 2.6.5 Continuity handling ................................................................................................................ 44 2.6.6 RAB Modification (RDS7256, RDS14221)................................................................................. 50 2.6.7 MGW selection ....................................................................................................................... 52 2.6.8 Optimized MGW selection ...................................................................................................... 52 2.6.9 Connection model .................................................................................................................. 52 2.6.10 TFO and Voice Quality Enhancement features ......................................................................... 54 2.6.11 Call Mediation Node (CMN) (RDS 5317)................................................................................. 54 2.6.12 Early Audible Ringing (RDS14077, RDS14756) ........................................................................ 54 2.7 3GPP FRAMING PROTOCOL ............................................................................................................. 55 2.7.1 3GPP Framing protocol initialisation........................................................................................ 55 2.7.2 Rate Control procedure (Informative)....................................................................................... 62 2.7.3 Time Alignment procedure (Informative) .................................................................................. 63 2.7.4 Transfer of user data............................................................................................................... 63 2.7.5 RFCI values correction / RFCI mapping ................................................................................... 63 2.8 TONES AND ANNOUNCEMENT (H.248 SPECIFIC)................................................................................... 65 2.8.1 Audio termination ................................................................................................................... 65 2.8.2 Tones ..................................................................................................................................... 66 2.8.3 Announcements ...................................................................................................................... 67 2.9 RECEIPT OF UNRECOGNIZED MESSAGES OR PARAMETERS .......................................................................... 67
3 3.1
MOBILE TO MOBILE SPEECH CALL ESTABLISHMENT ........................................................... 69 INTER-MSC MOBILE TO MOBILE CALL ESTABLISHMENT VIA BICN ............................................................... 69 EDITION 08 RELEASED En 2/149
3.1.1 3G originating call.................................................................................................................. 69 3.1.2 2G originating call.................................................................................................................. 76 3.1.3 3G terminating call (VMSC)..................................................................................................... 78 3.1.4 2G terminating call (VMSC)..................................................................................................... 88 3.1.5 3G/2G Terminating call (GMSC)............................................................................................. 91 3.2 INTER-MSC MOBILE TO MOBILE CALL ESTABLISHMENT VIA ISUP................................................................. 94 3.3 INTRA-MSC MOBILE TO MOBILE CALL ESTABLISHMENT ............................................................................. 94 3.3.1 Intra-MSC Inter-MGW mobile to mobile call establishment ...................................................... 94 3.3.2 Intra-MSC Intra-MGW mobile to mobile call establishment ...................................................... 98 4 MOBILE TO LAND (ISUP) SPEECH CALL ESTABLISHMENT.................................................. 100 4.1 INTER-MSC MOBILE TO LAND CALL ESTABLISHMENT VIA BICN ................................................................ 100 4.1.1 Originating MSC .................................................................................................................. 100 4.1.2 Border MSC.......................................................................................................................... 101 4.2 INTER-MSC MOBILE TO LAND CALL ESTABLISHMENT VIA ISUP ................................................................. 102 4.2.1 Originating MSC .................................................................................................................. 102 4.2.2 Border MSC.......................................................................................................................... 102 4.3 INTRA-MSC MOBILE TO LAND CALL ESTABLISHMENT ............................................................................. 102 4.3.1 Intra-MSC Inter-MGW mobile to land call establishment ........................................................ 103 4.3.2 Intra-MSC Intra-MGW mobile to land call establishment........................................................ 105 5 LAND (ISUP) TO MOBILE SPEECH CALL ESTABLISHMENT.................................................. 107 5.1 INTER-MSC LAND TO MOBILE CALL ESTABLISHMENT VIA BICN ................................................................ 107 5.1.1 GMSC .................................................................................................................................. 108 5.1.2 Terminating MSC .................................................................................................................. 109 5.2 INTER-MSC LAND TO MOBILE CALL ESTABLISHMENT VIA ISUP ................................................................. 109 5.2.1 GMSC .................................................................................................................................. 109 5.2.2 Terminating MSC .................................................................................................................. 109 5.3 INTRA-MSC LAND TO MOBILE CALL ESTABLISHMENT ............................................................................. 109 5.3.1 Intra-MSC Inter-MGW land to mobile call establishment ........................................................ 109 5.3.2 Intra-MSC Intra-MGW land to mobile call establishment........................................................ 112 6 TRANSIT CALL ESTABLISHMENT ........................................................................................ 114 6.1 6.2 6.3 6.4 6.4.1 6.4.2 7 7.1 8 9 BICC-BICC TRANSIT CALL .............................................................................................................. 114 BICC-ISUP TRANSIT CALL ............................................................................................................... 116 ISUP-BICC TRANSIT CALL ............................................................................................................... 116 ISUP-ISUP TRANSIT CALL................................................................................................................ 116 Intra-MSC Intra-MGW transit call .......................................................................................... 116 Intra-MSC Inter-MGW transit call .......................................................................................... 117
DATA CALL ESTABLISHMENT ............................................................................................. 120 SUPPORT IVVR SERVICE (RDS12591A).............................................................................................. 120 DELAY MT CALL( RDS12969) .............................................................................................. 122 CALL CLEARING ................................................................................................................. 124 9.1 9.1.1 9.1.2 9.2 9.3 9.3.1 9.3.2 9.4 NETWORK INITIATED CALL CLEARING ................................................................................................. 124 At GMSC Server (Border MSC / Transit MSC)......................................................................... 124 VMSC Server......................................................................................................................... 125 USER INITIATED CALL CLEARING ........................................................................................................ 126 (G)MSC SERVER INITIATED CALL CLEARING ......................................................................................... 126 GMSC Server initiated........................................................................................................... 126 VMSC Server initiated............................................................................................................ 127 MGW INITIATED CALL CLEARING ...................................................................................................... 127
10
INTERACTIONS WITH CAMEL/IN SERVICES........................................................................ 128
10.1 PRE-PAID INTERACTIONS ................................................................................................................. 128 10.2 FOLLOW ON AT GMSC-S AFTER CALLED PARTY RELEASE ........................................................................ 129 10.3 TEMPORARY CONNECTION TO A SPECIALIZED RESOURCE FUNCTION (GSMSRF) ........................................ 129 10.3.1 Upstream bearer not yet established ...................................................................................... 129 10.3.2 Upstream bearer already established..................................................................................... 131 3BL 61719 AAAA PBZZA EDITION 08 RELEASED En 3/149
10.4 10.5 11
INTERMEDIATE PACKET BEARERS TO REACH THE SRF............................................................................... 131 FOLLOW ON AT ORIGINATING MSC AFTER CALL RELEASE....................................................................... 135 CONTINUITY TEST SCENARIOS .......................................................................................... 137
11.1 GENERAL PRINCIPLES ...................................................................................................................... 137 11.2 OPERATOR CONTINUITY TEST ........................................................................................................... 138 11.2.1 Successful continuity test on outgoing circuit .......................................................................... 138 11.2.2 Unsuccessful continuity test on outgoing circuit ...................................................................... 139 11.2.3 Continuity test on incoming circuit ......................................................................................... 140 11.3 CALL BY CALL CONTINUITY TEST ....................................................................................................... 141 11.3.1 Successful continuity test on outgoing circuit .......................................................................... 141 11.3.2 Unsuccessful continuity test on outgoing circuit ...................................................................... 143 11.3.3 Continuity test on incoming circuit ......................................................................................... 144 12 RESTRICTIONS / LIMITATIONS .......................................................................................... 146
EDITION
08
RELEASED
En
4/149
HISTORY
Ed01 on 05-06-01. Creation Ed02 on 05-12-12 Update Ed03 September 2007 & February 2008 Update Ed04 March 2009 Update for releases W4.49 and W5.0 Ed05 September 2009-09-02 Update for release W4.32 SP2
REFERENCED DOCUMENTS
Alcatel-Lucent 5060 WCS TRS: [1] TRS Call scenarios : Handover 3BL61720AAAAPBZZA [2] TRS Supplementary services, Call Waiting/Call HOLD 3BL61721AAAAPBZZA [3] TRS Supplementary services, Explicit Call Transfer 3BL61721AAAAPBZZA [4] TRS Supplementary services, supplementary services, CLIP/CLIR/COLP/COLR 3BL76550AAAADSZZA [5] TRS supplementary services, call barring 3BL76551AAAADSZZA [6] TRS Supplementary services,Conference call scenarios 3BL61722AAAAPBZZA,3BL61722ABAAPBZZA [7] TRS Call scenarios : Lawful interception 3BL76379AAAAPBZZA [8] TRS DTMF management in mobile networks 3BL76536AAAADSZZA [9] TRS Codec management 3BL61733AAAADSZZA [10] TRS Echo cancellation and VQE features 3BL61723AAAADSZZA
EDITION
08
RELEASED
En
5/149
[11] TRS H248 interface 3BL61735AAAAPBZZA [12] TRS Internal/External SRF support with A8686 3BL76530AAAADSZZA [13] TRS Service Change for multimedia calls 3BL76557AAAADSZZA [14] WCS TRS TFO management 3BL76535AAAADSZZA [15] TRS Circuit Switched Data in GSM/UMTS 3BL76552AAAADSZZA [16] TRS Circuit Switched Multimedia Service 3BL76557AAAADSZZA [17] TRS CAMEL/IN 3BL76540AAAA DSZZA [18] TRS MSC M3UA signalling 3BL76542AAAADSZZA [19] TRS SS7 transport and Protocol 3BL76543AAAADSZZA [20] TRS translation and routing 3BL76554AAAADSZZA [21] TRS Preferential routing 3BL76555AAAADSZZA [22] TRS TRS ISDN-BC <-> PLMN-BC translation 3BL76760AAAADSZZA [23] TRS EGCP interface 3BL76765ABAADSZZA [24] TRS EGCP interface principles & procedures 3HP20038AAAADSZZA [25] TRS Tones and Announcements 3BL76767AAAADSZZA [26] TRS External Call scenarios : Features Interactions (IP loop) 3HP20005AAAADSZZA [27] TRS MGCF/SIP 3BL76655AAAADSZZA [28] TRS Mobility Services : security 3BL76560AAAADSZZA [29] TRS Routing mechanisms & scenario 3BL76802AAAADSZZA W4.0 RDS: [30] RDS 4162 : 3GPP BICN [31] RDS 4170 : IPBCP tunnelling W4.11 RDS:
EDITION
08
RELEASED
En
6/149
[32] RDS 5317 : Call Mediation Node (CMN) W4.21 RDS: [33] RDS 5914 : Completion of BICC basic functions [34] RDS 6068 : Toll Connection Successful Rate Improvement Based on Pre-paging [35] RDS 7499 : Late IAM support [36] RDS 8025 : Restricted usage of Taudio W4.32 SP2: [37] RDS 13186a: TMO AoIP Phase 2 W4.40 RDS: [38] RDS 10203 : End to end continuity with interconnects W4.49 RDS: [39] RDS 8197a: 3 Stage Disconnect sequence for Nokia handsets 100 & Nokia 1600b handsets W5.0 RDS: [40] RDS 11777: BICC APM segmentation [41] RDS 11324: Reduce Call setup time(MO assignment parallel with termination call) [42] RDS 8242: Iu-cs over IP (WCS) W5.0 SPx RDS: [43] RDS 6569: Codec algorithms for interconnect bearers Other Alcatel references None 3GPP references
EDITION
08
RELEASED
En
7/149
[44] 3GPP TS 23.009 : Handover procedures [45] 3GPP TS 23.018 : Basic call handling ; technical realization [46] 3GPP TS 23.205 : Bearer-Independent circuit-switched core network ; stage 2 [47] 3GPP TS 23.153 : Out of Band transcoder control ; stage 2 [48] 3GPP TS 29.232 : Media Gateway Controller (MGC) Media Gateway (MG) interface ; stage 3 [49] 3GPP TR 23.977 : Bandwidth and Resource Savings and Speech Enhancements for CS Networks (BARS) [50] 3GPP TS 25.401 : UTRAN overall description [51] 3GPP TS 25.410 : UTRAN Iu Interface: general aspects and principles [52] 3GPP TS 25.411 : UTRAN Iu interface layer 1 [53] 3GPP TS 25.412 : UTRAN Iu interface signalling transport [54] 3GPP TS 25.413 : UTRAN Iu interface RANAP signalling [55] 3GPP TS 25.414 : UTRAN Iu interface data transport and transport signalling [56] 3GPP TS 25.415 : UTRAN Iu interface user plane protocols [57] 3GPP TS 29.007 : General requirements on interworking between the PLMN and the ISDN or PSTN [58] 3GPP TS 29.414 : Core Network Nb Data Transport and Transport Signalling [59] 3GPP TS 29.415 : Core Network Nb interface user plane protocols [60] 3GPP TS 48.008: Mobile Switching Centre - Base Station System (MSC-BSS) interface; Layer 3 specification [61] 3GPP TS 48.103: Base Station System Media GateWay (BSS-MGW) interface; User Plane transport mechanism ITU-T references [62] ITU-T H.248.1 (03/02) : Gateway Control Protocol. Version 1 [63] ITU-T Q.1902.4 : Bearer independant call control protocol (CS2) : Basic call procedures [64] ITU-T Q.2630.2 : AAL type 2 signalling protocol Capability set 2 [65] ITU-T Q.1970 : BICC IP Bearer Control Protocol (IPBCP) [66] ITU-T Q.1990 : BICC Bearer Control Tunnelling Protocol (BCTP) [67] ITU-T Q.764 : Signalling system No. 7 ISDN user part signalling procedures [68] ITU-T Q.724 : Signalling system No. 7 Telephone user part Signalling procedures [69] ITU-R Recommendation X.213 (11/95): "Information technology - Open systems interconnection Network Service Definitions" IETF references [70] RFC 4566 SDP : Session Description Protocol
RELATED DOCUMENTS
See section REFERENCED DOCUMENTS.
EDITION
08
RELEASED
En
8/149
PREFACE
None.
SCOPE OF THE DOCUMENT
This document specifies the basic call scenarios implemented by the 5060 Wireless Call Server (WCS) product up to the WCS W4.32 SP2 and W5.0 releases for intra-MSC and inter-MSC ISUP/BICC call scenarios. SIP call scenarios are specified in TRS MGCF/SIP [27]. The TRS focuses on the main procedures required for a mobile NGN architecture. Most of the scenarios are described for a PLMN with VoIP or 3GPP IP core network bearers, established according to the delayed backward bearer establishment procedure. Scenarios involving other bearer establishment procedures can be derived thanks to the principles specified in subclause 2.2.3. A comprehensive description of all the possible scenarios is specified in subclause 3.1 for 3G originating and 3G terminating calls. The specification is written considering an H.248 interface Mc interface between the WCS and MGWs. Scenarios make reference to the logical H.248 procedures specified in [11], according to the following convention : <H.248 CMD> <Termination identity> (relevant parameters) [Logical H.248 procedure] As an example, ADD $ (selected codec) [EBE] specifies an H.248 ADD command and makes reference to the H.248 logical procedure Establish Bearer. Scenarios for the EGCP interface [23] shall be derived from those given for the H.248 interface. The EGCP connection model is prcised in the TRS, if different from the one retained for the H.248 interface. The logical EGCP procedures are specified in [24]. Throughout this TRS, it is assumed that for all two party calls, the 5060 WCS seizes a single context per call on each MGW involved in the call, i.e. that the WCS does never configure internal bearer inside the MGW. This is the connection model indeed supported with EGCP, and this is also the target H.248 solution, but the current WCS implementation actually seizes, in some very specific scenarios, two H.248 contexts inside a same MGW interconnected via RTP/IP terminations (IP hair-pinning). This is described in the TRS Features Interactions (IP loop) [26] which therefore amends all other TRSs till the target solution is supported.
GENERAL PRINCIPLES
2.1 MSC layered architecture and interfaces

The 5060 WCS is a NGN Class 4 and Class 5 capable Media Gateway Controller. It can control access MGWs interfacing BSS and RNS, or/and trunking MGW for transit ISUP or BICC calls, using the EGCP protocol for 7540/7549 MGWs and the H.248 protocol for 7570 MGWs. The 5060 WCS can act as a MSC Server, a GMSC Server or both. The 5060 WCS supports GERAN, UTRAN and UMAN accesses, and interfaces towards PSTN, BICC core network, SIP network and IMS, as illustrated below.
EDITION
08
RELEASED
En
9/149
PSTN / legacy MSC
ISUP/TUP
BICC Nc MAP Mc
A BSSAP Iu cs
H.248 EGCP
IP backbone
H.248 EGCP
RANAP IPBCP (IP)
ALCAP
Nb
UMA-RR AP
Access IP network
MPLS (IP)
SIP VoIP
SIP Phone
UMAN (Bluetooth, 802.11, ..)
Figure 1 MSC layered architecture and interfaces The following types of bearers are supported by the 5060 WCS within the CSCN. TDM bearers Packet backbone bearers : 3GPP IP bearers : 3GIP bearers, implementing the 3GPP Framing Protocol (NbFP/RTP/UDP/IP) see 3GPP TS 29.414 [58]. VoIP bearers : standard IETF VoIP bearers (RTP/UDP/IP), without the 3GPP Framing Protocol. Those bearers are not supported by 3GPP for BICC based CSCNs, but are defined by 3GPP for SIP-I based Nc CSCNs (from 3GPP Rel-8 onwards) and IMS. They are also defined for AoIP.
ATM-based packet backbones are not supported.
2.2 IP bearer establishment & release in BICC Core Network

2.2.1 Overview of IP bearer establishment
3GIP and VoIP bearers are established using the IPBCP protocol [65], transported over the Mc and Nc interface via the Bearer Control Tunnelling Protocol [66], as specified in 3GPP TS 29.414 [58] and illustrated below.
EDITION
08
RELEASED
En
10/149
Nc MSC-Server MSC-Server
IPBCP: Q.1970
Tunnel: Q.1990
Mc
Mc MGW Nb MGW
BICC: Q.765.5
TS 29.232
Figure 2 Protocols used for IP bearer bearer establishment
2.2.2
IP bearer establishment
2.2.2.1 IPBCP protocol The MGW in charge of establishing the IP bearer initiates the following messages exchange.
MGW-O REQUEST 1 ACCEPTED 2
MGW-T
IPBCP Figure 3 Successful IPBCP bearer establishment
1. The originating MGW allocates internal resources and sends a REQUEST message to the terminating MGW, providing in particular : - an interface IP address within the originating MGW, specifying the intended source and sink of the media stream at the originating MGW - a Media announcement field, containing the allocated transport port (i.e. UDP port) of the RTP termination in the originating MGW, and specifying the media type (audio), the transport protocol (RTP/AVP) and the media format. 2. Upon receipt of a REQUEST message, the terminating MGW examines the information in the REQUEST message, and if it is acceptable, replies to the originating MGW with an ACCEPTED message, providing in particular : - an interface IP address within the terminating MGW, specifying the intended source and sink of the media stream at the terminating MG - a Media announcement field, containing the allocated transport port (i.e. UDP port) of the RTP termination in the terminating MG Note : for VoIP bearers, there could be a conflict between the codec configured locally by the MSC Server and the codec received from the peer MGW in the IPBCP REQUEST message. The codec configured locally should
EDITION
08
RELEASED
En
11/149
prevail. For 3GIP bearers, the IPBCP REQUEST message does only refer to a IuFP payload type without specifying which codec it corresponds to ; the MGW gets the codec from its MSC Server. Alternatively, the terminating MGW may return a REJECTED message or a CONFUSED message, respectively if the received request can not be accepted (e.g. incorrect contents in the REQUEST message) or can not be processed.
MGW-O
MGW-T
REQUEST REJECTED 1 REQUEST CONFUSED 2
IPBCP
Figure 4 Unsuccessful IPBCP bearer establishment 2.2.2.2 IPBCP tunnelling IPBCP protocol exchanges are transported over the Mc and Nc interface by means of the Bearer Control Tunnelling Protocol [66]. The MSC-S and the MGW make use of the H.248 Tunnel Information Down and Tunnel Information Up procedures [11] to convey the tunnel data received from / to be sent to the preceding or succeeding MGW. The Tunnel information are then sent within the Bearer Control Information information element within BICC messages. As the IPBCP bearer establishment request is tunnelled within H.248 and BICC signallings, no BNC id is exchanged between MSCs as the MGW can correlate without BNC identity the IPBCP requests with the H.248 context settled by the MSC-S. 2.2.2.3 Mc procedures The following H.248 logical procedures are used by the MSC-S to trigger and transport the IP bearer establishment signalling between MGWs. See the TRS H.248 interface [11]. Establish BEarer (EBE) procedure : to request the MGW to initiate the establishment of an IP bearer, i.e. request generation of an IPBCP Request message. Prepare BEarer (PBE) procedure : to request the MGW to prepare the establishment of an IP bearer, i.e. request the MGW to reserve IP resource and be prepared to receive either a bearer establishment request from a peer MGW or a MSC-S Establish BEarer order. TUnnel Down / TUnnel Up procedures to transport the tunnelled IPBCP signalling (see 2.2.2.2)
Those procedures are used both for VoIP and 3GIP bearer establishment. The MSC-S shall configure 3GUP properties (see section 2.7.1.4) when seizing 3GIP terminations. This allows the MGW to differentiate whether a 3GIP or a VoIP bearer is being established. 2.2.3 BICC bearer establishement procedures
2.2.3.1 Overview of BICC bearer setup procedures Four variants of BICC IP bearer set-up procedures are defined in [63]. Fast Forward EDITION 08 RELEASED En 12/149
Delayed Forward Fast Backward Delayed Backward
Those procedures differ on the way the bearer control informations are exchanged, and on whether an APM (Connected) message shall be sent by the originating BICC node once the bearer is ready for use. Bearer control information exchanges : In Fast bearer setup (forward or backward) and in delayed forward bearer establishment procedures, the IP bearer establishment is done in the forward direction, i.e. the IPBCP request is sent from the originating towards the terminating MGWs ; the bearer establishment request is sent in the IAM message in fast (forward or backward) procedures, while it is sent in subsequent APM message, after a first IAM/APM exchange, in case of delayed forward bearer establishment. In reverse, in the Delayed backward bearer establishment procedure, the IP bearer establishment is done in the direction reverse to the call establishment direction, i.e. the IPBCP request is sent from the terminating towards the originating MGWs, through a backward APM message. In Forward bearer setup procedures, the terminating BICC node decides by its own whether it requires or not the originating BICC node to send an APM (Connected) message once the bearer is ready for use at the originating side. In Delayed backward bearer setup procedure, APM(Connected) is never sent (BICC protocol). In Fast backward bearer setup procedure, an APM(Connected) message shall always be sent (BICC protocol).
APM (Connected) exchange :
The 5060 WCS supports all those variants, both from the perspective of an outgoing or an incoming call, with one restriction for the fast backward bearer setup procedure : the WCS does not send nor expect to receive an APM(Connected) messageThe variant to be used for an outgoing BICC call setup is configurable by the operator on a per BICC trunk group level. The variant to be used for an incoming call is the one requested by the originating node (the BICC protocol does not allow the receiving node to modify the bearer establishment procedure selected by the originating node). The WCS supports the interworking between any combination of those procedures for BICC-BICC calls (e.g. delayed forward setup received upstreams, fast forward setup configured downstreams). The 5060 WCS also supports interworking between VoIP and 3GIP bearers (e.g. BICC 3GIP upstreams, BICC VoIP downstreams). On the Nc interface, the BICC protocol does not allow to differentiate the establishment of a 3GIP from a VoIP bearer (there is no specific Bearer Network Connection Characteristics value for 3GPP bearers). The 5060 WCS derives the type of IP bearer from the configuration of the outgoing / incoming BICC trunk group. 2.2.3.2 Fast Forward bearer establishment procedure
EDITION
08
RELEASED
En
13/149
MSC-S A
MGW A
1
MSC-S B
MGW B
ADD $ (TunOpt,TIND event,preferred codec,3GUP) [EBE] ADD Reply Ta NOTIFY Ta (BIT[IPBCP Req]) [TUU] NOTIFY Reply Ta
2
IAM (Connect fw, tunnelling to be used,TunnelInfo[IPBCP Req],SCL)
ADD $ (BIT[IPBCP Req],TunOpt,TIND event, selected codec,3GUP) [PBE+TUD] ADD Reply Tb NOTIFY Tb (BIT[IPBCP Resp]) [TUU] NOTIFY Reply Tb APM (with or w/o notif, TunnelInfo[IPBCP Resp],selected codec) MOD Ta (BIT[IPBCP Resp], selected codec, [3GUP]) [TUD+MBE] MOD Reply Ta Nb FP Initialisation Req
8 7 6 5
Nb FP Initialisation Ack NOTIFY Tb (Bearer Established) NOTIFY Reply Tb NOTIFY Ta (Bearer Established) NOTIFY Reply Ta APM(Connected)
10 9 9
Figure 5 Fast forward bearer establishment 1. Establish BEarer procedure The originating MSC-S requests the originating MGW to establish the IP bearer. The MSC-S indicates the preferred codec, the type of IP bearer (VoIP or 3GIP if 3GUP properties are set), that tunnelling is used and whether it expects to receive the Notify command with the IPBCP Request in the same H.248 message as the one carrying the ADD Reply command or at any time. Note The preferred codec should normally be the first codec sent in the BICC SCL. However the 5060 WCS always configure the AMR 12.2 codec as the preferred codec. Note The 5060 WCS supports receipt of the Notify command with the IPBCP Request at any time. 2. TUnnel Up procedure If the MGW can serve the MSC-S request, it reserves resources for the new call, prepares an IPBCP Request which it sends towards the MSC-S via a NOTIFY command. 3. Initial Address Message The originating MSC-S sends an IAM message to the succeeding node, with the ActionIndicator set to 'Connect Forward', the Supported Codecs List, the indication that tunnelling is used, and with the tunnelled IP bearer establishment request received precedingly from the originating MGW. The terminating node derives from the received information that a fast forward set-up procedure is requested (cf ActionIndicator, tunnelling to be used, and tunnel data received). 4. Prepare BEarer procedure + TUnnel Down The terminating MSC-S requests the terminating MGW to prepare the IP bearer establishment and simultaneously downloads the received tunnelled IPBCP request (see [11]). The MSC-S indicates the selected codec, the type of IP bearer (VoIP or 3GIP if 3GUP properties are set), that tunnelling is used and whether it expects to receive the Notify command with the IPBCP Response in the same H.248 message as the one carrying the ADD Reply command or at any time.
5. TUnnel Up procedure If the MGW can serve the MSC-S request, it reserves resources for the new call, prepares an IPBCP Response which it sends towards the MSC-S via a NOTIFY command.
EDITION
08
RELEASED
En
14/149
6. APM message The terminating MSC-S returns an APM message to the preceding node, with an ActionIndicator set to 'Connect forward, no notification + selected codec', or to 'Connect forward, plus notification + selected codec' depending on whether it requests the originating node to send a subsequent APM(Connected) message see section 2.6.4. The APM also contains the selected codec, the available codecs list (see TRS Codec management [9]), and the tunnelled IPBCP Response. Note If codec negotiation is disabled in the 5060 WCS, the ActionIndicator 'Connect forward, no notification' or 'Connect forward, plus notification' are sent instead. 7. TUnnel Down + Modify BEarer procedures The originating MSC-S relays the received IPBCP response to the originating MGW. In case of 3GIP bearer, if the selected codec differs from the preferred codec initially configured or if the 3GUP properties needs to be modified (see section 2.7.1.5.7), the MSC-S also initiates a Modify Bearer procedure. Note Since IPBCP is used for VoIP bearers and the IPBCP request for VoIP bearer shall specify the media format (selected codec) (unlike 3GIP bearer for which the media format in the IPBCP request just indicates an IuFP RTP payload type, without further specifying the actual codec used above IuFP layer), the fast setup procedure should be used to set-up a VoIP bearer only if the codec to be configured is known before sending the IAM (i.e. unique codec configured on the BICC trunk group). As an exception, if the MGW supports the possibility to receive different codecs from the peer MGW (in IPBCP Request message) and from its local MSC Server, and if the codec configured locally prevails, the fast setup procedure remains usable even if the codec needs to be negotiated with the distant node. 8. Nb FP Initialisation For 3GIP bearer, once the IPBCP response is received, the originating MGW initialises the Iu FP protocol towards the terminating MGW in accordance with the selected codec. 9. BEarer Established notification If the MSC-S requested the MGW to return a notification when the bearer is ready for use, the MGW shall, upon successful completion of the VoIP bearer, or successful completion of the Nb FP initialisation for 3GIP bearer, send a BEarer Established notification. The 5060 WCS requests BEE notifications for 3GIP terminations only ; see section 2.2.6. 10. APM(Connected) The originating MSC-S sends an APM message with the ActionIndicator set to 'Connected' when the bearer is ready for use at the originating side, if requested to do so by the succeeding node in the preceding APM message.
EDITION
08
RELEASED
En
15/149
2.2.3.3 Delayed Forward bearer establishment procedure

MSC-S A MGW A
1
MSC-S B
MGW B
ADD $ (TunOpt,TIND event,preferred codec,3GUP) [PBE] Add Reply Ta
IAM (Connect fw, tunnelling to be used, No tunnelled data,SCL)
ADD $ (TunOpt,TIND event,selected codec,3GUP) [PBE] Add Reply Tb APM (with or w/o notif, selected codec) 4 MOD Ta (selected codec,[3GUP]) [EBE] MOD Reply Ta NOTIFY Ta (BIT[IPBCP Req]) [TUU] 6 NOTIFY Reply Ta APM (TunnelInfo[IPBCP Req],tunnelling to be used)
7 5
MOD Tb (BIT[IPBCP Req]) [TUD] 8 MOD Reply Tb NOTIFY Tb (BIT[IPBCP Resp]) [TUU] NOTIFY Reply Tb APM (TunnelInfo[IPBCP Resp]) MOD Ta (BIT[IPBCP Resp]) [TUD] MOD Reply Ta Nb FP Initialisation Req
12 11 10 9
Nb FP Initialisation Ack NOTIFY Tb (Bearer Established) NOTIFY Reply Tb NOTIFY Ta (Bearer Established) NOTIFY Reply Ta APM(Connected)
14 13 13
Figure 6 Delayed forward bearer establishment 1. Prepare BEarer procedure The originating MSC-S requests the MGW to prepare the IP bearer establishment. The MSC-S indicates the preferred codec, the type of IP bearer (VoIP or 3GIP if 3GUP properties are set), that tunnelling is used and whether it expects to receive subsequent Notify command with the IPBCP Request in the same H.248 message as the one carrying the MOD Reply (subsequent EBE procedure) or at any time. Note The preferred codec should normally be the first codec sent in the BICC SCL. However the 5060 WCS always configure the AMR 12.2 codec as the preferred codec. Note The 5060 WCS supports receipt of the Notify command with the IPBCP Request at any time. 2. Initial Address Message Network side bearer establishment The originating MSC-S sends an IAM message to the succeeding node, with the ActionIndicator set to 'Connect Forward', the Supported Codecs List, the indication that tunnelling is used, but without tunnelled data. The terminating node derives from the received information that a delayed forward bearer set-up procedure is requested (cf ActionIndicator, tunnelling to be used, and no tunnel data received). 3. Prepare BEarer procedure The terminating MSC-S requests the terminating MGW to prepare the IP bearer establishment. The MSC-S indicates the selected codec, the type of IP bearer (VoIP or 3GIP if 3GUP properties are set), that
EDITION
08
RELEASED
En
16/149
tunnelling will be used and whether it expects to receive the Notify command with the IPBCP Response in the same H.248 message as the one carrying the ADD Reply command or at any time ; no tunnelled data is however downloaded. 4. APM message The terminating MSC-S returns an APM message to the preceding node, with an ActionIndicator set to 'Connect forward, no notification + selected codec', or to 'Connect forward, plus notification + selected codec' depending on whether it requests the originating node to send a subsequent APM(Connected) message see section 2.6.4. The APM also contains the selected codec, the available codecs list (see TRS Codec management [9]), but no tunnelled data. Note If codec negotiation is disabled in the 5060 WCS, the ActionIndicator 'Connect forward, no notification' or 'Connect forward, plus notification' are sent instead. 5. Establish BEarer procedure The originating MSC-S reconfigures the MGW with the selected codec and final 3GUP properties, and requests it to establish the IP bearer. The MSC-S already indicated that tunnelling is to be used and that the MGW should return the tunnelled IPBCP request within the Add Reply message. 6. TUnnel Up procedure The MGW prepares an IPBCP Request which it sends towards the MSC-S via a NOTIFY command. 7. APM message The returned tunnelled IP bearer establishment request is sent within the APM with the tunnelling indicator present. 8. Tunnel Down procedure The terminating MSC-S relays the received IPBCP request to the terminating MGW. 9. TUnnel Up procedure The MGW prepares an IPBCP Response which it sends towards the MSC-S via a NOTIFY command. 10. APM message The terminating MSC-S returns a second APM message to the preceding node, with the tunnelled IPBCP Response. 11. TUnnel Down procedure The originating MSC-S relays the received IPBCP response to the originating MGW. 12. Nb FP Initialisation For 3GIP bearer, once the IPBCP response is received, the originating MGW initialises the Iu FP protocol towards the terminating MGW in accordance with the selected codec. 13. BEarer Established notification If the MSC-S requested the MGW to return a notification when the bearer is ready for use, the MGW shall, upon successful completion of the VoIP bearer, or successful completion of the Nb FP initialisation for 3GIP bearer, send a BEarer Established notification. The 5060 WCS requests BEE notifications for 3GIP terminations only ; see section 2.2.6. 14. APM(Connected) The originating MSC-S sends an APM message with the ActionIndicator set to 'Connected' when the bearer is ready for use at the originating side, if requested to do so by the succeeding node in the first backward APM message.
EDITION
08
RELEASED
En
17/149
2.2.3.4 Fast backward bearer establishment procedure

MSC-S A MGW A MSC-S B MGW B
ADD $ (TunOpt,TIND event,preferred codec,3GUP) [EBE] ADD Reply Ta NOTIFY Ta (BIT[IPBCP Req]) [TUU] NOTIFY Reply Ta IAM (Connect bw, tunnelling to be used,TunnelInfo[IPBCP Req],SCL)
1
ADD $ (BIT[IPBCP Req],TunOpt,TIND event, selected codec,3GUP) [PBE+TUD] ADD Reply Tb NOTIFY Tb (BIT[IPBCP Resp]) [TUU] NOTIFY Reply Tb APM (selected codec)
2
APM (Connect bw, TunnelInfo[IPBCP Resp]) MOD Ta (BIT[IPBCP Resp], selected codec, [3GUP]) [TUD+MBE] MOD Reply Ta
4
Nb FP Initialisation Req Nb FP Initialisation Ack NOTIFY Tb (Bearer Established) NOTIFY Reply Tb NOTIFY Ta (Bearer Established) NOTIFY Reply Ta APM(Connected)
5
Figure 7 Fast backward bearer establishment The scenario is much alike the fast forward bearer setup scenario (see section 2.2.3.2). In particular, the IPBCP bearer establishment is still done in the forward direction, i.e. from the originating towards the terminating MGW. Only the differences are explained below. 1. IAM message The originating MSC-S sends an IAM message to the succeeding node, with the ActionIndicator set to 'Connect Backward', the Supported Codecs List, the indication that tunnelling is used, and with the tunnelled IP bearer establishment request received precedingly from the originating MGW. The terminating node derives from the received information that a fast backward beare set-up procedure is requested (cf ActionIndicator, tunnelling to be used, and tunnel data received). 2. First backward APM message As per ITU-T Q.1902.4 [63], sections 8.3.4.2 and 8.3.5.2, when codec negotiation is supported, the terminating BICC node shall return a first APM message with an ActionIndicator set to 'selected codec' and with the selected codec and the available codecs list (see TRS Codec management [9]). 3. Second backward APM message The terminating BICC node shall then return a second APM message, with an ActionIndicator set to 'Connect Backward' and with the tunnelled IPBCP Response. 5060 WCS restrictions : - when acting as the BICC terminating node, the WCS returns one single APM message containing both the selected codec and the tunnelled IPBCP response ; - when acting as the BICC originating node, the WCS does only expect to receive one single APM message. Note Since sending two separate APM messages increases useslessly the BICC signalling, both implementations may actually be encountered, i.e. BICC nodes sending one single or two APM
EDITION
08
RELEASED
En
18/149
messages. 4. TUnnel Down and Modify BEarer procedures Whether one or two APM messages are received from the terminating BICC node, one single H.248 command should be sent to minimize the signalling on the Mc interface. However, some implementations may proceed in two steps, i.e. sequentially initiates the MBE and the TUD procedures. 5. APM(Connected) In the fast backward bearer setup procedure, the originating BICC node shall systematically send an APM message with the ActionIndicator set to 'Connected' when the bearer is ready for use at the originating side (as per BICC protocol). This is not controllable by the BICC terminating node. 5060 WCS restriction : - when acting as the BICC originating node, the WCS does never send an APM(Connected) message in the fast backward bearer setup procedure ; this will cause the failure of the call establishment if the BICC terminating node is waiting for its receipt (as it should normally do). - when acting as the BICC terminating node, the WCS does not expect to receive an APM(Connected) message in the fast backward bearer setup procedure. 2.2.3.5 Delayed Backward bearer establishment procedure
MSC-S A MGW A MSC-S B MGW B
ADD $ (TunOpt,TIND event,preferred codec,3GUP) [PBE] 1 ADD Reply Ta IAM (connect bw, tunnelling to be used, No Tunnelled data,SCL) 2 ADD $ (TunOpt,TIND event,selected codec,3GUP) [EBE] 3 ADD Reply Tb NOTIFY Tb (BIT[IPBCP Req]) [TUU] 4 NOTIFY Reply Tb APM (selected codec) 5 APM (Connect bw, TunnelInfo[IPBCP Req]) 5 MOD Ta (BIT[IPBCP Req],selected codec,[3GUP]) [TUD,MBE] 6 MOD Reply Ta NOTIFY Ta (BIT[IPBCP Resp]) [TUU] 7 NOTIFY Reply Ta APM (TunnelInfo[IPBCP Resp]) 8 MOD Tb (BIT[IPBCP Resp]) [TUD] 9 MOD Reply Tb Nb FP Initialisation Req 10 Nb FP Initialisation Ack NOTIFY Tb (Bearer Established) 11 NOTIFY Reply Tb NOTIFY Ta (Bearer Established) 11 NOTIFY Reply Ta APM(Connected) never sent
12
Figure 8 Delayed backward bearer establishment
EDITION
08
RELEASED
En
19/149
1. Prepare BEarer procedure The originating MSC-S requests the MGW to prepare the IP bearer establishment. The MSC-S indicates the preferred codec, the type of IP bearer (VoIP or 3GIP if 3GUP properties are set), that tunnelling is used and whether it expects to receive subsequent Notify command with the IPBCP Response in the same H.248 message as the one carrying the MOD Reply (subsequent TUD procedure) or at any time.The preferred codec should normally be the first codec sent in the BICC SCL. However the 5060 WCS always configure the AMR 12.2 codec as the preferred codec. Note The 5060 WCS supports receipt of the Notify command with the IPBCP Request at any time. 2. Initial Address Message The originating MSC-S sends an IAM message to the succeeding node, with the ActionIndicator set to 'Connect Backward', the Supported Codecs List, the indication that tunnelling is used, but without tunnelled data. The terminating node derives from the received information that a delayed backward bearer set-up procedure is requested (cf ActionIndicator, tunnelling to be used, and no tunnel data received). 3. Establish BEarer procedure The terminating MSC-S requests the MGW to establish the IP bearer. The MSC-S indicates the selected codec, the type of IP bearer (VoIP or 3GIP if 3GUP properties are set), that tunnelling is used and whether it expects to receive the Notify command with the IPBCP Request in the same H.248 message as the one carrying the ADD Reply command or at any time. Note The 5060 WCS supports receipt of the Notify command with the IPBCP Request at any time. Note Since IPBCP is used for VoIP bearers, and since the IPBCP request for VoIP bearer shall mention the selected codec (unlike 3GIP bearer for which the IPBCP request just mentions it is an Iu bearer), the MSC-S B should invoke the Establish Bearer procedure only when it knows the codec that shall be selected on the termination. In case a BICC codec negotiation is required towards another downstream SN (e.g. MSC-S B is a transit node), the MSC-S B should wait for the outcome of this procedure before seizing the termination in MGW B, unless the MGWA supports the possibility to receive different codecs from the peer MGW (in IPBCP Request message) and from its local MSC Server, and if the codec configured locally prevails. 4. TUnnel Up procedure The MGW prepares an IPBCP Request which it sends towards the MSC-S via a NOTIFY command. 5. APM message As per ITU-T Q.1902.4 [63], sections 8.3.4.2 and 8.3.5.2, when codec negotiation is supported, the terminating BICC node shall return a first APM message with an ActionIndicator set to 'selected codec' and with the selected codec and the available codecs list (see TRS Codec management [9]). The terminating BICC node shall then return a second APM message, with an ActionIndicator set to 'Connect Backward' and with the tunnelled IPBCP Request 5060 WCS restriction: - when acting as the BICC terminating node, the WCS returns one single APM message containing both the selected codec and the tunnelled IPBCP response ; - when acting as the BICC originating node, the WCS does only expect to receive one single APM message. Note Since sending two separate APM messages increases useslessly the BICC signalling, both implementations may actually be encountered, i.e. BICC nodes sending one single or two APM messages. 6. TUnnel Down and Modify BEarer procedures The originating MSC-S reconfigures the MGW with the selected codec and final 3GUP properties, and simultaneously downloads the received tunnelled IPBCP request. 7. TUnnel Up procedure The MGW prepares an IPBCP Response which it sends towards the MSC-S via a NOTIFY command.
EDITION
08
RELEASED
En
20/149
8. APM message The originating MSC-S forwards the tunnelled IPBCP Response to the succeeding node. 9. Tunnel Down procedure The terminating MSC-S relays the received IPBCP response to the terminating MGW. 10. Nb FP Initialisation For 3GIP bearer, once the IPBCP response is sent, the originating MGW initialises the Nb FP protocol towards the terminating MGW in accordance with the selected codec. In case the Nb FP initialisation request arrives at the terminating node before the IPBCP response, the terminating MGW should either send back the Initialisation Ack message immediately (using the IP address, UDP port and RTP payload received in the packet carrying the Iu Initialisation message) or upon receipt of the IPBCP Accept message. The originating MGW starts a timer when sending the Iu Initialisation request and resends the message upon timer expiry ; this process may apply again until the maximum number of repetitions is reached. 11. BEarer Established notification If the MSC-S requested the MGW to return a notification when the bearer is ready for use, the MGW shall, upon successful completion of the VoIP bearer, or successful completion of the Nb FP initialisation for 3GIP bearer, send a BEarer Established notification. The 5060 WCS requests BEE notifications for 3GIP terminations only ; see section 2.2.6. 12. APM(Connected) is never sent An APM(Connected) message is never sent in delayed backward bearer establishment procedure (as per BICC protocol). This is not controllable by the BICC terminating node. 2.2.3.6 BICC APM segmentation (RDS 11777) 2.2.3.6.1 Introduction
With BICC fast forward/backward bearer establishment, the size of the IAM message may exceed the maximum size permitted by the underlying MPT3 transport, depending on the ISUP IEs and the content of the Application Transport Parameter IE (e.g. codec list, bearer control informations) included in the IAM. NOTE: W/o RDS 11777, the WCS does not support sending over M3UA BICC IAM messages larger than the max. IAM size permitted for MTP3. The same limit therefore also applied for M3UA. With RDS 11777, the WCS supports sending & receiving: over MTP3 and M3UA BICC IAM messages larger than the maximum size allowed by the MTP3 transport, by support segmentation of the APM informations; over M3UA large BICC IAM messages without APM segmentation.
Use of APM segmentation is decided on a per call basis, i.e. if the operator enables the APM segmentation feature, it is actually used only if required by the size of the IAM of the particular call. Note that use of APM segmentation does not degrade the WCS performance since APM segmentation is only used for message requiring it, and it does not generate extra internal or Mc signalling. When APM segmentation is used for the call, it is not more costly than if delayed forward bearer establishement were used. 2.2.3.6.2 Procedure
ID::RDS11777:R001; APM segmentation configuration
An operator configurable parameter shall be supported on a per BICC trunk group to enable or disable the APM segmentation. By default, the APM segmentation shall be enabled. The setting of this parameter is independent (i.e. no O&M check) from the underlying signaling transport (MTP3 or/and M3UA). NOTE1: This parameter only applies for outgoing IAM msg, i.e. it has no effect on incoming IAM which may be segmented or not. Incoming IAM message with or w/o APM segmentation shall be properly handled irrespectively of the setting of this parameter.
EDITION
08
RELEASED
En
21/149
When enabled, APM segmentation shall be used if the IAM msg size exceeds the maximum size limit, whatever the underlying signaling transport. The same maximum size limit applies, whatever the underlying signaling transport: For ANSI , the maximum ISUP/BICC payload is 265 bytes. For ITU, the maximum ISUP/BICC payload is 268 bytes.
When disabled, APM segmentation shall NOT be used, i.e. if M3UA is selected as the underlying signaling transport, the IAM msg shall be sent without segmentation even if exceeding the limit size (265/268 bytes). if MTP3 is selected as the underlying signaling transport, the IAM message shall be sent without segmentation if its size is smaller or equal to the maximum size limit (265/268 bytes), otherwise shall be dropped.
The maximum BICC IAM message required to be supported in emission & reception (with and w/o APM segmentation) is 512 bytes. When dropping a BICC IAM message (as per reqt above), the WCS shall generate a maintenance EVENT to inform the operator of the problem & WCS misconfiguration. Events shall be filtered, e.g. no more than 1 event every 5 seconds. The corresponding call is released upon expiry of BICC timer.
ID::RDS11777:R002; APM segmentation procedure overall requirements
APM segmentation shall be supported as per ITU-T Q.765 standard, both in emission and reception with the clarifications/modifications specified in this subclause. 1/ The WCS shall support APM segmentation for the BAT ASE APM-user (i.e. BICC). 2/ APM segmentation is ONLY required to be supported for ITU BICC. Not required for ANSI BICC. APM segmentation shall be supported for all ITU BICC variants. NOTE2: BICC is not deployed/intended to be deployed in North American markets, nor between ITU and ANSI networks. 3/ As per ITU-T Q.765, the APM segmentation may take place for any of application data associated with an IAM, ACM, CPG, CON, ANM or PRI message. The WCS ONLY supports APM segmentation in IAM message. 4/ As per ITU Q.765 10 APM segments can be sent at most. The WCS only supports 2 BAT ASE APM segments for both segmentation and re-assembly, i.e. one IAM with a first APM segment, plus an APM message with the second APM segment: the WCS shall support the sending of 2 BAT ASE APM segments. No other APM-user application is requested to be supported in emission; the WCS shall support reception of at most 2 BAT ASE APM segments. The WCS shall release the call if more than 2 BAT ASE segments are received; the WCS shall support reception of APM segments with unknown Application Context Identifier as specified in ID::RDS11777:R006.
5/ The WCS shall support incoming IAM message with more than 1 APM segment (APM-user), but shall handle APM segments with unknown ACI as specified in ID::RDS11777:R006 (e.g. APM segment with unknown ACI is dropped if instructed so by the PIN) . Re-assembly is only supported for APM segments with BAT ASE ACI. 6/ If the BICC IAM message size is greater than 268 octets and APM segmentation configured, the WCS shall perform APM segmentation. It is assumed that the BICC IAM message including an Application Transport parameter w/o an Encapsulated application information in the APP parameter will never exceed the 268 octets. It is therefore NOT required to support in emission both ISUP segmentation and APM segmentation for the same outgoing IAM message (i.e. sending of an IAM + SEGMENTATION + APM messages). The WCS can release such a call as a defense implementation in such a case.
EDITION
08
RELEASED
En
22/149
ID::RDS11777:R003; APM segmentation procedure Acknowlegdment of first APM segment
As per ITU-T Q.765, the first segmented APM should only be sent once a backward message containing empty APP is received. When acting as a PAN (receiving node), the WCS shall send an APM message containing an empty APP to acknowledge reception of an IAM indicating segmentation of APM information (for BAT ASE). No acknowledgment is sent for APM segments with unknown Application Context Identifier. When acting as a PIN (sending node), the WCS shall accept an APM message containing an empty APP as per ITU-T Q.765. NOTE3: An ACM 'no indication' or CPG can not be used as a first backward message acknowledging the receipt of the first APM segment. Indeed in BICC signalling (in which context APM segmentation is required to be supported) the BICC bearer shall be set up before an ACM is returned. This requires beforehand that the BICC infos have been received by the PAN. The acknowledgment message is an APM message containing an Application Transport parameter set as follows:
8 ext. ext. ext. 1 ext. 7 MSB Spare SI APM segmentation indicator Segmentation local reference APM-user information SNI RCI 6 5 4 3 Application context identifier 2 1 LSB
1 1a 2 3 3a 4 : n
with APM-user information:

Originating Address length Originating Address Destination Address length Destination Address Encapsulated Application Information
With : the Application Information field shall be empty, i.e. NO Encapsulated Application Information (greyshaded fields are not sent) The ATII (SNI & RCI bits of octet 2 of figure above) will be set to "release call" and "do not send notification" (cf Q.765 subclause 10.2.3). Encoding of Application transport instruction indicators bit 1 Release call indicator (RCI) 0 do not release call 1 release call bit 2 Send notification indicator (SNI) 0 do not send notification 1 send notification the originating address field and the destination address field will contain the destination address and the originating address, respectively, received in the segments currently under reassembly.
Since this acknowledgement is not segmented, APM segmentation indicator shall be set to '0' (last segment), SI to 1, and Segmentation Local Reference shall be absent, cf Q.765 subclause 10.2.1: The APM Segmentation indicator is set to zero (0), the Sequence Indicator field is coded "new sequence" and the Segmentation Local Reference is absent, unless segmentation procedures apply (see 10.2.4).
EDITION
08
RELEASED
En
23/149
When acting as a PIN (sending node), the WCS does not need to arm a new timer to monitor the receipt of the acknowledgement. The timer T7 is sufficient to tear down the call if no acknowledgement were received. The WCS shall release the call with the error cause 111 (Protocol error, unspecified) if any other message than the awaited acknowledgement is received, e.g. if ACM is received before the acknowledgment message.
ID::RDS11777:R004; APM segmentation procedure Segment formats
As per ITU Q.765 subclause 10.2.4.1: The Encapsulated Application Information field in the first segment shall begin with the first octet of the application Information and sequentially fill the Encapsulated Application Information field. (Alternatively the first segment may contain zero octets of Application Information, and the second segment is filled as described.) The Sequence Indicator field will be set to indicate "new sequence", the APM segmentation indicator field will indicate the number of segments that remain to be sent and a Segmentation Local Reference value included that is unique to the call. Any of the approaches specified in this subclause are authorized. I.e. the WCS may systematically send a first segmentation with zero octets of Application Information and the second segment filled as above, if simpler from design perspective. The WCS shall support the reception of an IAM message with a first APM segment with whatever size of Application Information (zero octets or non-zero octets of Encaspulated Application Information). When nonzero info is received, the WCS shall combine these bytes with the bytes further received in the subsequent BAT ASE APM segment.
ID::RDS11777:R005; APM segmentation procedure Error during re-assembly of BAT ASE APM segments
ITU-T Q.765 requires that during the process of re-assembly, if the re-assembly timer (cf table 30/Q.765) expires or an out of sequence segment arrives, an error notification shall be sent backwards to the PIN if notification has been requested in the Send Notification Indicator in the received APM. The re-assembly process shall be stopped and the call released. To simplify the design of the feature, the WCS will, in the error scenarios quoted above, immediately release the call w/o sending an error notification, even if such a notification was requested in the Send Notification Indicator in the received APM. The error cause '111' (Protocol error, unspecified) shall be sent in the release message.
ID::RDS11777:R006; Receipt of APM segments with unknown Application Context Identifier
1/ As per Q.765 section 10.2.4.2 Procedure for reassembly Each segment is therefore directed towards a specific reassembly function according to the Application Context Identifier, the originating address and the Segmentation Local reference it contains. To simplify the design of the feature, the WCS does only need to consider the CIC + the Application Context Identifier for segments re-assembly. I.e. the originating address and the Segmentation Local reference will be ignored. 2/ Upon reception of a segment with an unknown Application Context Identifier (ACI), the WCS shall either release the call or simply discard the segment, according to the Application Transport Instruction Indicators (ATII) field received in the APM segment. The WCS shall return or not an error notification according to the instructions received from the PIN. NOTE4: When an IAM message is received with an APM segment with an unknown ACI, and with associated ATII indicating to simply discard the segment, only the APM segment within the IAM is discarded, i.e. the IAM message is not dropped. The same applies when an APM message contains an APM segment with an unknown ACI. NOTE5: When the ATII instructs to release the call, it is not mandated to send an error notification before releasing the call, even if this was required by the PIN.
EDITION
08
RELEASED
En
24/149
NOTE6: No acknowledgment is sent for an APM segment being received with an unknown ACI (as per Q.765 spec). This is not expected to cause any particular issue. If the unknown APM segment is not segmented, the PIN does not wait for an acknowledgment. If it is segmented, it can be assumed that the PIN can take notice of the error notification to abort sending subsequent APM segments, this w/o breaking the call (otherwise it would have set ATII to 'release call'). NOTE7: When a segmented APM with unknown ACI is dropped (call not released), the WCS shall not wait for further segments of this APM-user to deliver the IAM + APM to the call control application.
ID::RDS11777:R007; APM segmentation procedure Notification of errors
As a PIN, the WCS shall never request receiving notification of errors occurring at remote PAN, by setting the Send Notification Indicator in the sent APM to 'do not send notification'. As a PAN, the WCS shall support sending of error notification, in the conditions specified in preceding requirements. Format of Error Notification message : The notification message is an APM message containing an Application Transport parameter set as follows (Q.765):
8 ext. ext. ext. 1 ext. MSB SI Spare SNI APM segmentation indicator Segmentation local reference APM-user information RCI 7 6 5 4 3 2 1 LSB 1 1a 2 3 3a 4 : n
Application context identifier = EUCEH ASE
with APM-user information

Originating Address length Originating Address Destination Address length Destination Address Encapsulated Application Information
With : application context identifier set to "Enhanced Unidentified Context and Error Handling ASE" The ATII (SNI & RCI bits of octet 2 of figure above) will be set to "release call" and "do not send notification"
The Application Transport Notification information is carried within the Encapsulated Application Information field of the Application Transport Parameter (APP). Each Notification parameter within the Application Transport Notification Information field consists of the APM-user Context Identifier and the Reason of the error.
8 ext. 1 ext. 1 7 6 5 4 3 2 1 Octets 1 2
APM-user Context Identifier = Ctx Id received in incoming APM segment Reason
a)
Extension indicators 0 Further octet exists 1 Last octet
EDITION
08
RELEASED
En
25/149
b)
APM-user Context Identifier 0 No Information 1-16383 Refer to "Application Context Identifier" field in the Application Transport Parameter [3]. c) Reason 0 No Information 1 Unidentified Context/Addressing Error 2 Reassembly Error 3-127 Spare 2.2.4 Recommended IP bearer setup procedure
The fast setup procedure is the procedure involving the minimal signalling exchanges on Mc and Nc interface and which is the fastest. So this is the recommended procedure to be used (for both BICC VoIP and 3GIP).. When this procedure is used, the following additional recommendations also apply, depending on the transport used for the BICC trunk: 1/ MTP3 transport only : APM segmentation should be enabled; 2/ M3UA transport only : APM segmentation should be disabled (i.e. large non-segmented BICC msg sent over M3UA) if M3UA transport is used E2E towards peer switch & peer switch supports large BICC (non-segmented) msg; APM segmentation should be enabled if a M3UA to MTP3 conversion occurs along the signalling path downstreams or if peer switch does not support large BICC (non segmented) msg.
3/ MTP3/M3UA cohabitation : same recommendations as for MTP3 transport, in all cases (whether primary route is MTP3 or M3UA). BICC Fast Forward/Backward should be discouraged (or at least used with great care) if APM segmentation is not supported by peer switch & APM segmentation should be enabled as per preceding recommendations. In this case, delayed backward or delayed forward should be used. The delayed backward procedure has the advantage to minimize the number of signalling exchanges and should be faster than the delayed forward. NOTE: The BICC Fast setup procedure can not be used to establish a VoIP bearer with IPBCP in case the codec to be used for the call can not be determined at the very beginning by the originating MSC-S (unless the terminating MGW supports the possibility to receive different codecs from the peer MGW (in IPBCP Request message) and from its local MSC Server, and if the codec configured locally prevails). Since only G.711 is supported on BICC VoIP, Fast setup can be used w/o any particular problem.
2.2.5
Nb Framing protocol initialisation (3GIP bearer)
After successful completion of the IPBCP bearer establishment procedure, MGWs shall initialize the 3GUP protocol in case of 3GIP bearers before the bearer can be ready for use. See section 2.7.1. 2.2.6 Bearer establishment notifications
The MSC-S may request the MGW to report a BEarer Established (BEE) notification (see TRS H.248 [11]) on any VoIP or 3GIP termination. In such case, the MGW shall send a BEE event to the MSC-S upon successful completion of the IPBCP bearer establishment procedure for a VoIP termination (i.e. after receiving or sending a positive IPBCP response), or upon successful completion of the 3GUP protocol initialisation for a 3GIP termination (i.e. after receiving or sending a positive Nb FP Initialisation Acknowledgement message). In the current release, the 5060 WCS does never request BEE notifications for VoIP terminations, and always request BEE notifications for 3GIP terminations. See section 2.6.4.
EDITION
08
RELEASED
En
26/149
The MSC-S may also request the MGW to report BEarer Released (BER) notification (see TRS H.248 [11]) for unsuccessful bearer establishment. The WCS does never request BER notifications. 2.2.7 IP bearer release
There is no IPBCP message exchanged between MGWs to release an IP bearer. When wishing to release an IP bearer, the MSC-S simply requests the MGW to release the associated IP termination. The MGW then discards any packet arriving at the (RTP, RTCP) ports pair used for the old bearer until it sets up a new bearer on this IP address/port.
2.3 AAL2 bearer establishmentmodification & release on Iucs interface

ALCAP (based on Q.2630.2) is used as the protocol for dynamically setup and release AAL-2 connections between the RNC and the MSC. The ALCAP protocol is normally terminated in the MGW (e.g. 7570 MGW, 754x MGW with VMGW configured). However, for 7540/7549 MGW, it is terminated in the 5060 WCS instead if w/o VMGW configured. The latter case is not further described in the TRS. 2.3.1
AAL2 bearer establishment
Both UTRAN and MSC are taking part in the establishment of AAL2 connection.
RNC
MSC-S
MGW
ADD $ (codec,3GUP, [BEE event]) [PBE] 1 Add Reply Ta (BIWF@, BNC-Id) RAB Assignment Request (BNCid,BIWFad,RAB parameters) 2 ESTABLISH REQUEST (BNC-Id) 3 ESTABLISH CONFIRM 4 Iu FP Initialisation Request 5 Iu FP Initialisation Acknowledgement 6 RAB Assignment Response
7
NOTIFY Ta [BEE] 8 NOTIFY Reply Ta
Figure 9 Successful AAL2 bearer establishment (Iucs interface) 1. Prepare Bearer procedure The MSC-S starts by requiring the MGW to prepare the establishment of an AAL2 connection, using the H.248 Prepare BEarer (PBE) logical procedure (see TRS H.248 ) ; the MSC-S indicates the type of Iu bearer (support or transparent mode), the codec for speech or multimedia calls, the type of service (e.g. CSD call), and whether it requests or not to be notified when the Iu bearer is successfully established. The MGW returns in the response : a BIWF address (E164 NSAP address) used by the RNC to route the ALCAP AAL2 connection establishment request to the destination MGW, and a BNC identity which allows the MGW to correlate the subsequent ALCAP AAL2 connection establishment request with the resources already prepared in the MGW for the call (e.g. the associated H.248 termination). EDITION 08 RELEASED En 27/149
The 5060 WCS does never request the MGW to report a Bearer Established notification on a Iucs termination, neither for 3G originating or 3G terminating calls. 2. RAB Assignment Request The MSC-S then requests the RNC to establish the radio bearer. The MSC-S provides the RAB parameters which define the SDU format combinations according to the codec type / active codec set selected for the call. The NAS Synchronisation Indicator is also set to indicate to the UE the codec to be used for the call. The BIWF address and BNC Id retrieved precedingly from the MGW are also sent in the request to allow the establishment of the AAL2 connection. 3. AAL2 connection establishment request The RNC is responsible for initiating the AAL2 connection establishment upon receipt of an Iu radio access bearer service request. It shall select in particular a Virtual Circuit to be used for the particular RAB. The RNC selects a route in accordance with the BIWF address received, and selects an AAL2 path within that route which is able to accomodate the new connection. On the selected outgoing AAL2 path, the RNC allocates a Channel Identifier (CID) and other resources (e.g. indicated by link characteristics or SSCS information). It then sends an ESTABLISH REQUEST (ERQ) message to the MGW, providing in particular : the destination AAL2 Service Endpoint Address; this information is used to route the AAL type 2 connection via the AAL type 2 network to its destination endpoint. the Connexion Element Identifier (CEID), which is the concatenation of an an AAL2 path identifier (VC) and a AAL2 channel identifier (CID) the binding reference identifying the bearer network connection (BNCid), received from the MSC Server the Link characteristics
4. AAL2 connection establishment response Upon receipt of an ESTABLISH REQUEST message, the terminating checks the availability of the CID value and other resources (e.g. as indicated by link characteristics or SSCS information) in the incoming AAL2 path. If the CID and the other resources are available for the new connection, they are allocated to the new connection and then the AAL type 2 service endpoint address is examined. If the nodal function determines that the destination AAL type 2 service endpoint has been reached, the terminating MGW completes the AA2 connection establishment by sending an ESTABLISH CONFIRM (ECF) message. 5. Iu FP initialization After successful completion of the AAL2 connection, the RNC is responsible for initializing the Iu Framing Protocol towards the RNC if Iu support mode was requested by the MSC-S. See section 2.7.1.1. 6. RAB Assignment Response After successful setup of the Iu bearer (and after successful initialisation of the Iu Framing Protocol), and successful setup of the radio bearer, the RNC returns a RAB Assignment Response message. 7. Bearer Established notification Upon successful setup of the Iu bearer, the MGW shall send a BEarer Established notification to the MSCS, if requested to do so precedingly. Alternatively, the terminating MGW may return a RELEASE CONFIRM message if the AAL2 connection establishment request can not be accepted (e.g. CID already used).
RNC ESTABLISH REQUEST 1 RELEASE CONFIRM 2
MGW
Figure 10 Unsuccessful AAL2 bearer establishment (Iucs interface)
EDITION
08
RELEASED
En
28/149
2.3.2
AAL2 bearer modification
ALL2 bearer can be modified through ALCAP MODIFY command. For WCS supported ALL2 bearer modification scenario, please see detail of Section 2.6.6 RAB Modifiation.
2.3.3
AAL2 bearer release
The RNC is also responsible for initiating the release of AAL2 connections. In abnormal cases, the MSC may also initiate release of AAL2 connections.
RNC RELEASE REQUEST 1 RELEASE CONFIRM 2
MGW
Figure 11 AAL2 bearer release (Iucs interface) 1. The RNC releases the AAL2 connection by sending a RELEASE REQUEST primitive including the cause of the release. 2. Upon receipt of the RELEASE REQUEST message, the MGW frees the AAL2 resource that was allocated and sends back a RELEASE CONFIRM message.
2.4 IP bearer establishment & release on Iucs interface (RDS 8242)

2.4.1 Introduction
The WCS supports Iu-cs over IP, as per the following main characteristics: IPv4 only; At Control plane (M3UA) and User Plane (RTP/UDP/IP); 7540 & 7549 MGWs, Gigabit Ethernet physical interface only (no PPP, no HDLC framing); cohabitation of Iu over ATM and Iu over IP for different RNCs; migration from Iu over ATM to Iu over IP transport with minimum outage (control plane and user plane can be switched to IP transport independently from each other, transient cohabitation of ATM and IP transport during user plane migration); ATM and IP transports cohabitation for a same RNC beyond migration is not supported; Multiple IP Realms : i.e. capability for the MSC to allocate IuoIP terminations within a specific IP Realm, not necessarily the same IP Realm as for Nb, IMS, external SIP network. No new development. RTCP is enabled by default, and can be enabled/disabled by provisioning. migration procedures are supported to migrate an existing RNC from Iu over ATM transport to Iu over IP transport, with a very short outage. They enable the control plane and user plane to be switched from ATM to IP independently, i.e. allow IP control plane (RANAP and ALCAP over M3UA) with ATM user plane.
The WCS supports RANAP over M3UA transport in IPSP mode. See TRS [19]. The WCS indicates to the RNC and to the MGW, on a per call basis, which type of transport it requests to setup. As soon as Iu-cs over IP traffic is enabled by the operator for a particular RNC, all subsequent calls are established with the IP transport only. The WCS rejects the call establishment request (or the handover attempt) 3BL 61719 AAAA PBZZA EDITION 08 RELEASED En 29/149
if no resource for the selected transport can be successfully reserved. Provisioning, transport selection and MGW selection principles are further specified in TRS Routing mechanisms & scenario [29]. An IuoIP termination shall be reserved in the MGW before sending the radio bearer establishment message (for an IuoAAL2 call with ALCAP in the WCS, the IuoAAL2 termination is reserved during the radio bearer establishment procedure). As a result, if a directed retry or signalling handover occurs which require to select an alternative originating MGW, the WCS shall subtract the IuoIP termination in the original MGW and consider the new originating MGW as the anchor MGW for the call. 2.4.2 IuoIP bearer establishment
ALCAP is no longer used for Iu-cs over IP transport. RANAP signaling is used to establish, modify (when will be supported) and release RTP sessions. The IP address is exchanged as a NSAP address in the Transport Layer Address IE (see 3GPP TS 25.413 [54] and TS 25.414 [55] subclause 5.1.3.1). The IANA ICP IDI format of the NSAP addressing format as specified in X.213 [69] shall be used, and the IPv4 format recommended by X.213 shall be adopted (see 3GPP TS 29.232 [48] subclause C.16).
IE/Group Name Presence Range IE type and reference Semantics description
Transport Layer Address
BIT STRING (1..160, )
The Radio Network Layer is not supposed to interpret the address information. It should pass it to the transport layer for interpretation. For details on the Transport Layer Address, see [69].
The UDP port is exchanged within the Binding ID of the Iu Transport Association IE (see 3GPP TS 25.413 [54]).
IE/Group Name Choice Iu Transport Association Presence Range IE type and reference Semantics description
>GTP TEID >Binding ID
OCTET STRING (4) OCTET STRING (4)
If the Binding ID includes an UDP port, the UDP port is included in octet 1 and 2. The first octet of the UDP port field shall be included in the first octet of the Binding ID.
The WCS shall generate the NSAP address from the raw IPv4 address it retrieves from the MGW. During the establishment of a 3G call with Iu over IP transport, the WCS provides the source IP@/UDP port allocated by the MGW within the RANAP RAB ASSIGNMENT REQUEST; retrieves the remote IP@/UDP port allocated by the RNC within the RANAP RAB ASSIGNMENT RESPONSE.
Similarly, the MSC-S provides the source IP@/UDP port within the RANAP RELOCATION REQUEST and retrieves the remote IP@/UDP port allocated by the target RNC within the RANAP RELOCATION RESPONSE. As per 3GPP TS 25.414 [55], a dynamic Payload Type shall be used (values in the Range between 96 and 127 shall be used). The value can however not be exchanged through RANAP, and shall be ignored in the receiving MGW. The WCS establishes 3G calls as per the following call flow. 3BL 61719 AAAA PBZZA EDITION 08 RELEASED En 30/149
RNC
MSC-S
MGW
1
ADD $ (codec,3GUP, [BEE event]) Prepare IuoIP Transport] ADD Reply Ta (IP@/UDPport) RAB ASSIGNMENT REQUEST (source IP@/UDPport)
2
Iu FP Initialisation Request
Iu FP Initialisation Acknowledgement RAB Assignment Response (remote IP@/UDPport)

4
MOD Ta (remote IP@/UDPport) Modify IuoIP Transport] MOD Reply Ta NOTIFY Ta [BEE]
6
NOTIFY Reply Ta
1. Prepare IuoIP Transport procedure The MSC-S starts by requiring the MGW to prepare the establishment of an RTP connection point, using the Prepare IuoIP Transport logical procedure ; the MSC-S indicates the type of Iu bearer (support or transparent mode), the codec for speech or multimedia calls, the type of service (e.g. CSD call). The MGW returns in the response the IP address / UDP port locally reserved in the MGW. 2. RAB Assignment Request The MSC-S then requests the RNC to establish the radio bearer. The MSC-S provides the RAB parameters which define the SDU format combinations according to the codec type / active codec set selected for the call. The NAS Synchronisation Indicator is also set to indicate to the UE the codec to be used for the call. The IP address/UDP port retrieved precedingly from the MGW are also sent in the request within the Transport Layer Address and Iu Transport Association IEs. The RNC derives the type of transport (IP or ATM, and IP version when IP transport) within the NSAP contained in the Transport Layer Address IE. 3. Iu FP initialization The RNC initializes the Iu Framing Protocol towards the RNC if Iu support mode was requested by the MSC-S. The MGW sends the IuFP Initialisation Acknowledgement to the source IP@/UDP port of the RTP packet containing the IuFP Request. 4. RAB Assignment Response Before reporting the successful outcome of a specific RAB to establish, the RNC shall have executed the initialisation of the user plane, if necessary. The RNC then returns a RAB Assignment Response message with its own IP@/UDP port. 5. Modify IuoIP Transport procedure In IuFP transparent mode only, the MSC-S forwards the RNC IP address/UDP port number to the MGW using the procedure Modify IuoIP Transport procedure. 6. Bearer Established notification Upon successful setup of the Iu bearer, the MGW shall send a BEarer Established notification to the MSC-S (always sent for IP termination by the 754x MGW).
EDITION
08
RELEASED
En
31/149
NOTE: In IuoIP transparent mode, receipt of a RAB Assignment Response from the RNC does not guarantee that the RTP bearer is successfully setup between the MSC and the RNC. This is different to IuoATM.
2.4.3
IuoIP bearer release
No explicit signaling exists to release an RTP bearer. The MSC-S and RNC releases locally the RTP bearer when the associated RAB is being released. Example call flow to release a 3G call with Iu-cs over IP as per the following call flow.
MS RNC
1
MSC-S
MGW
GMSC
DISCONNECT RELEASE
3
RELEASE RELEASE COMPLETE Iu RELEASE COMMAND

4
Iu RELEASE COMPLETE SUBTRACT Ta [RTE] 5 SUBTRACT Reply Ta RELEASE COMPLETE SUBTRACT Tb [RTE] SUBTRACT Reply Tb
6
Compared to an IuoAAL2 bearer release, there is no ALCAP RELEASE Request/Confirm exchange for IuoIP and the SUBTRACT Reply contains the QoS metrics computed by the MGW.
2.5 IP bearer establishment & release on A interface (RDS 13186/13186a, RDS10893a, RDS16018)
2.5.1 Introduction
RDS13186b/RDS10893a specifies the WCS requirements to support A over IP (signaling & user plane) for commercial deployments. This covers in particular: at Control plane (M3UA) and User Plane (RTP/UDP/IP); RTCP is enabled by default, and can be enabled/disabled by provisioning; 7540 & 7549 MGWs, Gigabit Ethernet physical interface only (no PPP, no HDLC framing); Full-IP and PCMoIP architecture : As soon as IP transport is enabled for a BSS, the WCS only allocates IP bearers to all subsequent calls. TDM and IP transports may only transiently co-exist during a migration from TDM to IP transports. AoIP supported for all legacy GSM codecs Full compliance to 3GPP Rel-8 standard Support on AoIP of all the features, services & bearer types (speech, CSD) supported on AoTDM, including lawful interception of AoIP terminations All handover scenarios : intra BSC handover to a compatible or incompatible codec configuration, inter BSC or MSC handovers. For the first case, only IP to IP is in scope. End to end codec negotiation & TFO algorithms adaptations New pegs
EDITION
08
RELEASED
En
32/149
IPv4 only Multiple IP Realms : i.e. capability for the MSC to allocate AoIP terminations within a specific IP Realm, not necessarily the same IP Realm as for Nb, IMS, UMA, external SIP network. No new development.
The 754x MGW impacts are specified in RDS10999.
The WCS does not support the following features for AoIP: 1. Mixed IP/TDM BSS architecture, TDM/IP co-existing for one BSS. 2. GSM HR and GSM FR codecs in the packet backbone (3GIP and VoIP bearers, Inter-MSC or InterMGW). 3. Transcoder equipment removal (TrFO) between A interface over IP and packet backbone Feature transparent to the WCS. 4. However RDS 10893a assumes transcoding less call in the MGW (i.e. no intermediate G711 transcoding) between an AoIP and any peer termination (whatever type, e.g. AoIP, NbIP) if the same codec cfg is set at either side. The corresponding MGW developments are covered by RDS 10999. 5. AMR multi-rate configuration in the packet backbone (covered by RDS 6998) 6. RTP bearers multiplexing and RTP header compression on A interface over IP. 7. Late Channel assignment. 8. IPV6 (RFC 2460 and RFC 4443)
The WCS supports BSSAP over M3UA transport in IPSP mode. See TRS [19]. The WCS indicates to the BSC and to the MGW, on a per call basis, which type of transport it requests to setup. As soon as AoIP traffic is enabled by the operator for a particular BSC, all subsequent calls are established with the IP transport only. The WCS rejects the call establishment request if no resource for the selected transport can be successfully reserved. Provisioning, transport selection and MGW selection principles are further specified in TRS Routing mechanisms & scenario [29]. An AoIP termination shall be reserved in the MGW before sending the radio bearer establishment message. 2.5.2 AoIP bearer establishment
BSSAP signaling is used to establish and release RTP sessions. The BSS and MGW exchanges their IP address / UDP port in the AoIP Transport Layer Address IE (see 3GPP TS 48.008 [60]). During the establishment of a 2G call with A over IP transport, the WCS provides the source IP@/UDP port allocated by the MGW within the BSSAP ASSIGNMENT REQUEST msg; retrieves the remote IP@/UDP port allocated by the BSC within the BSSAP ASSIGNMENT COMPLETE msg.
As per 3GPP TS 48.103 [61], specific dynamic Payload Type defined by 3GPP shall be used. The value can is not exchanged through BSSAP but derived from the codec negotiated on the AoIP bearer. The WCS establishes 2G calls as per the following call flow.
EDITION
08
RELEASED
En
33/149
BSS
MSC
ADD.Request (T$)
MGW
ADD.Reply (T1, MGW IP@ / UDP port, preferred codec Assignment Request ( Container IE (IP Transport Layer InformationMGW, Codec List (MSC preferred)) Assignment Complete ( Container IE (IP Transport Layer InformationBSC, Speech Codec (Chosen)) MOD.Request (T1, BSC IP@ / UDP port, [selected codec] MOD.Reply (T1) Reserve RTP Connection Point
Configure RTP Connection Point User Plane is available for traffic, RTP and RTCP signaling can start
1. Reservation of AoIP connection point in the MGW The WCS sends an ADD.REQuest to the MGW to prepare for the IP Transport Layer using procedure Reserve RTP connection point (RRTP), providing the MSC preferred codec for the AoIP call together with its corresponding fixed payload type defined by 3GPP. The MGW establishes the connection end point. The IP address and the UDP port number of the connection end point are passed inside the AVD Rx Descriptor back to the WCS. 2. Assignment Request The MSC include the IP address and the UDP port number in the new AoIP Transport Layer Address to the BSS using an enhanced BSSMAP Assignment Request message. The BSS performs channel assignment. As part of the assignment procedure the Transport Layer information of the local connection end point inside BSS is put into another AoIP Transport Layer Address, which is sent back to the MSC within the BSSMAP Assignment Complete message. 3. Configuration of the AoIP connection point in the MGW The MSC forwards the received IP address and the UDP port number of the BSS connection end point to the MGW using the existing procedure MODify IP Transport Address and the procedure Configure RTP connection point (CRTP). The MSC also downloads the the codec finally selected on the termination together with its corresponding fixed payload type defined by 3GPP, if it differs from the MSC preferred codec configured during the "Reserve RTP Connection Point" procedure. 2.5.3 AoIP bearer release
No explicit signaling exists to release an RTP bearer. The MSC-S and BSC release locally the RTP bearer when the associated bearer is being released. 2.5.4 AoIP trunk support for octet-aligned RTP packets per RFC 4867 (RDS16018)
2.5.4.1 Background of RDS16018 T-Mobile will be deploying end-user devices which connect to the 5060 WCS and 754x MGW via the Mavenir mTAS (its name mOne box in RDS 13186/13186a). The mTAS is connected to the WCS and MGW using SIGTRAN for signaling and AoIP for bearer (see RDS 13186/13186a for details). In RDS13186/RDS13186a, only G.711 is required at AoIP interface. In W5.1, RDS10893a is implemented as generic and complete AoIP RDS for all the market, which should be for mOne also.
EDITION
08
RELEASED
En
34/149
In 3GPP TS 26.102 section 10.2, for AMR, it is clearly indicated that the bandwidth efficient mode of RFC4867 shall be used on AoIP interface. But mTAS only support octet-aligned payload format since the end-user devices indicated only support octet-aligned payload format, so this RDS requires that octet-aligned payload format should also be supported on AoIP interface. To be noted that using octet-aligned mode on AoIP is a very specific case, which should only be used toward the Mavenir mTAS. For other cases, we shall still use bandwidth-efficient mode on AoIP interface.
2.5.4.2 Recall of Bandwidth-Efficient or Octet-Aligned Mode of AMR codec According to RFC 4867, section 3.8 Bandwidth-Efficient or Octet-Aligned Mode: For a given session, the payload format can be either bandwidth efficient or octet aligned, depending on the mode of operation that is established for the session via out-of-band means. In the octet-aligned format, all the fields in a payload, including payload header, table of contents entries, and speech frames themselves, are individually aligned to octet boundaries to make implementations efficient. In the bandwidth-efficient format, only the full payload is octet aligned, so fewer padding bits are added. Note, octet alignment of a field or payload means that the last octet is padded with zeroes in the least significant bits to fill the octet. Also note that this padding is separate from padding indicated by the P bit in the RTP header. Between the two operation modes, only the octet-aligned mode has the capability to use the robust sorting, interleaving, and frame CRC to make the speech transport more robust to packet loss and bit errors. 2.5.4.3 The impact of Mc interface AMR-NB (FR_AMR, HR_AMR) shall be encoded in SDP according to the MIME registration in IETF RFC 4867. If the octet-align mode of RFC 4867 is configured for BSS IP trunk group, the octet-align parameter shall be explicitly present in SDP. Absence of the octet-align parameter indicates bandwidth efficient mode. For detail Mc interface information, please refer to TRS EGCP interface principles & procedures (3HP20038AAAADSZZA). 2.5.4.4 Configuration Parameter per BSC trunk group AMR Payload Format is added to indicate which payload format will be used on A interface: bandwidth-efficient or octet-aligned mode. Bandwidth-efficient mode is set as default. It is a VoIP specific attributes of BSS trunk group, which should be present at WEM only if IP bearer is selected for the BSS trunk group and AoIP interface type is Full IP. This parameter is BSC level parameter, i.e. all BSC trunk groups under same BSC should have same payload format.
2.6 Call establishment

2.6.1 Call control protocols
The 5060 WCS supports the following call control protocols to establish calls in CSCN, PSTN, SIP network or IMS : ISUP / TUP for TDM bearers (with different ISUP variants) BICC-CS2 for VoIP and 3GIP bearers SIP for VoIP bearers
EDITION
08
RELEASED
En
35/149
SIP-I protocol is not supported in this release. 2.6.2 Pre-Paging (RDS 6068)
As an option configurable by the operator, the 5060 WCS may initiate pre-paging upon receipt of the MAP PROVIDE_ROAMING_NUMBER message from the HLR, as follows : If the called subscriber is free and does not have CFNRc, the WCS immediately starts the paging procedure. The WCS allocates and returns an MSRN only if a paging response is received ; otherwise, the WCS returns an error (cause="system failure"). Pre-paging is supported as per 3GPP TS 23.018 [45]. If the called subscriber is free and has CFNRc, or if the called subscriber is busy, the WCS directly allocates and returns an MSRN. If pre-paging is activated and if there is no IMSI in the VLR, the WCS initiates a restore data procedure first, and then proceeds as specified above.
Use of this option can increase the rate of successful terminating calls. Note The ReleaseResourceSupported IE is not included in SRI, and the MAP RELEASE_RESOURCES message is not sent from GMSC to VMSC. Note Pre-paging is not further described in the TRS. The call flows are represented without prepaging. 2.6.3 Codec negotiation
Unnecessary transcoding of speech significantly degrades quality and, therefore, cellular systems try to avoid it for mobile-to-mobile calls when both UEs and the network support a common codec type. Besides, the transmission of compressed information in the CN of the cellular network also offers the possibility of bandwidth savings. Therefore Out-of-Band Transcoder Control is applied to mobile-to-mobile calls but also to calls to or from an external network to enable the selection for the call of a codec configuration supported by all the affected nodes (UEs and (potential) transcoding points inside the network). This codec negotiation maximises the chances of operating in compressed mode end-to-end for mobile-to-mobile calls. 2.6.3.1 BICC codec negotiation The BICC codec negotiation is done prior to (or in parallel to) the establishment of inter-MSC bearer connections, so that appropriate bearer resources are committed to the call. The codec negotiation starts with the IAM message containing the list of supported codec types (in this example v, w, x, y, z), sent by the Originating MSC (O-MSC). Transit nodes may puncture out (i.e. delete) codec types from the list (in this example y). The terminating MSC (T-MSC) selects the codec type (here v) The selected codec is conveyed in an APM message, together with the remaining list of alternative, but currently not selected codec types (here v, x, z).
EDITION
08
RELEASED
En
36/149
O-MSC O-MGW
Transit Transit MGW T-MGW
T-MSC
Codec List (v, w, x, y, z) Codec List (v, w, x, z) Selected Codec = v Selected Codec = v, Available List (v, x, z, ) Selected Codec = v, Available List (v, x, z, ) Selected Codec = v Bearer Established Bearer Established Selected Codec = v
Codec negotiation and codec algorithms supported by the 5060 WCS are further described in TRS Codec Management [9]. The codec negotiation algorithm takes into account the radio coverage of the called MS/UE (e.g. to force UMTS_AMR2 in case of a 3G terminating call). This implies that the called MS/UE shall be paged before the terminating MSC-S seizes the Nb or Iucs termination. This also allows to retrieve the list of codecs supported by the called MS/UE. 2.6.3.2 Codec negotiation for IP Interconnect bearer (RDS 6569) Codec negotiation and algorithms supported by the 5060 WCS for VoIP/3GIP interconnect bearers are specified in TRS Codec Management [9]. The rest of this subclause only focuses on the corresponding call setup requirements.
ID::RDS6569:R14; Intra-MSC call or Inter-MSC ISUP calls with a VoIP or 3GIP Interconnect
The configuration of the selected codec on the VoIP or 3GIP Interconnect can only occur once the Intra-MSC codec negotiation has been performed between the originating and terminating half calls. This implies to delay the internal bearer set up till the internal codec negotiation determines the codec to be selected on the packet bearer. NOTE: This is required to minimize the amount of signaling on the Mc interface, to ensure that the NbFP layer of a 3GIP bearer is initialized with the right codec configuration, and to ensure that the IPBCP Request includes the selected media payload type in case of VoIP bearer.
EDITION
08
RELEASED
En
37/149
2 1 RAN Codec selection MSC-S 4 originating call DirectCodecListO Codec-T, ICON_Sel_codec terminating call
3 RAN Codec selection
UTRAN
RNC Codec-O
MG
Packet Interconnect
RNC MG Codec-T UTRAN
ICON_Sel_codec
Figure 12 Intra-MSC call with a VoIP/3GIP Interconnect Numbers given in the figure reflect the minimum ordering required in the call flows. The terminating RAB establishment shall not occur until the packet bearer is successfully setup with the codec selected for the Interconnect codec, see subclause 2.6.5.
1 RAN Codec selection originating call MSC-S 3
DCLo Codec-T, ICON_Sel_codec
terminating call
ISUP IAM COT
MSC-S
UTRAN
RNC Codec-O
MG
Packet Interconnect
TDM
MG
MG
ICON_Sel_codec
Figure 13 Outgoing Inter-MSC ISUP call with a VoIP/3GIP Interconnect The ISUP IAM message should be sent downstreams before the packet bearer is fully established with the selected codec, not to delay unnecessarily the call setup in the network (unless late IAM is required on the ISUP trunk group). In this case, the ISUP IAM message shall indicate to the succeeding node that a subsequent CONTINUITY message shall be awaited. Once the interconnect bearer is finally configured with the selected codec, a CONTINUITY message shall be sent downstreams. See subclause 2.6.5.
EDITION
08
RELEASED
En
38/149
RAN Codec selection
1 terminating call MSC-S 3 3
DCLo Codec-T, ICON_Sel_codec
originating call
ISUP
MSC-S
UTRAN
RNC Codec-T
MG
Packet Interconnect
TDM
MG
MG
ICON_Sel_codec
Figure 14 Incoming Inter-MSC ISUP call with a VoIP/3GIP Interconnect The terminating RAB establishment shall not occur until the packet bearer is successfully setup with the codec selected for the Interconnect codec and till receipt of a CONTINUITY message from upstreams if to be awaited as indicating in the received ISUP IAM message, see subclause 2.6.5.
ID::RDS6569:R16; Inter-MSC VoIP/3GIP with a VoIP or 3GIP Interconnect
For a BICC originating call also involving the setup of a VoIP/3GIP interconnect bearer, the WCS acting as originating MSC shall wait for the result of the BICC codec negotiation prior to setting up the interconnect bearer. As a consequence, the BICC IAM message shall indicate to the succeeding node that a subsequent CONTINUITY message shall be awaited. Once the interconnect bearer is finally configured with the selected codec, a CONTINUITY message shall be sent downstreams.
1 RAN Codec selection 2 Originating MSC-S 3 5 4 4 4 Sel_codec, ACL COT SCL MSC-S
UTRAN
RNC
MG Codec-O
Packet Interconnect
MG
Packet Interconnect
MG
ICON_ Sel_codec
Codec-T = BICC sel_codec
Figure 15 Outgoing Inter-MSC BICC call with a VoIP/3GIP Interconnect This allows the selection of a common codec on the Interconnect packet bearer and on the Inter-MSC packet bearer allowing TrFO (or TFO/TrFO) end to end. The requirements above also apply if the Interconnect trunk group and the BICC trunk group are of different nature, e.g. 3GIP Interconnect and VoIP BICC trunk group. Similar principles also apply to the case where a BICC originated call terminates in a MSC-T which needs to set up a packet interconnect, as shown below.
EDITION
08
RELEASED
En
39/149
RAN Codec selection
1 Terminating MSC-S 4
SCL MSC-S Sel_codec, ACL
Interco sel_codec
BICC sel_codec
UTRAN
RNC
RAN Sel_codec
MG
Packet Interconnect
MG
Packet Interconnect
MG
Terminating mode
Figure 16 Incoming Inter-MSC BICC call with a VoIP/3GIP Interconnect The terminating RAB establishment shall not occur until the packet bearer is successfully setup with the codec selected for the Interconnect codec (not represented here in the figure), and till receipt of a CONTINUITY message from upstreams if to be awaited as indicating in the received BICC IAM message, see subclause 2.6.5. 2.6.4 Early/late access bearer assignment (mobile originating call)
2.6.4.1 Access bearer assignment (mobile originating call) To operate with the same compressed codec end to end, the originating MSC-S should ideally establish 3G radio bearers that contain RAB parameters set according to the codec type and Available Codec Set negotiated end to end. OoBTC call scenarios specified in 3GPP TS 23.153 [47] hence assumes that the 3G radio bearer is established only once the end to end codec negotiation is completed. This is referred as late channel assignment. However, this increases the MSC-S complexity because some scenarios require that the radio bearer is established before the end to end codec negotiation is even started (e.g. need to send an announcement, interaction with CAMEL or IN services) this is further referred as early channel assignment. As long as a single 3G radio configuration can be set on the radio interface (i.e. typically UMTS-AMR2 12.2 kb/s), the early channel assignment procedure is sufficient for the establishment of a speech call. This is what is supported by the 5060 WCS, i.e. late channel assignment is not supported. RAB modification is supported for 3G access by RDS7256 with AMR-WB introducing. For 3G over ATM with ALCAP terminated in MGW, RAB modification is in the scope of RDS14221. Note Late channel assignment should be supported when more than one 3G radio codec configuration can be set-up in the radio and core network (e.g. UMTS-AMR2 12.2 or UMTSAMR2 multi-rate configuration, or WB-AMR). Alternatively it may also be envisaged to implement the early channel assignment followed by a possible RAB modification procedure if the codec negotiated end to end differs from the preferred codec initially configured in the originating RAN. In either case a continuity indication would then need to be sent in the first IAM, followed by a Continuity message once the end to end codec negotiation and radio bearer establishment or modification is complete). Note The SCUDIF feature also leads to the same problematic : end to end negotiation is required to negotiate either the multimedia codec or a speech codec. Either of the above solutions is also required to avoid releasing a multimedia call setup if the terminating end does not support multimedia capabilities. SCUDIF support will be addressed by RDS4018.
EDITION
08
RELEASED
En
40/149
2.6.4.2
Parallel outgoing call setup for reduced call setup time (RDS 11324)
To reduce the call setup time, the WCS acting as an originating MSC does not wait for the completion of the access bearer assignment before proceeding with the call setup. After sending the radio bearer assignment request to the originating BSC/RNC, the WCS immediately performs the following procedures: Translation, SendRoutingInfo procedure with the HLR (if GMSC function) & call routing; for an intra-MSC call: paging, setup/call confirmed procedures with the called party; (NOTE1) sending of outgoing ISUP IAM message if early IAM is supported by the succeeding ISUP network; (NOTE2) sending of outgoing BICC IAM message if it is a 3G originating call or 2G AoIP originating call; (NOTE3) for an outgoing ISUP call:
for an outgoing BICC call:
NOTE1: The radio bearer establishment at the terminating MSC is still delayed until the originating radio bearer and core network bearer, if any, is established. NOTE2: The call setup of a mobile originated call to ISUP is really shortened only if the downstream ISUP network supports early IAM. NOTE3: The WCS defers the sending of an outgoing BICC IAM message for a 2G AoTDM mobile originating call till the 2G radio bearer is established to attempt to negotiate the same 2G codec selected by the BSC within the BICC core network. The principles above do not apply for calls determined by the WCS as emergency calls before the access bearer assignmement. For those calls, the access bearer is established first before performing any of the procedures above. NOTE4: This is because certain BSCs today have a bug where if assignment and GLMC Location queries are done in parallel, they reject the Location procedures. This feature does not impact the codec negotiation principles and algorithms supported by the WCS (see TRS Codec Management [9]). The call flow for an intra-MSC call is depicted below.
EDITION
08
RELEASED
En
41/149
WCS
DTAP SETUP DTAP CALL PROCEEDING ASSIGNMENT REQ
Translation and Routing are started without waiting for MO Assignment Complete
TRANSLATION, SRI/ACK & ROUTING
MO ALCAP PROCEDURES (3G only) ASSIGNMENT COMPLETE
PAGING REQUEST
PAGING RESPONSE
DTAP SETUP CALL CONFIRMED ASSIGNMENT REQ MT ALCAP PROCEDURES Alcap Procedures and Assignment Complete could be done/received at any point in this duration. 3G only
ASSIGNMENT COMPLETE
Note: If timeout is received wating for Assignment Complete, the call will be released as per existing implementation
NOTE: ALCAP Procedure only applies to 3G IuoATM.
For a mobile originating call to ISUP, if the radio bearer assignment response has not been received after the translation & routing procedures have been run, the WCS either: sends immediately the outgoing IAM message with the continuity indicators set to 'cot on previous' if the downstream ISUP network supports early IAM, defers the sending of the outgoing IAM until the radio bearer establishment is complete.
otherwise (i.e. if the downstream ISUP network does not support early IAM)
If the radio bearer assignment response has been received before the translation & routing procedures have been run, the WCS sends the outgoing IAM message as per the normal requirements specified in subclause 2.6.5. 3BL 61719 AAAA PBZZA EDITION 08 RELEASED En 42/149
Similar requirements apply also for a 3G mobile originating call to BICC and 2G AoIP mobile originating call to BICC. In this case, the CONTINUITY message is always supported by the downstream BICC network. The call flow for a 3G mobile originating call and 2G AoIP mobile originating to BICC is depicted below.
WCS
DTAP DTAP CALL ASSIGNMENT REQ TRANSLATION, SRI/ACK & MO ALCAP PROCEDURES ASSIGNMENT COMPLETE
Translation and Routing are started without waiting for MO Assignment Complete
IAM
COT ACM/CPG
Alcap Procedures and Assignment Complete could be done/received at any point in this Note: If timeout is received wating for Assignment Complete, the call will be released as per existing
NOTE: ALCAP Procedure only applies to 3G IuoATM.
If the call involves a CAMEL interaction with ETC or R2U (O-CSI, N-CSI and T-CSI), the WCS defers the sending of the IAM message until the access bearer is successful established. If the WCS needs to play an announcement (e.g. routing failure, paging failure during intra-MSC call, CFU announcement), it waits for for the access bearer assignment completion, if not already done, before applying it. An announcement shall prevail over early RBT. 3BL 61719 AAAA PBZZA EDITION 08 RELEASED En 43/149
Interaction with call waiting : for an Intra-MSC call, the WCS defers the sending of the SETUP message until the upstream radio and core network bearer, if any, are setup. 2.6.5 Continuity handling
The radio bearer and IP network bearers may be established between successive Service Nodes independently of each others. During the setup of a call, the terminating switching node (e.g. MSC-S, PSTN switch) shall never alert the callee till all upstreams bearers from the calling to the callee are ready for use. Otherwise, the callee could pick up the call though not yet being able to communicate with the calling, charging would start, without even having the guarantee that the network will succeed in setting up all the bearers. This could results in clipping effects and legal complications. The end to end path continuity may not be ensured immediatly e.g. in the following situations : the originating MSC delays the establishment of the radio bearer towards the calling UE (late channel assignment), or the call involves BICC or interconnect packet bearers, and the bearers are not established at the time an IAM is sent downstreans, e.g. the corresponding MSC-S waits for the completion of the end to end codec negotiation to establish the bearer with the right codec ; a call by call continuity test is performed on an upstream ISUP circuit.
2.6.5.1 Early / Late IAM Some ISUP nodes in the network may not support the ISUP continuity procedures. To take this possibility into account, the 5060 WCS enables the configuration, on a per ISUP trunk group level, of whether the downstream node support the continuity procedure (early IAM) or not (late IAM).
ID::RDS10203:R0005; Early IAM
When sending an IAM to a downstream BICC node or ISUP node supporting early IAM, the WCS shall include a continuity indicator to indicate that a subsequent CONTINUITY message will follow (DC bits of the Nature of Connection IE shall be set to value 2 Continuity check performed on a previous circuit (ISUP) / COT to be expected (BICC)), if the end to end upstream path continuity (see 2.6.5.2) is not achieved at the time the IAM is sent (see section 2.6.5.2). When the end to end path upstream path continuity is then achieved, the WCS shall send a CONTINUITY message with the Continuity Indicators parameter set to "continuity".
ID::RDS10203:R0006; Late IAM
When sending an IAM to a downstream ISUP node only supporting late IAM, the WCS shall delay the sending of the downstream ISUP IAM messages till the end to end upstream path continuity is achieved. The IAM shall then indicate that no subsequent CONTINUITY message shall be awaited. 2.6.5.2 End to end upstream path continuity
ID::RDS10203:R0004; E2E upstream path continuity
The WCS shall consider that the end to end upstream path continuity is achieved when all of the following conditions are satisfied : if an incoming IAM was received indicating that the CONTINUITY message would follow, a CONTINUITY message with the Continuity Indicators parameter set to continuity has been received from the preceding node ; the upstream BICC bearer, if any, is ready for use, as specified in section 2.6.5.3 (i.e. relying on receipt of an APM(Connected) message or a BEarer Established notification from the local MGW, depending on the type of bearer establishment procedure and the type of bearers VoIP / 3GIP); TDM / VoIP / 3GIP interconnect bearers, if any, are successfully established and ready for use, as specified in section 2.6.5.4.
EDITION
08
RELEASED
En
44/149
2.6.5.3 Upstream BICC bearer establishment A BICC terminating node shall monitor when the upstream BICC bearer is ready for use. An upstream BICC bearer shall be considered as ready for use when : Either a BEarer Established (BEE) notification is received from its local MGW for the corresponding IP termination when an APM(Connected) message is not expected : forward bearer setup when no APM (Connected) notification is requested delayed backward bearer setup
Or (exclusive) an APM message with the Action indicator set to "Connected" is received from the preceding BICC node : forward bearer establishment when an APM (Connected) notification was requested fast backward bearer setup
A BICC originating node shall monitor when the downstream BICC bearer is ready for use, when requested to send an APM(Connected) message. The 5060 WCS implements the following principles : fast and delayed forward : BICC VoIP : the WCS acting as terminating MSC-S always requests the originating node to send a BICC APM (Connected) message the H.248 Bearer Established (BEE) event is never configured (never by originating nor terminating MSC-S) the WCS acting as terminating MSC-S does not request, by default, the originating node to send a BICC APM (Connected) message ; however, this is configurable via the system-wide parameter 'Nb_Notification_desired' (in System Parameters > Call Manager), default value : false. H.248 BEE event is systematically configured on both sides of the BICC bearer. The terminating MSC-S releases the call if the BEE event is not received. The originating MSC-S does not release the call if the BEE does never arrive.
BICC 3GIP :
Delayed backward : No BICC APM(Connected) exchanged, as per BICC protocol H.248 BEE event : same as for fast / delayed forward
Fast backward : The WCS acting as originating MSC-S does never send an APM(Connected) message, though required by the BICC protocol H.248 BEE event : same as for fast / delayed forward
the H.248 BEarer Released (BER) event is not supported (never configured, therefore never notified by MGW) could be used to be notified of bearer establishment failure. Note The current WCS implementation for VoIP bearer does not strictly comply to the BICC requirements : when acting as an originating BICC node, the WCS does not request BEE notification to its local MGW when having to send an APM(Connected) message ; When acting as a terminating BICC node, the WCS does not request BEE notification to its local MGW when no APM(Connected) is exchanged.
EDITION
08
RELEASED
En
45/149
Note The current WCS implementation for 3GIP bearer leads to systematically request BEE notification to the local MGW, even in cases where this is not required (e.g. originating BICC node without having to send an APM(Connected) message). Note For 3GIP bearers, when no APM(Connected) message is exchanged, there is still the risk that the Nb FP Initialisation Acknowledgement sent back by the terminating MGW is not received by the originating MGW. In such a case, the originating MGW will repeat the initialisation procedure (up to the maximum number of repetitions locally configured in the MGW). Use of an APM Connected message (in scenarios where this is possible) can allow to get the confirm that the Nb bearer establishment is successfully completed at both sides.
ID::RDS10203:R0007; Forcing a BICC bearer establishment
Upon receipt of an ISUP / BICC IAM message with a continuity indicator indicating that a subsequent CONTINUITY message shall be awaited, the WCS arms the T8 timer (10-15s range) to monitor receipt of the CONTINUITY message, as per ITU-T Q.764 and Q.1902.4. The time to setup a BICC bearer is typically much longer than the corresponding time for an ISUP bearer, because of a significantly greater number of signalling exchanges (e.g. to negotiate the codec and to exchange the IP@/UDP port between MGWs). In some scenarios, the time actually left available to establish the BICC bearer may become insufficient and may lead to the expiry of the T8 timer, and therefore the release of the call. E.g. this may be the case for a BICC-BICC call when the most downstream BICC node is a combo GMSC/VMSC where a non negligeable part of the T8 timer may be run during the SRI interrogation and the subsequent paging procedure, or in scenarios with late channel assignment at the originating side (in which time of T8 timer of the downstream node will be run during the radio bearer establishment at the originating RAN), or in call forwarding scenarios (e.g. CFNRy) towards another node. To ensure that the T8 timer does not expire, the WCS shall arm the timer Start_Bearer_Establishment_Timer upon receipt of an incoming BICC IAM message, and upon expiry of that timer, force the establishment of the upstream BICC bearer. In such a case, the codec negotiated for the upstream BICC bearer is decided based on the codec informations available at the WCS (early codec negotiation decision), e.g. the first codec received in the BICC-SCL and supported by the WCS is chosen. The Start_Bearer_Establishment_Timer shall be stopped when the WCS sends the first APM message backwards. The Start_Bearer_Establishment_Timer shall be configurable by the operator, on a per WCS-wide basis, and shall be set consistently with the BICC T8 timer and with the IPBCP T1 timer (Q.1970, range 1-30s). Range : 1-14 seconds Default values : - T8 : 14s - Start_Bearer_Establishment_Timer : 8s (MGW IPBCP timer should be set to 14s) Note The timer Start_Bearer_Establishment_Timer is started even for incoming IAM w/o the continuity indicator set to 'cot to be expected' though there is no T8 timer running in that case. This allows to limit the maximum time to setup the BICC bearer, for whatever incoming BICC IAM. Note The Start_Bearer_Establishment_Timer is also specified by 3GPP TS 23.205. However, the conditions to start or stop the timer differ from those specified above. In 3GPP TS 23.205, the timer is started in the terminating MSC Server only (not GMSC), for any incoming BICC call, when the paging procedure is started if the network side bearer establishment is delayed until paging is completed, and stopped when the paging procedure is completed or optionally when the Call Confirmed msg is received.
EDITION
08
RELEASED
En
46/149
Note The WCS currently arms a Bearer_Connection_Timer when starting the paging procedure, but the timer expiry leads to release the call. It shall be ensured that the default value of this timer is greater than 15s not to inhibit the forced BICC bearer establishment mechanism. Note Forcing the upstream bearer establishment for a BICC-BICC transit call may lead to apply transcoding at the intermediate node if the upstream and downstream BICC selected codecs differ.
2.6.5.4 TDM/VoIP/3GIP Interconnect bearer establishment

ID::RDS10203:R0001; Interconnect bearer establishment time, downstream ISUP/BICC call
When an interconnect bearer is required to be set up at an originating or intermediate MSC-S (e.g. transit MSC or call forwarding MSC), the WCS : Shall Establish the interconnect bearer before sending the IAM downstreams, if the downstream ISUP trunk group is configured with late IAM support ; May otherwise send an ISUP/BICC IAM downstreams either before establishing the interconnect bearer (not to increase the call setup duration), in which case it shall set the continuity indicators to 'cot on previous' in ISUP IAM or 'cot to be expected' in BICC IAM to indicate that a subsequent CONTINUITY message will follow, or after establishing the interconnect bearer, in which case it shall set or not the continuity indicators, as specified in section 2.6.5.1 (i.e. originating MSC-S will never need to send 'cot on previous' or 'cot to be expected', but intermediate MSC-S may still have to do it). Note For packet interconnects and downstreams BICC call, it is important to send the IAM downstreams before establishing the interconnect to allow selection of the best codec on the interconnect bearer, taking into account the codec negotiated on the BICC bearer. But this will be the object of a separate RDS.
ID::RDS10203:R0002; Interconnect bearer establishment time, terminating call
The WCS shall establish any interconnect bearer(s) before establishing the radio bearer of a terminating call. Packet interconnect bearers shall be established after the SETUP/CALL CONFIRM exchange to know the type of call negotiated (speech/data) and to get the list of UE codecs before selecting the codec on the interconnect bearer. This is illustrated below with the example of an incoming ISUP call, with a packet interconnect bearer. In that case, the WCS shall internally negotiate (1) the codecs to be set on the target RAN (if UTRAN) and packet interconnect, then establish the interconnect bearer (2) prior to establishing the terminating radio bearer (3).
radio bearer setup
1 MSC-S ISUP MSC-S
RAN
MG
packet Interconnect
TDM
MG
MG
EDITION
08
RELEASED
En
47/149
ID::RDS10203:R0003; Interconnect bearer establishment outcome
The WCS shall monitor whether and when a TDM / VoIP / 3GIP interconnect is successfully established and ready for use. For 3GIP interconnect bearer, this shall be done by requesting the MGW to report a BEarer Established (BEE) event when the bearer is ready for use, on the upstream termination of the bearer (with respect to the direction of the call setup). The WCS shall consider that the 3GIP bearer is successfully established and ready for use if the BEE event is received before expiry of an internal timer (e.g. 10s). For VoIP and TDM interconnect bearers, the WCS does not configure BEE events on the interconnect terminations. The WCS shall consider that the VoIP or TDM interconnect is successfully established and ready for use if both terminations of the interconnect are successfully seized (successful ADD) in the MGW, and if, for a VoIP bearer, they are successfully configured with the remote IP address (successful MOD). The WCS shall release the call if the interconnect bearer is not successfully established.
2.6.5.5 Additional MSC-S requirements 2.6.5.5.1 General requirements
ID::RDS10203:R0008; Continuity failure
The WCS shall release the call if any of the following conditions occurs : - if the timer monitoring the end to end path continuity expires, or - the T8 timer expires, or - if the WCS sent a downstream IAM with the continuity indicator set to 'cot on previous' or 'cot to be expected', and if it receives an ACM message before it has sent the CONTINUITY message downstreams. This corresponds to a protocol error since as per ITU-T Q.764 and Q.1902.4, the downstream node shall in that case withhold returning an ACM message till it receives the CONTINUITY message indicating that upstream continuity is achieved.
ID::RDS10203:R0012; ACM and tone/announcements
As long as the end to end upstream path continuity is not achieved, the WCS shall also delay : returning the ACM message playing a tone or an announcement backwards (on an upstream leg) ;
The MSC-S shall also delay the execution of an inter-MSC handover/relocation requiring a circuit connection between the anchor and the target MSC till the bearer between both MSCs is ready for use. See TRS Handover [1]. 2.6.5.5.2 Specific terminating MSC requirements
Upon receipt of an incoming ISUP IAM with 'cot' or 'cot on previous', the WCS suspends the processing of the mobile terminating call (VLR query, paging ) till receipt of a CONTINUITY message with the indication 'continuity', at which stage it resumes the terminating call procedure. Note This behaviour ensures that the terminating call can be delivered if an ISUP call re-attempt is performed as a result of a failure of a circuit continuity check test. For BICC-ISUP calls, the terminating MSC has no means to know whether the indication 'cot on previous' received in an incoming IAM is the result of a circuit continuity check procedure on an upstream ISUP leg or whether this is inferred by an upstream packet bearer (e.g. BICC) not yet established. This may therefore uselessly delay the setup of a BICC-ISUP call, but this still ensures that an ISUP call reattempt for an ISUP-ISUP call will succeed.
EDITION
08
RELEASED
En
48/149
Upon receipt of an incoming BICC IAM, with or w/o 'cot to be expected', the WCS proceeds with the terminating call procedure (VLR query, paging ). Note An ISUP call re-attempt that would be triggered for an ISUP-BICC call as a result of a circuit continuity check failure on the ISUP leg will fail at the terminating MSC since the call re-attempt will be handled like a new call, decorrelated from the first BICC IAM received. Since the MSRN is released by the WCS very quickly for a terminating call (before the paging procedure), the second BICC IAM will indicate an MSRN that would either have been released or, possibly worse, been reallocated to a new call in the extreme case where the MSRN would be re-allocated very quickly to a new call (MSRN pool shortly dimensioned). No specific development (like freezing the MSRN for a minimum idle time) is required at this stage since it is expected that this problem should nearly never happen (conditions : operator performs circuit continuity test during call setup, and ISUP-BICC call, and continuity test fails, and MSRN is very quickly reallocated in spite of most idle MSRN allocation principle run by WCS).
ID::RDS10203:R0009; E2E upstream path continuity before establishing the terminating radio bearer
The WCS shall delay the establishment of the terminating radio bearer for all mobile terminating calls till E2E upstream continuity is achieved as specified in section 2.6.5.2, including setup of local TDM / VoIP / 3GIP interconnect bearers, if any. This ensures that the callee is never alerted before the end to end path is ready for use.
ID::RDS10203:R0010; E2E upstream path continuity for incoming waiting call
For incoming waiting calls, the WCS shall delay the sending of the SETUP message to the called party till the E2E upstream continuity is achieved, including setup of local TDM / VoIP / 3GIP interconnect bearers, if any. This ensures that the callee will never accept the incoming waiting call before the end to end path is ready for use. Note For call waiting scenarios that would require a change of the media configured on the interconnect bearer after receipt of the Call Confirmed message, e.g. when multimedia waiting call is supported, the callee will be alerted about the new waiting call prior to the interconnect being reconfigured.
ID::RDS10203:R0011; Circuit Pool interaction with terminating call
When multiple MGWs are connected to a given BSS, the WCS will select a CIC resource on one MGW and, if necessary, establish an interconnect bearer towards this MGW, before sending the ASSIGNMENT REQUEST message to the BSS, as per the principles specified in this RDS. If the CIC provided by the MSC was compatible with the channel type indicated, but the BSS wishes to change the circuit pool, the BSS may return an ASSIGNMENT FAILURE message with the cause "switch circuit pool" and the "circuit pool list" information element. Upon receipt of such a message, the WCS shall try to select a CIC belonging to a pool among the "circuit pool list" located on the same MGW as the preceding CIC. If none is available on that MGW, the WCS shall release the call. I.e. it is not requested in the latter case that the WCS selects a CIC on another access MGW, release the interconnect bearer towards the initial MGW if necessary, and re-establish a new interconnect bearer towards the new MGW, if necessary. It is assumed that circuit pools will be uniformly mapped on the different access MGWs. In such case, it is not needed to try to re-establish the call using an alternative access MGW. 2.6.5.6 Example call flow As an example, the handling of end to end path continuity procedure is illustrated on the following 3G to 2G call scenario (early channel assignment).
EDITION
08
RELEASED
En
49/149
RNC A
MSC-S A
MGW A
GMSC-S
MGW G
MSC-S B
MGW B
BSC B
RAB Assignment procedure BICC_IAM (no cot) 1 BICC_IAM (cot) 2 Bearer Establishment & UP FP initialisation NOTIFY (BEarer Established) 3 CONTINUITY 4 Bearer Establishment & UP FP initialisation NOTIFY (BEarer Established) 5 synchro COT upstreams and NOTIFY (BEarer Established)
6
Assignment Command procedure Alerting 7 ACM 8 ACM backward bearer path ready for use
9
1. The originating MSC-SA establishes the RAB prior to sending the IAM message to the succeeding node. The BICC IAM indicates that no continuity message needs to be awaited by the succeeding node, since the upstream RAB has already been established. 2. As the upstream packet bearer is not yet established/operational (on-going end to end codec negotiation), the GMSC-S forwards the IAM message to the terminating MSC-SB indicating that a Continuity message shall be awaited by the succeeding node. 3. The MGWG notifies the GMSC-S that the upstream Nb bearer is established and operational (Nb FP has been successfully initialised). 4. Since no Continuity message needs to be received from upstream and since the upstream Nb bearer is established and operational, the GMSC-S sends a Continuity message downstreams. 5. The MGWB notifies the MSC-SB that the upstream Nb bearer is established and operational (Nb FP has been successfully initialised). 6. Since a Continuity message was announced in the IAM, the MSC-SB waits for the reception of the Continuity message from upstream and the Notification from the MGWB that the upstream bearer is established and operational, prior to establish the radio bearer towards the terminating BSCB. 7. MSC-SB returns an Address Complete message to the preceding node, here the GMSC-S, which itself propagates it to the preceding node, here MSC-SA. 8. The bearer path is backward through-connected. Ring back tones can start being sent. 2.6.6 RAB Modification (RDS7256, RDS14221)
WCS is able to send a second RAB assignment request to the RNC following the initial RAB assignment in order to modify the speech codec configured initially. Other types of modifications are not supported.
EDITION
08
RELEASED
En
50/149
The RAB modification procedure is supported for all following cases: Iu-CS over IP (RDS7256) Iu-CS over ATM With ALCAP in MGW (RDS14221) With ALCAP in WCS (RDS7256) In ATM case, due to modification of the bandwidth requirements inherent to a codec change, the ALCAP (in WCS and in MGW) shall be ready to process the Modify Request message, and positively acknowledge it unless any CAC check determines that there is not enough resource to accept the Modify request. In Iu-CS over IP and Iu-CS over ATM, the MGW shall support a second Iu-FP INIT procedure. When appropriate, Nb-FP initialization on Nb inter-MSC trunks or on intra-MSC Nb-FP interconnect trunks shall be done only with the RFCI advertised by the second Iu-FP INIT procedure.
RNC
UE access and security procedure Setup (..,UE codec list, .) Call proceeding
MSC
ALCAP in WCS or MGW shall be supported
RAB assignment request (, AMR2 subflows parameters, ..) ALCAP bearer estblishment Iu FP intialization RAB assignment response
Only parameters linked to codec characteristics nd change in the 2 RAB assig. Req.
RAB assig. req (,WB-AMR subflows parameters, ..). ALCAP bearer modification Iu FP new initialization RAB assignment response Alerting
Only in case of Iu o ATM
connect Connect ack

Call flow for RAB modification (WB to NB) The second RAB assignment, if required by the codec selected on T-side, is only attempted when the first RAB assignment response has been received. If the timeout period expires for the first RAB establishment, WCS currently takes the decision to release the call in such case, the second RAB establishment with new codec information is not attempted. If the first RAB establishment is good, but the second RAB establishment is failed, the call shall be continued using the original codec. 3BL 61719 AAAA PBZZA EDITION 08 RELEASED En 51/149
NOTE: There is a flag per RANAP Trunk Group, whether or not RNC support RAB modification. Interaction with RDS11324 Reduce Call setup time(MO assignment parallel with termination call): No impact identified with the following precision: The Continuity indicator (either external ISUP/BICC COT, or internal) shall be triggered as currently specified i.e. when the first RAB establishment response is received by the originating side.
2.6.7
MGW selection
When setting up a call, the 5060 WCS always selects the MGW prior to sending an IAM message downstreams. As an exception, when acting as a Call Mediation Node (CMN) see section 2.6.11, the 5060 WCS relays the call control signalling without seizing any local MGW resources. The MGW selection principles supported by the 5060 WCS are further described in the TRS [20] and [21]. 2.6.8 Optimized MGW selection
When Virtual MGW function applies, a physical MGW can be controlled by several Call Server, under this configuration, WCS supports optimized MGW selection function if Nc interface is BICC/SIP/SIP-I. The BICC procedures allow MSC-Servers, as an option, to exchange the identity of the MGW selected through BCUID (RDS13107:R001) to optimize the MGW selection at the other side, e.g. by preferentially trying to seize the same MGW (with the Virtual MGW concept). If WCS acts as the other side, it also supports optimized MGW selection upon MGW ID received (RDS13170:R003) except WCS acts as CMN. If Nc interface is SIP/SIP-I, MGW identity is transferred through MGW_Identifier in SDP offer (RDS13170:R002). Optimized MGW selection at the other side upon MGW ID received, is also supported (RDS13170:R003). This optimized MGW selection is also applied to CFx(RDS13170:R004) and Handover(RDS13170:R005). Optimized MGW selection, including MGW identity transfer and optimized MGW selection function, are controlled by a system flag and flag per Trunk group.
2.6.9
Connection model
The following conventions are used throughout the document.

RAN A Ta Tb Party B Topology between 2 terminations 2 way connected RAN A Ta Inactive 1 way connected isolated Stream mode of a termination SendReceive SendOnly ReceiveOnly
For two party calls, the 5060 WCS seizes a single context per call on each MGW of the MSC-S involved in the call, as examplified below. See the TRS features interactions (IP loop) [26] for a few exceptions. Inter-MGW call :
EDITION
08
RELEASED
En
52/149
MSS
RAN A Ta Party A Ta0 Tb0 Tb
RAN B
Party B
MG A
MG B
Intra-MGW call :
MSS
RAN A Ta Party A Ta0
RAN B
Party B
MG A
The same connection model is applied on the EGCP interface. 2.6.9.1 Bearer through-connection principles - Termination stream mode The 5060 WCS both-way through-connects the call only when the called party answers, as specified in 3GPP TS 23.153[47]. As a general principle, the downstream termination of H.248/EGCP context is always seized in Send&Receive mode, while the upstream termination is seized in SendOnly mode (downstream and upstream being relative to the direction of the call setup, stream mode given in this TRS according to the H.248 semantic). This setting allows the ring back tone applied at the terminating side to be passed backwards up to the calling party.
MSS B
MSS A
RAN B
SendOnly
S&R MG A
SendOnly
S&R MG B
Party B
As an exception, in W4.3x release, an upstream 2G and ISUP termination is seized initially with the EGCP 'Active' stream mode (equivalent to H.248 'inactive' stream mode) default setting, but may be seized alternatively with the EGCP stream mode 'Rec_Only' (equivalent to H.248 'SendOnly') configurable parameter Orig_Init_Path_Type. When seized initially to the EGCP 'Active' mode, the termination EGCP stream mode is changed to 'Rec_Only' upon receipt of the indication that the called party is being alerted or that inband informations are available. Upon reception of the signalling message indicating that the called party answered (ANM or Connect message), all terminations are set to Send&Receive mode, i.e. the call is both-way through-connected.
EDITION
08
RELEASED
En
53/149
This behaviour is applied for any type of call (mobile originating call, ISUP/BICC originating call. For intraMSC inter-MGW call, only the most upstream termination is set in SendOnly mode, as shown below. Consequently, one H.248/EGCP exchange is needed with only one MGW to both-way through-connect the call.
Originating MSC
MSC-S A
RAN A Ta Party A Party B Ta0 Tb0 Tb
SendOnly
S&R MG A
S&R
S&R MG B
2.6.10 TFO and Voice Quality Enhancement features Activation of VQE and TFO features is performed by the 5060 WCS as specified in [10] and [14]. The TFO activation order is always sent to the MGW after the call is answered (see [14]). TFO activation on upstream terminations is always done at the same time as through-connecting the corresponding termination (no extra command generated). TFO activation on downstream terminations is always performed via an additional H.248 MOD command. 2.6.11 Call Mediation Node (CMN) (RDS 5317) The 5060 WCS can be configured to behave as a National Call Mediation Node (CMN) within a 3GIP backbone. See ITU-T Q.1902.4 [63]. If so, the WCS acts as a transit MSC, but without involving any bearer control function / MGW for the calls. Only signalling is transited. Bearer set-up procedures and codec negotiation procedures are not applicable at a CMN - a CMN shall pass all bearer and codec related information element unchanged.
2.6.12 Early Audible Ringing (RDS14077, RDS14756) Under System prarameter/Call manager, there are two timers, two flags, and one Early Ringback Tone ID configurations related with Early Audible Ringing. Two Timers are GSM Early Alert timer, (ISUP) Early ACM timer which controls incoming ISUP/BICC/SIP/SIP-I. Two flags are: EarlyACMApplyTone which controls whether an Audible Tone is applied or not when early alerting triggered. WCS will play tone to calling party when Early Alert is triggered, and EarlyACMApplyTone is turned on, whatever the role WCS acts as. EmergencyCallApplyEAR which controls Emergence call audio ringing separately. When the flag is turned on, audible ringing will be played just after the air bearer to calling party is established, earlyAlertGSMTimer will not be started. When the flag is turned off, treat Emergence call same as normal call.
There are two choices for Early Ringback Tone: Default Ringback Tone(default), Call Progress Tone. For more details about Tone ID, please see TRS [25]. 3BL 61719 AAAA PBZZA EDITION 08 RELEASED En 54/149
Through D76342, Early Alert timer is also triggered for the second call when the first call is on hold.
2.7 3GPP Framing Protocol

The 3GPP User Plane (3GUP) protocol (also called 3GPP Framing Protocol 3G FP) is used to convey user data on 3GPP bearers. It is respectively declined in Iu Framing Protocol and Nb Framing Protocol on Iu and Nb interfaces, but Iu FP and Nb FP actually behave in the same manner. Two modes of operation are supported by the 3GUP protocol : the transparent mode (TrM), which is used for user data transfers which do not require any particular feature from the UP protocol ; one single version has been defined by 3GPP (version 1) ; the Support Mode for predefined SDU size (SMpSDU), intended for RAB which require particular features from UP. Both versions 1 & 2 defined by 3GPP are supported by the 5060 WCS and shall also be supported by the MGW.
The main procedures offered by the Support Mode are described hereafter (see [56] and [58] for a comprehensive description). 2.7.1 3GPP Framing protocol initialisation
2.7.1.1 Iu / Nb FP Initialisation procedure In UP Support Mode version 1, the initialisation procedure can only be initialised by the RNC ; in version 2, the procedure may be initialised by the RNC or the CN. The initialisation procedure controls the exchange of initialisation information, in particular the RAB sub-Flow Combination Indicator set (list of RFCIs and their respective SDU sizes) to be used until termination of the connection or until the next initialisation procedure. All requested RAB sub-Flow Combination SDU sizes shall be configured, except when version 1 of the user plane was included as an alternative in the RAB Assignment request ; in that case, the RNC is allowed to initialise just a subset of the requested RAB sub-Flow Combinations. The first RAB Sub-Flow Combination proposed in the list of RAB Sub-Flow Combinations corresponds to the maximum bit rate allowed to be used when starting the communication phase, until the first RATE CONTROL frame occurs. This procedure is also used for negotiating the version of the UP mode among the versions allowed by the MSC Server, as illustrated below. In this example, the initiator supports the UP mode versions 1 and 2 (the version in the header of the INITIALISATION control frame indicates version1), and the responder selects the version 2.
RNC / MGW
MGW /RNC
Initialisation (RFCIs,SDU sizes, init vers.= 1,supported vers.=(1,2) 1 Initialisation Ack (version = 2) 2
1. The initiating UP protocol entity indicates the UP mode version it uses for the initialisation (which shall be the lowest version supported that has enough information to initialise the highest proposed protocol version) as well as the UP mode versions it supports for the related RAB among the versions the CN requested for the related RAB. A supervision timer is started after sending the UP INITIALISATION control frame, supervising the reception of the INITIALISATION ACKNOWLEDGEMENT frame. The sending entity shall re-send the
EDITION
08
RELEASED
En
55/149
INITIALISATION frame a configurable number of times upon receipt of an INITIALISATION NEGATIVE ACKNOWLEDGEMENT control frame, an erroneous acknowledgement or at timer expiry. 2. Upon reception of the INITIALISATION frame, the receiving UP entity stores the RAB sub-Flow Combination set and chooses a UP version it supports which is among the set of required versions (received on the H.248 interface). Then it sends an INITIALISATION ACKNOWLEDGEMENT frame using the version of the UP mode that is chosen. If the receiver does not support the UP Mode version for the Initialisation procedure, it shall send a negative acknowledgement using the highest version it supports among the versions proposed by the sender. If none of the proposed versions are supported, the receiver shall respond with a negative acknowledgement using the highest version it supports. The initialisation procedure shall not be re-invoked by a RNC without a RAB modification requested by the MSC. When this procedure is invoked, all the other UP procedures are suspended until termination of the initialisation procedure. 2.7.1.2 MSC/RNC UP version negotiation
RNC
MSC-S
MGW
Add (RAN termination, UP versions) 1 RAB Assignment Request (UP versions)

2
Initialisation (init vers.= 1, supported vers.= UP version) 3 Initialisation Ack (UP version) 4 RAB Assignment Response 5 Transfer of user data 6
1. The 5060 WCS determines from the RNC circuit trunk the Iu UP version(s) to be used when establishing a 3G radio bearer towards the related RNC (default value : v1+v2, alternative values : v1, or v2). This Iu UP version(s) is provided to the MGW when seizing the RNC termination. 2. The 5060 WCS proposes the same Iu UP version(s) to the RNC in the RAB Assignment Request message. 3. The RNC initiates the Iu FP initialisation procedure, proposing the UP versions it can support for the requested radio bearer among the versions received in the RAB Assignment Request. 4. The MGW retains the highest UP version among the UP versions proposed by the RNC, authorized by the MSC Server (in the Add command) and those the MGW actually supports. This selected version is returned in the Initialisation Ack message. 5. Once the Iu FP initialisation is complete and the radio bearer established, the RNC can return the RAB Assignment Response message. 6. Data transfer in any direction can start. 2.7.1.3 UP version within the CN The 5060 WCS shall systematically configure UP mode version 2 on the Nb interface to enable TrFO, independently of what is configured on the Iu interface.
EDITION
08
RELEASED
En
56/149
2.7.1.4 3GUP properties on Mc interface The 5060 WCS shall provide the MGW with the following 3GUP properties for each Iu and 3GIP termination [48]. UP mode : support mode or transparent mode. Support Mode is always configured on Iu and Nb termination, except for 64 kbit/s transparent data call on Iucs termination which shall be set to transparent mode.
Note 64 kbit/s transparent data call is transported in Support Mode within the CN, hence a corresponding Nb termination is set to support mode. UP protocol version : list of the UP mode versions allowed by the MSC-S, as specified in section 2.7.1.1. Delivery of erroneous SDUs : indicates whether erroneous SDU shall be delivered or not or whether error detection is not considered at all. It shall be set to 'NA' for any type of calls. Iu Framing Termination Type : RAN : Iu framing protocol on Iu interface CN : Iu Framing protocol on Nb interface
Iu Framing Initialisation procedure : Incoming : RAN / incoming : indicates the originating RNC interface CN / incoming : the termination expects to receive an initialisation externally or after receiving an initialisation internally it sends an initialisation externally, based on what occur first ; in other words, the termination relays any Iu/Nb Initialisation procedure received after its creation. RAN / outgoing : it expects to receive an initialisation externally ; it shall not pass it internally ; it may initiate RFCI value correction out from this termination (using the RFCI values stored at the incoming termination) CN / outgoing : Iu Framing protocol is initialised by the MGW on the Nb interface (using preferably the RFCI values of any existing termination in the context having the same codec configurations, otherwise own pre-configured RFCI values)
Outgoing :
The setting of the last two properties is further described in section 2.7.1.5. 2.7.1.5 Setting of Iu Framing Initialisation property The setting of the 3GUP property Iu Framing Initialisation procedure depends on : the direction of the termination, upstream or downstream, with regards to the direction of the call set-up (not the direction of the bearer set-up) ; The bearer type associated to the termination, 3GPP bearer or not ; The interface of the termination, CN or RAN ; The codec configuration selected on terminations ; whether the Iu FP initialisation has already been initialised or not on the upstream bearer. This means that in the originating MSC-S, it also implicitly depends on whether early or late channel assignment is done when establishing the 3G radio bearer.
The principles to set the Iu Framing Type and Iu Framing Initialisation properties is then the following, where the columns direction, bearer type and interface refer to the characteristics of the termination for which the 3GUP properties shall be computed.
EDITION
08
RELEASED
En
57/149
Direction Upstream
Bearer type 3GPP Non 3GPP
Interface RAN CN RAN
Upstream term.
Downstream
3GPP
CN
No 3GUP properties CN or RAN Incoming and same codec type/modes on upstream and downstream terminations and UP initialisation on upstream bearer not yet done [CN or RAN Outgoing] or [CN or RAN Incoming and (different codec type/modes on upstream and downstream terminations) or (UP initialisation on upstream already done)]
3GUP Properties RAN Incoming CN Incoming None RAN - Outgoing (1) CN Outgoing CN Incoming
CN Outgoing
Non 3GPP
None None
The MGW behaviour as a function of the configured 3GUP properties is specified in 3GPP TS 29.232 [48]. This is further illustrated in the following sections for basic calls. 2.7.1.5.1 3G-3G call
Early channel assignment (3G RAB established before CN bearer establishment)

whether downstream and upstream codec cfg are identical or not MSCA Calling Party A RNCA MGWA RAN/Inc CN/Out GMSC MSCB MGWB CN/Inc RAN/Out If UP v2
MGWG CN/Inc CN/Inc
RNCB
Called Party B
Legend FP already initialized FP initialization RFCI value correction
Late channel assignment (3G RAB established after CN bearer establishment) (not supported)
EDITION
08
RELEASED
En
58/149
If downstream and upstream codec cfg is identical MSCA Calling Party A RNCA MGWA RAN/Inc CN/Inc GMSC MSCB MGWB CN/Inc RAN/Out If UP v2
MGWG CN/Inc CN/Inc
RNCB
Called Party B
If downstream and upstream codec cfg is different MSCA Calling Party A RNCA MGWA RAN/Inc CN/Out GMSC MSCB MGWB CN/Inc RAN/Out If UP v2
MGWG CN/Inc CN/Inc
RNCB
Called Party B
2.7.1.5.2
2G-3G call / PSTN-3G call

If UP v2
MSCA Calling Party A BSCA MGWA CN/Out
GMSC
MSCB MGWB CN/Inc RAN/Out
MGWG CN/Inc CN/Inc
RNCB
Called Party B
2.7.1.5.3
3G-2G call / 3G-PSTN call
Early channel assignment (3G RAB established before CN bearer establishment)
EDITION
08
RELEASED
En
59/149
whether downstream and upstream codec cfg iare identical or not MSCA Calling Party A RNCA MGWA RAN/Inc CN/Out GMSC MSCB MGWB CN/Inc BSCB Called Party B
MGWG CN/Inc CN/Inc
Late channel assignment (3G RAB established after CN bearer establishment) (not supported)
If downstream and upstream codec cfg is identical MSCA Calling Party A RNCA MGWA RAN/Inc CN/Inc GMSC MSCB MGWB CN/Inc BSCB Called Party B
MGWG CN/Inc CN/Inc
If downstream and upstream codec cfg is different MSCA Calling Party A RNCA MGWA RAN/Inc CN/Out GMSC MSCB MGWB CN/Inc BSCB Called Party B
MGWG CN/Inc CN/Inc
EDITION
08
RELEASED
En
60/149
2.7.1.5.4
2G/2G 2G/PSTN call
MSCA Calling Party A BSCA MGWA CN/Out
GMSC
MSCB MGWB CN/Inc BSCB Called Party B
MGWG CN/Inc CN/Inc
2.7.1.5.5
Transit call / terminating call at GMSC
In the preceding diagrams, both upstream and downstream Nb terminations at the GMSC are seized as CN incoming terminations. The same applies at a transit MSC for a BICC-BICC transit call. In all cases, this assumes that the downstream termination is seized before the Iu FP initialisation is received from upstreams. Otherwise the downstream termination needs to be seized as a CN outgoing termination. 2.7.1.5.6 Addition of a leg to an existing call
The handover / SRNS relocation scenarios, or supplementary services scenarios present the common need to be able to add a new leg to an existing call, e.g. a handover leg or a call forwarding leg. A possible example is illustrated below.
MSCA Calling Party A RNCA MGWA CN / Out Handover CN/Inc Calling Party A RNCA MGWA RAN/Out
GMSC
MSCB MGWB RNCB Called Party B
MGWG
The initialisation shall be propagated from the source MGW towards the target MGW or RNC. The 3GUP properties of the new termination taken in the source MGW shall be set to CN or RAN, depending on the target equipment, and to outgoing whatever the 3GUP properties of the existing leg to which the new leg shall be connected. This leads the MGW to initiate the Iu FP initialisation procedure on the new bearer, preferably using the RFCI values stored at any termination in the context having the same codec configurations, using otherwise own pre-configured RFCI values. 2.7.1.5.7 Intermediate setting of Iu Framing Initialisation property during BICC codec negotiation
Before initiating the BICC codec negotiation, the originating WCS always seizes a Nb termination whatever the establishment procedure used to settle the Nb bearer, though it does not know yet the codec selected for the 3BL 61719 AAAA PBZZA EDITION 08 RELEASED En 61/149
call. The 5060 WCS can only configure in the MGW a preferred codec at that stage of the procedure, with its corresponding 3GUP properties. Once the codec is negotiated, the selected codec may differ from the preferred codec initially configured in the MGW, which may also require a new setting of the 3GUP properties. The setting of the 3GUP properties by the MSC-S shall ensure that the originating MGW will not initiate a Iu FP initialisation procedure towards the remote MGW with a codec which would not be the finally selected codec. This only requires that the originating WCS reconfigures the MGW with the finally selected codec before or at the same time as : it tunnels down the IPBCP Response received from the peer MGW, for forward bearer establishment procedures ; it tunnels down the IPBCP Request received from the peer MGW, for delayed backward bearer establishment procedure.
The MGW shall always initialize the Nb bearer according to the latest codec configuration received from the MSC-S. Note In the case of 3G originating call with late channel assignment (not supported), the Iu FP initialisation on Iucs is initiated only once the Nb termination has been seized in the originating MSC and configured with the codec selected for the call. The MSC-S should set the Nb termination to CN outgoing only if the codec configuration differs from the codec configured on the 3G radio interface. Depending on the result of the end to end codec negotiation, the MSC-S may need to modify the 3GUP properties from e.g. CN/Incoming to CN/Outgoing. 2.7.2 Rate Control procedure (Informative)
This section is for information only as the Rate Control procedure is transparent to the MSC-S. The purpose of the rate control procedure is to signal to the peer UP protocol entity the maximum rate in the reverse direction of the sent RATE CONTROL message. The procedure can be initiated at : any time during the transfer of user data. by a UP protocol entity receiving user data with non permitted rate ; during a SRNS relocation : when the user plane is initiated following a SRNS relocation, no rate control is signalled before the reception of the relocation execution trigger. At the reception of this trigger, the RNC shall start the Iu Rate Control procedure. This enables both TrFO partners to exchange the current maximum rates and proceed user data transport based on the latest rate decision.
In UP mode version 2, the Rate Control procedure does only indicate the permitted maximum bit rate ; it does not allow to restrict some rates, as in version 1. Moreover, in the UP mode version 2, the SRNS may also receive RATE CONTROL frames from the TrFO partner, whereas in version 1 only the SRNC can initiate a rate control procedure.
RNC / MGW
MGW /RNC
Rate Control (maximum bit rate) 1 Rate Control Ack (maximum bit rate) 2
1. The sending UP protocol entity indicates the maximum rate it wishes to receive. A supervision timer is started after sending the UP RATE CONTROL control frame, supervising the reception of the rate control acknowledgement frame. 2. The receiving UP protocol entity acknowledges the RATE CONTROL frame by including its own maximum rate control information. 3BL 61719 AAAA PBZZA EDITION 08 RELEASED En 62/149
2.7.3
Time Alignment procedure (Informative)
This section is for information only as the Time Alignment procedure is transparent to the MSC-S. The time alignment procedure controls the timing of the data sent in the reverse direction of the time alignment message. Its purpose is to minimize the buffer delay in reception by controlling the transmission timing in the reverse direction. The procedure is invoked whenever the SRNS detects the reception of UP PDU at an inappropriate timing that leads to unnecessary buffer delay.
RNC
MGW
user data with bad timing Time Alignment Ack user data with adjusted timing
2.7.4
Transfer of user data
The UP protocol is in charge of : making the padding of the payload if needed, so that the UP frame payload is an integer number of octets ; performs if needed the CRC calculation of the UP frame payload formatting the frame header and payload into the appropriate PDU type sending the UP frame PDU accross the Iu or Nb interface ; checking the validity of received UP frames (e.g. received RFCI is in the list of RFCI initialised during the initialisation procedure). protocol indicates in the INITIALISATION frame which type of PDU shall be used directions. If the reliability attribute Delivery of Erroneous SDU in the RAB IU RELOCATION REQUEST equals no-error-detection-consideration for all 1 shall be used (no CRC on the payload), otherwise PDU type 0 shall be used.
The node initialising the UP for data transfer in both ASSIGNMENT REQUEST or sub-flows then the PDU type
The same PDU type shall be configured on the end to end path to allow TrFO (the header of both PDU types do not have the same length). The setting by the 5060 WCS of the 3GUP property Delivery of Erroneous SDUs is specified in section 2.7.1.4. 2.7.5 RFCI values correction / RFCI mapping
The MSC-S is involved in that procedure only by the setting of a RAN outgoing termination . The Framing Protocol is established through the core network in a forward direction, independently of the bearer establishment direction, link (MGW-MGW interface) by link. During this initialisation, each MGW involved in the call stores the RFCIs received from the previous node in the Framing Protocol initialisation PDU ; the subsequent initialisation is performed using the same RFCI set as received from the preceding node, independently of the stream mode directions. When the MGW terminations are through-connected and the RFCIs at both terminations are matching, the MGW may revert to transparent mode (i.e. TrFO break removal).
EDITION
08
RELEASED
En
63/149
At the terminating end of a TrFO connection, with Iu FP initialised to the terminating MGW, the originating allocation is stored. The terminating RNC is then requested to perform a RAB Assignment towards the terminating MGW. This results in an Iu Framing initialisation where the allocation of the RFCI values is independent from the originating RNCs allocation. The terminating MGW shall acknowledge the Iu Framing initialisation and compare the RFCI values stored from the originating side with those received from the terminating RNC. If they do not match, the terminating MGW shall either initiate a RFCI values correction procedure or perform RFCI values mapping. 2.7.5.1 RFCI values correction
RNC-O Initialisation (RFCI-o) 1 Initialisation Ack Initialisation (RFCI-o) 2 Initialisation Ack Initialisation (RFCI-t) 3 Initialisation Ack Initialisation (RFCI-o) 4 Initialisation Ack Rate Control (maximum bit rate towards RNC-t) 5 Rate Control (maximum bit rate towards RNC-t) 6 Rate Control Ack (maximum bit rate towards RNC-o) Rate Control Ack (maximum bit rate towards RNC-o) MGW-O MGW-T RNC-T
1. During Iu FP initialisation, MGW-O stores the RFCI values received from the originating RNC. 2. The MGW-O then relays the Iu FP initialisation to the succeeding node. The MGW-T stores the RFCI values received from upstream. 3. During the RAB establishment, the terminating RNC initialises the Iu FP protocol towards MGW-T, sending its own RFCI values. 4. If the RAN termination is configured as RAN outgoing, and if the codec configuration of that RAN termination is identical to the codec configuration of the CN termination, the MGW checks whether the RFCI values received from the terminating RNC match those received from upstream. If not, and if Iu UP support mode version 2 has been negotiated with the target RNC, MGW-T initiate a new Iu FP initialisation procedure towards the terminating RNC with the RFCI values of the originating node (the order of the RFCI values shall not be changed, as this order implicitly conveys the current maximum bit rate acceptable in the reverse direction) - procedure called RFCI values correction. 5. As the first RFCI received from the terminating RNC in the first Initialisation message corresponds to an initial maximum rate control, the MGW should send a RATE CONTROL PDU backwards indicating this maximum speech mode expected to be received by the target RNC. 6. The Rate Control PDU is propagated backwards up to the originating RNC. 2.7.5.2 RFCI values mapping If the RFCI values correction is not applied, e.g. because Iu UP support mode version 1 has been negotiated with the target RNC, or because the RFCI values correction procedure is not supported by the MGW, the MGW shall map the RFCI indices of the incoming side to the corresponding RFCI indices at the outgoing side for all SDUs passed between the terminations procedure called RFCI mapping.
EDITION
08
RELEASED
En
64/149
RNC-O Initialisation (RFCI-o) 1 Initialisation Ack
MGW-O
MGW-T
RNC-T
Initialisation (RFCI-o) 2 Initialisation Ack Initialisation (RFCI-t) 3 Initialisation Ack Rate Control (maximum bit rate towards RNC-t) 4 Rate Control (maximum bit rate towards RNC-o) 5 Rate Control Ack (maximum bit rate towards RNC-t) Rate Control (maximum bit rate towards RNC-t) Rate Control Ack (maximum bit rate towards RNC-o) Rate Control Ack (maximum bit rate towards RNC-o)
1. During Iu FP initialisation, MGW-O stores the RFCI values received from the originating RNC. 2. The MGW-O then relays the Iu FP initialisation to the succeeding node. The MGW-T stores the RFCI values received from upstream. 3. During the RAB establishment, the terminating RNC initialises the Iu FP protocol towards MGW-T, sending its own RFCI values. If the RAN termination is configured as RAN outgoing, and if the codec configuration of that RAN termination is identical to the codec configuration of the CN termination, the MGW checks whether the RFCI values received from the terminating RNC match those received from upstream. If not, MGW-T maps RFCI indices of the incoming side to the corresponding RFCI indices at the outgoing side for all SDUs passed between the terminations - procedure called RFCI values correction. 4. As the first RFCI received from the terminating RNC in the Initialisation message corresponds to an initial maximum rate control, the MGW should send a RATE CONTROL PDU backwards indicating this maximum speech mode expected to be received by the target RNC. 5. If Iu UP support mode version 2 has been negotiated with the target RNC, MGW-T should also initiate a Rate Control procedure towards the target RNC to inform it about the maximum rate expected in the reverse direction by the originating node.
2.8 Tones and announcement (H.248 specific)

This section summarizes the main principles supported by the 5060 WCS to send tone and play announcement. See TRS Tones and Announcements [25] for a comprehensive description. 2.8.1 Audio termination
H.248 enables to play in-band signals (tones, announcements) either by applying a corresponding H.248 signal directly on the external H.248 termination with an external direction (towards the party behind the termination), or by creating an intermediate IP termination further referred as audio termination - with an internal direction and a one-way topology set towards the external H.248 termination on which the in-band signal shall finally be sent. An audio termination in created by an ADD command, with the following characteristics : RTP bearer type ; No TIND event, no BNCChange events, no 3GUP properties, no Acodec property ; signal id ; EDITION 08 RELEASED En 65/149
one-way topology from the audio termination towards the external termination(s) towards which the signal shall be played.
The stream mode of the termination through which the tone/announcement passes shall allow the sending of media stream towards the exterior of the MGW, i.e. it shall be set to either SendOnly or Send&Receive. See the TRS H.248 [11] Play Announcement procedure - for further details. 2.8.2 Tones
The 5060 WCS always play tones (normal and special tones e.g. pre-paid warning tones) directly on the external H.248 termination, i.e. without using an audio termination. If the tone needs to be intercepted, the WCS also plays the same tone on the external (egress) tap termination. When the tone needs to be stopped, the WCS initiates a Stop Tone procedure on the party's external termination and the tap termination. The H.248 topology existing in the context at a time a tone shall be played should not be changed when playing a tone, i.e the termination on which the tone is requested to be played should not be isolated from the other possible terminations in the context. The MGW shall know by its own whether a tone is a normal tone or a special tone, and therefore whether it shall superpose or not the tone with the media stream possibly received from a remote end. This enables to keep the handling of normal and special tones identical from the WCS perspective. Upon the occurrence of a handover / SRNS relocation, if a tone is being sent towards the source access termination, the WCS starts the same tone on the target access termination upon receipt of the Handover / Relocation Detect message (or Handover / Relocation Complete message if Handover / Relocation Detect has not been received beforehand), preferably within the same H.248 message as the one sent to modify the H.248 topology. Notes : 1) The source and target access termination may be a radio access termination or a core network termination as a result of an Inter-MSC handover / SRNS relocation or any Intra-MSC Inter-MGW handover / SRNS relocation. As a result of the above requirement, the tone is not sent on the target access termination during the handover / SRNS relocation execution (i.e. before the receipt of the Handover/Relocation Detect message). This will not be noticeable to the end user. Duplicating the tones during the handover execution would complexify the design : tones would have to be stopped on 2 terminations if to be stopped, tone would have to be started when adding the 2G target access termination, but would have to be added upon receipt of the Notify Bearer Established for a 3G target access termination. There is no real need to send a Stop Tone command on the source access termination upon receipt of the Handover / Relocation Detect message, since implicitly stopped upon release of the source access termination (successful completion of handover). Handover / Relocation Detect messages should normally be received first. The BSS shall send a Handover Detect message upon detection of the handset in the target cell (see 3GPP TS 48.008), and the RNC shall send a Relocation Detect message as well. However 3GPP TS 25.413 also specifies that the MSC shall handle normally a Relocation Complete message that would be received before a Relocation Detect message. The case where a Handover / Relocation Complete message would be received first is therefore added in the requirements above.
2)
3)
4)
Similarly, if a tone needs to be sent towards a subscriber currently being handed-over, the WCS shall start the tone on the current access termination connected to the RAN (or target MSC) under which the MS is currently located (i.e. on the source access termination if the Handover / Relocation Detect message has not been received yet, on the target access termination otherwise). If this is the source access termination, the tone is then continued on the target access termination upon receipt of the Handover / Relocation detect message, as explained above.
EDITION
08
RELEASED
En
66/149
For tones whose duration is controlled by a WCS timer (e.g. prepaid warning tones), the overall duration of a tone takes into account the duration it has been played on the source access termination, i.e. the duration of the tone on the target access termination is the total expected tone duration minus the tone duration on the access termination. Tones are explicitly stopped by the WCS using the Stop Tone procedure, see TRS H.248 [11]. 2.8.3 Announcements
Announcements shall be played continuously during and after an handover execution, i.e. they shall not be replayed from the start after the handover. As the old and the new RAN terminations shall remain isolated (e.g. to avoid Iu rate control PDU received from the old RAN termination to be forwarded to the new RAN termination), the 5060 WCS shall not play announcements on RAN terminations. Announcements shall also be intercepted if the party towards which the signal is played is itself intercepted. This also prevents playing announcement on CN terminations due to missing corresponding capabilities of H.248.1 v1 & v2, as illustrated below where the Ta termination needs to be intercepted with stereo interception. There is indeed no possibility here to intercept the announcement on the T2 termination which monitors the traffic sent towards the party A. See [7] for further details. The 5060 WCS therefore implements the following main principles. 1. Announcement are played via an audio termination only in the following cases : the announcement is sent towards an access termination (or towards a radio access network via a nonaccess termination as a result of an Inter-MSC handover/SRNS relocation or any Intra-MSC Inter-MGW handover/SRNS relocation) , or the announcement needs to be intercepted.
When playing an announcement via an audio termination, a one way topology shall be set from the audio termination towards the external termination Ta, and Ta shall be isolated from any peer termination in the context (Tb termination towards remote party). The topology is then restored as appropriately in the context when subtracting the audio termination. 2. Any other announcement not covered by the preceding point is played using normal procedures, i.e. is played directly on the external H.248 termination, i.e. without using an audio termination. In that latter case, the H.248 topology existing in the context at a time an announcement shall be played should preferably not be changed when playing an announcement w/o audio termination, i.e. the termination on which the announcement is requested to be played should not be isolated from the other possible terminations in the context. The MGW knows intrinsically that it shall never superpose an announcement with the media stream possibly received from a remote end. This enables to avoid the need for a subsequent H.248 command restoring the initial H.248 topology upon receipt of an Announcement Completed notification. 3. The WCS invokes the StoP Announcement procedure (see TRS H.248 [11]) in case it needs to stop the announcement before its completion. If not stopped beforehand, the MGW invokes the Announcement CompleteD procedure once the announcement has been broadcast the number of times ordered by the WCS ; no further Stop Announcement procedure is invoked in that case. 4. The WCS does never attempt to move a termination which is currently sending tone/announcement. So the MGW is not expected to support continuous sending of tone/announcement played on a termination that would be moved.
2.9 Receipt of unrecognized messages or parameters

The 5060 WCS handles the receipt of unrecognized message, parameter type or parameter value, as specified by ITU-T Q.1902.4 section 13.4. In particular, the WCS looks for corresponding instructions contained in the Message Compatibility Information or Parameter Compatibility Information parameters respectively, if received. 3BL 61719 AAAA PBZZA EDITION 08 RELEASED En 67/149
Unrecognized messages received without Message Compatibility Information parameters are discarded and a Confusion message is returned. If Message Compatibility Information parameters are received, the WCS may either transfer the message transparently, discard the message, discard the message and return a Confusion message, or release the call. Unrecognized or unexpected parameters received without Parameter Compatibility Information parameters are either discarded or passed on unmodified. If discarded, a Confusion message is returned. If Parameter Compatibility Information parameters are received, the WCS may either transfer the parameter transparently, discard the parameter, discard the message, discard the parameter or the message and return a Confusion message, or release the call.
EDITION
08
RELEASED
En
68/149
MOBILE TO MOBILE SPEECH CALL ESTABLISHMENT

one outgoing call at the originating VMSC one transit call at a GMSC (HLR interrogation) one incoming call at the terminating VMSC
A mobile to mobile call consists of :
The GMSC function (HLR interrogation) can be located within the originating VMSC or within the terminating VMSC or within a different MSC.
Originating MSC GMSC Terminating MSC
MSC-S A
GMSC-S
HLR
MSC-S B
RAN A Ta Party A Ta0 Tga Tgb Tb0 Tb
RAN B
Party B
MG A
MG G
MG B
ISUP/BICC signalling and transport path is required between the GMSC and respectively originating and terminating MSC only if the GMSC is not co-located respectively with the originating and terminating MSC. All the general principles explained in chapter 0 apply to the detailed call scenarios specified further down in the TRS. They are not repeated.
3.1 Inter-MSC mobile to mobile call establishment via BICN

BICC
IP backbone
Access IP network
Access IP network
AP
AP
3.1.1
3G originating call
Call flows are illustrated with: IuoAAL2 bearers. Call flows with IuoIP can be derived according to subclause 2.4. the BICC IAM message being sent by the originating MSC after the completion of originating 3G radio bearer establishment. The BICC IAM message may be sent in parallel to the 3G radio bearer establishment, as per subclause 2.6.4.2.
EDITION
08
RELEASED
En
69/149
3.1.1.1 Delayed Backward bearer establishment
UE/RNC A
MSC-S A
1
MGW A
GMSC
UE access & security procedures SETUP (UE codec list) CALL PROCEEDING 3
2
ADD $ (SendOnly,codec,BEE event) [PBE] 4 ADD Reply Ta (BNCid, BIWFad) RAB ASSIGNEMNT REQUEST (BNCid,BIWFad,codec) 5 Bearer establishment (BNCid) Iu FP Initialisation RAB ASSIGNMENT RESPONSE ADD $ (S&R,pref.codec) [PBE] ADD Reply Ta0 IAM (DestNb,bw, BNCchar,SCL) 6 APM (selected codec, ACL,Tunnel[IPBCP Req]) MOD Ta0 (sel.codec,Tunnel[IPBCP Req]) [MBE+TUD] MOD Reply Ta0 NOTIFY Ta0 (Tunnel[IPBCP Resp]) [TUU] NOTIFY Reply Ta0 APM (Tunnel[IPBCP Resp]) Nb FP Initialisation 7 NOTIFY Ta0 [BEE] 8 NOTIFY Reply Ta0 ACM 9 ALERTING Ring back tone ANM MOD Ta (S&R) [CTC] 10 MOD Reply Ta MOD Ta0 (TFO codecs list) [TFO] 11 MOD Reply Ta0 CONNECT 12 CONNECT ACK Conversation
1. UE access and security procedures When the user wishes to originate a call, UEA establishes a signalling connection with RNCA, and sends a Connection Management (CM) service request to the RNCA which relays it to the MSC-SA. MSC-SA checks
EDITION
08
RELEASED
En
70/149
that UEA is allowed service ; at this stage, authentication and ciphering may be initiated (see [28]). 2. Setup When UEA has been granted access to the network, it sends a Setup message containing the called subscriber (further referred as UEB) address to the MSC-SA. UEA also uses the Setup message to indicate the bearer capability required for the call and the list of codecs it supports. 3. Call Proceeding If the MSC-SA determines that the call should be connected, it sends a Call Proceeding message to UEA to indicate that the call has been accepted. 4. Prepare access bearer establishment MSC-SA requests the MGW to prepare the AAL2 bearer establishment (see section 2.3). The termination is seized in SendOnly mode. MSC-SA does not request the MGW to send a notification when the access bearer is established (and IuFP initialised). 5. RAB Assignment Request MSC-SA requests the RNC to establish the radio bearer and the Iu bearer, see section 2.3. 6. Delayed backward bearer establishment See section 2.2.3.5. 7. Nb Framing Protocol Initialisation (3GIP bearer) Once the IP bearer is setup, the MGW initiates the initialisation of the Nb FP protocol, as specified in 2.7.1.1. 8. BEarer Established notification See section 2.6.5. 9. Address Complete message When the destination exchange returns an ACM, MSC-SA sends an ALERTING message to UEA to indicate to the calling user that the B subscriber is being alerted. 10. Both-way Through-Connection Upon receipt of the ANM message, MSC-SA switches the Ta termination to Send&Receive mode to through-connect Ta and Ta0. In case TrFO can be entered, the MGW removes the TBE and frames pass transparently through the UP entities. 11. TFO Activation TFO is activated on the CN termination once the call is answered, if the conditions to activate TFO are satisfied (see TRS TFO [14]). 12. Connect message MSC-SA then sends a CONNECT message to UEA to instruct UEA to connect to the speech path.
EDITION
08
RELEASED
En
71/149
3.1.1.2 Fast Forward bearer establishment
UE/RNC A
MSC-S A
MGW A
GMSC
UE access & security procedures SETUP (UE codec list) CALL PROCEEDING ADD $ (SendOnly,codec,BEE event) [PBE] ADD Reply Ta (BNCid, BIWFad) RAB ASSIGNEMNT REQUEST (BNCid,BIWFad,codec) Bearer establishment (BNCid) Iu FP Initialisation RAB ASSIGNMENT RESPONSE ADD $ (S&R,pref.codec) [EBE] ADD Reply Ta0 NOTIFY Ta0 (Tunnel[IPBCP Req]) [TUU] NOTIFY Reply Ta0 IAM (DestNb,fw, BNCchar,SCL,Tunnel[IPBCP Req]) 1 APM (selected codec, ACL,Tunnel[IPBCP Resp]) MOD Ta0 (sel.codec,Tunnel[IPBCP Resp]) [TUD+MBE] MOD Reply Ta0 Nb FP Initialisation NOTIFY Ta0 [BEE] 2 NOTIFY Reply Ta0 APM (Connected) 3 ACM ALERTING Ring back tone ANM MOD Ta (S&R) [CTC] MOD Reply Ta MOD Ta0 (TFO codecs list) [TFO] MOD Reply Ta0 CONNECT CONNECT ACK Conversation
1. Fast Forward bearer setup procedure See section 2.2.3.2. 2. BEarer Established notification See section 2.6.5.
EDITION
08
RELEASED
En
72/149
3. APM(Connected) message See section 2.6.5.
EDITION
08
RELEASED
En
73/149
3.1.1.3 Delayed Forward bearer establishment
UE/RNC A
MSC-S A
MGW A
GMSC
UE access & security procedures SETUP (UE codec list) CALL PROCEEDING ADD $ (SendOnly,codec,BEE event) [PBE] ADD Reply Ta (BNCid, BIWFad) RAB ASSIGNEMNT REQUEST (BNCid,BIWFad,codec) Bearer establishment (BNCid) Iu FP Initialisation RAB ASSIGNMENT RESPONSE ADD $ (S&R,pref.codec) [PBE] ADD Reply Ta0 IAM (DestNb,fw, BNCchar,SCL,no IPBCP) 1 APM (selected codec, ACL) MOD Ta0 (sel.codec) [EBE] MOD Reply Ta0 NOTIFY Ta0 (Tunnel[IPBCP Req]) [TUU] NOTIFY Reply Ta0 APM (Tunnel[IPBCP Req]) 1 APM (Tunnel[IPBCP Resp]) MOD Ta0 (Tunnel[IPBCP Resp]) [TUD] MOD Reply Ta0 Nb FP Initialisation NOTIFY Ta0 [BEE] 2 NOTIFY Reply Ta0 APM (Connected) 3 ACM ALERTING Ring back tone ANM MOD Ta (S&R) [CTC] MOD Reply Ta MOD Ta0 (TFO codecs list) [TFO] MOD Reply Ta0 CONNECT CONNECT ACK Conversation
EDITION
08
RELEASED
En
74/149
1. Delayed Forward bearer setup procedure See section 2.2.3.3. 2. BEarer Established notification See section 2.6.5. 3. APM(Connected) message See section 2.6.5.
EDITION
08
RELEASED
En
75/149
3.1.2
2G originating call
UE/BSC A
MSC-S A
MGW A
GMSC
UE access & security procedures SETUP (UE codec list) CALL PROCEEDING ASSIGNMENT REQUEST 1 ASSIGNMENT COMPLETE ADD $ (SendOnly) [RCI] 2 ADD Reply Ta ADD $ (S&R,pref.codec) [PBE] ADD Reply Ta0 IAM (DestNb,bw, BNCchar,SCL) 3 APM (selected codec, ACL,Tunnel[IPBCP Req]) MOD Ta0 (sel.codec,Tunnel[IPBCP Req]) [MBE+TUD] MOD Reply Ta0 NOTIFY Ta0 (Tunnel[IPBCP Resp]) [TUU] NOTIFY Reply Ta0 APM (Tunnel[IPBCP Resp]) Nb FP Initialisation NOTIFY Ta0 [BEE] 4 NOTIFY Reply Ta0 ACM ALERTING Ring back tone ANM MOD Ta (S&R, TFO codec list) [CTC,TFO] 5 MOD Reply Ta CONNECT CONNECT ACK Conversation
1. Radio bearer establishment MSC-SA requests the BSS to establish the radio channel, sending the CIC corresponding to the TDM termination it has pre-allocated for the call. 2. Reserve Circuit procedure The TDM termination corresponding to the CIC provided to the BSS is reserved in the MGW using the
EDITION
08
RELEASED
En
76/149
Reserve Circuit procedure. 3. Delayed backward bearer establishment See section 2.2.3.5. 4. BEarer Established notification See section 2.6.5. 5. TFO activation TFO is activated on the 2G access termination once the call is answered, if the conditions to activate TFO are satisfied (see TRS TFO [14]). This is done at the same time as through-connecting the bearer.
EDITION
08
RELEASED
En
77/149
3.1.3
3BL 61719 AAAA PBZZA 3G terminating call (VMSC)
EDITION
08
RELEASED
En
78/149
GMSC
MSC-S B
1
MGW B
RNC/UE B
IAM (DestNb,bw, BNCchar,SCL,cot)
Paging & Security SETUP

3
CALL CONFIRMED (UE codec list) ADD $ (SendOnly,sel. codec) [EBE] ADD Reply Tb0 NOTIFY Tb0 (Tunnel[IPBCP Req]) [TUU] NOTIFY Reply Tb0 APM (selected codec, ACL,Tunnel[IPBCP Req]) ADD $ (S&R,codec) [PBE]
6 1 5
ADD Reply Tb (BNCid,BIWFad) APM (Tunnel[IPBCP Resp]) MOD Tb0 (Tunnel[IPBCP Resp]) [TUD] MOD Reply Tb0 Nb FP Initialisation
7 1
NOTIFY Tb0 [BEE] COT

9
NOTIFY Reply Tb0
WCS waits E2E path continuity before RAB Assignment
10
RAB ASSIGNMENT REQUEST (BNCid,BIWFad,codec)
11
Bearer Establishment (BNCid) Iu FP Initialisation RFCI value correction RAB ASSIGNMENT RESPONSE ALERTING ACM MOD Tb0 (ring back tone) [SDT] MOD Reply Tb0 ring back tone towards calling party CONNECT
15 14 13 12
MOD Tb0 (stop Tone,S&R,TFO codec list) [SPT, CTC,TFO] MOD Reply Tb0 ANM CONNECT ACK conversation
16
EDITION
08
RELEASED
En
79/149
1. Initial Address message / Delayed backward bearer establishment See section 2.2.3.5. The WCS may also receive in the IAM message an indication that a Continuity message shall be awaited. See section 2.6.5. 2. Paging and Security procedures If MSC-SB recognizes the roaming number and UEB is allowed service, it sends a page request to the RNCB. Upon being paged, UEB establishes a signalling connection with RNCB, and sends a page response to RNCB which relays it to MSC-SB ; at this stage, authentication and ciphering may be initiated (see [28]). 3. SETUP MSC-SB sends a SETUP message towards UEB, indicating that early bearer assignment is used. 4. CALL CONFIRMED When UEB receives the SETUP message, it responds with a CALL CONFIRMED message, which includes the list of codecs it supports. 5. Establish BEarer procedure MSC-SB requests the MGW to establish the IP bearer. The termination is seized in ReceiveOnly mode. MSC-SB may also requests the MGW to send a notification when the CN bearer is established. See section 2.6.5. 6. Prepare access bearer establishment MSC-SB requests the MGW to prepare the AAL2 bearer establishment (see section 2.3). The termination is seized in Send&Receive mode. MSC-SB does not request the MGW to send a notification when the access bearer is established (and IuFP initialised). 7. Nb Framing protocol initialisation (3GIP bearer) The Nb Framing protocol is established through the core network in a forward direction (independently of the bearer establishment direction). As the CN termination has been defined as supporting the UP package with Initialisation Direction incoming and the Iu termination has been defined as supporting the UP package with Initialisation Direction outgoing, the MGW shall not forward the UP initialisation from the CN termination until it has received an UP initialisation at the Iu termination. 8. BEarer Established notification See section 2.6.5. 9. Continuity message In case the GMSC indicated in the IAM message that a Continuity message had to be expected, it sends this message when path continuity is ensured upstreams. 10. WCS waits for end to end path continuity MSC-SB delays the RAB establishment to the target RNC until end to end path continuity is achieved. See See section 2.6.5. 11. RAB Assignment Request MSC-SA requests the RNC to establish the radio bearer and the Iu bearer, see section 2.3. During that procedure, the target RNC initiates the initialisation of the Iu Framing Protocol towards the MGW. 12. RFCI values correction In case the RFCI values received from the terminating RNC does not match the RFCI values received from the preceding node, the MGW initiates a RFCI values correction if allowed, as defined in section 2.7.5. 13. ALERTING When UEB has tuned to the specified traffic channel, it sends an ALERTING message to indicate to that the called user is being alerted. Upon receipt of this message, MSC-SB sends an ACM to the preceding node which relays it to the originating MSC. Besides, MSC-SB requests the MGW to provide a ringing tone to the calling party using the Send Tone procedure.
EDITION
08
RELEASED
En
80/149
14. Ring back tone The awaiting answer indication (e.g. ring back tone) is applied to the bearer path to the calling party. 15. Connect message When the called user answers, UEB sends a CONNECT message. On receipt of that message, MSC-SB requests the MGW to stop the ring back tone on the Tb0 termination and to switch it to Send&Receive mode. TFO is also activated on the CN termination once the call is answered, if the conditions to activate TFO are satisfied (see TRS TFO [14]). If TrFO can be entered, the MGW removes the TBE ; frames pass transparently through the UP entities.
EDITION
08
RELEASED
En
81/149
3.1.3.2 Fast Forward bearer establishment
EDITION
08
RELEASED
En
82/149
GMSC
MSC-S B
MGW B
RNC/UE B
IAM (DestNb,fw, BNCchar,SCL,cot,Tunnel[IPBCP Req]) 1 Paging & Security SETUP CALL CONFIRMED (UE codec list) ADD $ (SendOnly,sel. codec,Tunnel[IPBCP Req]) [PBE+TUD] 1 ADD Reply Tb0 NOTIFY Tb0 (Tunnel[IPBCP Resp]) [TUU] NOTIFY Reply Tb0 APM (selected codec, ACL,Tunnel[IPBCP Resp]) ADD $ (S&R,codec) [PBE] ADD Reply Tb (BNCid,BIWFad) Nb FP Initialisation NOTIFY Tb0 [BEE] NOTIFY Reply Tb0 APM (Connected) 2 COT WCS waits E2E path continuity before RAB Assignment RAB ASSIGNMENT REQUEST (BNCid,BIWFad,codec) Bearer Establishment (BNCid) Iu FP Initialisation RFCI value correction RAB ASSIGNMENT RESPONSE ALERTING ACM MOD Tb0 (ring back tone) [SDT] MOD Reply Tb0 ring back tone towards calling party CONNECT MOD Tb0 (stop Tone,S&R,TFO codec list) [SPT,CTC,TFO] MOD Reply Tb0 ANM CONNECT ACK conversation
EDITION
08
RELEASED
En
83/149
1. Initial Address Message / Fast forward bearer establishment See section 2.2.3.2. 2. APM(Connected) message See section 2.6.5.
EDITION
08
RELEASED
En
84/149
3.1.3.3 Delayed Forward bearer establishment
EDITION
08
RELEASED
En
85/149
GMSC
MSC-S B
1
MGW B
RNC/UE B
IAM (DestNb,fw, BNCchar,SCL,cot)
Paging & Security SETUP CALL CONFIRMED (UE codec list) Add $ (SendOnly,sel. codec) [PBE] Add Reply Tb0 APM (selected codec, ACL) Add $ (S&R,codec) [PBE] Add Reply Tb (BNCid,BIWFad) APM (Tunnel[IPBCP Req]) MOD Tb0 (Tunnel[IPBCP Req]) [TUD] MOD Reply Tb0 NOTIFY Tb0 (Tunnel[IPBCP Resp]) [TUU] NOTIFY Reply Tb0 APM (Tunnel[IPBCP Resp]) Nb FP Initialisation NOTIFY Tb0 [BEE] NOTIFY Reply Tb0 APM (Connected) COT WCS waits E2E path continuity before RAB Assignment RAB ASSIGNMENT REQUEST (BNCid,BIWFad,codec) Bearer Establishment (BNCid) Iu FP Initialisation RFCI value correction RAB ASSIGNMENT RESPONSE ALERTING ACM MOD Tb0 (ring back tone) [SDT] MOD Reply Tb0 ring back tone towards calling party CONNECT MOD Tb0 (stop Tone,S&R,TFO codec list) [SPT,CTC,TFO] MOD Reply Tb0 ANM CONNECT ACK conversation
2 1
EDITION
08
RELEASED
En
86/149
1. Initial Address Message / Delayed forward bearer establishment See section 2.2.3.3. 2. APM(Connected) message See section 2.6.5.
EDITION
08
RELEASED
En
87/149
3.1.4
3BL 61719 AAAA PBZZA 2G terminating call (VMSC)
EDITION
08
RELEASED
En
88/149
GMSC
MSC-S B
MGW B
BSC/MS B
IAM (DestNb,bw, BNCchar,SCL,cot) 1 Paging & Security SETUP 3 CALL CONFIRMED (UE codec list) 4 ADD $ (SendOnly,sel. codec) [EBE] 5 ADD Reply Tb0 NOTIFY Tb0 (Tunnel[IPBCP Req]) [TUU] NOTIFY Reply Tb0 APM (selected codec, ACL,Tunnel[IPBCP Req]) APM (Tunnel[IPBCP Resp]) MOD Tb0 (Tunnel[IPBCP Resp]) [TUD] MOD Reply Tb0 Nb FP Initialisation 6 NOTIFY Tb0 [BEE] 7 NOTIFY Reply Tb0 COT 8 WCS waits E2E path continuity before RAB Assignment
9 2
ASSIGNMENT REQUEST
10
ASSIGNMENT COMPLETE ADD $ (S&R) [RCI] 11 ADD Reply Tb ALERTING 12 ACM MOD Tb0 (ring back tone) [SDT] 13 MOD Reply Tb0 ring back tone towards calling party CONNECT 14 MOD Tb0 (stop Tone,S&R) [SPT, CTC] MOD Reply Tb0 MOD Tb (TFO codec list) [TFO] 15 MOD Reply Tb ANM CONNECT ACK conversation
EDITION
08
RELEASED
En
89/149
1. Initial Address message / Delayed backward bearer establishment See section 2.2.3.5. The WCS may also receive in the IAM message an indication that a Continuity message shall be awaited. See section 2.6.5. 2. Paging and Security procedures If MSC-SB recognizes the roaming number and UEB is allowed service, it sends a page request to the BSCB. Upon being paged, UEB establishes a signalling connection with BSCB, and sends a page response to BSCB which relays it to MSC-SB ; at this stage, authentication and ciphering may be initiated (see [28]). 3. SETUP MSC-SB sends a SETUP message towards UEB, indicating that early bearer assignment is used. 4. CALL CONFIRMED When UEB receives the SETUP message, it responds with a CALL CONFIRMED message, which includes the list of codecs it supports. 5. Establish BEarer procedure MSC-SB requests the MGW to establish the IP bearer. The termination is seized in ReceiveOnly mode. MSC-SB may also requests the MGW to send a notification when the CN bearer is established. See section 2.6.5. 6. Nb Framing protocol initialisation (3GIP bearer) The Nb Framing protocol is established through the core network in a forward direction (independently of the bearer establishment direction). As the CN termination has been defined as supporting the UP package with Initialisation Direction incoming and the Iu termination has been defined as supporting the UP package with Initialisation Direction outgoing, the MGW shall not forward the UP initialisation from the CN termination until it has received an UP initialisation at the Iu termination. 7. BEarer Established notification See section 2.6.5. 8. Continuity message In case the GMSC indicated in the IAM message that a Continuity message had to be expected, it sends this message when path continuity is ensured upstreams. 9. WCS waits for end to end path continuity MSC-SB delays the RAB establishment to the target RNC until end to end path continuity is achieved. See See section 2.6.5. 10. Radio bearer establishment MSC-SA requests the BSS to establish the radio channel, sending the CIC corresponding to the TDM termination it has pre-allocated for the call. 11. Reserve Circuit procedure The TDM termination corresponding to the CIC provided to the BSS is reserved in the MGW using the Reserve Circuit procedure. 12. ALERTING When UEB has tuned to the specified traffic channel, it sends an ALERTING message to indicate to that the called user is being alerted. Upon receipt of this message, MSC-SB sends an ACM to the preceding node which relays it to the originating MSC. Besides, MSC-SB requests the MGW to provide a ringing tone to the calling party using the Send Tone procedure. 13. Ring back tone The awaiting answer indication (e.g. ring back tone) is applied to the bearer path to the calling party. 14. Connect message When the called user answers, UEB sends a CONNECT message. On receipt of that message, MSC-SB 3BL 61719 AAAA PBZZA EDITION 08 RELEASED En 90/149
requests the MGW to stop the ring back tone on the Tb0 termination and to switch it to Send&Receive mode. 15. TFO Activation TFO is also activated on the 2G termination once the call is answered, if the conditions to activate TFO are satisfied (see TRS TFO [14]).
3.1.5
3G/2G Terminating call (GMSC)
3.1.5.1 Delayed Backward bearer establishment Only the delayed backward bearer establishment is represented here. The other bearer establishment scenarios can be derived from previous sections. The GMSC always establishes the downstream bearer according to the bearer setup procedure configured for the outgoing circuit trunk, independently of the bearer setup procedure selected by the upstream node.
EDITION
08
RELEASED
En
91/149
MSC A
GMSC-S
1
MGW G
HLR
MSC B
IAM (DestNb,bw,BNCchar,SCL,cot)
SEND ROUTING INFO PROVIDE ROAMING NUMBER PROVIDE ROAMING NUMBER ACK (MSRN) SEND ROUTING INFO ACK (MSRN) IAM (MSRN,bw,BNCchar,SCL',cot) 2 APM (sel.codec & ACS,ACL,Tunnel[IPBCP Request]) ADD $ (S&R,sel. codec,Tunnel[IPBCP Req]) [PBE+TUD] ADD Reply Tgb NOTIFY Tgb (Tunnel[IPBCP Resp]) [TUU] NOTIFY Reply Tgb APM (Tunnel[IPBCP Resp]) 4 ADD $ (SendOnly,sel. codec) [EBE] 5 ADD Reply Tga NOTIFY Tga (Tunnel[IPBCP Req]) [TUU] NOTIFY Reply Tga APM (sel.codec & ACS,ACL,Tunnel[IPBCP Req]) APM (Tunnel[IPBCP Resp])
7 6 3
MOD Tga (Tunnel[IPBCP Resp]) [TUD] MOD Reply Tga Nb FP Initialisation

8
NOTIFY Tga [BEE] 9 NOTIFY Reply Tga Nb FP Initialisation NOTIFY Tgb [BEE] 9 NOTIFY Reply Tgb COT Wait for COT and BEE event
10
COT ACM ACM ANM MOD Tga (S&R) [CTC] MOD Reply Tga ANM bidirectional path
12 11
1. Upon receipt of the IAM, the GMSC-S first interrogates the HLR to retrieve subscriber data and the MSRN allocated by the terminating MSC. A Continuity message may be announced in the IAM.
EDITION
08
RELEASED
En
92/149
2. The GMSC-S propagates the IAM message towards the terminating MSC, with a potentially reduced list of supported codecs (depending on its MGW capabilities and operator codec configuration). The COT indication shall be set in the IAM message since the upstream bearer is not yet established. 3. The terminating MSC returns the selected codec and the tunnelled IP bearer establishment request for the downstream bearer. The GMSC-S seizes the CN downstream termination with the selected codec, relaying the IPBCP request it received. 4. The tunnelled IPBCP response returned by the MGW is forwarded to the terminating MSC. 5. The GMSC-S then seizes the upstream termination with the codec selected downstreams ; the MGW returns the tunnelled IP bearer establishment request for the upstream bearer set-up. Note : in case of an upstream VoIP bearer, the EBE procedure shall not be initiated on the upstream CN termination before the codec negotiation with the succeeding node is completed ; indeed the contents of the IPBCP request that will be prepared by the MGW for the upstream CN bearer depends on the codec configuration. 6. The selected codec and the tunnelled upstream IP bearer establishment request is sent to the preceding SN. 7. The preceding node returns the upstream IP bearer establishment response, which is relayed to the MGW. 8. The Nb Framing protocol is established through the core network in a forward direction. The two terminations of the H.248 context have been defined as supporting the UP package and with Initialisation Direction incoming ; then, when an Initialisation procedure is received from the incoming side (provided the bearer connection from the other termination to its peer MGW is established), the MGW shall start an UP initialisation procedure towards the succeeding MGW, independently of the through-connection of the terminations in the context. 9. BEarer Established (BEE) notification See section 2.6.5. 10. WCS waits for end to end path continuity MSC-SB delays the sending of the CONTINUITY message till end to end path continuity is achieved. See section 2.6.5. 11. The ACM message received from the terminating MSC is propagated to the originating MSC. 12. Upon receipt of the ANM message, the GMSC-S requests the MGW to both-way through-connect the bearer using the Change Through-Connection procedure and propagates the ANM to the originating MSC. If TrFO can be entered, the MGW removes the TBE ; frames pass transparently through the UP entities.
EDITION
08
RELEASED
En
93/149
3.2 Inter-MSC mobile to mobile call establishment via ISUP

ISUP
TDM
Access IP network
Access IP network
AP
AP
Scenarios for mobile originating call, mobile terminating calls are identical to those described in sections 4.2.1.
3.3 Intra-MSC mobile to mobile call establishment

Call flows are illustrated with: IuoAAL2 bearers. Call flows with IuoIP can be derived according to subclause 2.4. the paging & setup/call confirmed procedures being initiated by the originating MSC after the completion of originating 3G radio bearer establishment. Those procedures may be initiated in parallel to the 3G radio bearer establishment, as per subclause 2.6.4.2. Intra-MSC Inter-MGW mobile to mobile call establishment
3.3.1
IP / TDM backbone
Access IP network
Access IP network
AP
AP
The principles for intra-MSC inter-MGW mobile to mobile calls are similar to those of inter-MSC inter-MGW mobile to mobile calls, with the exception that there is no BICC / ISUP signalling exchange. This is illustrated below, taking the example of a 3G to 3G call. The following termination names are used.
EDITION
08
RELEASED
En
94/149
MSC-S A
HLR
RAN B
Party B
MG A
MG B
3.3.1.1 MGWs connected via packet backbone IPBCP is used to establish the inter-MG bearer. The codec to be settled on the inter-MG bearer is the codec negotiated between the originating and terminating half calls, see subclause 2.6.3 and TRS Codec Management [9].
EDITION
08
RELEASED
En
95/149
UE/RNC A
MSC-S A
MGW A
MGW B
UE/RNC B
UE access & security procedures SETUP (UE codec list) CALL PROCEEDING ADD $ (SendOnly,codec,BEE event) [PBE] ADD Reply Ta (BNCid, BIWFad) RAB ASSIGNEMNT REQUEST (BNCid,BIWFad,codec) Bearer establishment (BNCid) Iu FP Initialisation NOTIFY Ta [BEE] NOTIFY Reply Ta RAB ASSIGNMENT RESPONSE ADD $ (S&R,pref.codec) [EBE] ADD Reply Ta0 NOTIFY Ta0 (Tunnel[IPBCP Req]) [TUU] NOTIFY Reply Ta0 Paging & Security SETUP CALL CONFIRMED (UE codec list) ADD $ (S&R,sel. codec,Tunnel[IPBCP Req]) [PBE+TUD] ADD Reply Tb0 NOTIFY Tb0 (Tunnel[IPBCP Resp]) [TUU] NOTIFY Reply Tb0 MOD Ta0 (sel.codec,Tunnel[IPBCP Resp]) [TUD+MBE] MOD Reply Ta0 Nb FP Initialisation NOTIFY Tb0 [BEE] NOTIFY Reply Tb0 NOTIFY Ta0 [BEE] NOTIFY Reply Ta0 ADD $ (S&R,codec) [PBE] ADD Reply Tb (BNCid,BIWFad) RAB ASSIGNMENT REQUEST (BNCid,BIWFad,codec) Bearer Establishment (BNCid) Iu FP Initialisation RFCI value correction RAB ASSIGNMENT RESPONSE ALERTING ALERTING Mod Ta (ring back tone) [SDT] Mod Reply Ta ring back tone towards calling CONNECT Mod Ta (stop Tone, S&R) [SPT, CTC] Mod Reply Ta MOD Ta0 (TFO codec list) [TFO] MOD Reply Ta0 MOD Tb0 (TFO codec list) [TFO] MOD Reply Tb0 CONNECT ACK CONNECT CONNECT ACK conversation
EDITION
08
RELEASED
En
96/149
3.3.1.2 MGWs connected via TDM backbone

UE/RNC A MSC-S A MGW A MGW B UE/RNC B
UE access & security procedures SETUP (UE codec list) CALL PROCEEDING ADD $ (SendOnly,codec,BEE event) [PBE] ADD Reply Ta (BNCid, BIWFad) RAB ASSIGNEMNT REQUEST (BNCid,BIWFad,codec) Bearer establishment (BNCid) Iu FP Initialisation NOTIFY Ta [BEE] NOTIFY Reply Ta RAB ASSIGNMENT RESPONSE Add Ta0 (S&R) [RCI] Add Reply Ta0 Paging & Security SETUP CALL CONFIRMED (UE codec list) Add Tb0 (S&R) [RCI] ADD Reply Tb0 ADD $ (S&R,codec) [PBE] ADD Reply Tb (BNCid,BIWFad) RAB ASSIGNMENT REQUEST (BNCid,BIWFad,codec) Bearer Establishment (BNCid) Iu FP Initialisation RFCI value correction RAB ASSIGNMENT RESPONSE ALERTING ALERTING MOD Ta (ring back tone) [SDT] Mod Reply Ta ring back tone towards calling CONNECT MOD Ta (stop Tone,S&R) [SPT, CTC] MOD Reply Ta MOD Ta0 (TFO codec list) [TFO] MOD Reply Ta0 MOD Tb0 (TFO codec list) [TFO] MOD Reply Tb0 CONNECT Ack CONNECT CONNECT Ack conversation
TFO is activated on the CN termination once the call is answered, if the conditions to activate TFO are satisfied (see TRS TFO [14]).
EDITION
08
RELEASED
En
97/149
3.3.2
Intra-MSC Intra-MGW mobile to mobile call establishment
Access IP network
AP
The principles for intra-MSC intra-MGW mobile to mobile calls are similar to those of intra-MSC inter-MGW mobile to mobile calls, with the exception that only one MGW is involved in the call, and thus that no bearer needs to be established between MGWs. This is illustrated below, taking the example of a 3G to 3G call.
EDITION
08
RELEASED
En
98/149
UE/RNC A
MSC-S A
MGW A
UE/RNC B
UE access & security procedures SETUP (UE codec list) CALL PROCEEDING ADD $ (SendOnly,codec,BEE event) [PBE] ADD Reply Ta (BNCid, BIWFad) RAB ASSIGNEMNT REQUEST (BNCid,BIWFad,codec) Bearer establishment (BNCid) Iu FP Initialisation NOTIFY Ta [BEE] NOTIFY Reply Ta RAB ASSIGNMENT RESPONSE Paging & Security SETUP CALL CONFIRMED (UE codec list) ADD $ (S&R,codec) [PBE] ADD Reply Tb (BNCid,BIWFad) RAB ASSIGNMENT REQUEST (BNCid,BIWFad,codec) Bearer Establishment (BNCid) Iu FP Initialisation RFCI value correction RAB ASSIGNMENT RESPONSE ALERTING ALERTING MOD Ta (ring back tone) [SDT] Mod Reply Ta ring back tone towards calling CONNECT MOD Ta (stop Tone,S&R) [SPT, CTC] MOD Reply Ta CONNECT Ack CONNECT CONNECT Ack conversation
1. The MSC shall start the RAB Assignment procedure towards the called UE only once the RAB assignment is completed at calling side, i.e. upon receipt of the RAB Assignment Response (or Notify Ta).
EDITION
08
RELEASED
En
99/149
MOBILE TO LAND (ISUP) SPEECH CALL ESTABLISHMENT

one outgoing call at the originating VMSC one call at a Border MSC towards PSTN
A Mobile to Land call is composed of :
Only ISUP signalling for the PLMN to PSTN interface is represented in this TRS. SIP call scenarios are specified in TRS MGCF/SIP [27]. The PSTN trunk group may be handled by a MSC server different from the VMSC (Border MSC function not co-located with the VMSC), or by the VMSC itself (Border MSC function co-located with the VMSC). These two cases are respectively described as inter-MSC and intra-MSC mobile to land call establishment. In the former case, BICC or ISUP (or TUP) signalling may be used between the VMSC and the Border MSC. Besides, if there is a transit node between the originating VMSC and the Border MSC, section 6 further specifies the call flows in the transit node.
4.1 Inter-MSC mobile to land call establishment via BICN

Originating MSC BICC Border MSC
ISUP
IP backbone
Access IP network
AP
For the sake of simplicity, it is further assumed in that section that at the Border MSC, the PSTN termination (TDM) and the PLMN termination (IP/ATM) are located on the same MGW. Otherwise an interconnect bearer also needs to be setup. The connection model is the following.
Originating MSC Border MSC
MSC-S A
BMSC-S
MG A
MG B
4.1.1
Originating MSC
3G/2G originating call at originating MSC are identical to originating call scenarios of section 3.1.
EDITION
08
RELEASED
En
100/149
4.1.2
Border MSC

MSC-S MSC-S B MGW B PSTN
BICC_IAM (DestNb,bw, BNCchar,SCL) 1 Add Tb (S&R) [RCI] 2 Add Reply Tb ISUP_IAM (DestNb,cot) 3 ADD $ (SendOnly,sel. codec) [EBE] 4 ADD Reply Tb0 NOTIFY Tb0 (Tunnel[IPBCP Req]) [TUU] NOTIFY Reply Tb0 APM (sel.codec, ACL,Tunnel[IPBCP Req]) APM (Tunnel[IPBCP Resp]) MOD Tb0 (Tunnel[IPBCP Resp]) [TUD] MOD Reply Tb0 Nb FP Initialisation Notify Tb0 [BEE] Notify Reply Tb0 BICC_COT WCS waits E2E path continuity before sending COT
5
ISUP_COT ISUP_ACM 6 BICC_ACM ISUP_ANM 7 MOD Tb0 (S&R) [CTC] MOD Reply Tb0 MOD Tb (TFO codec list) [TFO] MOD Reply Tb BICC_ANM conversation
1. Initial Address message / Delayed backward bearer establishment See section 2.2.3.5. The WCS may also receive in the IAM message an indication that a Continuity message shall be awaited. See section 2.6.5.
EDITION
08
RELEASED
En
101/149
The Border MSC acts as a transit node which provides interworking between PLMN and PSTN. 2. Creation of outgoing side (PSTN) termination The MSC-SB requests the MGW to create the TDM termination on the PSTN side. 3. MSC-SB sends an ISUP IAM message to the PSTN node, indicating that a continuity message shall be awaited since the upstream packet bearer is not yet established. 4. Incoming side (PLMN) bearer establishment See section 2.2.3.5. 5. Continuity message and ISUP_COT message sending MSC-SB delays the sending of the CONTINUITY message till end to end path continuity is achieved. See section 2.6.5. 6. The ACM message received from PSTN is transparently relayed towards the originating MSC 7. Both-way Through connection Upon receipt of the ANM message, MSC-SB through-connects the Tb0 termination (Send&Receive) and sends the BICC ANM to the originating MSC. This corresponds to the conversation start time to be recorded in the CDR generated by MSC-SB. TFO is activated on the PSTN termination once the call is answered, if the conditions to activate TFO are satisfied (see TRS TFO [14]).
4.2 Inter-MSC mobile to land call establishment via ISUP

Originating MSC ISUP Border MSC
ISUP
TDM backbone
Access IP network
AP
4.2.1
Originating MSC
3G/2G/UMA originating call at originating MSC are identical to intra-MSC inter or intra-MGW mobile to land call scenarios of section 4.3. 4.2.2 Border MSC
The call flow at the border MSC is identical to the ISUP-ISUP transit call flow described in section 6.4.
4.3 Intra-MSC mobile to land call establishment
EDITION
08
RELEASED
En
102/149
4.3.1
Intra-MSC Inter-MGW mobile to land call establishment

Originating & Border MSC
ISUP
IP/TDM backbone
Access IP network
AP
The connection model is the following.

Originating and border MSC
MSC-S A
MG A
MG B
Call flows are illustrated with: 3G calls with IuoAAL2 bearers. Call flows with IuoIP can be derived according to subclause 2.4. the ISUP IAM message being sent by the originating MSC after the completion of originating 3G radio bearer establishment. The ISUP IAM message may be sent in parallel to the radio bearer establishment, as per subclause 2.6.4.2.
4.3.1.1 MGWs connected via packet backbone IPBCP is used to establish the inter-MGW bearer. The codec to be settled on the inter-MGW bearer is the codec negotiated between the originating and terminating half calls ( see subclause 2.6.3 and TRS Codec Management [9]).
EDITION
08
RELEASED
En
103/149
This is illustrated for a 3G originating call. Similar principles apply for 2G and UMA originating calls.
UE/RNC A MSC-S A MGW A MGW B PSTN
UE access & security procedures SETUP (UE codec list) CALL PROCEEDING ADD $ (SendOnly,codec,BEE event) [PBE] ADD Reply Ta (BNCid, BIWFad) RAB ASSIGNEMNT REQUEST (BNCid,BIWFad,codec) Bearer establishment (BNCid) Iu FP Initialisation NOTIFY Ta [BEE] NOTIFY Reply Ta RAB ASSIGNMENT RESPONSE ADD Tb (S&R) [RCI] ADD Reply Tb ISUP_IAM (DestNb, cot) ADD $ (S&R,pref.codec) [EBE] ADD Reply Ta0 NOTIFY Ta0 (Tunnel[IPBCP Req]) [TUU] NOTIFY Reply Ta0
ADD $ (S&R,sel. codec,Tunnel[IPBCP Req]) [PBE+TUD] ADD Reply Tb0 NOTIFY Tb0 (Tunnel[IPBCP Resp]) [TUU] NOTIFY Reply Tb0 MOD Ta0 (sel.codec,Tunnel[IPBCP Resp]) [TUD+MBE] MOD Reply Ta0 Nb FP Initialisation NOTIFY Tb0 [BEE] NOTIFY Reply Tb0 NOTIFY Ta0 [BEE] NOTIFY Reply Ta0 WCS waits E2E path continuity before sending COT ISUP_COT ISUP_ACM ALERTING ISUP_ANM MOD Ta (S&R) [CTC] MOD Reply Ta MOD Ta0 (TFO codec list) [TFO] MOD Reply Ta0 MOD Tb (TFO codec list) [TFO] MOD Reply Tb CONNECT CONNECT ACK conversation
4.3.1.2 MGWs connected via TDM backbone This is illustrated for a 3G originating call. Similar principles apply for 2G and UMA originating calls.
EDITION
08
RELEASED
En
104/149
UE/RNC A
MSC-S A
MGW A
MGW B
PSTN
UE access & security procedures SETUP (UE codec list) CALL PROCEEDING ADD $ (SendOnly,codec,BEE event) [PBE] ADD Reply Ta (BNCid, BIWFad) RAB ASSIGNEMNT REQUEST (BNCid,BIWFad,codec) Bearer establishment (BNCid) Iu FP Initialisation NOTIFY Ta [BEE] NOTIFY Reply Ta RAB ASSIGNMENT RESPONSE ADD Tb (S&R) [RCI] ADD Reply Tb ADD Ta0 (S&R) [RCI] ADD Reply Ta0 ADD Tb0 (S&R) [RCI] ADD Reply Tb0 ISUP_IAM (DestNb) ISUP_ACM ALERTING ISUP_ANM MOD Ta (S&R) [CTC] MOD Reply Ta MOD Ta0 (TFO codec list) [TFO] MOD Reply Ta0 CONNECT CONNECT ACK conversation
4.3.2
Intra-MSC Intra-MGW mobile to land call establishment

ISUP
Access IP network
AP
The connection model is described hereafter.
EDITION
08
RELEASED
En
105/149
MSS
ISUP
RAN A Ta Party A remote Party B Tb
MG A
The call scenarios for intra-MSC intra-MGW mobile to land call scenarios can be derived from those on intraMSC inter-MGW mobile to land call establishment, the difference being that no local bearer is settled here between local MGWs. This is illustrated below for the 3G originating call.
UE/RNC A
MSC-S A
MGW A
PSTN
UE access & security procedures SETUP (UE codec list) CALL PROCEEDING ADD $ (SendOnly,codec,BEE event) [PBE] ADD Reply Ta (BNCid, BIWFad) RAB ASSIGNEMNT REQUEST (BNCid,BIWFad,codec) Bearer establishment (BNCid) Iu FP Initialisation NOTIFY Ta [BEE] NOTIFY Reply Ta RAB ASSIGNMENT RESPONSE ADD Tb (S&R) [RCI] ADD Reply Tb ISUP_IAM (DestNb) ISUP_ACM ALERTING ISUP_ANM MOD Ta (S&R) [CTC] MOD Reply Ta MOD Tb (TFO codec list) [TFO] MOD Reply Tb CONNECT CONNECT ACK conversation
EDITION
08
RELEASED
En
106/149
LAND (ISUP) TO MOBILE SPEECH CALL ESTABLISHMENT

one call at a GMSC from PSTN one terminating call at the terminating VMSC
A Land to Mobile call is composed of :
Only ISUP signalling for the PSTN to PLMN interface is represented in this TRS. SIP call scenarios are specified in TRS MGCF/SIP [27]. The PSTN trunk group may be handled by a MSC server different from the VMSC (GMSC function not colocated with the VMSC), or by the VMSC itself (GMSC function co-located with the VMSC). These two cases are respectively described as inter-MSC and intra-MSC land to mobile call establishment. In the former case, BICC or ISUP (or TUP) signalling may be used between the VMSC and the GMSC. Besides, if there is a transit node between the originating VMSC and the GMSC, section 6 further specifies the call flows in the transit node.
5.1 Inter-MSC land to mobile call establishment via BICN

Terminating MSC BICC GMSC
ISUP
IP backbone
Access IP network
AP
For the sake of simplicity, it is further assumed in that section that at the GMSC, the PSTN termination (TDM) and the PLMN termination (IP/ATM) are located on the same MGW. Otherwise an interconnect bearer also needs to be set up. The connection model is the following.
GMSC Terminating MSC
GMSC-S
MSC-S B
RAN B remote Party A Tga Tgb Tb0 Tb Party B
MG G
MG B
EDITION
08
RELEASED
En
107/149
5.1.1
GMSC

PSTN ISUP_IAM (MSISDN)
1
GMSC-S
MGW G
HLR
MSC B
ADD Tga (SendOnly) [RCI] Add Reply Tga SEND ROUTING INFO PROVIDE ROAMING NUMBER PROVIDE ROAMING NUMBER ACK (MSRN) SEND ROUTING INFO ACK (MSRN) ADD $ (S&R,pref. codec]) [PBE] ADD Reply Tgb IAM (MSRN,bw,BNCchar,SCL)
2
APM (sel.codec, ACL,Tunnel[IPBCP Request]) MOD Tgb (sel. codec,Tunnel[IPBCP Req]) [MBE,TUD] MOD Reply Tgb NOTIFY Tgb (Tunnel[IPBCP Resp]) [TUU] NOTIFY Reply Tgb APM (Tunnel[IPBCP Resp]) Nb FP Initialisation NOTIFY Tgb [BEE] NOTIFY Reply Tgb ISUP_COT WCS waits E2E path continuity before sending COT
3
COT ACM ISUP_ACM ANM Mod Tga (S&R,TFO codec list) [CTC,TFO] Mod Reply Tga ISUP_ANM conversation
1. The IAM message may indicate that a continuity message shall be awaited. 2. The GMSC propagates the IAM message towards the terminating MSC with the list of supported codecs. A continuity indicator shall be set in the IAM if required (see section 2.6.5). 3. If a continuity indicator was sent in the BICC_IAM message, a BICC Continuity message shall be sent when end to end path continuity is achieved (see section 2.6.5).
EDITION
08
RELEASED
En
108/149
5.1.2
Terminating MSC
3G/2G/UMA terminating call at terminating MSC are identical to terminating call scenarios of section 3.1.
5.2 Inter-MSC land to mobile call establishment via ISUP

Terminating MSC ISUP GMSC
ISUP
TDM backbone
Access IP network
AP
5.2.1
GMSC
The call flow at the GMSC is identical to the ISUP-ISUP transit call flow described in section 6.4 (with the only difference that the HLR is also interrogated in the case of a GMSC terminating call). 5.2.2 Terminating MSC
3G/2G/UMA terminating call at terminating MSC are identical to intra-MSC inter or intra-MGW land to mobile call scenarios of section 5.3.
5.3 Intra-MSC land to mobile call establishment

5.3.1 Intra-MSC Inter-MGW land to mobile call establishment
ISUP
IP/TDM backbone
Access IP network
AP
The connection model is the following.
EDITION
08
RELEASED
En
109/149
MSC-S B
GMSC and Terminating MSC
RAN B remote Party A Tga Tgb Tb0 Tb Party B
MG G
MG B
5.3.1.1 MGWs connected via packet backbone IPBCP is used to establish the inter-MGW bearer. The codec to be settled on the inter-MG bearer is the codec negotiated between the originating and terminating half calls (similar behaviour as for inter-MSC calls, but the codec negotiation remains internal to the MSC, see subclause 2.6.3 and TRS Codec Management [9])). This is illustrated for 2G terminating calls.
EDITION
08
RELEASED
En
110/149
PSTN
HLR
MSC-S B
MGW G
MGW B
BSC/MS B
ISUP_IAM (MSISDN) ADD Tga (SendOnly) [RCI] Add Reply Tga SEND ROUTING INFO PROVIDE ROAMING NUMBER PROVIDE ROAMING NUMBER ACK (MSRN) SEND ROUTING INFO ACK (MSRN) Paging & Security SETUP CALL CONFIRMED (UE codec list) ADD $ (S&R,sel. codec) [EBE] ADD Reply Tgb NOTIFY Tgb (Tunnel[IPBCP Resp]) [TUU] NOTIFY Reply Tgb ADD $ (S&R,sel. codec,Tunnel[IPBCP Req]) [PBE+TUD] ADD Reply Tb0 NOTIFY Tb0 (Tunnel[IPBCP Resp]) [TUU] NOTIFY Reply Tb0 MOD Tgb (Tunnel[IPBCP Resp]) [TUD] MOD Reply Tgb Nb FP Initialisation Notify Tb0 [BEE] Notify Reply Tb0 Notify Tgb [BEE] Notify Reply Tgb ISUP_COT WCS waits E2E path continuity before RAB assignment ASSIGNMENT REQUEST ASSIGNMENT COMPLETE ADD Tb (S&R) [RCI] ADD Reply Tb ALERTING ISUP_ACM MOD Tga (ring back tone) [SDT] MOD Reply Tga ring back tone towards calling CONNECT MOD Tga (stop Tone,S&R,TFO codec list) [SPT, CTC,TFO] Mod Reply Tga MOD Tb (TFO codec) [TFO] Mod Reply Tb ISUP_ANM CONNECT ACK conversation
5.3.1.2 MGWs connected via TDM backbone This is illustrated for 2G terminating calls.
EDITION
08
RELEASED
En
111/149
PSTN
HLR
MSC-S B
MGW G
MGW B
BSC/MS B
ISUP_IAM (MSISDN) ADD Tga (SendOnly) [RCI] Add Reply Tga SEND ROUTING INFO PROVIDE ROAMING NUMBER PROVIDE ROAMING NUMBER ACK (MSRN) SEND ROUTING INFO ACK (MSRN) Paging & Security SETUP CALL CONFIRMED (UE codec list) ADD Tgb (S&R) [RCI] ADD Reply Tgb ADD Tb0 (S&R) [RCI] ADD Reply Tb0 ISUP_COT WCS waits E2E path continuity before RAB assignment ASSIGNMENT REQUEST ASSIGNMENT COMPLETE ADD Tb (S&R) [RCI] ADD Reply Tb ALERTING ISUP_ACM MOD Tga (ring back tone) [SDT] MOD Reply Tga ring back tone towards calling CONNECT MOD Tga (stop Tone,S&R) [SPT, CTC] Mod Reply Tga ISUP_ANM CONNECT ACK conversation
5.3.2
Intra-MSC Intra-MGW land to mobile call establishment

ISUP
Access IP network
AP
EDITION
08
RELEASED
En
112/149
ISUP
MSS
RAN B remote Party A Ta Tb Party B
MG A
The call scenarios for intra-MSC intra-MGW land to mobile call scenarios can be derived from those on intraMSC inter-MGW land to mobile call establishment, the difference being that no local bearer is settled here between local MGWs. This is illustrated below for the 2G terminating call.
PSTN HLR MSC-S B MGW B BSC/MS B
ISUP_IAM (MSISDN) ADD Tga (SendOnly) [RCI] Add Reply Tga SEND ROUTING INFO PROVIDE ROAMING NUMBER PROVIDE ROAMING NUMBER ACK (MSRN) SEND ROUTING INFO ACK (MSRN) Paging & Security SETUP CALL CONFIRMED (UE codec list) ISUP_COT WCS waits E2E path continuity before RAB assignment ASSIGNMENT REQUEST ASSIGNMENT COMPLETE ADD Tb (S&R) [RCI] ADD Reply Tb ALERTING ISUP_ACM MOD Tga (ring back tone) [SDT] MOD Reply Tga ring back tone towards calling CONNECT MOD Tga (stop Tone,S&R) [SPT, CTC] Mod Reply Tga ISUP_ANM CONNECT ACK conversation
EDITION
08
RELEASED
En
113/149
TRANSIT CALL ESTABLISHMENT
6.1 BICC-BICC transit call

Originating MSC Transit MSC BICC Border MSC BICC
IP backbone
IP backbone
Access IP network
AP
UMAN
The transit MSC relays calls between the preceding and succeeding switching nodes (e.g. an originating MSC and a border MSC, as exemplified in the figure above). For the sake of simplicity, it is assumed that only one transit MGW is needed for BICC-BICC transit call (e.g. fully meshed transport network). Otherwise an interconnect bearer needs to be set up. It is also assumed in that section that the same bearer establishment procedure is used upstreams and downstreams (interworking between different bearer setup is also supported). The connection model is described hereafter.
BICC BICC
Transit MSS
remote Party A
Ta
remote Party B Tb
MG
The call flow below is represented with the delayed backward bearer establishment procedure. The call scenario for the BICC-BICC transit call is identical to the call flow of BICC-BICC GMSC terminating call of section 3.1.5, with the exception that there is here no exchange with the HLR. See the same section for the comments of the call flow.
EDITION
08
RELEASED
En
114/149
MSC A
Transit MSC-S
Transit MGW
MSC B
IAM (DestNb,bw,BNCchar,SCL,cot) ADD $ (S&R,pref.codec) [PBE] ADD Reply Tb IAM (MSRN,bw,BNCchar,SCL',cot) APM (sel.codec,ACL,Tunnel[IPBCP Request]) MOD Tb (sel. codec,Tunnel[IPBCP Req]) [MBE,TUD] MOD Reply Tb NOTIFY Tb (Tunnel[IPBCP Resp]) [TUU] NOTIFY Reply Tb APM (Tunnel[IPBCP Resp]) Add $ (SendOnly,sel. codec) [EBE] Add Reply Ta NOTIFY Ta (Tunnel[IPBCP Req]) [TUU] NOTIFY Reply Ta APM (sel.codec,ACL,Tunnel[IPBCP Req]) APM (Tunnel[IPBCP Resp]) Mod Ta (Tunnel[IPBCP Resp]) [TUD] Mod Reply Ta Nb FP Initialisation Notify Ta [BEE] Notify Reply Ta Nb FP Initialisation Notify Tb [BEE] Notify Reply Tb COT WCS waits E2E path continuity before sending COT COT ACM ACM ANM Mod Ta (S&R) [CTC] Mod Reply Ta ANM conversation
EDITION
08
RELEASED
En
115/149
The downstream bearer is established before the upstream bearer to simplify the setting of the 3GUP properties (see section 2.7.1.5.5) and because, in the case of VoIP bearer, the contents of IPBCP Request the transit MGW shall generate is function of the codec negotiated with the terminating MSC.
6.2 BICC-ISUP transit call

The call flow is identical to the one specified in section 4.1.2.
6.3 ISUP-BICC transit call

The call flow is identical to the one specified in section 5.1.1, with the only difference that there is no exchange with the HLR in case of a transit call.
6.4 ISUP-ISUP transit call

One or two transit MGWs may be involved at the transit MSC. 6.4.1 Intra-MSC Intra-MGW transit call
Originating MSC Transit MSC ISUP Border MSC ISUP
TDM backbone
TDM backbone
Access IP network
AP
UMAN

ISUP ISUP
Transit MSS
remote Party A
Ta
remote Party B Tb
MG
TDM hairpinning is supported by the 5060 WCS, i.e. no IP loop is established between the two TDM terminations.
EDITION
08
RELEASED
En
116/149
MSC A
Transit MSC-S IAM (DestNb,cot)
Transit MGW
MSC B
ADD Ta (SendOnly) [RCI] ADD Reply Ta ADD Tb (S&R) [RCI] ADD Reply Tb IAM (DestNb,cot) COT COT ACM ACM ANM MOD Ta (S&R) [CTC] MOD Reply Ta ANM conversation
6.4.2
Intra-MSC Inter-MGW transit call

Originating MSC ISUP Transit MSC ISUP Border MSC
TDM backbone
IP/TDM backbone
TDM backbone
Access IP network
AP UMAN
EDITION
08
RELEASED
En
117/149
ISUP
Transit MSS
ISUP
remote Party A
Ta
Ta0
Tb0
remote Party B Tb
MG A
MG B
6.4.2.1 MGWs connected by packet backbone

MSC A Transit MSC-S MGW A MGW B MSC B
IAM (DestNb,cot) IAM (DestNb,cot) 1 ADD Ta (SendOnly) [RCI] ADD Reply Ta ADD $ (S&R,sel.codec) [EBE] 2 ADD Reply Ta0 NOTIFY Ta0 (Tunnel[IPBCP Resp]) [TUU] NOTIFY Reply Ta0 ADD $ (S&R,sel.codec,Tunnel[IPBCP Req]) [PBE+TUD] ADD Reply Tb0 NOTIFY Tb0 (Tunnel[IPBCP Resp]) [TUU] NOTIFY Reply Tb0 Mod Ta0 (Tunnel[IPBCP Resp]) [TUD] Add Reply Ta0 Add Tb (S&R) [RCI] Add Reply Tb Nb FP Initialisation Notify Tb0 [BEE] Notify Reply Tb0 Notify Ta0 [BEE] Notify Reply Ta0 COT WCS waits E2E path continuity before sending COT COT
3
ACM ACM ANM Mod Ta (S&R) [CTC] Mod Reply Ta ANM
EDITION
08
RELEASED
En
118/149
1. The IAM is forwarded to the succeeding node, with the indication that a CONTINUITY message shall be awaited if required (see section 2.6.5). 2. The local bearer between the two MGWs is established with IPBCP. 3. A Continuity message is sent to the succeeding node when end to end path continuity is achieved (see section 2.6.5). 6.4.2.2 MGWs connected by TDM backbone
MSC A Transit MSC-S MGW A MGW B MSC B
IAM (DestNb,cot) ADD Ta (SendOnly,TDM) [RCI] ADD Reply Ta ADD Ta0 (S&R,TDM) [RCI] ADD Reply Ta0 ADD Tb0 (S&R,TDM) [RCI] ADD Reply Tb0 ADD Tb (S&R,TDM) [RCI] ADD Reply Tb IAM (DestNb,cot) COT COT ACM ANM MOD Ta (S&R) [CTC] MOD Reply Ta ANM
EDITION
08
RELEASED
En
119/149
DATA CALL ESTABLISHMENT
CSD call scenarios are specified in TRS Circuit Switched Data [15]. Multimedia call scenarios are specified in TRS Circuit Switched Multimedia Service [16]. All the general principles specified in section 0 also apply to data calls, with the following exceptions : TFO & VQE features are not activated ; Codec negotiation should only be performed for SCUDIF multimedia calls (the Multimedia Dummy Codec MuMe is normally negotiated in that case, together with speech codecs). For other data calls, the IAM normally only contains TMR/USI informations, as specified in [16] ; the same TMR is also configured on the Mc interface. In the specific case of data call originated by a POTS subscriber, the MSC-S located between the PSTN and the terminating MSC may be unaware of the actual type of service requested by the originator (speech or data) ; in that case it will indicate a speech call and propose codec(s) in accordance to the algorithms specified in [9], but a codec non transparent for the data call may be negotiated if the terminating VMSC is a legacy MSC. This is further described in [9]. Support IVVR service (RDS12591a)
7.1 Support IVVR service (RDS12591a)
Enhanced on voice based IVR, IVVR can provide the interactive service on video call, for an example, VOD(video on demand): subscriber will first make video call to a specific number, when video call is setup, subscriber enters a video based interface to input his choice, after the selection is made, the requested video is played and charging really starts.
But the problem comes due to the charging starting point. Only when CONNECT is sent to UE, video calls user plane is started to buildup, in other words, without CONNECT message, subscriber cant enter a video based interface to experience IVVR. But the sending CONNECT message implies to start charging in existing code, so subscriber will be over-charged when he makes choice in IVVR interface before the requested video is played.
So by RDS12951a, under MRBT scenario, when ACM message comes from IVVR platform, WCS sends CONNECT to UE to trigger user plane setup, when ANM message comes from IVVR platform which means the requested video is started to play, WCS starts charging, and doesnt send CONNECT to UE anymore.
EDITION
08
RELEASED
En
120/149
Specific numbers for the deployed IVVR platforms is assigned. When the called party number matches those specific numbers, WCS translation function indicates Cpcallm that it is IVVR service. When Cpcallm knows it is IVVR service(only based on specific number, not care about the service speech or video call), it shall send ALERTING and additional CONNECT message to UE on reception of ACM message. And suppress charging until the ANM message comes in.
To assure the success of H245 setup, when incoming signaling is ISUP&BICC and succeeding switch sends ACM(sub_free) or CPG(alerting), video calls user plane shall be bi-way through connected.
EDITION
08
RELEASED
En
121/149
DELAY MT CALL( RDS12969)
Per 3GPP 24.008 section 4.5.3.1, If an RR connection used for a MM specific procedure exists to the mobile station, the CM request may be rejected or delayed depending on implementation. When the MM specific procedure has been completed, the network may use the same RR connection for the delayed CM request. " WCS behavior is to reject MT call before RDS12969 implementation. The limitations of WCS are detailed as followings (two race cases): If MT is in the paging phase and no paging response received yet, the succeeding LU will kill the MT. MT CM activities and related resources will be released, and no second paging for the MT. If MS is in Location Update procedure, the succeeding MT will be rejected as User Busy.
By RDS12969, WCS supports delay MT call when parallel Location Update. It applies to 2G and 3G. The details are as following:
ID::RDS12969:R001: MT is suspended in the race case first MT(paging) then LU After the authentication of the A/Iu Location Update Request or at the receipt of Gs Location Update, the ongoing paging procedure shall be stopped. The pending MT CM requests shall remain suspended. Note: Before the authentication complete of the Location Update, the paging procedure is not affected. ID::RDS12969:R002: MT is suspended in the race case first LU then MT During the location update procedure, a new MT CM request shall be suspended. ID::RDS12969:R003: MT will be continued after A/Iu LU After A/Iu Location Update is accepted (and TMSI allocation is complete), instead of releasing the RR connection, MSC shall use the same RR connection to continue all MT CM activities. And won't do access procedure again. This also applies to UMA. NOTE: Classmark 2 is always present in the 3G Location Update. For 2G, if Classmark2 is not present in Location Update, then WCS, under this condition(MT shall be continued after A/Iu LU) and only under this condition, needs to get CM2 using Classmark Request systematically in 2G Location Update. Currently Classmark Request procedure is disabled in Location Update by RDS6536/RDS5721. ID::RDS12969:R004: Paging response will be discarded during Gs LU During the Gs Location Update, if the paging response is received for the same MS, MSC shall release the RR layer and SCCP connection of paging request. ID::RDS12969:R005: MT will be continued after Gs LU
EDITION
08
RELEASED
En
122/149
After Gs Location Update is accepted (and TMSI allocation is complete), MSC shall send Gs paging using the new LAI updated during location update. When the paging response is received, MSC shall perform the MM procedures and then continue all MT CM activities. MSC shall try the second paging via A/Iu if the Gs paging is the first paging and timeout. ID::RDS12969:R006: Abnormal case handling If Location Update fails, MSC shall release the suspended MT CM activities. ID::RDS12969:R007: second or third paging race case shall also be considered MSC shall continue MT CM activities if Location Update comes after second or third paging message sending with the following exception: MSC shall release MT CM activities if Gs Location Update comes after third paging message sending. If Location Update is received via A/Iu, after A/Iu Location Update is accepted (and TMSI allocation is complete), instead of releasing the RR connection, MSC shall use the same RR connection to continue all MT CM activities. And won't do access procedure again. This also applies to UMA. NOTE: Whether second paging or third paging can be done and how to be done are also decided by system configurations for second paging and third paging. For Gs Location Update, that means, in order to avoid too many pagings, based on the paging configuration, if Gs location update is received during the last paging, the MT call be rejected.
EDITION
08
RELEASED
En
123/149
CALL CLEARING
The release scenarios are equivalent whatever the radio access, the only difference being that either BSSAP or RANAP messages are used. A 3G call release is illustrated for the network initiated call clearing case, and a 2G call release for the user initiated call clearing case. The scenarios apply for both TDM and IP based CSCN.
9.1 Network initiated call clearing

In this chapter, the terms "incoming" and "outgoing" refer to the direction of propagation of the Release message, not to the direction of the original call establishment. The following connection model applies.
Originating MSC GMSC Terminating MSC
MSC-S A
GMSC-S
HLR
MSC-S B
RAN A Ta Party A Ta0 Tga Tgb Tb0 Tb
RAN B
Party B
MG A
MG G
MG B
9.1.1
At GMSC Server (Border MSC / Transit MSC)
MSC A RELEASE 1
GMSC-S
MGW G
MSC B
SUBTRACT Tga [RTE] SUBTRACT Reply Tga RELEASE COMPLETE RELEASE 2 RELEASE COMPLETE SUBTRACT Tgb [RTE] SUBTRACT Reply Tgb
1. Call clearing from the incoming side : once the Release message has been received from the preceding node, the GMSC server releases any MGW allocated resources for the incoming side. If any resources were seized in the MGW, the GMSC server uses the Release Termination procedure to indicate to the MGW to remove the incoming side bearer termination and that the bearer can be released towards the preceding MGW. After the resources in the MGW are released, the GMSC server sends the Release Complete message to the preceding node. 2. Call clearing to the outgoing side : the GMSC server sends the Release message to the succeeding node. Once the succeeding node has sent the Release Complete message, the GMSC server releases any MGW allocated resources for the outgoing side. If any resources were seized in the MGW, the GMSC server uses
EDITION
08
RELEASED
En
124/149
the Release Termination procedures to indicate to the MGW to remove the outgoing side bearer termination and that the bearer can be released towards the succeeding MGW.
9.1.2
VMSC Server
UE A RNC A MSC-S A MGW A GMSC
RELEASE DISCONNECT 1 SUBTRACT Ta0 [RTE]

2
SUBTRACT Reply Ta0 RELEASE COMPLETE ADD $ (audio termination, topology) [PBE] MOD Reply Taudio RELEASE
4 3
RELEASE COMPLETE Iu RELEASE COMMAND 5 Bearer Release

6
Iu RELEASE COMPLETE 7 SUBTRACT Taudio [RTE] SUBTRACT Reply Taudio SUBTRACT Ta [RTE] SUBTRACT Reply Ta
1. Upon receipt of the Release message from the network, the MSC-S initiates call clearing towards the UE, 2. and releases any MGW allocated resources for the network side. If any resources were seized in the MGW, the 5060 WCS uses the Release Termination procedure to indicate to the MGW to remove the network side bearer termination and that the bearer can be released towards the preceding MGW. 3. The MSC-S may activate the generation of a tone or announcement towards the mobile subscriber. In the latter case, an audio termination is seized. 4. Upon receiving the DISCONNECT message from the network, the UE sends a RELEASE message to the network, to which the network answers by a RELEASE COMPLETE message. 5. The MSC-S initiates the release of all the resources associated to the Iu connexion : Iu transport resources and established Radio Bearer. 6. The RNC releases the access bearer, as defined in section 2.3.2. 7. When all Iu transport resources have been successfully released, the RNC acknowledges the Iu release to the MSC-S, and the MSC-S releases any MGW allocated resources for the access side using the Release Termination procedure. Note Without RDS 8197a, when releasing a mobile terminated call after receipt of the ALERTING message but before receipt of the CONNECT message, the WCS does not send a DISCONNECT message to the called UE, but directly sends a RELEASE message which is then answered by a RELEASE COMPLETE message. This behaviour leads certain handsets to generate a continous ringing.
EDITION
08
RELEASED
En
125/149
9.2 User initiated call clearing

MS BSC A
1
MSC-S A
MGW A
GMSC
DISCONNECT RELEASE
3
RELEASE 2 RELEASE COMPLETE CLEAR COMMAND

4
CLEAR COMPLETE SUBTRACT Ta [RTE]

5
SUBTRACT Reply Ta RELEASE COMPLETE SUBTRACT Ta0 [RTE] SUBTRACT Reply Ta0
6
1. The mobile station initiates the clearing of a call by sending a DISCONNECT message to the network. 2. The MSC-S sends a RELEASE message to the network side. 3. The MSC-S proceeds with the call clearing procedure towards the MS by sending a Release message, to which the MS answers by a RELEASE COMPLETE message. 4. The MSC-S requests the BSC to release the resources associated to the call (CIC and radio channel). When all the resources have been successfully released, the BSC acknowledges the clear command to the MSC-S. 5. Upon receipt of the Clear Complete message from the BSC, the MSC-S releases the RAN termination using the Release Termination procedure. 6. Upon receipt of the Release Complete message, the MSC-S releases the network side termination by using the Release Termination procedure.
9.3 (G)MSC Server initiated call clearing

9.3.1 GMSC Server initiated
MSC A
GMSC-S
MGW G
MSC B
RELEASE RELEASE RELEASE Complete SUBTRACT Tga [RTE] SUBTRACT Reply Tga RELEASE Complete SUBTRACT Tgb [RTE] SUBTRACT Reply Tgb
EDITION
08
RELEASED
En
126/149
9.3.2
VMSC Server initiated

MS A BSC A
1
MSC-S A
MGW A
GMSC
DISCONNECT RELEASE
RELEASE RELEASE COMPLETE CLEAR COMMAND CLEAR COMPLETE SUBTRACT Ta [RTE] SUBTRACT Reply Ta
RELEASE COMPLETE SUBTRACT Ta0 [RTE] SUBTRACT Reply Ta0
9.4 MGW initiated call clearing

The 5060 WCS does not require the MGW to report a notification when it detects the normal or abnormal release of a bearer, e.g. following a network failure or upon a normal AAL2 connection release. MGW initiated call clearing scenarios are hence not supported. The WCS releases the call and the associated resources in the MGW upon receipt of call release signalling at the call control signalling level, once end users hang up.
EDITION
08
RELEASED
En
127/149
10 INTERACTIONS WITH CAMEL/IN SERVICES

All the general principles (IP bearer setup, codec negotiation, end to end path continuity ) specified in section 0 also apply upon interactions with CAMEL/IN services, in particular when : establishing a call within the VoIP or 3GIP packet backbone (e.g. T-CSI on DP12 with a Continue or Connect request leading to establish BICC or packet interconnect bearers) ; having to generate an announcement or tones (e.g. prepaid warning tones requested to be played by the prepaid SCP) ; having to detect DTMFs (e.g. SCP server requests the CAMEL subscribers to enter DTMF), codec negotiation in case of call redirection requested by the CAMEL server.
Some examples are specified further down. A comprehensive description of CAMEL/IN services and scenarios supported by the 5060 WCS can be found in the TRS CAMEL/IN [17].
10.1 Pre-paid interactions

In this example, the calling subscriber has the prepaid service. A VoIP/3GIP call is setup after interactions with the SCP (O-CSI) credit not exhausted. Later on, after the call was answered, the SCP requests the MSC to send prepaid warning tones to the subscriber (account nearly exhausted).
UE/RNC A MSC-S A MGW A gsmSCF GMSC/BMSC
call setup initiation (see previous scenarios) InitialDP(...) ApplyCharging(Tcp,tone) Continue/Connect BICC_IAM(DestNbr,bw,BNCchar,SCL,cot) Call setup continuation (see previous scenarios) BICC_ANM EventReportBCSM(O_Answer)
3 2 1
RequestReport-BCSM-Event(BCSMEvent)
Call setup termination (see previous scenarios) CONNECT CONNECT ACK Tcp-TW expiry
4
Mod T1 (send toneId,ext dir)[SDT] Mod Reply T1 tone sent Mod T1 (stop toneId)[SPT] Mod Reply T1 Call termination (see previous scenarios)
5
1. The MSC-S is requested by the gsmSCF (in the CAP ApplyCharging operation) to insert a tone before release of the call. The tone has to be sent at TW s before the end of the call period (Tcp value, provided by the gsmSCF). 2. On the Continue/Connect request from the gsmSCF, the call is established toward the called party (codec negotiation is performed as already described in previous originating call scenarios). 3. At called party answer, the gsmSCF is informed (for charging purpose).
EDITION
08
RELEASED
En
128/149
4. TW s before expiry of the call period (Tcp), the MSC requests the MGW to send prepaid warning tones to the prepaid subscriber. 5. After receipt of the acknowledge from the MSC-S, the call is continued and completed normally.
10.2 Follow on at GMSC-S after called party release

MSC-o GMSC-S MGW gsmSCF VMSC-t/BMSC
call established (with TrFO or with Tc at Boarder MSC) BICC_REL EventReport-BCSM(event type, ...) Connect Subtract T3 Bearer Release Substract Reply T3 BICC_RLC BICC_IAM(DestNbr,bw,BNCchar,SCL,cot) BICC_APM(selected codec & ACS,ACL,TunnelInfo) Call continuation (can be considered as similar to call forwarding scenario) Iu FP initialisation
With regard to establishment of the new call toward the new destination indicated by the gsmSCF, the scenario is as the one described for Call Forwarding in [2] (this can be considered as similar to the resume call handling scenario in GMSC, for which gsmSCF may also be invoked). See [9] for codec negotiation aspects.
10.3 Temporary Connection to a Specialized Resource Function (gsmSRF)

A temporary connection to a gsmSRF may be requested by the CAMEL server : 1. At call establishment (including the failure cases), 2. At called party release of an established call. This section assumes that BICC signaling is used between the originating MSC and the GMSC. 10.3.1 Upstream bearer not yet established The following call scenario corresponds to the case where a connection to the gsmSRF is needed at HLR interrogation before continuation of the call toward the initially called CAMEL subscriber or a new destination indicated by the CAMEL server, i.e. before codec negotiation and bearer establishment are performed with originating MSC. This is illustrated with a scenario involving an assisting SSF, even though not supported in this release.
EDITION
08
RELEASED
En
129/149
VMSC (originating) (call control) MSC Server
GMSC (call control) MSC Server
HLR MAP
MSC (assisting)
MSC Server CAP gsm SCF
CAP
BICC
SSF (initiating)
BICC
SSF (assisting)
ISUP gsm SRF
H.248
(transport)
H.248
H.248
MGW ATM/IP (e.g. AMR2) T4
MGW IP (e.g. AMR2) T3 T2
MGW TDM (G711) T1
Tc
MSC-o
GMSC-S (SSF-i)
MGW-i/MGW-a
GMSC-S (SSF-a)
gsmSCF
gsmSRF
BICC_IAM (MSISDN,bw,BNCchar,SCLo,cot) HLR interrogation (1st SRI, res with T-CSI info) InitialDP (no IPSSPcapabilities) EstablishTemporaryConnection(AssitingSSFid,SCFid,Correlid[,bothwayThrCx]) BICC_IAM (AssistingSSFid,bw,BNCchar,SCL,SCFid,CorrelId) AssistRequestInstruction(Correlid,IPSSPcap) ConnectToResource(IP address,ServIntInd(=bwThrCx))) ISUP_IAM <handling of tunnel info for bearer establishment on Nb toward assisting SSF/MGW (T3 term.)> BICC_APM (sel. Codec & ACS,ACL,TunnelInfo4) <handling of tunnel info for bearer establishment on Nb & Nb FP init on calling side> Nb FP Initialisation between MGW-i & -a BICC_COT Synchro COT & NOTIFY (bearer established on calling side) BICC_COT Synchro COT & NOTIFY (bearer established betweenMGW-i & -a) ISUP_COT ISUP_CON/ANM Mod (T1,S&R) [CTC] Mod Reply T1 BICC_CON/ANM BICC_CON/ANM Mod T3 (S&R) [CTC] Mod Reply T3 Prompt&CollectUserInfo(CollectedInfo,InfoToSend,...) ISUP_USR (PCUI inv)) <Announcement & collect of DTMF digits if any< ISUP_USR (PCUI res) Prompt&CollectUserInfo res(collected digits) DisconnectForwardConnection release of the connection to the assisting SSF & gsmSRF (same as for OC case) Continue HLR interrogation (2nd SRI) call continuation (based on routing info received from HLR)
With regard to establishment of the temporary connection to the gsmSRF the scenario is similar to the one described in section Error! Reference source not found.. With regard to establishment of the call between the originating MSC and the GMSC see section 3.1. The DTMF digits prompted by the calling user are received out-of-band by the GMSC from the originating MSC (BICC signalling) and transmitted also out-of-band to the assisting SSF (BICC signalling). The assisting SSF requests its MGW to send the DTMF digits in-band to the gsmSRF. The signalling sequence between the
EDITION
08
RELEASED
En
130/149
user and the gsmSRF is as described in section Error! Reference source not found. with an addidtional BICC signalling segment to transport the DTMF digits out-of-band. The call continuation further to indication from the CAMEL server is handled in the same way as for call forwarding at GMSC in the case where the bearer has already been established with the calling side. With regard to the codec renegotiation which might be invoked, see [9]. 10.3.2 Upstream bearer already established The following call scenario corresponds to the case where a connection to the gsmSRF is requested by the CAMEL server further to report of the call release by the called party. The difference with regard to the previous one is that the codec is already selected (e.g. AMR2) and the bearer is established on the calling side. The codec is negotiated on the downstream bearer as defined in [9]. If any, the initiating SSF receives the DTMF digits out-of-band on the BICC signalling from the originating VMSC.
MSC-o GMSC-S (SSF-i) MGW-i/MGW-a GMSC-S (SSF-a) gsmSCF gsmSRF
BICC_REL received fom the called side - codec negotiated & bearer established (not shown) Bearer release on the called side (not shown, same as on previous scenarios) EventReport-BCSM EstablishTemporaryConnection(AssitingSSFid,SCFid,Correlid[,bothwayThrCx]) BICC_IAM (AssistingSSFid,bw, BNCchar,SCL,SCFid,CorrelId,cot) AssistRequestInstruction(Correlid,IPSSPcap) ConnectToResource(IP address[,ServIntInd(=bwThrCx)]) ISUP_IAM <handling of tunnel info for bearer establishment on Nb between initiating & assisting SSF/MGW> Nb FP Initialisation between MGW-i & -a BICC_COT Synchro COT & NOTIFY (bearer established betweenMGW-i & -a) ISUP_COT ISUP_CON/ANM Mod (T2,S&R) [CTC] Mod Reply T2 BICC_CON/ANM Mod T4 (S&R) [CTC] Mod Reply T4 Prompt&CollectUserInfo inv (CollectedInfo,InfoToSend,...) ISUP_USR (PCUI inv)) <Announcement & collect of DTMF digits if any> ISUP_USR (PCUI inv)) Prompt&CollectUserInfo res(collected digits) DisconnectForwardConnection release of the connection to the assisting SSF & gsmSRF Continue release on the calling side (see previous scenarios)
10.4 Intermediate packet bearers to reach the SRF

During call establishment, a connection to a Specialized Resource Function (gsmSRF) (also called Intelligent Peripheral (IP)) may be needed for interaction with the calling user (e.g. announcement to be played, need of subscriber input (e.g. DTMF digits)). Reference [12] specifies the 5060 WCS support of Internal /External SRF and the corresponding call scenarios. When a packet backbone is deployed in the PLMN, packet bearers may be required between the initiating SSF and the standalone SRF (via a BICC-ISUP transit node), or between the initiating SSF and the assisting SSF, or between the initiating/assisting SSF and the external SRF (via a BICC-ISUP transit node). In such a case, VoIP / 3GIP bearers are established as specified in section 3.1. DTMFs sent by the mobile calling party are exchanged via DTMF out of band within the packet backbone. The codec settled on the packet bearer may be compressed (see [9]). A continuity indicator may be sent to the SRF if the upstream bearer is not yet established. 3BL 61719 AAAA PBZZA EDITION 08 RELEASED En 131/149
As an illustration, the following message exchange shows the case where RTP bearers are used between an initiating and assisting SSF (even though assisting SSF not supported in this release).
VMSC (originating) (call control) MSC Server CAP gsm SCF MSC Server MSC (assisting)
CAP
SSF (initiating) RANAP H.248
BICC
SSF (assisting)
ISUP gsm SRF
RNC (orig.)
(transport)
H.248
MGW ATM (e.g. AMR2 ) T1 IP (e.g. AMR2) T3
MGW TDM (G711) T4
Tc
T2
3G OC case - Connection to the Intelligent Peripheral (IP) via a gsmSSF assisting function
EDITION
08
RELEASED
En
132/149
UE/RNC A
MSC-S (SSF-i)
1
MGW-i
MSC-S (SSF-a)
MGW-a
gsmSCF
gsmSRF
UE access & security procedures Setup (UE codec list) Call Proceeding
Add $ (SendOnly,pref.codec,NotifyRequest) [PBE] Add Reply T1 (BNCid, BIWFad) RAB Assignment Request (BNCid,BIWFad,pref. codec) Bearer establishment (BNCid) Iu FP Initialisation Notify T1 [BEE] Notify Reply T1 RAB Assignment Response calling checked as a CAMEL subscriber InitialDP (no IPSSPcapabilities)
2
EstablishTemporaryConnection(AssitingSSFid,SCFid,Correlid[,bothwayThrCx]) 3 BICC_IAM (AssistingSSF,bw, BNCchar,SCL,SCFid, Correlid,cot)

4
AssistRequestInstruction(Correlid,IPSSPcap) 5 ConnectToResource(IP address,ServIntInd(=bwThrCx))) Add $ (S&R,TDM) [RCI] Add Reply T4 Add $ (SendOnly,sel. codec,NotifyRequest)[EBE] Add Reply T3 (Tunnel[IPBCP Req])[TUU] ISUP_IAM (PAddr,cot) BICC_APM (sel. codec, ACL,Tunnel[IPBCPP Req]) 9 Add $ (S&R,sel.codec,Tunnel[IPBCP Req]) [PBE+TUD] Add Reply T2 (Tunnel[IPBCP Acc]) [TUU] BICC_APM (Tunnel[IPBCP Acc]) Mod T3 (Tunnel[IPBCP Acc])[TUD] Mod Reply T3 Iu FP Initialisation Notify T3 [BEE] Notify Reply T3 BICC_COT
10 8 7 6
ISUP_COT ISUP_CON/ANM 11 Mod T3 (S&R) [CTC] Mod Reply T3 BICC_CON/ANM 12 Mod T1 (S&R) [CTC] Mod Reply T1 Connect Connect Ack Prompt&CollectUserInfo(CollectedInfo,InfoToSend,...) ISUP_USR (PCUinv) Tone played until receipt of 1rst digit to be collected (e.g.)
13
EDITION
08
RELEASED
En
133/149
UE/RNC A
MSC-S (SSF-i)
14
MGW-i
MSC-S (SSF-a)
MGW-a
gsmSCF
gsmSRF
StartDTMF(digit1) StartDTMF Ack
BICC_APM(StartDTMF(digit1,duration,notif)) 15 Mod T4 (DTMF(digit1),duration) [SDD] Mod Reply T4 BICC_APM(StartDTMF Ack) StopDTMF StopDTMF Ack if any, other DTMF digits sending in the same way> 17 ISUP_USR(PCUIres) DisconnectForwardConnection(collected digits) BICC_REL ISUP_REL ISUP_RLC Subtract T3, T4 [RTE] Substract Reply T3, T4 BICC_REL Subtract T2 [RTE] Substract Reply T2 Continue/Connect 20 Call continuation
19 18 16
DTMF(digit1) in-band
Prompt&CollectUserInfo res(collected digits)
1. The RAB assignment is triggered on the originating MSC side (same signalling as for previously described originating call scenarios). 2. At subscription checking by the MSC-S, the calling party is detected as a CAMEL subscriber and the CAMEL server (gsmSCF) is invoked. The CAP InitialDP operation does not contain the IP-SSP-Capabilities parameter, which means that the gsmSRF is not connected to the originating VMSC. 3. If the involved CAMEL service requires the use of an Intelligent Peripheral (e.g. for playing announcement and collecting user information from the calling subcriber), the originating VMSC is requested by the gsmSCF to establish a temporary connection (ETC operation) toward a gsmSSF assisting function in order to reach a gsmSRF function. The address of the gsmSSF assisting, together with a correlation identifier and the gsmSCF address is provided in the ETC operation. 4. The gsmSCF identity and the Correlation Id are included in the BICC IAM message. 5. The assisting SSF interrogates the gsmSCF with AssistRequestInformation (ARI) operation, based on the identity received in the IAM. The correlation id is provided for the gsmSCF to link this request with the previous ETC operation. IP capabilities are also indicated. 6. Further to receipt of the ARI operation, the gsmSCF requests the assisting SSF to connect to a gsmSRF via the ConnectToResource (CTR) operation. The ServiceInteractionIndicator (SII2) parameter may be present and set to 'bothwayThroughConnection' if the calling user is requested to provide input information (e.g. DTMF digits) (also assumed if absent). 7. After receipt of the CTR operation terminations on the gsmSRF side and gsmSSF initiating sides are taken in the MGW of the assisting gsmSSF. 8. The ISUP IAM message is sent by the assisting SSF to establish the connection with the gsmSRF. 9. The assisting SSF sends the BICC APM to the initiating SSF for bearer establishment (same signalling as for previously described originating call scenarios). 10. The assisting SSF waits for BICC COT from the initiating SSF (if indicated in IAM message) and notification of bearer establishment on Nb interface to send an ISUP COT messge to the gsmSRF. 11. On receipt of the ISUP CON/ANM message from the gsmSRF, the assisting SSF asks its MGW to set the corresponding terminations as bothway through-connected and propagates the corresponding BICC CON/ANM to the initiating SSF.
EDITION
08
RELEASED
En
134/149
12. On receipt of the BICC CON/ANM at the SSF assisting side, the terminations are through connected in the MGW. At that point in time, the gsmSRF and the calling user are through connected : if requested by the gsmSCF, announcement can be played and listen to, DTMF digits can be received by the gsmSRF from the user, as described on the following. 13. In order to start interaction with the calling subscriber, the PromptAndCollectUserInformation (PCUI) operation is sent by the gsmSCF to the assisting SSF. That PCUI operation indicates the announcement to be played to the user, the information to be collected(e.g. DTMF). It is forwarded to the gsmSRF encapsulated within the ISUP USR message. 14. Each DTMF digit is sent out-of-band from the UE to the MSC-S (DTAP Start DTMF). The acknowledge (DTAP Start DTMF Ack) is sent back by the MSC-S to the UE. 15. The DTMF digit is sent out-of-band via BICC signalling (APM message) to the assisting SSF. 16. On the assisting SSF side, DTMF digits can be sent in-band only to the gsm SRF. On receipt of the BICC APM, the assisting SSF asks its MGW to send the indicated DTMF digit on the gsmSRF termination. BICC APM is sent to the initiating SSF. 17. New DTMF digits, if required, are sent in the same way. 18. When all the requested digits have been collected, the gsmSRF sends the PCUI result operation, encapsulated within ISUP signalling to the assisting SSF. That PCUI result is then forwarded to the gsmSCF. 19. After processing of the collected information, the gsmSCF triggers the release of the gsmSRF by sending the CAP DisconnectForwardConnection to the MSC-S. The MSC-S asks the initiating SSF for release of the assisting SSF leg. This triggers release of the assisting SSF and gsmSRF resources. The MSC-S waits for instruction from the gsmSCF for continuation or release of the call. 20. The gsmSCF indicates that the call can be continued to the originally called party (CAP Continue) or to an other destination (CAP Connect). This might be similar to the case of a new call initiated after having put the existing call on hold and requiring change of codec-related information.
10.5 Follow on at originating MSC after call release

This scenario deals with the case where the CAMEL server is invoked at release of the network leg of an established call and requests connection to a new destination.
UE/RNC A MSC-S A MGW A gsmSCF GMSC/BMSC
call established (with TrFO or with Tc at GMSC/Boarder MSC) BICC_REL EventReport-BCSM(event type, ...) Connect check if new destination allowed Subtract T2
3 2 1
Bearer Release Substract Reply T2 BICC_RLC BICC_IAM(DestNbr,bw,BNCchar,SCL,cot)

4
BICC_APM(selected codec & ACS,ACL,TunnelInfo) Call continuation (not detailed)

5
Iu FP initialisation
1. The MSC-S reports the call release (initiated by the network side) to the gsmSCF. 2. The gsmSCF requests connection to a new destination. 3. The MSC-S triggers the release of the called leg which leads to release completion on the network side. 3BL 61719 AAAA PBZZA EDITION 08 RELEASED En 135/149
4. The MSC-S requests creation of the new destination leg. This can be considered as similar to the initiation of a new call after having put an existing call on hold (i.e. resources on the calling side not released) 5. Depending on the codec negotiated for the new call, a RAB modification might be required (see [9]).
EDITION
08
RELEASED
En
136/149
11 CONTINUITY TEST SCENARIOS 11.1 General principles

On TDM networks where intermediate switches are under control of signaling system N7, it is a requirement to provide facility in order to check the continuity from end to end of any 64k circuit. The test can be operated: at any time and on any circuit by an operator command (operator continuity test), or at the call setup time on the circuit selected for the call (call by call continuity test).
Circuit continuity is tested by the exchange of specific frequencies on the circuit. Two types of networks have to be considered prior to performing continuity tests : 4 wires networks : concerns the overwhelming majority of today networks. These are digital networks from end to end and it can be assumed that no echo situation occurs ; 2 wire networks : networks with analog transport, that may still be rarely encountered in some transit networks. Echo situation can occur and must be taken into account by the continuity test procedure.
Procedure on a 2 wire type circuit The MSC Server may either play the role of the switching exchange controlling & initiating the test, or the remote exchange responding to the test. The switching exchange controlling the test connects a receiver-transmitter on the circuit under test and transmits forward a 2000 Hz frequency signal. The remote exchange also connects a receiver-transmitter on that circuit, and upon detection of the 2000 Hz signal, sends back a 1780 Hz frequency signal. Upon detection of the 1780 Hz signal, the switching exchange that initiated the test shall determines whether continuity check requirements are fullfiled. The result of the test is also negative if : The test frequency 1780 Hz is not received correctly 2 seconds after the transmission of the 2000 Hz signal on the circuit ; or if The received signal is not at the non operating level 1 second after the interruption of the transmission of the 2000 Hz signal.
Procedure on a 4 wire type circuit The procedure is similar as for the 2 wire circuit, with the difference that the remote exchange loops back the circuit under test. Hence the switching exchange initiating the test shall detect back the 2000 Hz signal instead of a 1780 Hz signal. As the type of continuity test procedure to be run is not specified on the Mc interface, the MGW involved in the continuity test shall know the type of each TDM circuit : 2 or 4 wires to run the appropriate procedure.
Continuity tests are not required/not supported for BICC circuits.
EDITION
08
RELEASED
En
137/149
11.2 Operator continuity test

11.2.1 Successful continuity test on outgoing circuit
MSC-S Add Ta (TDM) [RCI] 1 Add Reply Ta
MGW
Remote SN
Continuity Check Request 2 Mod Ta (ct signal,cmp event) [CCT] 3 Add Reply Ta continuity tone 4 continuity tone continuity tone detected Notify Ta (cmp event, success) [CTV] 5 Notify Reply Ta Release 6 Release Complete Substract Ta [RTE] 7 Substract Reply Ta
1. The MSC-S seizes the TDM termination corresponding to the circuit to be tested. 2. The MSC-S initiates the continuity test towards the remote switching node by sending a CCR message with the indication of the CIC to be tested. 3. Continuity Check Tone procedure : the MSC-S requests the MGW to send a continuity test tone (continuity test signal) and to report the outcome of the test when completed (test completion event) 4. The MGW applies the continuity tone. 5. Continuity Test Verify procedure : the MGW reports a successful outcome if it recognizes the continuity tone within the required delay. 6. The circuit is released. 7. The TDM termination is freed.
EDITION
08
RELEASED
En
138/149
11.2.2 Unsuccessful continuity test on outgoing circuit
MSC-S Add Ta (TDM) [RCI] 1 Add Reply Ta
MGW
Remote SN
Continuity Check Request 2 Mod Ta (ct signal,cmp event) [CCT] 3 Add Reply Ta continuity tone 4 continuity failure detected Notify Ta (cmp event, failure) [CTV] 5 Notify Reply Ta Continuity (failure) 6 Substract Ta [RTE] 7 Substract Reply Ta Add Ta (TDM) [RCI] 8 Add Reply Ta Continuity Check Request
1. The MSC-S seizes the TDM termination corresponding to the circuit to be tested. 2. The MSC-S initiates the continuity test towards the remote switching node by sending a CCR message with the indication of the CIC to be tested. 3. Continuity Check Tone procedure : the MSC-S requests the MGW to send a continuity test tone (continuity test signal) and to report the outcome of the test when completed (test completion event) 4. The MGW applies the continuity tone. 5. Continuity Test Verify procedure : the MGW reports a failure if it does not recognizes the continuity tone within the required delay. 6. The MSC-S sends a Continuity message indicating the failure of the continuity test. 7. The termination is freed. 8. The MSC-S periodically repeats the complete procedure until the continuity test succeeds, as specified by Q.764 [67] and Q.724 [68].
EDITION
08
RELEASED
En
139/149
11.2.3 Continuity test on incoming circuit
Remote SN
MSC-S
MGW
Continuity Check Request 1 Add Ta (TDM, rsp signal) [RCI,CCR] 2 Add Reply Ta continuity tone 3 continuity tone Release 4 Release Complete Substract Ta [RTE] 5 Substract Reply Ta
1. The MSC-S gets the information that a continuity test is requested by the preceding node. 2. The MSC-S seizes the corresponding TDM termination and requests the MGW to respond to a continuity test by configuring the response signal (Continuity Check Response procedure). Upon reception of a command with the rsp signal, the MGW loops back the circuit in case of a 4 wire circuit, or connects a receiver-transmitter in case of a 2 wire circuit. 3. The continuity tone is either looped-backed (4 wire circuit), or answered by a 1780 Hz signal (2 wire circuit). 4. The circuit is released. 5. The termination is freed.
EDITION
08
RELEASED
En
140/149
11.3 Call by call continuity test

11.3.1 Successful continuity test on outgoing circuit
MS/BSC A
MSC-S
MGW
PSTN
MS access & security procedures Setup (MS codec list) Call Proceeding Assignment Request Assignment Complete Add Ta (SendOnly,TDM) [RCI] Add Reply Ta Add Tb (S&R,TDM) [RCI] Add Reply Tb ISUP_IAM (DestNb,continuity test required) 1 Mod Tb (ct signal,cmp event) [CCT] 2 Add Reply Tb continuity tone 3 continuity tone continuity tone detected Notify Ta (cmp event, success) [CTV] 4 Notify Reply Ta Continuity (success) 5 ISUP_ACM 6 Alerting IAM_ANM Mod Ta (S&R) [CTC] Mod Reply Ta Connect Connect Ack conversation
1. The MSC-S indicates in the IAM message the request to perform a continuity test on the circuit selected for the call (Bits DC of Nature of Connection IE indicates continuity check required on this circuit). 2. Continuity Check Tone procedure : the MSC-S requests the MGW to send a continuity test tone (continuity test signal) and to report the outcome of the test when completed (test completion event) 3. The MGW applies the continuity tone. 4. Continuity Test Verify procedure : the MGW reports a successful outcome if it recognizes the continuity tone within the required delay.
EDITION
08
RELEASED
En
141/149
5. The MSC-S informs the destination node of the successful outcome of the continuity test. 6. The destination exchange withholds sending the address complete message until a successful continuity indication has been received. The call establishment proceeds normally up to the conversation phase. Note At a transit node, the receipt of an ISUP IAM message with the request to perform a continuity test on the circuit shall not prevent the sending of the IAM message to the succeeding node. The ISUP or BICC IAM sent downstreams then indicates that a continuity test is performed on a previous circuit (ISUP) or that a COT shall be expected (BICC). In the specific case of downstream ISUP circuit whereby call by call continuity test is also required, the IAM indicates continuity check required on this circuit.
EDITION
08
RELEASED
En
142/149
11.3.2 Unsuccessful continuity test on outgoing circuit
MS/BSC A
MSC-S
MGW
PSTN
MS access & security procedures Setup (MS codec list) Call Proceeding Assignment Request Assignment Complete Add Ta (SendOnly) [RCI] Add Reply Ta Add Tb (S&R) [RCI] Add Reply Tb ISUP_IAM (DestNb,continuity test required) 1 Mod Tb (ct signal,cmp event) [CCT] 2 Add Reply Tb continuity tone 3 continuity failure detected Notify Ta (cmp event, failure [CTV] 4 Notify Reply Ta Continuity (failure) 5 Substract Ta [RTE] 6 Substract Reply Ta Disconnect 7 REL RLC Clear Command Clear Complete Subtract Ta [RTE] Substract Reply Ta Add Tb (SendOnly) [RCI] 8 Add Reply Tb Continuity Check Request
1. The MSC-S indicates in the IAM message the request to perform a continuity test on the circuit selected for the call (Bits DC of Nature of Connection IE indicates continuity check required on this circuit).
EDITION
08
RELEASED
En
143/149
2. Continuity Check Tone procedure : the MSC-S requests the MGW to send a continuity test tone (continuity test signal) and to report the outcome of the test when completed (test completion event) 3. The MGW applies the continuity tone. 4. Continuity Test Verify procedure : the MGW reports a failure if it does not recognizes the continuity tone within the required delay. 5. The MSC-S sends a Continuity message indicating the failure of the continuity test. 6. The termination is freed. 7. The MSC-S releases the call. 8. The MSC-S periodically repeats the operator continuity test scenario, see section 11.2.1, as specified by Q.764 [67] and Q.724 [68]. 11.3.3 Continuity test on incoming circuit
Remote SN
MSC-S B
MGW B
BSC B
ISUP_IAM (DestNb,continuity test required) 1 Add Tb0 (rsp signal) [RCI,CCR] 2 Add Reply Tb0 Paging & Security Setup Call Confirmed (MS codec list) Add Tb (S&R) [RCI] Add Reply Tb continuity tone 3 continuity tone Continuity (success) 4 Mod Tb0 (empty signal) [CCR] 5 Mod Reply Tb0 End of mobile terminated call scenario 6
1. The MSC-S gets the information in the IAM message that a continuity test is requested by the preceding node and starts T8 timer (as specified in Q.764 [67]). 2. The MSC-S seizes the corresponding TDM termination and requests the MGW to respond to a continuity test by configuring the response signal (Continuity Check Response procedure). Upon reception of a command with the rsp signal, the MGW loops back the circuit in case of a 4 wire circuit, or connects a receiver-transmitter in case of a 2 wire circuit. In parallel, the MSC-S starts the mobile terminating scenario up to the assignment procedure.
EDITION
08
RELEASED
En
144/149
3. The continuity tone is either looped-backed (4 wire circuit), or answered by a 1780 Hz signal (2 wire circuit). 4. The MSC-S gets the information from the preceding node that the continuity test was successful. 5. Upon reception of the Continuity message, the MSC-S ends the continuity test response in the MGW by sending a Mod command with an empty signal list. 6. The MSC-S then proceeds with the mobile terminating call scenario (assignment procedure up to conversional phase). In case T8 timer expires before reception of the Continuity message, the MSC-S releases the call. If an indication of continuity check failure is received in a continuity message, timer T27 is started awaiting a continuity re-check request. Upon expiry of T27, a reset circuit message is sent to the preceding exchange (see Q.764 and Q.724).
The MSC-Server shall not request the MGW to detect in-band DTMF during the continuity test on the incoming circuit. Any such request shall be differed after the successful completion of the continuity test, i.e. after the MSC-Server has stopped the continuity test in the MGW (step 5).
EDITION
08
RELEASED
En
145/149
12 RESTRICTIONS / LIMITATIONS
Main restrictions / limitations common to W4.32 SP1 and W5.0: H.248 is not supported;
Main restrictions / limitations specific to W4.32 SP1: Iu-cs over IP (RDS 8242b);
GLOSSARY/TERMINOLOGY
MGC / MSC-S / MSC Server MSC Local bearer Internal bearer Termination Media Gateway Controller / / MSc Server / Mobile Switching Centre Call Server. MSC Server and its MGWs
Bearer between two MGWs of the same MGC Bearer between 2 terminations of the same MGW Logical entity on a MGW that sources and/or sinks media and.or control streams. A termination is described by a number of characterizing properties, which are grouped in a set of Descriptors that are included in commands. Physical termination Termination representing a physical entity and having a semi-permanent existence. E.g. a termination representing a TDM channel exists as long as it is provisioned in the MGW. Ephemeral termination Termination existing only during the duration of their use, respectively created and deleted by means of an Add and Substract command. E.g. RTP termination. Association between a collection of terminations that the MGC and the MGW use to Context establish, maintain and clear calls. Contexts are identified by a ContextID which is assigned by the MGW and is unique within the MGW. The null context contains all the idle physical terminations. The topology of a context describes the flow of media between the terminations (who Topology hears/sees whom). Both-way / One-way Terminations that are both-way or one-way connected from a H.248 topology point of connected view. The stream mode of the terminations can be set to any value (INA, send, receive, send&receive) Through-connected Terminations that are both-way connected and whose stream mode is set to Send&Receive. upstream / downstream Respectively the incoming or outgoing termination or bearer with regard to the direction of termination or bearer the call set-up (and not to the direction of the bearer set-up)
EDITION
08
RELEASED
En
146/149
LIST OF ABBREVIATIONS
Table 1 Abbreviations
ACD ACL ACM ACS AIW ANM APM AVP BC BCP BEE BEM BER BICC BIT BIWF
Announcement CompleteD : Notify that the announcement is completed Available codec list (codec list negotiated for a particular call through out of band signalling and propagated from the terminating MSC Server to the originating MSC Server) Address Complete Message Active codec set (list of codec modes negotiated for the selected codec for a particular call through out od band signalling and propagated from the terminating MSC Server to the originating MSC Server) Activate InterWorking function : Activate the interworking function Answer Message Application Transport Message Activate Voice Processing function : Activate the voice processing (echo cancellation and gain control) function Bearer Capabilities Bearer Control Protocol BEarer Established : Notify to the MGC that the bearer is established BEarer Modification support : Notify the MGC that the established bearer can be modified BEarer Released : Notify to the MGC that the bearer is released or the bearer establishment failed Bearer Independent Call Control Bearer Information Transport : name of the H.248 event and signal allowing to convey tunnelled bearer control signalling. Bearer InterWorking function : A functional entity which provides bearer control functions (BCF) and media mapping/switching functions within the scope of a Serving Node (BCFN, BCF-T or BCF-G) and one or more MCF and MMSF, and is functionally equivalent to a Media Gateway that incorporates bearer control. The address on which the BNC is terminated Backbone Network Connection : Represents the edge-to-edge transport connection within the backbone network, consisting of one or more Backbone Network Connection Links (BNCL). The Backbone Network Connection represents a segment of the end-toend Network Bearer Connection (NBC Base Station Controller (GSM) Centralized Automatic Message Accounting Channel Associated Signalling Call Instance Code COntinuity test Completed CM Service Prompt (i.e. possibility to support or not network initiated mobile originating call) Call Mediation Node : A functional entity which provides call service functionality without an associated bearer control function entity Core Network Connect message ConTinuity message Change Through-Connection : Change the through-connection termination DetecT Dtmf : Request detection of a DTMF tone Dual Tone Multi-Frequency Establish Bearer : Request a bearer establishment Emergency Services Network Entity Emergency Services Routing Digits in the bearer
BIWF address BNC
BSC CAMA CAS CIC COC CMSP CMN CN CON COT CTC DTD DTMF EBE ESNE ESRD 3BL 61719 AAAA PBZZA
EDITION
08
RELEASED
En
147/149
ESRK IAM IBE ICO ISDN ISUP IP IWI JBE MBE MG MGC MO MSC-O MSC-T MT PBE PCP PYA RAB RAN RBE RCI RCO REL RNC RVF RTD RTE RTP SCL SDD SDT SN SPA SPD SPDD SPT SRI SS SSF TBE TCD TDM TFO TUD TUU UP
Emergency Services Routing Key Initial Address Message Isolate BEarer termination : Isolate one bearer from the other bearer terminations within the context Initiate COntinuity test Integrated Services Digital Network ISDN User Part Internet Protocol InterWorking Indication : Notify the MGC about Interworking function protocol changes Join BEarer termination : Join a bearer termination with other terminations within the context Modify BEarer characteristics : Modify the bearer characteristics Media Gateway Media Gateway Controller Mobile Originating MSC where an Originating call is performed MSC where an Terminating call is performed Mobile Terminating Prepare Bearer : Prepare a bearer establishment Prolonged Clearing Procedure (i.e. generic procedure to delay the sending of the RELEASE COMPLETE message from the MSC to the MS when the RELEASE message has been received from the MS) PlaY Announcement : Play an announcement Radio Access Bearer : transport resource for user data between the User Equipment (UE) and the Core Network (CN) Radio Access Network Release Bearer : Release the bearer Reserve Circuit : Select a TDM circuit in the MG Respond COntinuity test Release message Radio Network Controller (UMTS) Radio control and VLR Function ReporT Dtmf : Report a detected DTMF tone Release Termination : Release the bearer termination Real time Transport Protocol Supported codec list (list of codecs propagated from the originating MSC Server to the terminating MSC Server during BICC codec negotiation SenD Dtmf : Request the sending of a DTMF tone SenD Tone : Send a tone Serving Node : a functional entity that is either an ISN (interface serving node), a GSN (gateway serving node) or a TSN (transit serving node) see Q.765.5 StoP Announcement : Stop an announcement StoP Dtmf : Stop the sending of a DTMF tone StoP Dtmf Detection : Stop detection of a DTMF tone StoP Tone : Stop a tone Send Routing Information Supplementary Service Service Switching Function TrFO Break Equipment Tone CompleteD : Notify that the tone is completed Time Division Multiplex activate TFO Activate Tandem Free Operation TUnnel information Down : Transfer tunnel data from the MGC to the MG Tunnel information Up : Transfer tunnel data from the MGW to the MGC User Plane
EDITION
08
RELEASED
En
148/149
END OF DOCUMENT
EDITION
08
RELEASED
En
149/149

3bl61719aaaapbzza 08 en

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3bl61719aaaapbzza 08 en

Uploaded by

Copyright:

Available Formats

All rights reserved.

External call scenarios : basic calls

Edition Date Change Note

03 11 February 2008 Update

04 March 2009 Update

06/07 June 2010 Update

08 March 2011 Update

3BL 61719 AAAA PBZZA

ABSTRACT REVIEW HISTORY

Ed.01 on 01/2005 Ed.02 on 12/2005

Ed.03 Pr01 09/2007

Ed.03 Pr02 02/2008 Ed.04 Pr01 03/2009

3BL 61719 AAAA PBZZA

INTERNAL REFERENCED DOCUMENTS

3BL 61719 AAAA PBZZA

3BL 61719 AAAA PBZZA

External call scenarios:

Alcatel-Lucent 5060 Wireless Call Server

TECHNICAL REQUIREMENT SPECIFICATION

3BL 61719 AAAA PBZZA

INTERACTIONS WITH CAMEL/IN SERVICES........................................................................ 128

3BL 61719 AAAA PBZZA

3BL 61719 AAAA PBZZA

3BL 61719 AAAA PBZZA

3BL 61719 AAAA PBZZA

3BL 61719 AAAA PBZZA

SCOPE OF THE DOCUMENT

2.1 MSC layered architecture and interfaces

3BL 61719 AAAA PBZZA

PSTN / legacy MSC

RANAP IPBCP (IP)

UMAN (Bluetooth, 802.11, ..)

ATM-based packet backbones are not supported.

2.2 IP bearer establishment & release in BICC Core Network

3BL 61719 AAAA PBZZA

Figure 2 Protocols used for IP bearer bearer establishment

MGW-O REQUEST 1 ACCEPTED 2

IPBCP Figure 3 Successful IPBCP bearer establishment

3BL 61719 AAAA PBZZA

REQUEST REJECTED 1 REQUEST CONFUSED 2

3BL 61719 AAAA PBZZA

Delayed Forward Fast Backward Delayed Backward

APM (Connected) exchange :

3BL 61719 AAAA PBZZA

IAM (Connect fw, tunnelling to be used,TunnelInfo[IPBCP Req],SCL)

3BL 61719 AAAA PBZZA

3BL 61719 AAAA PBZZA

2.2.3.3 Delayed Forward bearer establishment procedure

ADD $ (TunOpt,TIND event,preferred codec,3GUP) [PBE] Add Reply Ta

IAM (Connect fw, tunnelling to be used, No tunnelled data,SCL)

3BL 61719 AAAA PBZZA

3BL 61719 AAAA PBZZA

2.2.3.4 Fast backward bearer establishment procedure

3BL 61719 AAAA PBZZA

Figure 8 Delayed backward bearer establishment

3BL 61719 AAAA PBZZA

3BL 61719 AAAA PBZZA

ID::RDS11777:R001; APM segmentation configuration

3BL 61719 AAAA PBZZA

3BL 61719 AAAA PBZZA

ID::RDS11777:R003; APM segmentation procedure Acknowlegdment of first APM segment

with APM-user information: