V 041

Information
System System Description CN GSM/UMTScs

A50016-D1112-V41-2-7618
DRAFT
System Description CN GSM/UMTScs
Information System
Important Notice on Product Safety

Elevated voltages are inevitably present at specific points in this electrical equipment. Some of the parts may also have elevated operating temperatures. Non-observance of these conditions and the safety instructions can result in personal injury or in property damage. Therefore, only trained and qualified personnel may install and maintain the system. The system complies with the standard EN 60950 / IEC 60950. All equipment connected has to comply with the applicable safety standards.
The same text in German: Wichtiger Hinweis zur Produktsicherheit In elektrischen Anlagen stehen zwangslufig bestimmte Teile der Gerte unter Spannung. Einige Teile knnen auch eine hohe Betriebstemperatur aufweisen. Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Krperverletzungen und Sachschden fhren. Deshalb wird vorausgesetzt, dass nur geschultes und qualifiziertes Personal die Anlagen installiert und wartet. Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Angeschlossene Gerte mssen die zutreffenden Sicherheitsbestimmungen erfllen.
Trademarks: All designations used in this document can be trademarks, the use of which by third parties for their own purposes could violate the rights of their owners.
Copyright (C) Siemens AG 2005.

Issued by the Communications Group Hofmannstrae 51 D-81359 Mnchen Technical modifications possible. Technical specifications and features are binding only insofar as they are specifically and expressly agreed upon in a written contract.
DRAFT
A50016-D1112-V41-2-7618
Information System
This document consists of a total of 346 pages. All pages are issue 2.
Contents
1 1.1 1.2 1.3 2 2.1 2.1.1 2.1.2 2.2 2.2.1 2.2.2 2.3 2.4 2.4.1 2.4.2 2.5 2.5.1 2.5.2 2.6 2.6.1 2.6.2 2.7 2.7.1 2.7.1.1 2.7.1.2 2.7.1.3 2.7.2 2.7.2.1 2.7.2.2 2.7.2.3 2.7.2.4 3 3.1 3.1.1 3.1.1.1 3.1.1.2 3.1.2 3.1.3 3.1.4 3.1.4.1 3.1.4.2 Overview of System Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Documentation Overview of System Description . . . . . . . . . . . . . . . . . . . . Scope of the CN GSM/UMTScs Description. . . . . . . . . . . . . . . . . . . . . . . . Definition of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Architecture of the Circuit-Switched Domain of the Core Network (CNcs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Combination of Network Elements of the Core Network (CN) Nodes. . . . . Integrated Circuit-Switched CN Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stand-Alone Circuit-Switched CN Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware Architecture of an MSC/VLR Node. . . . . . . . . . . . . . . . . . . . . . . CP Platform Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MP Platform Parts - within the Circuit-Switched Domain . . . . . . . . . . . . . . Hardware Architecture of a GSM MGW Node (2G only) . . . . . . . . . . . . . . Hardware Architecture of a GMSC Node . . . . . . . . . . . . . . . . . . . . . . . . . . CP Platform Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MP Platform Parts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware Architecture of an HLR/AC Classic (HLRc) Node . . . . . . . . . . . CP Platform Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MP Platform Parts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware Architecture of an EIR Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . CP Platform Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MP Platform Parts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software Architecture of an MSC Node, HLR/ACc Node, EIR Node . . . . . Software Architecture of the CP Platform . . . . . . . . . . . . . . . . . . . . . . . . . . Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software Architecture of the MP Platform. . . . . . . . . . . . . . . . . . . . . . . . . . Main processor (MP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TRAU server card, type D (TSCD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AAL2 break server (A2BS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Line interface cards (LIC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functions of the Circuit-Switched Domain of Core Network (CNcs) Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functions of the Circuit-Switched Domain of Core Network (CNcs) . . . . . . Functions of the MSC Network Element . . . . . . . . . . . . . . . . . . . . . . . . . . . Functions of the GSM MGW Network Element (2G only) . . . . . . . . . . . . . . Functions of the VLR Network Element . . . . . . . . . . . . . . . . . . . . . . . . . . . Functions of GCR Network Element (2G only) . . . . . . . . . . . . . . . . . . . . . . Functions of the GMSC Network Element . . . . . . . . . . . . . . . . . . . . . . . . . Functions of the HLR/AC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functions of the HLR Network Element . . . . . . . . . . . . . . . . . . . . . . . . . . . Functions of the AC Network Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 15 17 17 18 19 19 20 20 21 32 36 39 39 39 41 41 41 42 42 43 45 45 46 48 50 51 51 52 52 52 54 54 54 56 57 59 60 60 60 63
A50016-D1112-V41-2-7618
DRAFT
Information System
3.1.5 3.2 3.3 3.3.1 3.3.1.1 3.3.1.2 3.3.1.3 3.3.2 3.3.3 3.3.4 3.3.4.1 3.3.5 3.3.5.1 3.3.5.2 3.3.6 3.3.6.1 3.3.6.2 3.3.7 3.3.7.1 3.3.8 4 4.1 4.1.1 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.3 4.3.1 4.3.2 4.3.2.1 4.3.2.2 4.3.2.3 4.3.3 4.3.3.1 4.3.3.2 4.3.3.3 4.3.4 4.3.5 4.4 4.4.1 4.4.2 4.5 4.5.1
Functions of the EIR Network Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 CSC Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Functions of the IN/CAMEL Subsystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Functions of the IN/CAMEL Subsystem in the Core Network (CNcs) . . . . . 69 SSP+MSC/VLR in the CNcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 CAMEL Phase Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Support of Prepaid Service for Circuit-Switched Services . . . . . . . . . . . . . . 71 Categories of IN/CAMEL Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 IN/CAMEL Entry (Triggering) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 CAMEL Phase 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Charging Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 CAMEL Phase 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Functional Network Architecture of CAMEL Phase 2. . . . . . . . . . . . . . . . . . 75 CAMEL Phase 2 Feature Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 CAMEL Phase 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 CAMEL Phase 3 Feature Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 CAMEL Phase 3 Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 CAMEL Phase 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 CAMEL Phase 4 Feature Package (Step1) . . . . . . . . . . . . . . . . . . . . . . . . . 85 Special CAMEL Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Network Functions of the Circuit-Switched Domain of Core Network (CNcs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Overall Functions Both in the Circuit-Switched and Packet-Switched Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Separated or Combined Mobility Management . . . . . . . . . . . . . . . . . . . . . . 89 Transport and Signaling Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 CN Transport Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 CN Signaling Capabilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 CN Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Transport and Signaling Handling with Transit-MSC . . . . . . . . . . . . . . . . . . 93 Transport Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Requirements and Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 TDM Based . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Flat TDM Based CN Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Hierarchical TDM Based CN Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Access to the TDM Backbone Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 ATM Based . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Flat ATM Based CN Scenarios (3G only) . . . . . . . . . . . . . . . . . . . . . . . . . 101 Hierarchical ATM Based CN Scenarios (3G only) . . . . . . . . . . . . . . . . . . . 104 Access to the ATM Backbone CN (3G only) . . . . . . . . . . . . . . . . . . . . . . . 106 IP Based. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Interworking Between TDM and ATM Based Networks . . . . . . . . . . . . . . . 109 Signaling Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Mode of Operation within the CN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 SS7 Network Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Basic Functions of Call Handling - for Traffic over TDM CN . . . . . . . . . . . 117 Mobile-Originated Call (MOC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
DRAFT
A50016-D1112-V41-2-7618
Information System
4.5.2 4.5.3 4.5.4 4.5.5 4.5.6 4.5.7 4.5.8 4.5.8.1 4.5.8.2 4.5.9 4.5.10 4.5.11 4.5.12 4.5.13 4.5.13.1 4.5.13.2 4.5.13.3 4.5.13.4 4.5.13.5 4.5.14 4.5.15 4.5.16 4.6 4.6.1 4.6.2 4.6.3 4.6.4 4.6.5 4.6.6 4.7 4.7.1 4.7.2 4.7.3 4.7.4 4.7.5 4.7.6 4.7.7 4.7.8 4.7.9 4.7.10 4.7.11 4.7.12 4.7.13 4.8 4.8.1
A50016-D1112-V41-2-7618
DRAFT
Mobile-Terminated Call (MTC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Mobile-to-Mobile Calls (MMC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Calls to IN/CAMEL applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Optimal Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Carrier Routing Call by Call and Preselected . . . . . . . . . . . . . . . . . . . . . . 132 Number Portability for Mobile Subscribers . . . . . . . . . . . . . . . . . . . . . . . . 134 Location Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Mobile Terminating Location Request (MT-LR) . . . . . . . . . . . . . . . . . . . . 145 Mobile Originating Location Request (MO-LR) . . . . . . . . . . . . . . . . . . . . . 150 Full-Rate and Half-Rate Channel Connections (2G only) . . . . . . . . . . . . . 152 Enhanced Full-Rate Channel Connections (2G only) . . . . . . . . . . . . . . . . 153 Pooling for Circuit Allocation on A Interface (2G only) . . . . . . . . . . . . . . . 154 Support of Adaptive Multirate (AMR) Codec. . . . . . . . . . . . . . . . . . . . . . . 155 Handling the Subscriber Telecommunication Services. . . . . . . . . . . . . . . 156 Bearer Services in 2G. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Bearer Services in 3G. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Teleservices in 2G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Teleservices in 3G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Supplementary Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Service Change and UDI Fallback (SCUDIF) (3G only) . . . . . . . . . . . . . . 172 User Information (Tones, Announcements and Indications) . . . . . . . . . . . 172 Support of DTMF for Mobile Subscribers . . . . . . . . . . . . . . . . . . . . . . . . . 173 Charging and Billing - for Traffic over TDM CN . . . . . . . . . . . . . . . . . . . . 174 Charging Collection Function (Generation of Call Data Recordings) . . . . 176 Charging Gateway Function (CGF) / Interface to Billing Domain . . . . . . . 178 Charging with Hot Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Interadministrative Procedures for Billing/Revenue Accounting (IACHASTA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Charging for IN/CAMEL Subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Special Charging Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Enhanced Functions of Call Handling, Charging and User Information for Traffic over TDM CN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Flexible Routing of Calls in the CN (Circuit-Switched Domain) . . . . . . . . 193 A-Directory Number-Dependent Routing, Charging and Barring in the CN194 IMSI/MSISDN-Dependent Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Subscriber Data-Specific Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Number Length-Dependent Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Subscriber Data-Specific Charging Generation . . . . . . . . . . . . . . . . . . . . 198 Subscriber-Specific Advice of Charge . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Multilingual Announcements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 IN: Influenced Management of Call Legs (Leg Management) . . . . . . . . . 200 IN: Call Party Handling and Midcall Trigger . . . . . . . . . . . . . . . . . . . . . . . 200 IN: Announcement in Parallel to Call Setup . . . . . . . . . . . . . . . . . . . . . . . 202 IN: Advanced Interworking with Supplementary Services . . . . . . . . . . . . 204 IN: Audible Checking of Announcements . . . . . . . . . . . . . . . . . . . . . . . . . 205 Mobile-Specific Functions of Circuit-Switched Call Handling for Traffic over TDM CN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Radio-Access Security and User Authentication Management . . . . . . . . 206
Information System
4.8.1.1 4.8.1.2 4.8.1.3 4.8.1.4 4.8.1.5 4.8.1.6 4.8.2 4.8.2.1 4.8.2.2 4.8.2.3 4.8.3 4.8.4 4.8.5 4.8.5.1 4.8.5.2 4.8.5.3 4.8.5.4 4.8.5.5 4.8.5.6 4.8.5.7 4.8.6 4.8.6.1 4.8.6.2 4.8.6.3 4.8.7 4.8.7.1 4.8.7.2 4.8.8 4.8.9 4.8.10 4.8.11 4.8.12 4.8.13 4.9 4.9.1 4.9.2 4.10 4.10.1 4.10.2 4.10.3 4.10.4 4.10.5 4.10.6 4.10.7
DRAFT
Authentication (2G only). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Authentication and Key Agreement (AKA) (3G only) . . . . . . . . . . . . . . . . . 208 Data Integrity (3G only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 User/Signaling Data Confidentiality (Ciphering). . . . . . . . . . . . . . . . . . . . . 213 User Identity Confidentiality (TMSI Reallocation). . . . . . . . . . . . . . . . . . . . 213 Checking the Mobile Equipment Identity . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Separated Mobility Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 IMSI Attach/Detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Location Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Mobility Management with the MTC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Combined Mobility Management (CS-Side). . . . . . . . . . . . . . . . . . . . . . . . 221 Support of Dual Transfer Mode (DTM) (2G only). . . . . . . . . . . . . . . . . . . . 223 Categorization of Handover (or/and Relocation in 3G Case). . . . . . . . . . . 224 2G to 2G Handover (2G only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Hard Handover (3G only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 3G to 3G Handover/Relocation (3G only) . . . . . . . . . . . . . . . . . . . . . . . . . 231 Inter-System Handover from 2G to 3G or 3G to 2G. . . . . . . . . . . . . . . . . . 234 Service Based Handover from 2G to 3G/3G to 2G . . . . . . . . . . . . . . . . . . 243 Inter PLMN Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Directed Retry (MSC-controlled) (2G only) . . . . . . . . . . . . . . . . . . . . . . . . 246 Roaming Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Roaming Definitions for Own and Foreign Mobile Subscribers . . . . . . . . . 247 Roaming Definitions for Own or Foreign CAMEL Mobile Subscribers . . . . 251 Roaming Definitions for WLL Subscribers . . . . . . . . . . . . . . . . . . . . . . . . . 251 Sharing PLMN Resources (Infrastructure Sharing) . . . . . . . . . . . . . . . . . . 252 Support of Multiple PLMNs in an MSC/VLR. . . . . . . . . . . . . . . . . . . . . . . . 252 Network Identity and Time Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Cell-Oriented Routing of Service Numbers . . . . . . . . . . . . . . . . . . . . . . . . 256 Subscriber-Related Routing of Service Numbers . . . . . . . . . . . . . . . . . . . 256 Off-Air Call Setup (OACSU) for CN Switching Nodes . . . . . . . . . . . . . . . . 257 Queuing and Priority for Traffic Channels . . . . . . . . . . . . . . . . . . . . . . . . . 257 Catastrophe Handling For Traffic Channels. . . . . . . . . . . . . . . . . . . . . . . . 258 Overload Handling For Traffic Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Functions for Expanding PLMN Capacity (2G only). . . . . . . . . . . . . . . . . . 260 Standard Functions for Capacity Expansion . . . . . . . . . . . . . . . . . . . . . . . 260 Supplementary Functions for Capacity Expansion . . . . . . . . . . . . . . . . . . 260 Fraud Prevention/Lawful Interception Functions for Traffic over TDM CN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Barring a Mobile Subscriber SCI from Forwarding Calls to International Diversion Directory Numbers (Service Directory Numbers) . 263 Monitoring Calls in the MSC Forwarded with Call Forwarding (CF) and Call Transfer (CT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Variable Starting Time Criterion for Charge Registration of Mobile Subscribers with AOCC (AOCC Time Stamp) . . . . . . . . . . . . . . . . 264 Fraud Prevention for the First Second of a Call . . . . . . . . . . . . . . . . . . . . . 265 Restricting the Call Duration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Display of Current Mobile Subscriber Data in the VLR . . . . . . . . . . . . . . . 265 Security Enhancements for Fraud Prevention . . . . . . . . . . . . . . . . . . . . . . 265
A50016-D1112-V41-2-7618
Information System
4.10.8 4.11 4.11.1 4.11.1.1 4.11.1.2 4.11.2 4.12 4.12.1 4.12.2 4.12.3 4.12.3.1 4.12.3.2 4.12.3.3 4.12.4 4.12.4.1 4.12.5 4.12.6 4.13 4.13.1 4.13.2 4.13.3 4.13.3.1 4.13.4 4.13.5 4.13.6 4.13.7 4.13.8 4.13.9 4.13.10 4.13.11 4.13.12 4.13.13 4.13.14 4.13.15 4.13.16 4.13.17 4.13.18 4.13.19 4.13.20 4.13.21 4.13.22 4.13.23 4.13.24 4.13.25
A50016-D1112-V41-2-7618
DRAFT
Lawful Interception Package. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Call Handling Functions in the Optional GSM MGW and GSM MSC-S - for Traffic over TDM CN (2G only) . . . . . . . . . . . . . . . . . . GSM MGW Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Framework for Basic Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Framework for Mobility Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GSM MSC-S Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Call Handling Functions in the MSC-S Part and CS-MGW Part of MSC - for Traffic over ATM CN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MSC Server (MSC-S) Part and Circuit-Switched Media Gateway (CS-MGW) Part. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basic Functions of Call Handling for Traffic in ATM CN . . . . . . . . . . . . . . Framework for Traffic in ATM CN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Framework for Basic Call Handling Functions . . . . . . . . . . . . . . . . . . . . . Framework for Charging and Billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Framework for Mobility Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transcoder Free Operation (TrFO) (3G only) . . . . . . . . . . . . . . . . . . . . . . Framework for TrFO (3G only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transit MSC (ATM/AAL2 Transit Functionality) . . . . . . . . . . . . . . . . . . . . Seamless 3GPP R99 and Rel-4 Interworking (3G only) . . . . . . . . . . . . . Special Operation and Maintenance Functions . . . . . . . . . . . . . . . . . . . . Functions Based on Special Handling of Identities. . . . . . . . . . . . . . . . . . IMSI Tracing in the CN - Circuit-Switched Domain . . . . . . . . . . . . . . . . . . Security-Relevant AC Operator Functions . . . . . . . . . . . . . . . . . . . . . . . . Use and Administration of the Encryption Functions . . . . . . . . . . . . . . . . Security Enhancements in the AC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Support of USIM with Two 3G Security Algorithm Sets in the AC (3G only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IPsec Encrypted Transmission (IP Security) on O&M Paths of CNcs . . . Exchange Procedure for New Mobile Subscriber Chip Cards ((U)SIM) . . Roaming Restrictions for Mobile Subscribers . . . . . . . . . . . . . . . . . . . . . . Operator-Determined Barring (ODB) of CN Service Functions . . . . . . . . Administrative Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Barred Directory Numbers for Call Forwarding . . . . . . . . . . . . . . . . . . . . . USSD Text Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Barring of USSD for Roaming Mobile Subscriber . . . . . . . . . . . . . . . . . . . Administration of Mobile Subscriber Profiles in the HLR . . . . . . . . . . . . . User-Specific HLR Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bulk HLR Subscriber Administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Combined HLR/AC Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Combined MSC/VLR Trunk Administration (with ATM in CN) . . . . . . . . . Deletion of Mobile Subscriber Data in the VLR. . . . . . . . . . . . . . . . . . . . . Display of Number of Mobile Subscribers in VLR . . . . . . . . . . . . . . . . . . . Enhanced Display of Mobile Subscriber Data in VLR. . . . . . . . . . . . . . . . Display of HLR Statistics for Subscribers Roaming Outside HPLMN . . . . Display of Allocated Data for AAL2 Paths. . . . . . . . . . . . . . . . . . . . . . . . . Purge Initiation in VLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IN/CAMEL: Roaming Subscriber Table in VLR. . . . . . . . . . . . . . . . . . . . .
267 270 271 275 276 278 279 280 283 284 284 286 286 288 289 290 292 293 294 295 295 296 298 299 299 301 302 304 306 306 307 307 307 307 308 309 309 309 310 310 310 310 311 311
Information System
4.13.26 4.14 4.14.1 4.14.2 4.14.3 4.14.4 4.14.5 4.14.5.1 4.14.5.2 4.14.5.3 4.14.5.4 4.14.6 4.14.7 4.14.8 4.14.8.1 4.14.8.2 5
HSCSD Administration (2G only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 Protocol Stacks for Transport and Signaling . . . . . . . . . . . . . . . . . . . . . . . 313 Circuit-Switched Domain Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 Overview of Protocol Stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 Summary of all the ATM based Protocol Stacks on the Iu,cs Interface (3G only) or Nb/Nc Interface. . . . . . . . . . . . . . . . . . . . . . . . 315 ATM-based User Data Transport Protocols in the Circuit-Switched Domain of Core Network (CNcs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 TDM/ATM/IP-based Control Signaling Protocols in the Circuit-Switched Domain of Core Network (CNcs). . . . . . . . . . . . . . . . . . . 317 Control Signaling Protocol SS7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 ATM-based Control Signaling Protocol on the Iu,cs Interface (3G only) . . 324 ATM-based Control Signaling Protocol on the SS7 Interface . . . . . . . . . . 326 IP-based Control Signaling on SS7 Interfaces. . . . . . . . . . . . . . . . . . . . . . 327 ATM-based Transport Signaling Protocols in the Circuit-Switched Domain of Core Network (CNcs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 Structure of the DSS.1 Signaling System . . . . . . . . . . . . . . . . . . . . . . . . . 331 Communication Protocols of the Telecommunication Management Network (TMN). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 Structure of the TCP/IP or UDP/IP Communication Protocol. . . . . . . . . . . 333 Structure of the X.25 Communication Protocol . . . . . . . . . . . . . . . . . . . . . 334 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
DRAFT
A50016-D1112-V41-2-7618
Information System
Illustrations
Fig. 2.1 PLMN subsystem architecture (with circuit-switched domain and packet-switched domain in the CN - for an MSC/VLR or an SGSN/SLR node) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Block diagram of an integrated MSC/VLR node . . . . . . . . . . . . . . . . . . 22 Line/trunk group P (LTGP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 STM-1 interface integrated (STMI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Line/trunk group N (LTGN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Host timeslot interchange (HTI) - in connection to the remote timeslot interchange (RTI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Data service unit (DSU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Digital line unit G (DLUG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Functional units in the SND (example: capacity stage for more than 252 LTGs). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Coordination processor (CP113) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Hardware architecture of the SSNC in relation to the other hardware subsystems within the circuit-switched part of the MSC/VLR node . . . . 34 Block diagram of a GSM MGW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 GSM MGW and GSM MSC-S interfaces . . . . . . . . . . . . . . . . . . . . . . . . 37 Remote timeslot interchange (RTI) - in connection to the host timeslot interchange (HTI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Block diagram of a GMSC node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Block diagram of an HLR/AC classic (HLRc) node (with SSNC) . . . . . . 41 Block diagram of a compact HLR/AC classic node (with SSNC but with no SN, LTG and MB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Block diagram of an EIR node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Block diagram of a compact EIR node (with SSNC but with no SN, LTG and MB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Software shells for a processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 CSC with wired ISDN subscribers within a PLMN environment . . . . . . 66 Several virtual PABX groups in a PABX with ISDN-PA . . . . . . . . . . . . . 69 Access to the IN/CAMEL function for mobile subscribers in the CNcs with an integrated IN/CAMEL network architecture . . . . . . 70 Functional network architecture of CAMEL phase 2 . . . . . . . . . . . . . . . 76 Separated/combined mobility management (MM) . . . . . . . . . . . . . . . . . 90 Transport/signaling handling in Core Network . . . . . . . . . . . . . . . . . . . . 91 CN routing principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 CN configuration with transit MSC in ATM/AAL2 transit layer . . . . . . . . 94 Survey of CN connectivity/technologies in the circuit-switched domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Flat TDM CN configuration example . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Hierarchical TDM CN configuration example. . . . . . . . . . . . . . . . . . . . . 98 TDM network configuration example - backbone access . . . . . . . . . . . 99 3G MSCs fully meshed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 3G MSCs connected via ATM backbone . . . . . . . . . . . . . . . . . . . . . . . 103
Fig. Fig. Fig. Fig. Fig.
2.2 2.3 2.4 2.5 2.6
Fig. 2.7 Fig. 2.8 Fig. 2.9 Fig. 2.10 Fig. 2.11 Fig. 2.12 Fig. 2.13 Fig. 2.14 Fig. 2.15 Fig. 2.16 Fig. 2.17 Fig. 2.18 Fig. 2.19 Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. 2.20 3.1 3.2 3.3 3.4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10
A50016-D1112-V41-2-7618
DRAFT
Information System
Fig. 4.11 Fig. 4.12 Fig. 4.13 Fig. Fig. Fig. Fig. Fig. Fig. Fig. 4.14 4.15 4.16 4.17 4.18 4.19 4.20
Fig. 4.21 Fig. 4.22 Fig. 4.23 Fig. 4.24 Fig. 4.25 Fig. 4.26 Fig. 4.27 Fig. 4.28 Fig. 4.29 Fig. 4.30 Fig. 4.31 Fig. 4.32 Fig. 4.33 Fig. 4.34
Fig. 4.35 Fig. 4.36 Fig. Fig. Fig. Fig. Fig. 4.37 4.38 4.39 4.40 4.41
10
DRAFT
Hierarchical CN of MSCs with 3G MSC parts . . . . . . . . . . . . . . . . . . . . 105 PVC solution for connecting RNCs or 3G MSCs to an MSC via an ATM CN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 PVP solution for connecting RNCs or 3G MSCs to an MSC via an ATM CN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 TDM over IP configuration in the CS domain . . . . . . . . . . . . . . . . . . . . 108 Traffic separation TDM/ATM based CN . . . . . . . . . . . . . . . . . . . . . . . . 109 TDM/ATM interworking aspects for an TDM based CN . . . . . . . . . . . . 110 TDM/ATM interworking aspects for an ATM based CN . . . . . . . . . . . . 111 Multiple SS7 networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Multiple SS7 networks and multiple SPCs in the CN node . . . . . . . . . . 116 Call procedure of an MOC to a fixed network subscriber in the circuit-switched domain of CN. . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Call procedure of an MTC (with call origin in the fixed network) within the circuit-switched domain of the CN . . . . . . . . . . . . . . . . . . . . 120 Call procedure of an MMC in the circuit-switched domain of CN . . . . . 121 MOC call procedure to IN/CAMEL applications when a mobile subscriber is roaming inside the HPLMN . . . . . . . . . . . . . . . . . 123 MOC call procedure to IN/CAMEL applications when a mobile subscriber is roaming outside the HPLMN . . . . . . . . . . . . . . . . 124 Principle of optimal routing of mobile-to-mobile call (speech path). . . . 126 Message flow for optimal routing of mobile-to-mobile calls . . . . . . . . . 127 Principle of optimal routing of early call forwarding -during mobile terminating calls- (speech path) . . . . . . . . . . . . . . . . . . . . . . . . 128 Principle of optimal routing of late call forwarding -during mobile terminating calls- (speech path) . . . . . . . . . . . . . . . . . . . . . . . . 129 Message flow for optimal routing of late call forwarding -during mobile terminating calls- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Carrier routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Internal number portability (NP) database (MSC/VLR-based or HLR/AC-based) . . . . . . . . . . . . . . . . . . . . . . . . . . 136 CP switch-based external number portability database . . . . . . . . . . . . 137 SCP-based external number portability database . . . . . . . . . . . . . . . . 137 Call procedures (in the case of internal NP server used) with ported-in number using the query on digit (QoD) analysis method with originating call in individual PLMN . . . . . . . . . . . 139 Network architecture for a 2G PLMN to support location services of MSs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Network architecture for a 3G PLMN to support location services of MSs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 General network positioning for an MT-LR in a 2G PLMN . . . . . . . . . . 147 General network positioning for an MT-LR in a 3G PLMN . . . . . . . . . . 148 MO-LR to perform self-location. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Enhanced full-rate channel connections . . . . . . . . . . . . . . . . . . . . . . . . 154 Protocol model for asynchronous data transmission with GSM bearer service (data CDA) and fixed network bearer service (3.1 kHz audio) . 157
A50016-D1112-V41-2-7618
Information System
Fig. 4.42
Fig. 4.43
Fig. 4.44
Fig. 4.45 Fig. 4.46
Fig. 4.47 Fig. 4.48 Fig. 4.49 Fig. 4.50 Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. 4.51 4.52 4.53 4.54 4.55 4.56 4.57 4.58 4.59 4.60 4.61 4.62 4.63 4.64 4.65 4.66 4.67 4.68 4.69 4.70 4.71 4.72 4.73 4.74
A50016-D1112-V41-2-7618
DRAFT
Protocol model for asynchronous data transmission with GSM bearer service (data CDA) and fixed network bearer service (unrestricted digital (UDI)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Protocol model for synchronous data transmission with the GSM bearer service (data CDS) and packet data access via X.32 signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Protocol model for synchronous data transmission with the GSM bearer service (data CDS) and packet handler (PH) using X.31 signaling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Protocol model for packet data transmission with the GSM bearer service (dedicated PAD access) . . . . . . . . . . . . . . . . . . . 160 Protocol model for asynchronous data transmission with the GSM bearer service (data CDA) and fixed network bearer service (3.1 kHz audio/V.34) for one HSCSD traffic channel (TCH/F14.4) . . 161 HSCSD channel combining on the basis of circuit pools . . . . . . . . . . . 162 Connection architecture for mobile circuit-switched data (MCSD) service BS 20 in 3G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Connection architecture for 3G-H.324/M to 3G-H.324/M calls . . . . . . 164 Transmission model for speech transmission with GSM teleservice (telephony) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Fax adapter function for teleservice telefax (group 3) . . . . . . . . . . . . . 166 Network architecture for the short message service . . . . . . . . . . . . . . 167 Network architecture for short message cell broadcast . . . . . . . . . . . . 168 Transmission model for speech transmission with UMTS teleservice (speech telephony) . . . . . . . . . . . . . . . . . . . . . . . . 170 Network architecture for short message service . . . . . . . . . . . . . . . . . 171 Special service destinations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Different private numbering plans for different mobile subscribers . . . 197 Special service destinations are free of charge for certain subscribers 199 Call procedure of parallel ringing for two B parties . . . . . . . . . . . . . . . 202 Call procedure of parallel ringing for two B parties . . . . . . . . . . . . . . . 204 Authentication procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Authentication procedure in the circuit-switched domain of the 3G PLMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Principle of data integrity in the circuit-switched domain of 3G . . . . . . 212 IMEI check procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 IMSI attach/detach procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Location update procedure with change of VLR in the same PLMN . . 218 Gs interface state model in the VLR (2G case) . . . . . . . . . . . . . . . . . . 222 Gs interface state model in the VLR (3G case) . . . . . . . . . . . . . . . . . . 223 Underlay/overlay radio cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Multiband handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 intra-MSC relocation of SRNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Basic inter-MSC relocation of SRNC . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Subsequent intra-MSC relocation within MSC-B . . . . . . . . . . . . . . . . . 233 Subsequent inter-MSC relocation (back to MSC-A or to a third MSC) 234
11
Information System
Fig. Fig. Fig. Fig.
4.75 4.76 4.77 4.78
Fig. 4.79 Fig. 4.80 Fig. 4.81 Fig. 4.82 Fig. 4.83 Fig. 4.84 Fig. 4.85 Fig. 4.86 Fig. Fig. Fig. Fig. 4.87 4.88 4.89 4.90
Fig. 4.91 Fig. 4.92 Fig. 4.93
Fig. 4.94
Fig. Fig. Fig. Fig. Fig.
4.95 4.96 4.97 4.98 4.99
Fig. 4.100 Fig. 4.101 Fig. 4.102
12
DRAFT
Intra-MSC inter-system handover 2G to 3G . . . . . . . . . . . . . . . . . . . . . 236 Intra-MSC inter-system handover 3G to 2G . . . . . . . . . . . . . . . . . . . . . 237 Basic inter-MSC inter-system handover 2G to 3G . . . . . . . . . . . . . . . . 238 Subsequent intra-MSC inter-system handover 2G to 3G within 2G/3G MSC-B. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 Subsequent inter-MSC inter-system handover 2G to 3G (to a third MSC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Subsequent inter-MSC inter-system handover 2G to 3G (back to MSC-A) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Basic inter-MSC inter-system handover 3G to 2G . . . . . . . . . . . . . . . . 241 Subsequent intra-MSC inter-system handover 3G to 2G within 2G/3G MSC-B. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Subsequent inter-MSC inter-system handover 3G to 2G (to a third MSC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Subsequent inter-MSC inter-system handover 3G to 2G (back to MSC-A) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Basic configuration for multiple PLMN support . . . . . . . . . . . . . . . . . . . 254 Lawful interception with interception for a mobile-originated call (MOC) - in case of X.25 interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 270 Connection within a GSM MGW (local MIC or MOC) . . . . . . . . . . . . . . 273 Connection between GSM MGWs (local MMC or MOC) . . . . . . . . . . . 274 Connection via the GSM MSC-S (local MMC or MOC) . . . . . . . . . . . . 275 Different 2G to 2G handover scenarios at the GSM MGW (here in case of an MOC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Different 2G to 3G (or vice versa) handover scenarios at the GSM MGW (here in the case of an MOC) . . . . . . . . . . . . . . . . . . . 278 Traffic separation 2G RAN/3G RAN - TDM/ATM based CN . . . . . . . . . 280 Separation of MSC server (MSC-S) part and circuit-switched Media Gateway (CS-MGW) part for traffic over ATM CN implementation in the 2G PLMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Separation of MSC-Server (MSC-S) part and circuit-switched Media Gateway (CS-MGW) part for traffic over ATM CN implementation in the 3G PLMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Overview of the transcoder free operation (TrFO) feature . . . . . . . . . . 288 MSC architecture for TrFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 CN with a separate ATM transit MSC as the transit layer. . . . . . . . . . . 291 R99 / Rel-4 traffic flow in a 3G MSC part . . . . . . . . . . . . . . . . . . . . . . . 292 Circuit-switched CN IPsec encrypted transmission secure configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 Overview of all PLMN points (PLMN interfaces) of the described protocol stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 Iu,cs interface (3G only) or Nb/Nc interface protocol stack for circuit-switched instances. . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 The Iu,cs interface (3G only) and Nb interface protocol stack of ATM-based user data transport protocol (user plane) in the circuit-switched domain of CN (CNcs) . . . . . . . . . . . . . . . . . . . . . . . . . 316
A50016-D1112-V41-2-7618
Information System
Fig. 4.103 Fig. 4.104 Fig. 4.105 Fig. 4.106 Fig. 4.107 Fig. 4.108 Fig. 4.109 Fig. 4.110 Fig. 4.111 Fig. 4.112
Signaling routes between CN network elements and additional service centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol stack of a TDM/PCM30-based SS7 signaling protocol . . . . . Iu,cs interface protocol stack of an ATM-based control signaling protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nc interface protocol stack of an ATM-based control signaling protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SS7 interface protocol stack of an IP-based control signaling protocol Iu,cs interface and Nb interface protocol stack of an ATM-based transport signaling protocol (transport plane). . . . . . . . . . Structure of the DSS.1 signaling system . . . . . . . . . . . . . . . . . . . . . . . Communication protocols for the O&M connections of the PLMN with CN nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structure of the TCP/IP communication protocol. . . . . . . . . . . . . . . . . Structure of the X.25 communication protocol . . . . . . . . . . . . . . . . . . .
318 319 324 326 327 329 331 332 333 334
A50016-D1112-V41-2-7618
DRAFT
13
Information System
Tables
Tab. 1.1 Tab. 3.1 Tab. 3.2 Tab. 3.3 Tab. Tab. Tab. Tab. Tab. Tab. Tab. Tab. Tab. Tab. 3.4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 Use of the individual system description documents . . . . . . . . . . . . . . . 15 Overview of all kinds of subscribers at the CSC (with classifying features) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Basic telecommunications services for the wired ISDN subscriber at the CSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Telecommunications services for the wired ISDN subscriber at the CSC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Categories of IN/CAMEL services in the M-SSP . . . . . . . . . . . . . . . . . . 72 Applicability of compressed speech mode dependent of type of traffic 112 Signaling network types in the CN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Sub multiplexing of user channels to the 2G RAN interfaces . . . . . . . . 153 Circuit pool types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Implemented bearer services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Classification of handover/relocation . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Classification of handover/relocation . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Methods of infrastructure sharing and CN relevancy . . . . . . . . . . . . . . 252 PLMN roaming restrictions on the basis of an additionally assigned roaming area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 Flexible roaming agreements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 SS7 components on the signaling routes . . . . . . . . . . . . . . . . . . . . . . . 319
Tab. 4.10 Tab. 4.11
14
DRAFT
A50016-D1112-V41-2-7618
Information System
1 Overview of System Description

1.1 Documentation Overview of System Description
The entire system description consists of the following individual documents: Network system concept CN GSM/UMTScs CN GPRS/UMTSps RAN GSM/GPRS RAN UMTS EM GSM/GPRS/UMTS GSM-R The individual document can be used either for the 2G network (PLMN) or for the 3G PLMN or for both the 2G and 3G PLMNs as shown in Tab. 1.1. Furthermore the documents Network System Concept and CN GSM/UMTScs can be used for Core Network circuit-switched (CNcs) domain or Network System Concept and CN GPRS/UMTSps can be used for Core Network packet-switched (CNps) domain. The documents Network System Concept, CN GSM/UMTScs, CN GPRS/UMTSps, and EM GSM/GPRS/UMTS can be used both for 2G PLMN and 3G PLMN in a combined 2G/3G network. If it is used for a pure 2G PLMN or pure 3G PLMN, the relevant 2G PLMN or 3G PLMN part can be ignored. The document RAN GSM/GPRS is only used for 2G parts and the document RAN UMTS is used for 3G parts of a combined 2G/3G PLMN. The document GSM-R is only used for additional GSM railway parts of a 2G PLMN.
Network generation CNcs domain Individual document Network System Concept CN GSM/UMTScs CN GPRS/UMTSps RAN GSM/GPRS RAN UMTS EM GSM/GPRS/UMTS GSM-R 2G + 3G 2G + 3G 2G + 3G 2G 3G 2G + 3G 2G + + + + + + + + + + Network subsystem CNps domain + 2G RAN + 3G RAN + EM in TMN +
Tab. 1.1
Use of the individual system description documents
A50016-D1112-V41-2-7618
DRAFT
15
Information System
To get an overview of a GSM network (2G circuit-switched) we recommend that you read: Network System Concept CN GSM/UMTScs RAN GSM/GPRS EM GSM/GPRS/UMTS. To get an overview of a GPRS network (2G packet-switched) we recommend that you read: Network System Concept CN GPRS/UMTSps RAN GSM/GPRS EM GSM/GPRS/UMTS. To get an overview of a GSM railway network (2G circuit-switched) we recommend that you read: Network System Concept CN GSM/UMTScs RAN GSM/GPRS EM GSM/GPRS/UMTS GSM-R. To get an overview of a combined 2G/3G network (circuit-switched + packetswitched) we recommend reading of: Network system concept CN GSM/UMTScs CN GPRS/UMTSps RAN GSM/GPRS RAN UMTS EM GSM/GPRS/UMTS. To get an overview of a pure 3G network (circuit-switched + packet-switched) we recommend reading of: Network system concept CN GSM/UMTScs CN GPRS/UMTSps RAN UMTS EM GSM/GPRS/UMTS.
16
DRAFT
A50016-D1112-V41-2-7618
Information System
1.2
Scope of the CN GSM/UMTScs Description

The CN GSM/UMTScs System Description is intended to give an introduction and overview of the SIEMENS second-generation (2G) circuit-switched (GSM) part of the Global System of the Mobile communication (GSM) and SIEMENS third-generation (3G) circuit-switched (CS) part of the Universal Mobile Telecommunication System (UMTS) network system based on 3GPP standards (Release 99, Rel-4 and Rel-5). The network system is modeled to the Telecommunication Management Network (TMN) framework which consists of the: Core Network (CN) Radio Access Network (RAN) Network Element Management (NEM). The Core Network nodes are designed to support a PLMN operator with a pure 2G GSM/GPRS PLMN, and both an evolution path GSM/GPRS/UMTS, and a pure 3G UMTS PLMN. This is possible by providing combined switching nodes 2G/3G MSC for circuit-switched domain of CN (CNcs) or 2G/3G SGSN for packet-switched domain of CN (CNps). A combined 2G/3G PLMN consists, in addition to the above mentioned system parts circuit-switched Core Network (CNcs) or packet-switched Core Network (CNps), of a 2G or 3G RAN, and a Network Element Management (NEM). Based on the CN node configurations, this CN GSM/UMTScs document describes the circuit-switched CN part of the SIEMENS product lines. Subjects are: PLMN system architecture (hardware, software), PLMN system functions, network functions. The purpose of this document is to support a network provider who provides: a pure circuit-switched 2G GSM network a 2G circuit-switched GSM railway network an evolution network circuit-switched 2G GSM and a 3G UMTS and a pure circuit-switched 3G UMTS network.
1.3
Denition of Terms
In this system description, the following terms are used as described below: MS CNcs CNps CP platform MP platform MSC/VLR RAN NEM 2G only 3G only is used for the 2G or 3G functional part of a subscribers mobile station. It consists of the mobile equipment & (U)SIM. is used for the 2G or 3G circuit-switched domain of Core Network (CN). is used for the 2G or 3G packet-switched domain of Core Network (CN). is used for the product name EWSD. is used for the product name SSNC. is used for the integrated 2G or 2G/3G circuit-switched node. The 2G/3G node can also be used as a 3G node only. is used for the 2G or 3G Radio Access Network. is used for the Network Element Management which is part of the Telecommunication Management Network (TMN) model. is used for the restriction to 2G functionality only. is used for the restriction to 3G functionality only.
A50016-D1112-V41-2-7618
DRAFT
17
Information System
2 System Architecture of the Circuit-Switched Domain of the Core Network (CNcs)

In the Global System of Mobile Communication (GSM) and Universal Mobile Telecommunication System (UMTS), Public Land Mobile Network (PLMN) the Core Network (CN) can be divided into a: Circuit-switched domain (CNps) Packet-switched domain (CNps). The circuit-switched domain of CN (CNcs) consists of the following network elements: Mobile-services Switching Center (MSC) - on the MSC/VLR node Optional GSM Media Gateway (GSM MGW) (2G only) Visitor Location Register (VLR) - on the MSC/VLR node Home Location Register (HLR) Authentication Center (AC) Equipment Identity Register (EIR) Gateway MSC (GMSC) Fig. 2.1 shows the PLMN subsystem architecture (with circuit-switched domain and packet-switched domain in the CN - in case of an MSC/VLR or an SGSN/SLR node).
Element managers (EMs) within Telecommunication Management Network (TMN) RC SC
SCP NodeB Iub RNC Iub NodeB 3G Radio Access Network (3G RAN) A BTS Iu MSC/VLR CAP interface 3G MSC part + SSP + LE 2G MSC part + SSP D F Iu Gs EIR Gf Gr Abis BSC Abis Asub TRAU Gb SGSN/SLR 3G SGSN part + SSP 2G SGSN part + SSP Ga Gn Ge E, Nb, Nc
Core Network (CN) Circuit-switched domain TMSC GMSC
HLR
AC
Packet-switched domain CG Ga GGSN/IPS Go PCS SCP Gq Gi to ABC
BTS
2G Radio Access Network (2G RAN)
18
DRAFT
Fig. 2.1
PLMN subsystem architecture (with circuit-switched domain and packetswitched domain in the CN - for an MSC/VLR or an SGSN/SLR node)
A50016-D1112-V41-2-7618
Information System
The packet-switched domain of CN (CNps) consists of (or involves) the following network elements: Serving GPRS Support Node (SGSN) - on the SGSN/SLR node SGSN Location Register (SLR) - on the SGSN/SLR node Gateway GPRS Support Node (GGSN) Intelligent Packet Solution (IPS) Home Location Register (HLR) Authentication Center (AC) Charging Gateway (CG) - as stand-alone node Policy Control Server (PCS).
2.1
Combination of Network Elements of the Core Network (CN) Nodes

The composition of network elements in a network node depends on the operating and geographical network requirements of the PLMN operating company. The dynamic load, interworking and reliability aspects also have to be taken into account. All these requirements and factors determine whether a combined or a stand-alone arrangement provides the best solution. Estimates of the transmission capacity of the signaling system No. 7 (SS7) show that the VLR is to be not physically separated from the MSC. The same applies to AC and HLR, that is, AC and HLR are to be combined in their own network node. This produces either the combination HLR/AC or also MSC/VLR which is part of the MSC/VLR node (see section 2.1.1). If a Group Call Register (GCR) is used it is collocated to every MSC (2G only). If a separation of transport and control is used due to the SIEMENS proprietary GSM Media Gateway (GSM MGW) and GSM MSC Server (GSM MSC-S) concept, the GSM MSC-S functionality is collocated to an MSC and GSM MGW is an external entity (2G only). If a separation of transport and control is used due to the SIEMENS traffic over ATM CN concept according to 3GPP standard, the MSC-S functionality part and circuitswitched Media Gateway (CS-MGW) functionality part are both collocated to an MSC with an internal interface. The network nodes (that is, combination of network elements) offered by SIEMENS are described below.
2.1.1
Integrated Circuit-Switched CN Nodes

MSC/VLR node The MSC/VLR node consists of a: MSC/VLR network element, handling the circuit-switched trafc via the A interface MSC/VLR network element, handling the circuit-switched trafc via the Iu interface HLR/AC node
A50016-D1112-V41-2-7618
DRAFT
For the current software version, the HLR/AC node can be implemented either by: the HLR/AC classic (HLRc, based on the classic EWSD platform (CP platform) and signaling system network control (SSNC) platform (MP platform)
19
Information System
or the HLR/AC innovation (HLRi), based on a server platform with UNIX operating system.
i
2.1.2
The HLRi node product is described in a separate documentation set that includes the network element description HLR/AC Innovation.
Stand-Alone Circuit-Switched CN Nodes

GSM MGW The GSM Media Gateway (GSM MGW) node consists of some identical parts of the platform of MSC/VLR node. GMSC node The Gateway MSC (GMSC) node consists of an MSC product. EIR node The Equipment Identity Register (EIR) node consists of an MSC product. Further nodes or network elements in the environment of CNcs For special PLMN services and operational and regulatory services further CNcs nodes or service centers (at the most OEM products) can be used. Examples are Short Message Service Center (SMSC), Voice Mail Service Center (VMSC), Gateway Mobile Location Center (GMLC), Stand Alone - Signaling Transfer Point (SA-STP), Number Portability Database (NPDB), IP Trunk Gateway, Master Equipment Identity Register (MEIR), Service Control Point (SCP)/CAMEL Service Environment (CSE) and Lawful Interception - Interception Management System (LI-IMS).
2.2
Hardware Architecture of an MSC/VLR Node

The MSC/VLR node consists of the following two platforms The CP platform (without SSNC) The ATM multiservice platform (MP platform). The above-mentioned platforms are used for the: Circuit-switched domain part of the Core Network (CN) with the CP platform (for MSC/VLR network element) with the MP platform (for SSNC (that is, SS7) functionality, Iu/Nb interface functionality and some circuit-switched functionality) The advantages of the CP and the MP platforms include: Fully digital design Compliance with ITU-T and ETSI Completely modular: hardware, autonomous subsystems with their own controls software, functionally divided into software shells, subsystems and modules Mechanical construction, exible in combining modules, frames and racks Clear-cut function organization Standardized internal and external interfaces Mature CHILL technology Extensive safeguarding measures to ensure trouble-free operation Fig. 2.2 shows the block diagram of an integrated MSC/VLR node.
20
DRAFT
A50016-D1112-V41-2-7618
Information System
2.2.1
CP Platform Parts
The hardware architecture of the CP platform permits many flexible combinations of Switching Subsystem elements and has clearly-defined interfaces. This forms the basis for cost-effective use of the circuit-switched domain part of the MSC/VLR node in all areas of the broad spectrum of applications. Functions determined by the network environment are handled by the line trunk groups (LTGs). The signaling system network control (SSNC) is logically a hardware subsystem inside the CP platform, but is implemented with MP platform components (see topic MP platform parts below). The SSNC handles the message transfer part (MTP) and signaling connection control part (SCCP) of signaling system SS7 (see also the information note above). The function of the switching network (SN) is to interconnect the trunks in accordance with the call requirements of the subscriber and the network administration. The controls of the subsystems involved carry out practically all the tasks arising in their area independently (e.g., the line/trunk groups handle digit reception, charge registration, supervision and other functions). Only for system-wide and coordination functions, such as routing and zoning, for example, do they require the assistance of the coordination processor (CP113). Fig. 2.2 shows how the most important controls are distributed throughout a CP platform part of an MSC/VLR network node. This principle of distributed control reduces the amount of coordination involved and the necessity for communication between the processors, and contributes to MSC/VLRs very high dynamic performance standard. The flexibility inherent in distributed control also makes it easy to introduce and modify features and to assign features to specific subscribers. For interprocessor communication, the switching network (SN) sets up 64-kbit/s connections in the same way as connections between subscribers. However, the processors remain connected and these connections are therefore referred to as semipermanent connections. A separate interprocessor control network is not needed then. The structure of an MSC/VLR network node (CP platform part) comprises the following main hardware components: Line trunk groups (LTG) Host timeslot interchange (HTI) - when GSM MSC Server functionality is provided Switching network (SN) Coordination area with coordination processor (CP113), message buffer (MB) and central clock generator (CCG). Fig. 2.2 shows the CP platform part of the MSC/VLR network node.
A50016-D1112-V41-2-7618
DRAFT
21
Information System
to 2G RAN (A interface) **) to SMSC (E interface) to EIR (F interface) *) to SCP (IN/CAMEL) (CAP interface) *) to SGSN (Gs interface) *) to HLR/AC (C/D interface) *)
LTG:BSSAP
LTG
Trunk loop LTG for mobile-to-mobile call or digital/fixed subscriber and for lawful interception * *) Only used for 2G part of the node.
LTG
LTG
LTG for standard announcements LTG for connecting a DLU for digital/fixed subscriber (within a CSC) Conference LTG (for MPTY service, ASCI services) DSU (IWF) LTG for connecting the DSU (for data services)
LTG SN LTG
LTG
DLU
LTG (ATCO) LTG LTG LTG
to VMSC/GMSC (E, Nc interface) LTG:ISUP/BICC, MAP
to GSM MGW (Interface trunks) * *)
HTI
LTG:BICC
LTG:RANAP/ BSSAP *) Pure SS7 links in circuit-switched domain can also be implemented in the ATM MP platform with LIC(TDM)-E1 interfaces. MB
CCG
CP 113
CP platform
MP platform TSCD TSCD
A2BS
A2BS to VMSC/GMSC (Nb interface)
MP:RANAP/BCF
ASN
LIC (ATM):Nb
MP:AAL2 to 3G RAN (Iu,cs interface) ***) LIC(ATM):Iu
MP:ACC MP-SA MP:STATS
***) Only used for 3G part of the node.
MP:SLT
MP:OAM
TCP / IP
Switch Commander (SC) to ABC or hot operation
MP:SM
MP:OAMD TCP / IP
Fig. 2.2
Block diagram of an integrated MSC/VLR node
22
DRAFT
A50016-D1112-V41-2-7618
Information System
With the current software version, the hardware components described in the next sections are used to equip the MSC/VLR network node anew. These components are: Line/trunk groups of type P or type N (LTGP/LTGN) for trunk use including DEC use and trunk-loop use Host timeslot interchange (HTI) - when GSM MSC-S functionality is provided Switching network, type D (SND) Signaling system network control (SSNC) which is implemented in the MP platform part Coordination area, with coordination processor, type C or type E (CP113/C/E), message buffer, type D (MBD), central clock generator, type E (CCGE).
Line trunk groups (LTG) The different LTGs control and supervise the incoming and outgoing trunk traffic (MTC and MOC) to and from e.g.: The TRAU server card, type D (TSCD) in the direction of the Iu interface Other public networks (e.g., other PLMNs or xed networks (PSTN/ISDN etc.)) Other CN nodes (e.g., HLR/AC) Voice Mail System Centers (VMSC)/Short Message Service Center (SMSC). The internal user data traffic flow (user data plane) from the 3G RAN interface (Iu) to the internal LTG:(BSSAP/)RANAP passes through LIC(ATM):Iu, A2BS and TSCD. The LTGs support all normal signaling systems (e.g., SS7). The LTG:ISUP (or TUP) contains, especially for the traffic for TDM CN, the SS7 user software for this type of connection between the MSCs, while the LTG:BSSAP(/RANAP) does so for connections to the 2G RAN. For connections to IN nodes (SCP/CSE), it is the SS7:CAP. In case of traffic for ATM CN the SS7 user software for connections to ATM domain is SS7:BICC. Digital echo compensators (DEC) are used on the connections to/from fixed subscribers. Although the signaling methods on the lines can differ, the line/trunk groups (LTG) have an internal signaling-independent interface to the switching network. This simplifies: exible introduction of additional or modied signaling procedures and a signaling-independent software system in the CP113 for all applications. The bit rate on the multiplex lines linking the line/ trunk group (LTG) and the switching network is 8192 kbit/s (8 Mbit/s). Each 8-Mbit/s highway contains 128 channels at 64 kbit/s each. Each LTG is connected to both planes of the duplicated switching network (SN). Depending on the use of the line/trunk group (LTG) the following three different LTGs can be used: LTGP and STMI for all kinds of trunks and connection lines and e.g., for a conference LTG for multiparty and for the implementation of a user interaction LTG for specialized resource function (SRF) LTGN (the predecessor of the LTGP) Each LTGP has the following functional units (Fig. 2.3): Group processor P (GPP) Optical interface for LTGP (SNOPT) Line/trunk unit, special (LTU:S), (with digital echo cancellers (DEC) and conference unit (ATCO) and OCANEQ for UI LTGN (OCE:N))
A50016-D1112-V41-2-7618
DRAFT
23
Information System
GPP
SNOPT optical output to SND
16x PCM30
SDC to SNB
LTU:S
Fig. 2.3
Line/trunk group P (LTGP)
STM-1 interface integrated STMI (STMI) is a variant of the LTGP that offers an integrated STM-1 interface (STM1I) to SDH-based transmission networks, that is, Core Network (CN) for trunk applications. The STMI is implemented based on the equipment of the LTGP (GPP and LTU:S), which is supplemented with STM-1 interface modules (STM1I) that provide optical (1300 nm short haul) and electrical (coax) STM-1 interfaces (Fig. 2.4). Each group processor for STMI (GPS) houses four GPP units and is connected to the STM1I boards via 63 PCM30 links. Four GPS are provided per STMI, with one GPP of each GPS connected to an LTU:S. The STMI is connected to the SN(D) via an optical multiplex interface.
GPS STM1I interfaces 16x PCM30 (4 x GPP)
SNOPT optical output to SND
STM-1
SDC to SNB
LTU:S
Fig. 2.4
STM-1 interface integrated (STMI)
24
DRAFT
Each LTGN has the following functional units (Fig. 2.5): Group processor N (GPN) Supplementary LTU position (LTU:S) (e.g., with digital echo compensator (DEC) and conference unit (ATCO) and OCANEC for UI LTGN (OCE:N)).
A50016-D1112-V41-2-7618
Information System
to the trunks 64 kbit/s
GPN to the SN 8 Mbit/s
LTU:S (DEC, ATCO, OCE:N)
Fig. 2.5
Line/trunk group N (LTGN)
Host timeslot interchange (HTI) (2G only) In the GSM MSC-S, the host timeslot interchange (HTI) provides the GSM MGW control interface between the GSM MSC-S and the GSM MGW. The HTI controls interface trunks, that is, trunks between the GSM MSC-S and the GSM MGW for GSM MGW control, SS7 signaling transport and user data transport, optionally. The host timeslot interchange (HTI) consists of the following functional units (Fig. 2.6): Message handler (MH) Signaling between the GSM MGW (that is, LTG) and the GSM MSC-S (that is, CP113). Timeslot interchange (TSI) Blocking free local switching network. The TSI consists of access multiplexers (AMUX) and timeslot interchange modules (TSIM). Remote switching unit controller (RSUC) Component controls the RTI-HTI connection and communicating with the GSM MSC-S (that is, CP113) like an LTG. Internally it communicates with the MH and TSI to set up and release paths and for O&M purposes. Digital interface unit 240 (DIU240) DIU240 connectivity for 8 PCM 30 links between the GSM MGW and the GSM MSCS and other GSM MGWs.
At the controlling MSC (that is, GSM MSC-S part), the HTI and message buffer (MB) type D is necessary. In this case, the HTI uses only the electrical, not the optical outputs of the SND.
A50016-D1112-V41-2-7618
DRAFT
25
Information System
SND HTI (in GSM MSC-S)
TSI
RSUC
MH
DIU240
DIU240
Interface trunks (8 x PCM30)
Sidedoor trunks (8 x PCM30)
RTI (in GSM MGW1) TSI
DIU240
DIU240
DIU240
DIU240
RTI (in GSM MGW2)
TSI RSUC RSUC
MH
MH
LTGPs
LTGPs
Fig. 2.6
Host timeslot interchange (HTI) - in connection to the remote timeslot interchange (RTI)
Data service unit (DSU) The data service unit DSU consists of the central functional units (Fig. 2.7): DLU sides (0 and 1) (in each case with functions: digital line unit control (DLUC) and bus distributor module (BDG)) Signal distribution networks.
26
DRAFT
A50016-D1112-V41-2-7618
Information System
DLU side 0 LTG 0
IWE (with integrated onboard modems) DLU side 1 LTG 1
signal distribution
Fig. 2.7
Data service unit (DSU)
The central functional units are joined by the peripheral units: Interworking equipment (IWE:HS) with integrated onboard modems which are data transmission modems (multimodems according to V.21, V.22, V.22bis, V.23, V.32, V.32bis, V.34, V.90 with V.42 (error protection protocol) and V.42bis (compression algorithm which can be used by modems for data compression)). They also support the FAX modem functionality (for transparent FAX transmissions). For data transmission and the associated bearer services, it can be necessary to match the radio side to the fixed-network side (e.g., PSTN/ISDN). For this reason, interworking functions (IWF) are provided in the MSC/VLR. The IWFs are introduced into the connection via line/trunk groups. IWFs perform the following tasks: Synchronization of the trafc channel Matching the bit rate to the radio side and to the xed-network side (in areas where digital connections are used throughout) Modem and codec functions, in case digital connections cannot be guaranteed on the whole route
To allow higher data throughput to the PLMN (downlink direction), the V90 modem functionality is integrated in the IWE:HS additionally. V.90 standard and data rates of up to 56000 bit/s downlink and 33600 bit/s uplink are only available if the relevant modems are connected to the IWE:HS. The new IWE:HS is capable of supporting multiple time slot calls for high-speed circuitswitched data service (HSCSD) and TCH/F14.4 channel coding as well as several single time slot calls operated simultaneously. HSCSD and TCH/F14.4 are implemented for general bearer service BS20. The operation of the existing data services with the new IWE:HS is guaranteed for former software releases without upgrading them to the current software release.
A50016-D1112-V41-2-7618
DRAFT
27
Information System
In the case of the mobile station (MS) signals, the old data services (non-HSCSD/non14.4 kbit/s) and the V.34 modems are state of the art for data communication within a fixed network. In this software version, the V.34 modems support 28.8 kbit/s for the highspeed circuit-switched data service (HSCSD) on the basis of GSM bearer services BS 20. Therefore, in the cases where the mobile station signals the new data service (HSCSD/14.4 kbit/s), the V.34 modems that are needed for data rates higher than 9.6 kbit/s can be requested. V.34 standard and data rates up to 33.600 bit/s are only available if the relevant modems are connected to the IWE:HS. Although the highest user rates provided by V.34 modems are not needed for the existing bearer services provided by 2G PLMN the V.34 modem improves data communication in the sense of better transmission reliability, faster call setup and support of the new negotiation mechanism according to V.8. The V.34 modulation is only applicable for those calls that require autobauding. Digital line unit G (DLUG) Digital line unit G (DLUG) is used to connect wired ISDN subscriber lines (including digital access lines for ISDN-PABXs) at a Combined Switching Center (CSC). Digital line unit G (DLUG) consists of the following central functional units (see also Fig. 2.8): DLU sides (0 and 1) (each with the modules digital line unit control (DLUC) and bus distributor module (BDG) Signal distribution networks.
DLU side 0 LTG 0 SLMD
DLU side 1 LTG 1
signal distribution
Fig. 2.8
Digital line unit G (DLUG)
Digital line unit G (DLUG) also consists of the following peripheral units: Subscriber line module, digital (SLMD) for connecting wired ISDN subscribers Switching network D (SND) The switching network D (SND) is a new type of switching network providing many improvements compared to the SNB. The main target is to extend the switching perfor-
28
DRAFT
A50016-D1112-V41-2-7618
Information System
mance and to provide a non blocking switch. The hardware consists of the following functional units, depending on the capacity stage (Fig. 2.9): Switching network multiplexer (SNMUX) The switching network multiplexer (SNMUX) establishes the connections to the LTGs. The SNMUX consists of a switching network matrix. The SNMUX performs internal processing of the 8-Mbit/s signals from the LTGs and passes them on to the LTG (depending on the capacity stage) or, in the case of SNDs with more than 252 LTGs, via optical waveguides to the switching network matrix (SNMAT). Switching network matrix (SNMAT) The switching network matrix (SNMAT) is used with SNDs with a capacity of more than 252 LTGs. It switches from 16/16 to a maximum of 128/128 inputs/outputs for the SNMUX. The capacity stage of the SNMAT depends on the capacity stage of the SND. The SND is designed redundantly for security reasons (SND0 and SND1). Each connection is always switched over both SND sides at the same time. If one SND side fails, the redundant switching of connections through the two SND sides ensures that no call data are lost and that the SND retains all of its functionality. The following capacity stages are possible for the SND: SND for up to 126 LTGs SND for up to 252 LTGs SND for up to 504 LTGs SND for up to 1008 LTGs The different capacity stages of the SND are implemented by the number of switching network multiplexers (SNMUX) used. Only one switching network multiplexer is needed for an SND for up to 126 LTGs. In this configuration, the SNMUX has a switching function. Two switching network multiplexers (SNMUX1 and SNMUX2) are used in the case of an SND for up to a maximum of 252 LTGs. In this constellation, the SNMUX1 implements the switching function and the SNMUX2 the multiplexer/demultiplexer function. Both SNMUXs are directly connected with each other by optical waveguides at 920 Mbit/s in this capacity stage.
A50016-D1112-V41-2-7618
DRAFT
29
Information System
Optical waveguide with Switching network multiplexer (SNMUX 1) Switching network matrix (SNMAT)
LTG
Optical waveguide with 920 Mbit/s Switching network multiplexer (SNMUX 8)
LTG
S1
S1
S3
MBD
MBD
Fig. 2.9
Functional units in the SND (example: capacity stage for more than 252 LTGs)
Additional switching network multiplexers (up to a maximum of 8 SNMUXs, in case of type B) and a switching network matrix (SNMAT) are used in capacity stages with more than 252 LTGs (up to maximum 1008 LTGs). All SNMUXs are connected directly with the SNMAT using 920-Mbit/s optical waveguides. In this case the SNMUX implements the multiplexer function and the SNMAT the switching function. Coordination processor (CP113) The coordination processor (CP) is responsible in the Core Network (CN) node for common functions such as the coordination of the distributed peripheral microprocessor controls and data transfers between them. A CP type is available for each size of CN nodes: Coordination processor 113C (CP113C) Coordination processor 113E (CP113E) power CP providing greater performance
Within this document the term CP113 stands for all the CP types CP113C and CP113E. When necessary the types are distinguished by letters. The CP113 is responsible for the main database and for configuration and coordination of the distributed microprocessor controls and data transfer between them: Storing and administering all programs and data of the MSC/VLR node and the GMSC node Storing and administering all programs, exchange, trunk data Processing received information for routing, path selection, zoning, charges Communicating with the Switch Commander (SC) Supervising all subsystems, receiving error messages, analyzing supervisory result messages and error messages, alarm treatment, error detection, error location and error neutralization and conguration functions
30
DRAFT
A50016-D1112-V41-2-7618
Information System
Handling the man-machine (Q3) interface.
The CP113 is used in the network nodes of the MSC/VLR and the GMSC. The CP113 is a multiprocessor and can be expanded in stages. In the CP113 (Fig. 2.10), two or more identical processors operate in parallel with load sharing. The rated load of n processors is distributed among n+1 processors. This means that if one processor fails, operation can continue without restriction (redundancy mode with n+1 processors). The main functional units of the multiprocessor are as follows: Base processor (BAP) for CP113 basic conguration; for operation and maintenance and call processing Call processor (CAP) for maximum conguration of the CP113; for call processing only Common memory (CMY) Input/output controller (IOC) Input/output processors (IOP) ATM bridge processor (AMP).
If the EWSD platform is used for an HLR/AC classic node, the security box function is implemented by special IOP:AUC modules.
Periphery, I/O terminals, external memory
IOP 0
IOP
IOP 15 0
IOP
IOP
IOP 15 SSNC
BAP0
BAP1
CAP0
CAPn
IOC0
IOC1
IOC3 AMP0 AMP1
CMY0
CMY1
Fig. 2.10
Coordination processor (CP113) Other units assigned to the control area of CP113 are: Message buffer (MB) for coordination of internal message traffic between the CP113, the SN, the LTGs and the SSNC in an MSC/VLR and GMSC node. Central clock generator (CCG) for the synchronization of the MSC/VLR and GMSC node and, where necessary, the network. The CCG is extremely accurate (10-9). It can, however, be synchronized even more accurately by an external master clock (10-11). Local O&M terminal (craft terminal local, CTL) for operation and maintenance. A CTL is used for APS installation, recovery and O&M (e.g., to display system internal alarms). It is connected via a TCP/IP, X.25 or V.24 interface and enables administration of Q3 tasks, MML commands including basic man-machine language (BMML) command level.
A50016-D1112-V41-2-7618
DRAFT
31
Information System
External memory (EM), e.g., for Programs and data that do not always have to be resident in the CP113 A mirror image of all resident programs and data for automatic recovery Call charge and trafc measurement data. To ensure that these programs and data are safeguarded under all circumstances, the EM is duplicated. It consists of two magnetic disk devices (MDD). The CP113 also has a magneto-optical disk (MOD) for input and output.
2.2.2
MP Platform Parts - within the Circuit-Switched Domain

Within the circuit-switched part of the MSC/VLR node, the low layer SS7 functionality is implemented by the signaling system network control (SSNC) based on the ATM MP platform components. Moreover in the direction of the 3G RAN (Iu interface) the control plane functionality is implemented by a CP platform component LTG:(BSSAP/)RANAP supported by MP platform component MP:RANAP and the transport signaling plane functionality is implemented by an MP platform component MP:AAL2. TRAU service card, type D (TSCD) together with the AAL2 break server (A2BS), which is also based on the MP platform parts, implements speech transcoding on the circuit-switched path in the direction of the 3G RAN (Iu interface). For traffic over ATM CN between the RAN (A/Iu interface) and the neighbor MSC (visited MSC/VLR or GMSC) one part of the control signaling (control plane) functionality is implemented by an MP platform component MP:(RANAP/)BCF and the transport signaling plane functionality is implemented by an MP platform component MP:AAL2. For the same scenario the TRAU server card, type D (TSCD) together with the AAL2 break server (A2BS), which is also based on the MP platform, implements the voice transcoding on the circuit-switched path between the RAN and the neighbor MSC (MSC/VLR or GMSC). In this case (traffic over ATM CN) the traffic path follows TDM-based connections to use the resources of the MSC-Server part which also comprises the CP-based LTG:BICC. In case of 3G transcoder free operation (TrFO) the AAL2 break server (A2BS) implements a TrFO break functionality on ATM level without using the transcoding function of TSCD. A further MP platform component MP:ACC is utilized for general data collection (GDC), which can be used for charging purposes. Signaling system network control (SSNC) ITU-T standardized signaling system No.7 (SS7) is used (e.g., MSC/VLR - PSTN/ISDN; MSC/VLR - MSC/VLR; MSC/VLR - HLR/AC; MSC/VLR - RAN) for the exchange of signaling messages between network nodes in CN. By distinguishing between a message transfer part (MTP) and several user parts (UP)/application parts (AP), great flexibility is achieved using this signaling system. The common MTP functions in a circuit-switched domain Core Network (CN) are performed by the signaling system network control (SSNC) The UP/AP depends on the specific applications (e.g., ISUP = ISDN user part, BICC = Bearer Independent Call Control, TUP = telephony user part, MAP = mobile application part, RANAP = radio access network application part (3G only)). The SSNC hardware is based on ATM technology with a uniform data rate of 207 Mbit/s. A scalable central MP cluster is responsible for the main control of the universal ATM platform. All processors transport their communication via an ATM switching network
32
DRAFT
A50016-D1112-V41-2-7618
Information System
(ASN). In addition to the MPs, the peripheral units and the line interface card (LIC) functionality (which is integrated in TSCD) are interconnected to the ATM network. In case of an LIC (TDM) the LIC functionality performs rate adaptation between the 207 Mbit/s ATM format and the narrow band bit rate of the subscriber and trunk lines (64 kbit/s). Fig. 2.11 shows the SSNC in relation to the other hardware subsystems within the MSC/VLR node. The SSNC uses the following SS7-specific MP types for MTP and SCCP function (see also 2.7): MP:SM (signaling management tasks) MP:SLT (SS7 signaling link termination tasks)
The SSNC functionality is implemented on the basis of the MP platform which is also the main platform of the packet-switched domain node SGSN/SLR. The main hardware subsystems of the MP platform are: main processor (MP), ATM switching network (ASN) and line interface card (LIC) functionality. The ASN is therefore used both from the SSNC functionality and from the main processors for BCF, AAL2 and ACC (for GDCS), and as well from the TRAU server card and the AAL2 break server (see section 2.7). The main processor for charging/accounting (MP:ACC) is used for participating of charging data collection by general data collection (GDC) and hot operation protocol (HOP). Within the SSNC (MP platform), the board type MP-SA (main processor - stand alone) is also equipped. The MP-SA carries the software components MP:OAM (operation and maintenance) and MP:STATS (statistics). Furthermore, the SSNC (MP platform) can be equipped with the board type MP-IO (main processor - input/output) with load type MP:ACCIO/OAMD (for charging/accounting output processing) and with the board type MP-EN (main processor - Ethernet) with load type MP:SLT (for SS7 over IP).
A50016-D1112-V41-2-7618
DRAFT
33
Information System
trunks and SS7 links (64 kbit/s)
2 Mbit/s TDM LTG SN
conventional SS7 links (64 kbit/s)
2 Mbit/s TDM
SSNC 207 Mbit/s ATM LIC; TSCD with LIC function
ASN
high-speed signaling SS7 links (2 Mbit/s) 2 Mbit/s TDM/ATM
LIC
MP:SLT
MP:SLT SS7 over IP interface (Ethernet: 10/100 Mbit/s)
MP:SLT
MP:SM
to ABC
TCP / IP (Ethernet: 10/100 Mbit/s)
MP:ACC
MP:OAMD
SC
TCP / IP (Ethernet: 10/100 Mbit/s)
MP:OAM/STATS
207 Mbit/s ATM CP AMP MBD
Fig. 2.11
Hardware architecture of the SSNC in relation to the other hardware subsystems within the circuit-switched part of the MSC/VLR node
Especial circuit-switched functions for 3G only A few circuit-switched functions not shown in Fig. 2.11 but shown in Fig. 2.2 are also implemented in the MP platform for 3G: Main processor for RANAP (MP:RANAP) used for support of control signaling with radio access network application part (RANAP) together with the LTG:(BSSAP/)RANAP in the direction of the Iu interface.
34
DRAFT
A50016-D1112-V41-2-7618
Information System
Main processor for AAL2 (MP:AAL2) used for transport signaling from AAL2 bearer control (acc. ITU Rec. Q.2630) in the direction of the Iu,cs interface. TRAU server card, type D (TSCD) uses the PCP platform which is also used for an LIC. The TSCD is responsible for transcoding and rate adaptation of the circuitswitched voice. The TSCD terminates 64 kbit/s connections on E1 interface from the PSTN which are semipermanent signed to a port on the BSSAP/RANAP LTG on the CP platform part. The TSCD internal connections are implemented with ATM AAL0 switched virtual connections (SVCs). The circuit-switched data on the Iu,cs interface are directed via the TSCD to the BSSAP/RANAP LTG, IWF LTG, and DSU (IWF). In the process, conversion to the A-TRAU format takes place on the TSCD. AAL2 break server (A2BS) terminates AAL2 path permanent virtual connections (PVCs) and AAL type 2 user connections in the direction of the RNC. The A2BS internal connections are implemented with ATM AAL0 switched virtual connections (SVCs). Furthermore it handles the user plane protocol for AAL2 connections (Iu interface for RNC). The A2BS switches ATM cells within an AAL0 connection through the ASN between the LIC(ATM):Iu and the TSCDs. In case of transcoder free operation (TrFO) the A2BS implements a short cut of ATM connection.
In the former software release, an A2BS was introduced as a new server card, as a hardware pre-delivery for the separation of transport and control in the current software version. In the last software release, the A2BS was configured as an AAL2 server card (A2SC) and switches the AAL2 connections between ATM-LICs and TSCs. A2SC and A2BS were alternatives. Line interface card for Iu interface (LIC(ATM):Iu) transfers all the Iu,cs interface messages (e.g., control plane and user plane (including transport network signaling) messages). The LIC(ATM):Iu can be of the types LIC(ATM)-E1 or LIC(ATM)-STM-1).
Especial circuit-switched functions for traffic over ATM CN only A few circuit-switched functions for traffic over ATM CN not shown in Fig. 2.11 but shown in Fig. 2.2 are also implemented in the MP platform for 2G and 3G: Main processor for RANAP and bearer control function (MP:RANAP/BCF) used for the bearer control function (BCF) in the direction of the Nb interface. Main processor for AAL2 (MP:AAL2) used for transport signaling from AAL2 bearer control (acc. ITU Rec. Q.2630) in the direction of the Nb interface. TRAU server card, type D (TSCD) uses the PCP platform which is also used for an LIC. The TSCD is responsible for transcoding and adapting the rate of the circuitswitched speech. The TSCD is responsible for transcoding and rate adaptation of the circuit-switched voice. This second TSCD terminates the 64 kbit/s connections on E1 interface from the LTG:BICC and following LTG:BSSAP/RANAP of the CP platform part in the direction of the Iu interface. The TSCD internal connections are implemented with ATM AAL0 switched virtual connections (SVCs). The circuitswitched voice on the Iu,cs interface (coming from A2BS and rst TSCD - with rst AMR codec conversion) is directed via the internal LTG:BSSAP/RANAP and LTG:BICC to the second TSCD. AAL2 break server (A2BS) terminates AAL2 path permanent virtual connections (PVCs) and AAL type 2 user connections in the direction of the Nb interface. The A2BS internal connections are implemented with ATM AAL0 switched virtual connections (SVCs). Furthermore it handles the user plane protocol for AAL2 connec-
A50016-D1112-V41-2-7618
DRAFT
35
Information System
tions Nb interface for ATM CN). The A2BS switches ATM cells within an AAL2 connection through the ASN between the LIC(ATM):Nb and the TSCDs.
In the former software release, a A2BS was introduced as a new server card, as a hardware pre-delivery for the separation of transport and control in the current software version. In the last software release, the A2BS was configured as an AAL2 server card (A2SC) and switches the AAL2 connections between ATM-LICs and TSCs. A2SC and A2BS were alternatives. Line interface card for Nb interface (LIC(ATM):Nb) transfers all the Nb interface messages (that is, user plane (including transport network signaling) messages). The LIC(ATM) can be of the types LIC(ATM)-E1 or LIC(ATM)-STM-1.
2.3
Hardware Architecture of a GSM MGW Node (2G only)

The structure of a GSM MGW network node comprises the following main hardware components: Line trunk groups (LTG) - also for optional additional xed subscribers STMIs Remote timeslot interchange (RTI) Fig. 2.12 shows a block diagram of a GSM MGW.
digital trunks to optional fixed subscribers connected to GSM MGW (ISDN PA/PABX)
LTG
digital trunks to the 2G RAN with SS7(BSSAP)
LTG or STMI
digital trunks e.g., to PSTN/ISDN with SS7(ISUP/TUP) (backdoor trunks) digital trunks to other MSC/VLR with SS7(MAP)
LTG or STMI
LTG
GSM MGW control interface to MSC/GSM MSC-S (interface trunks) digital trunks to neighbor GSM MGWs (sidedoor trunks)
RTI
Fig. 2.12
Block diagram of a GSM MGW
36
DRAFT
Fig. 2.13 shows the interfaces of a GSM MGW and a GSM MSC-S.
A50016-D1112-V41-2-7618
Information System
GSM MGW/xxx Interworking interface
to fixed subscribers BSC to GSM mobile subscribers to fixed subscribers BSC GSM MGW GSM MGW GSM MGW control interface MSC with GSMMSC-S
Other networks (PSTN/ISDN, PLMN)
BSC
GSM MGW/xxx Interworking interface
Fig. 2.13
GSM MGW and GSM MSC-S interfaces
Line trunk groups (LTGs) In the GSM MGW, the LTGs use digital trunks to connect to the 2G RAN, to other MSCs, to ISDN/PSTN (backdoor trunks), and optionally to wired subscribers via ISDN primary rate access (PA) or ISDN-PABX. For a description of LTGs, see section 2.2, Hardware Architecture of an MSC/VLR Node. STMIs As an alternative to LTGs, the STMIs use digital trunks to connect to the 2G RAN and the ISDN/PSTN (backdoor trunks) in the GSM MGW. For a description of STMIs, see section 2.2, Hardware Architecture of an MSC/VLR Node. Remote timeslot interchange (RTI) In the GSM MGW, the remote timeslot interchange (RTI) implements the GSM MGW control interface between the GSM MSC-S and the GSM MGW. The RTI controls either: Interface trunks, that is, trunks between the GSM MSC-S and the GSM MGW for GSM MGW control, SS7 signaling transport and user data transport, optionally. Sidedoor trunks, that is, trafc between different GSM MGWs without leading the trafc via the GSM MSC-S. Backdoor trunks, that is, trafc within a GSM MGW to PSTN/ISDN or other MSC/VLRs. A interface trunks, that is, trafc within a GSM MGW to the BSC.
A50016-D1112-V41-2-7618
DRAFT
37
Information System
SND HTI (in GSM MSC-S)
TSI
RSUC
MH
DIU240
DIU240
Interface trunks (8 x PCM30)
Sidedoor trunks (8 x PCM30)
RTI (in GSM MGW1) TSI
DIU240
DIU240
DIU240
DIU240
RTI (in GSM MGW2)
TSI RSUC RSUC
MH
MH
LTGPs
LTGPs
Fig. 2.14
Remote timeslot interchange (RTI) - in connection to the host timeslot interchange (HTI)
38
DRAFT
The remote timeslot interchange (RTI) have identical hardware components as the host timeslot interchange (HTI) and consists of the functional units (Fig. 2.14): Message handler (MH) Signaling between GSM MGW (that is, LTG) and GSM MSC-S (that is, CP113). Timeslot interchange (TSI) Blocking free local switching network. The TSI consists of access multiplexers (AMUX) and timeslot interchange modules (TSIM). Remote switching unit controller (RSUC) Component controls the RTI-HTI connection and communicating with the GSM MSC-S (that is, CP113) like an LTG. Internally, it communicates with the MH and the TSI to set up and release paths and for O&M purposes.
A50016-D1112-V41-2-7618
Information System
Digital interface unit 240 (DIU240) DIU240 connectivity for 8 PCM 30 links between the GSM MGW and the GSM MSCS and other GSM MGWs.
i 2.4
To implement standardized interfaces, a common LTGP or STMI is required.
Hardware Architecture of a GMSC Node

The GMSC nodes in the circuit-switched domain of Core Network (CN) are implemented with the proven SIEMENS electronic switching system digital (EWSD) platform (CP platform) and signaling system network control (SSNC) platform (MP platform).
2.4.1
CP Platform Parts
The structure of the CP platform part of a GMSC node comprises the following main hardware components: Line trunk groups (LTG) Switching network (SN) Coordination area with; coordination processor (CP113), message buffer (MB) and central clock generator (CCG).
2.4.2
MP Platform Parts
The SS7 functionality of a GMSC node is implemented on the base of the MP platform. This hardware component of the GMSC network node is equivalent to: Signaling system network control (SSNC).
A few circuit-switched functions for traffic over ATM CN shown in Fig. 2.15 are also implemented in the MP platform: Main processor for bearer control function (MP:BCF) Main processor for AAL2 (MP:AAL2) TRAU server card, type D (TSCD) AAL2 break server (A2BS) Line interface card for Nb interface (LIC(ATM):Nb)
Fig. 2.15 shows a block diagram of a GMSC node.
For detailed hardware architecture see section 2.2 above, which describes the CP platform and the MP platform for the circuit-switched domain part of the MSC/VLR nodes.
A50016-D1112-V41-2-7618
DRAFT
39
Information System
to MSC/VLR (E interface) to MSC/VLR (E, Nc interface)
LTG:ISUP SN LTG:ISUP/BICC
LTG:ISUP
to ISDN/PSTN to PLMN
LTG:BICC CCG
MB
CP 113
CP platform
MP platform TSCD ASN MP:BCF A2BS to MSC/VLR (Nb interface) MP:AAL2 LIC (ATM):Nb MP:STATS MP:SLT MP:OAM MP:SM MP-SA MP:OAMD TCP / IP to ABC TCP / IP Switch Commander (SC)
MP:ACC
Fig. 2.15
Block diagram of a GMSC node
40
DRAFT
A50016-D1112-V41-2-7618
Information System
2.5
Hardware Architecture of an HLR/AC Classic (HLRc) Node

The HLR/AC classic (HLRc) nodes are implemented with the proven SIEMENS electronic switching system digital (EWSD) platform (CP platform) and signaling system network control (SSNC) platform (MP platform).
2.5.1
CP Platform Parts
The structure of the CP platform part of an HLR/AC classic (HLRc) node comprises the following main hardware components: Line trunk groups (LTG) *) Switching network (SN) *) Coordination area with; coordination processor (CP113), message buffer (MB) *) and central clock generator (CCG). *) Not in compact HLR/AC classic node.
2.5.2
MP Platform Parts
The SS7 functionality of an HLR/AC classic (HLRc) node is implemented on the basis of the MP platform. This hardware component of the HLRc node is equivalent to: signaling system network control (SSNC). Fig. 2.16 shows a block diagram of an HLR/AC classic (HLRc) node (with SSNC).
For detailed hardware architecture see section 2.2 above which describes the CP platform + MP platform for the circuit-switched domain part of the MSC/VLR nodes. An HLRc network element integration into a circuit-switched MSC/VLR node is possible, but not an integration into a pure packet-switched SGSN/SLR node.
to MSC/VLR (C/D interface) to SGSN/SLR (Gr interface)
LTG
LTG to SMSC (Gd interface) LTG to SLMC (Lh interface) LTG CCG SN
MB
CP 113
CP platform
SSNC MP platform
TCP / IP
Switch Commander (SC)
Fig. 2.16
Block diagram of an HLR/AC classic (HLRc) node (with SSNC)
A50016-D1112-V41-2-7618
DRAFT
41
Information System
Fig. 2.17 shows a block diagram of a compact HLR/AC classic node (with SSNC - but with no SN, LTG and MB).
For detailed hardware architecture see section 2.2 above, which describes the CP platform and MP platform for circuit-switched domain MSC/VLR nodes (MSC/VLR network element). A compact HLR/AC classic network element (with SSNC - but with no SN, LTG and MB) can be connected via LIC (TDM)-E1 directly to the other PLMN CN nodes. Since the HLR supports SS7 messages only, the hardware components SN, LTG and MB are not necessary.
SSNC to MSC/VLR (C/D interface) LIC(TDM)-E1 to SGSN/SLR (Gr interface) LIC(TDM)-E1 to SMSC (Gd interface) LIC(TDM)-E1 to SLMC (Lh interface) LIC(TDM)-E1 MP platform MP:OAM TCP / IP Switch Commander (SC) A S N MP:SM
MP:SLT
CP 113
CCG
CP platform
Fig. 2.17
Block diagram of a compact HLR/AC classic node (with SSNC - but with no SN, LTG and MB)
2.6
Hardware Architecture of an EIR Node

The EIR nodes in the circuit-switched domain of Core Network (CN) are implemented with the proven SIEMENS electronic switching system digital (EWSD) platform (CP platform) and signaling system network control (SSNC) platform (MP platform).
2.6.1
CP Platform Parts
The structure of the CP platform part of a EIR node comprises the following main hardware components: Line trunk groups (LTG) Switching network (SN) Coordination area with; coordination processor (CP113), message buffer (MB) and central clock generator (CCG).
42
DRAFT
A50016-D1112-V41-2-7618
Information System
2.6.2
MP Platform Parts
The SS7 functionality of an EIR node is implemented on the base of the MP platform. This hardware component of the EIR network node is equivalent to the: Signaling system network control (SSNC). Fig. 2.18 shows a block diagram of an EIR node.
For a detailed description of the hardware architecture, see section 2.2, which describes the CP platform and the MP platform for the circuit-switched domain part of the MSC/VLR nodes.
to MSC/VLR (F interface) LTG to SGSN/SLR (Gf interface) LTG SN CCG
MB
CP 113
CP platform
SSNC MP platform
TCP / IP
Fig. 2.18
Block diagram of an EIR node Fig. 2.19 shows a block diagram of a compact EIR node (with SSNC - but with no SN, LTG and MB).
For detailed hardware architecture see section 2.2 above, which describes the CP platform and MP platform for circuit-switched domain MSC/VLR nodes (MSC/VLR network element). A compact EIR network element (with SSNC - but with no SN, LTG and MB) can be connected via LIC (TDM)-E1 directly to the other PLMN CN nodes. Since the EIR supports SS7 messages only, the hardware components SN, LTG and MB are not necessary.
A50016-D1112-V41-2-7618
DRAFT
43
Information System
SSNC to MSC/VLR (F interface) LIC(TDM)-E1 to SGSN/SLR (Gf interface) LIC(TDM)-E1 A S N MP:SM
MP:SLT
MP:OAM
TCP / IP
MP platform
CP 113
CCG
CP platform
Fig. 2.19
Block diagram of a compact EIR node (with SSNC - but with no SN, LTG and MB)
44
DRAFT
A50016-D1112-V41-2-7618
Information System
2.7
Software Architecture of an MSC Node, HLR/ACc Node, EIR Node

The software architecture of the circuit-switched MSC/VLR, HLR/ACc and EIR node is described by the software architecture of the CP platform and the software architecture of the MP platform below.
i
2.7.1
The software description of the CP platform mainly describes the CP113 software, but is in principle also valid for the MP software of the MP platform.
Software Architecture of the CP Platform

The CP platform-based node software is characterized by high quality and reliability, extensive dynamic capabilities (real-time requirements) and flexibility for implementations of additional functions. These characteristics have been achieved in a cost-effective manner by: exible, modular software architecture efcient CHILL-based software technology and consistent software quality assurance. The great flexibility of the circuit-switched part of the CP platform-based node stems from the extensive use of reloadable software. Only a few processors, namely those with a narrow range of functions that do not depend on the application, such as the switching network and message buffer controls, contain programs that are stored in read-only memories. The reloadable software for a CP platform-based node including the node-specific data forms the application program system (APS). For reasons of security, a current image of the APS is held in the duplicated external memory in each CP platform-based node. Hardware is subject to rapid technological change. To enable UMTS to profit from this evolution, the design of the CP platform-based node software is such that only a minimum of it is hardware-dependent. In accordance with the distributed control on the CP platform-based node each processor in the system requires its own software. This software is divided into an applicationindependent and an application-specific part (Fig. 2.20). The application-independent part always contains the operating system which is tailored to the functions of a particular hardware subsystem. The application-specific software also called the user software implements the functions for the various applications. The operating system provides all the programs in the user software with a uniform convenient interface through which users can make use of operating system functions and therefore the resources of the processor. The software of the individual processors normally contains a wide variety of functions. It is accordingly divided into subsystems. Each subsystem generally contains several modules. These represent the smallest units for compilation. The various types of data are essential components of the CP platform-based node software. Data can be classified according to type, scope, lifetime and storage location. Node-specific data is held in the database of the CP113. Its size and contents depends on the equipment and the network environment of the node involved. The database is part of the user software.
A50016-D1112-V41-2-7618
DRAFT
45
Information System
Application-specific software Application-independent software
Hardware
Operating system
User software
Fig. 2.20
Software shells for a processor
The call processing programs control the establishment of connections in accordance with subscriber requirements. Apart from the appropriate hardware resources, these programs require information about the network termination characteristics and the network environment (e.g., for routing). This information has to be provided by the operating company. Q3 tasks/MML commands can be used to incorporate such information into the system and to administer it there. Commands of this type are evaluated by the administration programs. The call processing programs also provide charge data and traffic data; the administration program edits this data, saves it and outputs it on demand. Safeguarding and maintenance programs guarantee unimpaired system operation. The safeguarding programs are part of the operating system and are executed automatically. In contrast, the maintenance programs such as the call processing and administration programs are user programs. Some of them only run after the appropriate Q3 tasks/MML commands have been entered. They make use of safeguarding program functions.
2.7.1.1
Operating System
Each processor in a CP platform-based node has its own operating system with capabilities dependent on the tasks to be performed by the processor and the resources which it manages. All operating systems have to perform their functions under real-time conditions. They are, therefore, interrupt-driven and work according to priorities. The coordination processor (CP113) operating system consists of executive and safeguarding programs. Executive programs The integral parts of the executive programs are: Scheduler The scheduler determines the sequence in which the CP113 performs its tasks. After the start phase, this is generally the sequence of events such as inputs or operating system requests. Individual functions or sub-functions are mainly arranged as
46
DRAFT
A50016-D1112-V41-2-7618
Information System
processes in the CP113 and are administered by the scheduler via process queues. Different priorities are assigned to the processes. When an event occurs, it generates an interrupt of the process currently executed and activates the scheduler, which then analysis the event sufciently to determine the process or program which is to perform further processing. The scheduler then transfers control to the process with the highest priority which is ready to run. If two or more processes with the same priority are ready to run, the process which has been waiting the longest, is given preference. The interrupt facility, the dening of processes to match the functions performed and the correct assignment of priorities guarantee that the real-time conditions are fullled and that the CP113 can respond to an event within an appropriate time. Timer administration Timer administration allows user programs to set and reset timers. In this way, they can supervise the correct timing for execution sequences and initiate further activities after a specic time. In addition, the user programs can interrogate timer administration to obtain the current date and time of delay. Memory management The time-critical part of the CP113 software is always loaded into the memory unit of the CP113 (resident). The remaining memory (unassigned memory) is available for the reloadable software, if required. It is allocated and released again by memory management. Input and output The input and output part of the executive programs controls and supervises the exchange of messages with the call processing periphery (LTG), the signaling system network control (SSNC) and the operation and maintenance periphery, and preprocesses Q3 tasks/MML commands.
Safeguarding programs The functions of the safeguarding programs are: Determining a functional system conguration on startup and establishing this conguration Recording and processing safeguarding messages from the periphery and from CP113 processes Controlling the execution of periodic checks Evaluating alarms from supervision circuits in the CP113 Collecting error symptoms and saving them Analyzing and locating errors Reestablishing an operable system conguration after hardware faults, and Rectifying, by means of adequate recovery measures, the effects of software errors which cannot be neutralized by the user programs themselves. Recovery measures in the CP platform-based node are implemented on several levels. The main levels are restart, new start and initial start. Restart only applies to the currently running process and does not affect more than one connection. New start resets all processes and affects those connections which are currently set up. Initial start, which involves reloading the entire software, results in the release of all connections. The choice of recovery level depends on the type and frequency of the detected software error. In the first instance, the level that promises success while involving the least
A50016-D1112-V41-2-7618
DRAFT
47
Information System
impairment of normal operation is selected. But if the same error recurs, the next higher recovery level comes into effect (escalation).
2.7.1.2
User Software
The user software implements the call processing, administration and maintenance functions and the associated database required for the specific application. New features, e.g., a specific signaling system for trunks, and whole feature packages can be easily implemented in the CP platform-based node by means of appropriate subsystem variants or by adding new subsystems. Database The node-specific data stored in the database cover, e.g., the following: Hardware image Hardware conguration Hardware characteristics Hardware states; Termination characteristics, e.g., Service features Signaling features Grouping of lines (trunk groups); Data for the establishment of links, e.g., between equipment number and termination data; Call setup, e.g., Digit translation Routing; Data accumulated during operation, e.g., Charging Trafc measurement. The database contains both transient and semipermanent data. The transient data is largely call-related and is, therefore, continuously changed by the call-processing programs during operation. The semipermanent data, on the other hand, describes conditions and characteristics which change relatively seldom during operation, e.g., the system configuration or line characteristics. This data is under write protection and its current image is always kept in the external memory. Semipermanent data is changed by entering the appropriate Q3 commands or by means of subscriber input. A number of modules in the database contain the definitions of data structures, data declarations and the access procedures. Users can only access data via these procedures. Initially, data fields are only small, their ultimate size depending on the capacity and port assignments of a particular node. A utility program is employed to expand data fields to meet the planned requirements. The database can be extended while the system is in operation. In accordance with the distributed control principle employed in the CP platform-based node, images of parts of the database are also found in peripheral processors such as the group processors and the common channel signaling network control.
48
DRAFT
A50016-D1112-V41-2-7618
Information System
Call processing programs In the coordination processor, the call processing programs e.g., for the CP platformbased nodes, only handle those call processing functions which require access to data available only to the CP113: Reading and analysis of call and network termination data Digit translation with the following functions: destination routing with possible route processing and charge zone determination Path selection in the switching network image and sending of setting commands to the switching network control Sending of messages to the group processors with the objective of initiating specic actions and transferring to the group processors the information required for further independent call processing. The call processing programs in the group processors (GP) deal with most of their call processing tasks without involving the CP113. They are activated by call processing events from the LTG periphery, commands from the CP113, reports from other GPs and orders from the SSNC. Event and message processing activities of the GP are as follows: Timing supervision Evaluation of call data and network termination data Modication of call data and transient network termination data Identication of signals Sending of messages to the CP113, reports to other GPs, or order to the SSNC Seizure and release of trafc channels Standardization of signaling before informing the CP113 or another GP (physically different signals from different signaling procedures with identical meanings are converted into uniform internal messages) Control of signaling Pre-analysis of dialed digits Execution of service feature-specic activities (provided no central coordination is required) Sending of setting commands to the group switch Generation of charge statistics and trafc data. Administration programs The CP113 administration programs, process the administrative Q3 tasks/MML commands. Activities required here are as follows: Incorporation of data into the database Modication of data in the database Reading and editing data in the database for output Using appropriate messages to pass information to the peripheral processors, (GP, MP) concerning data modication Control of trafc measurement processes in the CP113 Activation of measurements (trafc and statistics) in the periphery. In addition, the administration programs save charge, statistics and traffic data in the external memory. These are obtained from the call processing programs in the CP113 or supplied by the administration programs of the peripheral processors.
A50016-D1112-V41-2-7618
DRAFT
The administration programs of the peripheral processors (GP and MP) process the messages from the administration programs of the CP113. In response they: inform other peripheral processors;
49
Information System
modify their own data (partial image of the database); start or end measurements (statistics and trafc) and transfer data to the CP113.
Maintenance The CP113 maintenance programs process the Q3 tasks/MML commands that are essential for the provision of trouble-free service. Among the activities required here are: Control of conguration and recovery processes with the aid of safeguarding programs Control of measurement and testing processes for the trunk network Control of fault analysis and diagnostic processes Initiation of conguration, recovery, testing, measurement and diagnostic activities in peripheral processors using the appropriate commands. In addition, they process messages containing measurement, test and diagnostic results from the LTGs (GP). Another function of the maintenance program is to display faults on the craft terminal local (CTL) and provide audible signals for them where necessary. The maintenance programs of the GP process: commands from maintenance programs in the CP113; results from test equipment for trunks in the LTGs and messages from supervision equipment and supervision programs in the LTGs (e.g., trunk maintenance). Possible GP reactions are as follows: Sending control messages to test equipment Starting test and diagnostic procedures Executing conguration measures Sending messages to the CP113.
2.7.1.3
Software Technology
The CP platform-based node software technology is characterized by: Powerful standardized description and implementation languages (SDL, CHILL) Extensive and convenient hardware and software support (support software also based on CHILL). Specification and description language (SDL) An important design aid for the CP platform-based software is the specification and description language (SDL) standardized by the ITU-T. It is particularly suitable for providing unambiguous descriptions of processes and execution sequences which are characterized by states, events and by the ensuing actions and state transitions. The CP platform-based node development environment allows the developers to design, modify and administer computer-aided SDL diagrams and their graphic symbols. The SDL diagrams are the basis for coding in CHILL or assembler. A special software tool allows the assembler code to be generated directly from the SDL logic. CHILL
50
DRAFT
The source modules of the CP platform-based node software are largely written in the ITU-T standard high-level language CHILL. CHILL guarantees both structured programming and modular structure. Software written in CHILL is to a large extent self-documenting, easy to read, easy to expand and easy to maintain. CHILL, as a modern high-
A50016-D1112-V41-2-7618
Information System
level programming language, is the basis for the extensive portability of the CP/MP platform-based software. This means that software written in CHILL can be run on commercial data processing systems and on the CP platform-based coordination processors. In contrast to many other programming languages, CHILL provides specific facilities for declaring data types (modes) and structures. This allows interfaces to be precisely defined and automatically checked. This is extremely important in a project where more than one thousand software modules have to be linked together to an application program system (APS). Support software Efficient development and quality of software are greatly influenced by the support available. Commercial computer systems, personal computers and switching processors are used for the CP platform-based software development. Commercially available software is only able to support development activities to a limited extent. An extensive package of the CP/MP platform-based node support software is therefore needed to support rapid development, production and updating of application program systems. This software, including the CHILL compiler, is written in CHILL and is, therefore, portable. It supports all phases of the CP platform-based software development from analysis to application.
2.7.2 2.7.2.1
Software Architecture of the MP Platform Main processor (MP)

The software load running on one MP is characterized by a software loadtype, which can consist of one or more software components (e.g., loadtype MP:RANAP/BCF consists of the software components MP:RANAP and MP:BCF). The following software components/load types are available for the main processor: MP:RANAP (radio access network application part) (3G only) MP:RANAP is a software component that runs on the MP-AP module covering the support of control signaling (together with CP platform component LTG:(BSSAP/)RANAP) in the direction of the radio access network (Iu interface). MP:BCF (bearer control function) MP:BCF is a software component that runs on the MP-AP module (together with MP:RANAP) covering the bearer control plane in the direction of the radio access network (Iu interface) and in the direction of the ATM Core Network (Nb interface). MP:AAL2 (ATM adaptation layer 2) MP:AAL2 is a software component that runs on the MP-AP module covering transport signaling for AAL2 bearer control (acc. ITU Rec. Q.2630) in the direction of the Iu interface and to the ATM Core Network (interface Nb). MP:SM (signaling management) MP:SM is a software component that is used for SS7 handling. MP:SLT (signaling link termination) is a software component that is used for SS7 handling.
A50016-D1112-V41-2-7618
DRAFT
51
Information System
MP:ACC (accounting/charging) MP:ACC is a software component that is used for accounting functions. It is responsible for the accounting/charging data and layer management. MP:OAM (operation and maintenance) MP:OAM is a software component that runs on the MP-SA load type covering all operation, administration and maintenance functions. The Switch Commander (SC) is connected to this MP. MP:STATS (statistics) MP:STATS is a software component that runs on the MP-SA load type covering all statistic (for performance management/traffic management) functions. MP:OAMD (or charging output processing) MP:OAMD is a software component that runs on the MP-IO module covering all charging data transfer functions to an Administration and Billing Center (ABC).
2.7.2.2
TRAU server card, type D (TSCD)

The TSCD supports transcoding and rate adaptation of the circuit-switched speech and the user plane protocol termination. Furthermore, the TSCD supports the A-TRAU format conversion for circuit-switched data via DSU (IWF) and supports all adaptive multi rate (AMR) modes. In the case of the traffic over ATM CN application, the TSCD is responsible for the support of compressed mode for speech, termination of user plane protocol, support of TDM to ATM/AAL2 conversion, termination of ATM/AAL2 connections and transcoding between G.711 and compressed speech.
2.7.2.3
AAL2 break server (A2BS)

The A2BS switches the AAL2 connections between ATM-LICs and TSCDs. This is the case between Iu interface and TSC and between Nb interface (for traffic over ATM CN) and TSCD*.
2.7.2.4
Line interface cards (LIC)

For CN, the MP platform uses two different types of LICs: LIC for E1, TDM based (LIC(TDM)-E1) This LIC type is supporting the SS7 application on the CAP, Gs , Gr interface. LIC for E1, ATM based (LIC(ATM)-E1), supporting the user plane and control plane (SS7) application on the Iu interface and on the Nb interface (for traffic over ATM CN). The LIC(TDM/ATM)-E1 provides symmetrical interfaces with a bit rate of 2.048 Mbit/s. It provides cell-based traffic on the internal interface to the ASN. The external line interface carries constant bit rate (CBR) traffic. Therefore, the LIC provides functions for interworking between the STM and the ATM using the AAL1 type of service for packaging CBR traffic into ATM cells.
52
DRAFT
LIC for STM-1 (LIC(ATM)-STM-1)
This LIC type is supporting the user plane and control plane (SS7) application on the Iu interface and on the Nb interface (for traffic over ATM CN).
A50016-D1112-V41-2-7618
Information System
This LIC provides an STM-1 interface (155.520 Mbit/s) which carries ATM cells embedded in a SDH STM-1 frame.
A50016-D1112-V41-2-7618
DRAFT
53
Information System
3 Functions of the Circuit-Switched Domain of Core Network (CNcs) Subsystem

3.1 Functions of the Circuit-Switched Domain of Core Network (CNcs)
The functionality of the Core Network (CN) is described in the following by the individual functions of the CN network elements: MSC/VLR node, consisting of 2G MSC node or 2G MSC part of a 2G/3G MSC node (not used in a pure 3G PLMN) 3G MSC part of a 2G/3G MSC node (not used in a pure 2G PLMN) VLR Optional GSM MGW node (2G only) GMSC HLR/AC, consisting of HLR AC. EIR Following functions are described separately and not within the functions of the CN network elements (MSC and VLR/GCR, as well as HLR and AC or EIR) illustrated here in this section: The IN functionality of a Mobile Service Switching Point (M-SSP) is described in section 3.3 and the functionality of a Combined Switching Center (CSC) is described in section 3.2.
3.1.1
Functions of the MSC Network Element

The MSC/VLR controls all services of mobile users roaming in the RAN part which is served by BSCs/RNCs connected to the MSC/VLR via the A interface or Iu interface. The user database (VLR) contained within the MSC/VLR holds, after successful registration, the subscription data that is downloaded from the HLR, as well as temporary information about the user data. The main functions of the user database are the support of mobile-originated and mobile-terminated services and database restoration in case of failures. The MSC can play several roles. The roles and their basic meaning are listed in the following: Visited MSC (VMSC) MSC which serves the area of mobile subscribers / where the access network is connected to. Gateway MSC (GMSC) MSC which performs HLR interrogation and interconnects several network (types). Transit MSC (TMSC) Relaying of transport and signaling within a network. One MSC can play different roles. There are PLMNs in which e.g., some VMSCs are also used as TMSCs and GMSCs.
54
DRAFT
A50016-D1112-V41-2-7618
Information System
The MSC network element is a stored-program controlled digital exchange. The MSC (third generation Mobile-services Switching Center) network element is the exchange in the circuit-switched part of a PLMN that performs call processing; works as a gateway to other networks; is connected to other MSC network elements in the PLMN; connects the network elements of the Core Network (CN) to the network elements of the RAN in the service area of the circuit-switched part of a PLMN. The MSC network element has functions which are known from the exchanges in the fixed networks and special functions which are not necessary in the fixed network exchanges. The mobile-specific functions result from the mobility of the subscriber. Basic functions of the MSC network element are (for traffic over TDM CN), for instance: Selection of the routes Setting up of trafc and signaling connections Supervision of connections Message accounting Optimal routing Carrier routing call by call and preselected Number portability Location services Supporting telecommunication services Trafc data management (e.g., trafc measurement) Overload handling Optional support of trafc over ATM CN. GSM MSC-S functionality (2G only) is, for instance: Call control for the trafc trunks within the controlled GSM MGW Charging and billing Charging collection function Charging gateway function Charging with hot operation Special charging features Interadministrative procedures for billing/revenue accounting Enhanced functions of call routing, charging and user information are, for instance: Flexible routing of calls in the CN (A-number dependent) IMSI/MSISDN-dependent routing Subscriber data-specic routing Number length-dependent routing Subscriber data-specic charging generation Subscriber-specic Advice of Charge Multilingual announcements IN: Inuenced management of call legs (leg management) IN: Call party handling and midcall trigger IN: Announcement in parallel to call setup IN: Advanced interworking with supplementary services IN: Audible checking of announcements
A50016-D1112-V41-2-7618
DRAFT
Enhanced functions of call handling, charging and user information in the CN Flexible routing of calls A-directory number-dependent routing, charging and barring IMSI/MSISDN-dependent routing
55
Information System
Subscriber data-specic routing Multilingual announcements.
Mobile-specific functions of the MSC network element are: Mobility management: IMSI attach/detach, location update, interrogation, paging, handover/relocation Resource management Pooling for circuit allocation on A interface (2G only) Access to PLMN databases (VLR, GCR (2G only), HLR, EIR) Special security functions Control of queue operation with priority stages for the RAN (2G only) IWF for circuit-switched data services (BS20) TRAU functions for speech transcoding Fraud prevention functions Capacity increasing functions (2G only)
3.1.1.1
Functions of the GSM MGW Network Element (2G only)

The GSM MGW concept targets remote locations with a high portion of local traffic. The GSM MGW provides the transport functionality, while call control is performed by the GSM MSC-S functionality of the MSC.
This approach represents the first proprietary step towards implementing 3GPP Rel-4 architecture with its separation of control and transport. The concept of GSM MGW and GSM MSC-S described in this section is a proprietary solution of 3GPP Rel-4 (or later) architecture with its separation of control and transport. It differs from the concept of CS-MGW and MSC-S described in the section 4.8, MobileSpecific Functions of Circuit-Switched Call Handling - for Traffic over TDM CN, because the CS-MGW and MSC-S implements the original 3GPP Rel-4 (or later) architecture step by step. Here in the current software version the MSC-S and CS-MGW are still implemented as an integrated internal solution. It can be used to optimize transport or alternatively to minimize the number of switching elements in a GSM PLMN. Additionally, a GSM PLMN consolidation with reduction of the number of MSC is also possible. The GSM MGW enables local switching for mobile subscribers for: Mobile-to-mobile calls Mobile-to/from-PSTN calls Optional fixed subscribers via ISDN primary rate access (PA) or ISDN-PABX can also be additionally connected to GSM MGW node. Using the GSM MGW, requires less link capacity between the served BSC and the controlling MSC because local switching reduces traffic in this section. Only transit traffic (if network planning topology requires it) and calls to pooled equipment, e.g., interworking function (IWF) for data services or announcement equipment, are routed to the MSC. This type of equipment is best located at the MSC due to CAPEX and also traffic model considerations. To provide local switching functionality full MSC functionality, is not necessary at the remote location. The GSM MGW provides the same full-feature functionality as the controlling MSC.
56
DRAFT
To control the GSM MGW, the MSC is enhanced with GSM MSC-S functionality and the GSM MGW control interface.
A50016-D1112-V41-2-7618
Information System
3.1.1.2
Functions of the VLR Network Element

The VLR within MSC/VLR registers all mobile subscribers located in its service area. As long as a mobile subscriber is present, the VLR contains all parameters of the mobile subscriber required by the call handling functions. Call handling functions The call handling functions include addressing and identification. Addressing and identification are effected by means of: the international mobile subscriber identity (IMSI) the local mobile subscriber identity (LMSI) the mobile subscriber roaming number (MSRN). Call setup In an MSC network element, the call setup function is initiated by the MS via the MSC network element to retrieve the necessary mobile subscriber parameters from the VLR. The mobile subscriber is identified by the IMSI. Location registration The location registration function includes procedures for: location update and location cancellation. The location update procedure is initiated by the MS via the MSC network element if the MS changes the location area or if a timer has expired. The procedure determines the location of the mobile subscriber (VLR address) for the HLR and the authentication parameters of the mobile subscriber for the VLR concerned. The location cancellation procedure is initiated by the HLR when the mobile subscriber has left the VLR service area. Radio access security and user authentication The radio access security and user authentication is different between 2G GSM and 3G UMTS case: Authentication, ciphering and TMSI reallocation (2G case): Authentication is activated in conjunction with a location update if the mobile subscriber exceeds the limit of the VLR. For this purpose, the new VLR requests the unused triplets from the previous VLR (each triplet consisting of the random number for authentication (RAND), the signed response (SRES) and the cipher key (Kc)). These triplets are used by the new VLR for authentication. The new VLR can request a new set of triplets from the AC via the HLR, if the value falls below a minimum number in the VLR. An authentication request output by the VLR causes the MS to respond. The VLR compares the value of the signed response (SRES) transmitted by the MS with the value stored in its data record. If these values agree, authentication is successfully concluded. If authentication is not successful, an entry can be made in the security le. The condentiality of user data on the radio interface is secured by ciphering with the cipher key (CK). The user identity condentiality is secured by TMSI reallocation.
A50016-D1112-V41-2-7618
DRAFT
57
Information System
Authentication and key agreement, integrity check, ciphering and TMSI reallocation (3G case): Authentication and key agreement (AKA) is activated in conjunction with a location update if the mobile subscriber exceeds the limit of the VLR. For this purpose, the new VLR requests the unused quintets from the previous VLR (each quintet consisting of the random number for authentication (RAND), the extended response (XRES), the cipher key (CK), the integrity key (IK) and the authentication token (AUTN)). These quintets are used by the new VLR for authentication. The new VLR can request a new set of quintets from the AC via the HLR, if the value falls below a minimum number in the VLR. An authentication request output by the VLR causes the MS to respond. The VLR compares the value of the signed response (RES) transmitted by the MS with the value XRES stored in its data record. If these values agree, authentication is successfully concluded. If authentication is not successful, an entry can be made in the security le. The key agreement in the context of AKA is only the generation of the IK and CK. Together with the authentication a data integrity check is performed which enables the receiving entity to verify that signaling data has not been modied in an unauthorized way since it was sent by the sending entity, and that data origin of the signaling data received is indeed the one claimed. The condentiality of user data on the radio interface is secured by ciphering with the cipher key (CK). The user identity condentiality is secured by TMSI reallocation.
During inter-system handover, security parameters must be transported to the target entity (e.g., RNC, MSC) via the appropriate protocols. When handing over from 2G to 3G, the security keys must be converted because the 3G UMTS authentication consists of 5 parameters (unlike 2G GSM, where the authentication vector consists of 3 parameters). In the case of a 2G mobile subscribers inter-system handover from 2G to 3G, it is necessary to convert the 2G GSM security parameter Kc into the 3G UMTS security parameters CK and IK if 2G GSM authentication has been established. If a 3G mobile subscriber roaming in the 2G PLMN needs to be handed over to a 3G PLMN, a new authentication procedure is necessary. Because the 2G security context of the 3G mobile subscriber, which is derived from the 3G security context, information is lost. Therefore, the 3G security context cannot be reconstituted. Signaling information routing For the routing of signaling information to the HLR, the signaling information routing function refers to the IMSI of the mobile subscriber to determine: the signaling point code (SPC) of the HLR (in the same signaling network) and the global title (in the international signaling network between the various PLMNs). For routing signaling information to the previous VLR, the signaling information routing function uses the old location area identity (LAI), to determine the SPC of the previous VLR. Database The VLR database is subdivided into a semipermanent and a transient part. The semipermanent part has images on duplicated disks.
58
DRAFT
The signaling routing database is located in the semi-permanent part of the VLR database. It contains the IMSI and the LAI digit translators that make available the HLR address or the address of the preceding VLR.
A50016-D1112-V41-2-7618
Information System
In the semipermanent part, the national roaming database stores data from the areas in which the mobile subscriber is permitted, in accordance with national agreements, to make outgoing calls. The mobile subscriber database is located in the transient part of the VLR database. It contains the call processing data of the mobile subscribers currently located in the location area. Its memory is allocated dynamically and separately for each mobile subscriber. Data is distributed in several pools, e.g.: Joint data pool with MSISDN, certain supplementary service data, location area identity (LAI) and security data Call forwarding data pool with the call forwarding data (e.g., forwarding number) Basic telecommunication data pool with the registered and activated supplementary services CUG data pool (e.g., CUG index). Administration software The administration software has three functions: Parameter administration Updating the mobile subscriber data Trafc data management (e.g., trafc measurement). The software for parameter management uses Q3 instructions to manage the database. The following examples are data that can be managed: Location area identity (LAI) MSRN Timers. The function for updating the mobile subscriber data in the VLR is initiated by the HLR if mobile subscriber data in the HLR has been changed by the PLMN operator. Among other things, traffic data management uses counters for recording the following: Number of registered mobile subscribers Number of mobile subscribers who leave the VLR service area Number of location area changes for mobile subscribers of the local PLMN Number of location area changes for mobile subscribers of other PLMNs. Maintenance functions As in the case of the HLR, there is a procedure for restoring the mobile-specific location registers in addition to the general system recovery concept in the VLR. On account of data inconsistencies in the VLR all mobile subscriber data sets are deleted and set up again on the basis of the mobile subscriber's activities in his home VLR service area and on the basis of the information coming from the HLR.
3.1.2
Functions of GCR Network Element (2G only)

The group call services (VGCS, VBS) are created in the Group Call Register (GCR): the dispatchers, the group area and additional group attributes are defined for each group call reference. This information is started in the GCR, which is collocated to an MSC.
A50016-D1112-V41-2-7618
DRAFT
59
Information System
The GCR is implemented as a software function and database. For the same group call reference, both VGCS and VBS can be defined with different properties.
Group IDs are subscriber numbers of dispatchers (mobile subscribers, PABX and/or fixed subscribers). Group areas are radio cells belonging to the group. Allowed radio cells for the group area radio cells where a downlink channel is set up and from where a call is allowed to set up. In the current software version the area can be extended to 9 MSC (anchor MSC). A group identification (group ID) is a binary number specifying a numerical classification. One or more service subscribers (mobile subscribers as well as fixed subscribers) can belong to such a group. The maximum number of group IDs which can be defined in one PLMN depends on the maximum number of group call areas defined in the PLMN. The group call area identification (group area ID) is a binary number uniquely assigned to a group call area in one network, where a group call area is defined as a list of cells. The length per group ID is flexible per group area ID. The length of the group call reference, which consists of both the group ID and the group area ID must be 8 digits. In the current software version, the area can be extended to 9 MSCs (anchor MSC).
3.1.3
Functions of the GMSC Network Element

The Gateway MSC (GMSC) network element is the gateway of the Core Network with the PSTN/ISDN for circuit-switched services. For mobile terminating services, the Home Location Register (HLR) is interrogated for information about how to route and process the call further.
i
3.1.4
In this software version, the GMSC for a 3G case corresponds to an ordinary 2G GMSC.
Functions of the HLR/AC

In 2G and 3G PLMN there are two instances for the mobility information in the HLR, one for circuit-switched and one for the packet-switched part. The HLR supplies the MSC/VLR network elements with the circuit-switched related subscriber information via the SS7:MAP D/E interface. The SGSN network element is supplied with packetswitched subscriber information via the SS7:MAP Gr interface. The organization of the subscriber data in the 3G case is very similar to the 2G case with minor enhancements.
The HLR/AC functionality in SIEMENS systems is implemented with the HLR/AC classic (HLRc) which is based on the EWSD (CP) platform and SSNC (MP) platform. The Home Location Register (HLR) and the Authentication Center (AC) are integrated into one physical entity on this platform. A new server platform is also provided. The product name of this new HLR/AC innovation is called HLRi. The SIEMENS HLR implements the 3GPP-specified HLR function for mobile networks. It is the database containing the subscriber data of all the mobile subscribers created in that HLR. This makes the HLR a central entity of the network and defines the high requirements concerning availability, reliability and data integrity. Depending on the operator's organization of the network, the PLMN can be planned for one or several HLRs. Therefore, the HLR provides scalability to allow adaptation to these needs.
3.1.4.1
60
DRAFT
Functions of the HLR Network Element
The HLR network element is the main database of the mobile subscribers.
A50016-D1112-V41-2-7618
Information System
The HLR network element is in charge of the management of mobile subscribers. The following kinds of information are stored there: Subscription information Some location information enabling the charging and routing of circuit-switched calls towards the MSC/VLR network elements where the MS is registered (e.g., the MS roaming number, the VLR ISDN number, the MSC ISDN number, the local MS identity) Location information enabling the charging and routing of packet-switched services in the SGSN/SLR network element where the MS is currently registered (e.g., the SGSN/SLR number). The HLR supports the current VLR or SGSN/SLR network elements of the mobile subscribers by providing the necessary data, and the VLR or SGSN/SLR network element in its turn makes their VLR / SGSN/SLR address available. As an example, the HLR supports the circuit-switched mobile-terminated calls (MTC) by sending routing information to the Gateway MSC (GMSC).
The HLR is also used for the packet-switched domain of CN (CNps) (see separate CNps documents.) Subscription information The circuit-switched/packet-switched services handling functions include addressing and identifying. Addressing and identifying are performed by means of the following identities: The international mobile subscriber identity (IMSI) The mobile subscriber ISDN number (MSISDN) Packet data protocol (PDP) address(es). Circuit-switched/packet-switched service setup Circuit-switched domain of CN (CNcs): The HLR takes part in the setting up of an MTC. When an MTC is set up, the HLR is requested by the Gateway MSC (GMSC) to retrieve the mobile subscriber roaming number (MSRN) of the mobile subscriber from the current VLR. The HLR does this and sends the MSRN to the GMSC. If call forwarding on mobile subscriber not reachable (CFNRc) is active and the VLR signals that the mobile subscriber is not attainable (absent subscriber), the HLR initiates call diversion directly in the GMSC. If the supplementary service call forwarding unconditional (CFU) is active, if the mobile subscriber is barred by the administration or if the authentication check was not successful, interrogation of the current VLR by the HLR does not take place. Instead, the HLR sends back the number to which the call was diverted or sends an error indication to the GMSC. Packet-switched domain of CN (CNps): The mobile-originated packet-switched service is called mobile initiated PDP context activation. With an established mobile-originated packet-switched service, a transfer in the uplink and downlink direction is possible. A packet data session is set up by a PDP context activation for which subscription is held in the HLR.
A50016-D1112-V41-2-7618
DRAFT
Location registration Circuit-switched domain of CN (CNcs):
61
Information System
The location registration function includes procedures for: Location update VLR update Location cancellation. The location update is initiated by an MS moving into another location area. The HLR is informed of the change by the VLR if the new location area identity (LAI) belongs to another VLR service area. In the case of a VLR update, the HLR sends the mobile subscriber authentication data to the new VLR. The new VLR transfers its VLR address to the HLR. In the case of location cancellation, the HLR causes the previous VLR to delete the mobile subscriber data. Packet-switched domain of CN (CNps): The routing area update procedure is initiated by the MS. It provides the SGSN network element and HLR with information about the current routing area of the mobile subscriber. Signaling message routing The transmission of signaling messages and the exchange of data take place between the HLR network element and the VLR network element GMSC or MSC network element SGSN/SLR network element.
Circuit-switched domain of CN (CNcs):

The HLR stores the VLR ISDN number for the routing of signaling messages to the VLR network element. The HLR uses the address of the requesting GMSC/MSC/VLR network element for the routing of signaling messages to the GMSC/MSC/VLR network element.
Packet-switched domain (CNps):

The HLR stores the SGSN ISDN number for the routing of SS7 signaling messages to the SGSN/SLR network element. The HLR uses the address of the requesting SGSN network element for the routing of signaling messages to the SGSN/SLR network element. Database Circuit-switched domain of CN (CNcs): The HLR database contains both semipermanent and transient data. The semipermanent data includes: HLR mobile subscriber data and signaling data (network technical data of the HLR). The transient data includes: HLR mobile subscriber data and trafc measurement data.
62
DRAFT
The semipermanent HLR mobile subscriber data is located in the following data modules and tables: Common data module Basic telecommunication services data module Supplementary services data module
A50016-D1112-V41-2-7618
Information System
MSISDN bearer capability data module Bearer capability information element (BCIE) table Roaming restriction table (U)SIM chip card exchange table (IMSI exchange) HLR services table for mobile subscribers with access authorization to specic service centers, e.g., with routing depending on the directory number of the called mobile subscriber.
The transient HLR mobile subscriber data is located in the following data modules: Mobility data module (e.g., MSRN, relationship to the VLR address and local subscriber identication (LMSI)) Short message waiting data module. Packet-switched domain of CN (CNps): The HLR holds the mobile subscriber profile, which is used for the packet-switched subscription check and activation procedure. The following packet-switched data is also stored: PDP identier (PDP ID), which identies the PDP context per mobile subscriber in HLR (and SGSN/SLR network element) Allowed packet data protocol (PDP type) Packet data protocol address (PDP address) or an indication that a dynamically assigned address can be used Subscribed quality of service (QoS) Access point name (APN) International mobile subscriber identity (IMSI) Mobile subscriber ISDN (MSISDN) number Each PDP subscription is seen as a basic telecommunication service.
3.1.4.2
Functions of the AC Network Element

The AC network element functions are used both by the circuit-switched and packetswitched part of the MSC/VLR or the SGSN/SLR. The AC network element administers security-related functions, such as Managing the secret individual subscriber authentication keys (Ki) of the mobile subscriber Generation of n triplets (RAND, SRES, Kc) for each 2G mobile subscriber Storing the PLMN operator-specic algorithms A3/A8 (also A2, A4, A7) in the security box for each 2G mobile subscriber Generating n quintets (RAND, XRES, CK, IK, AUTN) for each 3G mobile subscriber Storing the PLMN operator-specic algorithms f1 to f5 (also A2, A4, (A7)) in the security box for each 3G mobile subscriber. Circuit-switched/packet-switched service handling functions For each 2G mobile subscriber, the AC database contains a set of available triplets (RAND, SRES, Kc) which are calculated in security boxes. The AC has several of these security boxes which contain the keys and the cryptological algorithms. A security box generates RAND, SRES and Kc when the security parameters are entered.
A50016-D1112-V41-2-7618
DRAFT
For each 3G mobile subscriber, the AC database contains a set of available quintets (RAND, XRES, CK, IK, AUTN) which are calculated in security boxes. The AC has several of these security boxes which contain the keys and the cryptological algorithms. A
63
Information System
security box generates RAND, XRES, CK, IK, AUTN when the security parameters are entered. On request from the HLR, the AC supports the required number of triplets/quintets and removes them from the AC database. New triplets/quintets are then calculated, to bring the set of triplets/quintets up to strength again. Database The AC database is subdivided into a semipermanent and a transient part. The semipermanent part has images on duplicated disks which are updated and kept consistent. The semipermanent part of the 2G database consists of the components: AC mobile subscriber database contains the individual subscriber authentication key (Ki) in A2-encrypted form, the version number of the algorithms A3/A8 and the A2 code for calling up the A2 algorithm. Triplet table contains a triplet set for each 2G mobile subscriber. Key database contains key organization data (for K2, K4, K7) and encrypted and designated keys for data security purposes. The transient part of the 2G database consists of the components: Triplet database contains 5 sets of triplets (RAND, SRES, Kc) for each IMSI at all times. Triplet status table contains an indication for each 2G mobile subscriber as to whether valid triplets are present. Key reference table for storing K4 keys for the duration of a communication. The semipermanent part of the 3G database consists of the components: AC mobile subscriber database contains the individual subscriber authentication key (Ki) in A2 encrypted form, the version number of the algorithms A3/A8 (for 2G mobile subscriber) and algorithms f1 to f5 (for 3G mobile subscriber) and the A2 code for calling up the A2 algorithm. Triple table contains a triplet set for each 2G mobile subscriber. Quintet table contains a quintet set for each 3G mobile subscriber. Key database contains key organization data (for K2, K4, (K7)) and encrypted and designated keys for data security purposes. The transient part of the 3G database consists of the components: Quintet database contains 5 sets of quintets (RAND, XRES, CK, IK, AUTN) for each IMSI at all times. Quintet status table contains an indication for each mobile subscriber as to whether valid quintets are present. Key reference table for storing K4 keys for the duration of a communication.
64
DRAFT
A50016-D1112-V41-2-7618
Information System
3.1.5
Functions of the EIR Network Element

The EIR functions check whether a mobile equipment identity (IMEI) is known to the IMEI database and whether it is authorized (white list) to be supervised (gray list) to be barred (black list) or whether it is unknown to the IMEI database. Call-handling functions The IMEI check is requested by the MSC. The call-handling functions search in the IMEI database and acknowledge with a message. The further measures taken by the MSC depend on this reply. Database The EIR (IMEI) database contains semipermanent data. The database has images on duplicated disks which are updated continuously and kept consistent. The white list contains the type approval code (TAC) and the final assembly code (FAC) which are both known as the number series with a serial number range. The gray list and the black list are implemented in an expandable part of the database which is accessed by means of the 15-digit IMEI number. The IMEI is deemed unknown if it is not contained in any list. Administration software The mobile-specific part of the administration software has two functions: Parameter management Trafc data management (e.g., trafc measurement) The parameter management function is used by the operator for managing the white, gray and black lists of the EIR database with the MML commands create, change, delete and print out. The traffic data management function provides information on the performance of the EIR. The numbers of successful and unsuccessful EIR operations by the call-handling functions are displayed. The MSs listed in the gray or black list can be recorded and passed on to the SC. Maintenance functions In the event of a reload recovery, the EIR database is reloaded from the disk.
3.2
CSC Functions
The Combined Switching Center (CSC) integrates the functions of PLMN network elements (MSC, VLR etc.) and of Local Exchange of a xed network (LE, such as EWSD) In a CSC network element, the following kinds of subscribers (Tab. 3.1) can be managed or connected: Fixed network subscriber Wired ISDN subscriber, ISDN either as basic access or private automatic branch exchange (PABX) Mobile subscriber following the 3GPP standard
A50016-D1112-V41-2-7618
DRAFT
65
Information System
Mobile subscriber (classic mobile subscriber) WLL subscriber (radio-in-the-loop mobile subscriber, which is supplied by the radio interface) Kind of subscriber Subscriber interface Standard of interface Classes of telecommunication services Allocation of directory number
Mobile subscriber WLL subscriber ISDN subscriber Radio interface 3GPP wired ITU-T Mobile network services Fixed network services
MSISDN with national destination code (NDC) Directory number of a fixed network, local area code (LAC) or MSISDN with national destination code (NDC)
Tab. 3.1
Overview of all kinds of subscribers at the CSC (with classifying features)
Wired ISDN subscribers The CN allows wired ISDN subscribers to be connected to a Combined Switching Center (CSC) (Fig. 3.1).
CSC: HLR/AC RAN CSC: LE-MSC/VLR MSC/VLR
wired ISDN subscribers (with/without PABX)
EIR
Fig. 3.1
CSC with wired ISDN subscribers within a PLMN environment
ISDN subscribers: The two access options for ISDN subscribers are as follows: Basic access (BA) for ISDN main stations and small PABX Primary rate access (PA) for medium and large ISDN PABXs. Tab. 3.2 and Tab. 3.3 below list all the available telecommunications services which are assigned by the CSC concerned.
66
DRAFT
A50016-D1112-V41-2-7618
Information System
ISDN bearer services, teleservices
BA
BA/P A
PA
ISDN bearer services
Circuit mode speech Circuit mode 64 kbit/s unrestricted digital Circuit mode 3.1 kHz audio Packet mode, switched B channel access, case B Packet mode, B channel access, case A
ISDN teleservices
x x x x x
x x x x x
x x x x x
Telephony 3.1 kHz Telephony 7 kHz Videotelephony Telefax, group 3 Telefax, group 4 Videotex *) Teletex *) *) are possible for mobile subscribers with GSM bearer services BS2.x Tab. 3.2
x x x x x x x
x x x x x x x
x x x x x x x
Basic telecommunications services for the wired ISDN subscriber at the CSC
ISDN supplementary services and ISDN features
BA
BA/P A
PA
ISDN supplementary services
CLIP/CLIR COLP/COLR Call forwarding unconditional (CFU) Call forwarding busy (CFB) Call forwarding on no reply (CFNR) Call waiting (CW) Call hold (HOLD) Closed user group (CUG) Terminal portability (TP)
x x x x x x x x x
x x x x x
x x x x x
A50016-D1112-V41-2-7618
DRAFT
Multiple subscriber number (MSN) x Tab. 3.3
Telecommunications services for the wired ISDN subscriber at the CSC
67
Information System
ISDN supplementary services and ISDN features
BA
BA/P A x x x x x x
PA
Subaddressing (SUB) Direct dialing in (DDI) User-to-user signaling 1 (UUS1)

ISDN features
Call completion to busy subscribers (CCBS) Three-party service Call barring Catastrophe handling Emergency call Local Dialing Do not disturb PBX number economy Several virtual PABX groups per PABX on the ISDN primary rate access (PA) Partial rerouting Overflow between DDI PABX Remote subscriber control input (RSCI), for control of CF and outgoing traffic restriction Tab. 3.3
x x x x x x x
x x x x x x
x x x x x x x x
x x x
x x
Telecommunications services for the wired ISDN subscriber at the CSC
Several virtual PABX groups per PABX on the ISDN primary rate access (PA) This function (see also Tab. 3.3) is for dening independent PABX groups to logically organize an ISDN primary rate access (with 30 B channels and 1 D channel per PA) (Fig. 3.2). Each PABX group has its own service prole, irrespective of other groups. This is done by marking the D channel corresponding to the PA with MML command as a multiple pilot number. Individual collection charge and services irrespective of each other are possible for each PABX group. Several customers (e.g., small businesses in one building) can be served with one physical PA.
68
DRAFT
A50016-D1112-V41-2-7618
Information System
089-722
PABX1
089-231
PABX2
CSC ISDN-PA
089-555
PABX3
Fig. 3.2
Several virtual PABX groups in a PABX with ISDN-PA
WLL subscribers WLL subscribers that are supplied by the radio interface are largely administered as normal mobile subscribers, that is, those not restricted in their freedom of movement. WLL subscribers are mobile subscribers that are only distinguished from normal mobile subscribers by a few typical services. One such typical service feature is restriction of roaming to a defined location area. Another is the subscriber directory number which can correspond to a directory number from the directory number volume for fixed network subscribers. The telecommunications services of a mobile subscriber apply just as much to WLL subscribers (see System Description, registerNetwork System Concept, section Basic Telecommunication Services and Section Supplementary Services).
i 3.3
WLL subscribers could also be normal hand-held units with roaming restrictions.
Functions of the IN/CAMEL Subsystem

The basic network components of the IN/CAMEL are described in the System Description, register Network System Concept, section 1, IN/CAMEL functions in a PLMN.
3.3.1
Functions of the IN/CAMEL Subsystem in the Core Network (CNcs)

SSP The Service Switching Point (SSP) forms the gateway from the basic mobile communication network to the Intelligent Network (IN)/customized application for mobile network enhanced logic (CAMEL) network (that is, SCP/CSE). The SSP detects whether a service is to be processed by the SCP/CSE and requests the service-specific information from SCP/CSE for the given circumstances. SCP/CSE
A50016-D1112-V41-2-7618
DRAFT
The Service Control Point (SCP)/CAMEL Service Environment (CSE) forms the IN/CAMEL node which controls the various services centrally. The SCP/CSE database is supplied with input by the service subscribers or by the administration via the service management point (SMP). The individual service subscriber, therefore, has the option
69
Information System
of controlling an IN/CAMEL service in accordance with specific criteria. For example, he can limit the traffic or divert it to different destinations at different times. Specialized Resource Function (SRF) An Specialized Resource Function (SRF) provides resources (e.g., IN/CAMEL announcements). One SRF solution is currently available in CNcs. Internal SRF A internal SRF in an M-SSP network node that can provide, among other things, tones, standard announcements or user-dened IN/CAMEL announcements. The internal SRF has the additional function of speech recognition for user interaction dialog. This function can recognize speech in different languages (e.g., German, English, French) and contains as a basic vocabulary 0, 1, 2, ... 9, YES, NO, HELP, CANCEL, STOP (the vocabulary can be increased up to 100 words). Furthermore, dual tone multi frequency (DTMF) inputs are identied by internal SRF.
3.3.1.1
SSP+MSC/VLR in the CNcs

Access to the IN/CAMEL service, for service users is implemented in an MSC/VLR with IN/CAMEL functions independently of the network environment. The integrated IN/CAMEL network architecture (Fig. 3.3) is the solution for this type of implementation. The SSP function is integrated into each MSC/VLR network element of a CNcs. Within the CNcs this type of network node, which then combines an SSP with an MSC/VLR network elements, is known as an M-SSP. In this way, the SCP/CSE node is also part of the CNcs.
SMP
PLMN
SCP/CSE MAP v3 CAP/ MAP HLR M-SSP M-SSP MAP v3 Signaling link
Fig. 3.3
Access to the IN/CAMEL function for mobile subscribers in the CNcs with an integrated IN/CAMEL network architecture
3.3.1.2
CAMEL Phase Negotiation

During location update the visited entity (SGSN or VLR) and the HLR have to negotiate the CAMEL phase required for the support of the provisioned CAMEL service. This CAMEL phase determines the protocol version used subsequently between the M-SSP and the CSE. This negotiation is implemented in 2 steps: In the rst step the VLR indicates its CAMEL capability.
70
DRAFT
A50016-D1112-V41-2-7618
Information System
In the second step the HLR determines the applied CAMEL phase from the service requirements (stored in CSI), the VLR capabilities (as received) and possible restrictions in the roaming subscriber table (see also section 4.13.25). The HLR then informs the VLR of the determined CAMEL phase.
The negotiated CAMEL capability determines the CAP protocol version (CAP phase 1, phase 2, phase 3 or phase 4) used during the CAMEL dialog between M-SSP and CSE. An alternative is using the trigger profile in order to determine the INAP protocol version.
3.3.1.3
Support of Prepaid Service for Circuit-Switched Services

The CN allows management of mobile subscribers with prepayment (prepaid service (PPS) subscriber) in the form of an IN/CAMEL solution.
Prepaid for circuit-switched services is supported based on CAMEL phase1/phase2. The basic demand of having mobile subscribers with prepayment is to access new target groups, to inhibit fraud and to minimize the administrative operating costs by direct booking of call charges from a prepaid mobile subscriber account. Charge booking for mobile subscribers with prepayment is processed by the prepaid service center (PPSC) in the SCP/CSE.
Call sequences:
In the SCP/CSE, a specific amount of money is normally stored for the prepaid service mobile subscriber from which charges are deducted for all chargeable calls made by this subscriber, e.g., MOC - who meets an activated supplementary service call forwarding (CFU, CFNRc). Several connections can be dealt with by dividing up the charge account. The SCP/CSE is initially interrogated for each call setup by this IN/CAMEL service. If the account balance of the prepaid service mobile subscriber is sufficient, then the desired call can be set up. While a call is active, the SCP/CSE makes regular checks on the account balance and disconnects the call if necessary (after warning the prepaid service mobile subscriber beforehand), when the account balance reaches a given threshold during the call (e.g., zero). The prepaid service mobile subscriber can enter a control procedure (DTMF) at the mobile station to request his remaining SCP/CSE charge account. The necessary AOCI charge data only can be transmitted to the prepaid service mobile subscriber in the case of an MOC.
The SCP/CSE interfaces required for prepaid service and the SCP/CSE functions themselves are not part of this System Description, CN GSM/UMTScs (in the case of SIEMENS IN/CAMEL network components, refer to the IN system description). Generally, the mobile subscriber is not sent a bill. The generation of MCR data records for MOC in the MSC/VLR network element (M-SSP) can be suppressed for the prepaid service mobile subscriber by selecting an appropriate category. Charge data records (MCR data records) for MTC, call forwarding and subscriber inputs are usually generated in the MSC/VLR network element (or M-SSP) (section 4.6.1, Charging Collection Function (Generation of Call Data Recordings)).
A50016-D1112-V41-2-7618
DRAFT
71
Information System
3.3.2
Categories of IN/CAMEL Services

In the M-SSP subscriber-specific services are supported (see Tab. 3.4). Category of IN/CAMEL service Subscriber-specific CAMEL services (for mobile subscribers) Applicability to the kind of subscriber Initiation of IN/CAMEL services Implicitly (with CAMEL subscription information (CSI), assigned in the HLR and transferred to the MSSP)
Mobile subscribers for which the authorization of the relevant CAMEL service is entered
CAMEL services for MOC: supported by the MSC/VLR network element serving the calling mobile subscriber CAMEL services for MTC: supported by the GMSC which performs the interrogation
Tab. 3.4
Categories of IN/CAMEL services in the M-SSP
Subscriber-specific CAMEL services for mobile subscribers must be defined in the HLR and assigned to the mobile subscribers in correlation with the CAMEL subscription information (CSI). Subscriber-specific CAMEL services for mobile subscribers are initiated implicitly without a specific directory number. CAMEL service marks (known as CAMEL subscription information (CSI); see System Description, register Network System Concept, section codes of IN/CAMEL services in a PLMN) are set in the mobile subscriber database in the HLR to describe authorization to such CAMEL services. These CSIs are transferred to the network elements where the service is maintained finally (that is, MSC/VLR in the circuit-switched domain (and SGSN/SLR in the packetswitched domain, too)). But some CSIs only exist in the HLR.
SCP/CSE supported possible applications of subscriber-specific IN/CAMEL services for mobile subscriber are: - Pre-paid service subscriber (mobile subscriber with prepayment and individual charging). - Virtual private network (VPN) service subscriber (mobile subscriber with membership to a private network)
3.3.3
IN/CAMEL Entry (Triggering)

Access from the IN/CAMEL network is via a trigger function as part of subscriber data evaluation and/or digit translation. The mechanism used by the SSP to recognize an IN/CAMEL service is referred to as IN/CAMEL triggering. Trigger detection points (TDPs) form a set of all possible entry points for IN/CAMEL service invocations during a call. For different call types (basic call state models (BCSMs)), different TDP sets are defined. A trigger procedure is called at every caught TDP so that presence and content of suitable users or network-related CSIs are evaluated. If an IN/CAMEL dialog has to be started, triggering is also used to determine the corresponding trigger profile. Triggering is always performed in the MSC. The trigger profiles are only available in the MSC. An alternative trigger procedure uses subscriber dependent digit processing and feature control (SDDPFC). In this case, additional preconditions can be evaluated in order to as-
72
DRAFT
A50016-D1112-V41-2-7618
Information System
sign a trigger profile (see section 4.7, Enhanced Functions of Call Handling, Charging and User Information - for Traffic over TDM CN). Conditional triggering Additional triggering criteria can be defined for CAMEL services. A CAMEL service is only triggered if all specified criteria are fulfilled. The conditional triggering criteria are standardized within CAMEL Phase 2. The following criteria are available: For O-CSI: Basic service: the CAMEL service is only triggered if the basic service applicable for the call matches one of the entered basic service codes. Call type: this criterion determines whether the CAMEL service is only triggered for forwarded calls or only for non-forwarded calls. Calls can be forwarded in two ways: by use of the supplementary service call forwarding or by use of a CAMEL service (CSE delivers new number). Destination number: several destination numbers can be entered in international or unknown format. They are compared to the dialed number. The dialed number matches a destination number if the format of the numbers is the same and all digits of the destination number match the leading digits of the dialed number. For T-CSI: Basic service: the CAMEL service is only triggered if the basic service applicable for the call matches one of the entered basic service codes. A possible application of conditional triggering is the translation of short codes dialed by mobile subscribers roaming in a foreign PLMN: the destination number and destination number length are used to trigger a CAMEL dialog when a short code is dialed.
Already in 2G (GSM/GPRS), the CAMEL functions have been introduced in more phases. Some CAMEL phase 1, phase 2 and phase 3 features were introduced in the 3GPP standard. In the current software version CAMEL phase 4 is also introduced for circuitswitched services.
3.3.4
CAMEL Phase 1
With CAMEL phase 1, the first step towards a standardized IN environment in GSM was supported. In addition to CAMEL, the SCP/CSE-supported rerouting feature (which is not standardized in an 3GPP recommendation) is provided as a proprietary enhancement to allow use of advanced IN functions for roaming mobile subscribers that cannot be provided using CAMEL phase 1 by itself. Another add-on to CAMEL is the CAMEL roaming subscriber table which allows a network operator to control the use of CAMEL resources by a network operator. The PLMN operator can control to which PLMNs individual CAMEL subscribers can roam with their CAMEL services and from which other PLMNs, CAMEL subscribers can use the CAMEL resources of the PLMN operator. The CAMEL phase 1 feature package consists of: Basic set of detection points
A50016-D1112-V41-2-7618
DRAFT
Basic set of detection points to trigger a CAMEL service from the basic call state model (BCSM) for originating IN services (mobile originating call (MOC), call forwarding (CF) and proprietary SMS mobile originated (SMS-MO)) and terminating IN services (mobile terminating call (MTC)).
73
Information System
Supporting CAMEL application part (CAP) on the SSP-SCP/CSE interface The CAP provides a CAMEL specific national variant, the Intelligent Network application part (INAP). Any time interrogation (ATI) Any time interrogation (ATI) (with help of MAP v3 interface between SCP/CSE and HLR). With the any time interrogation procedure, information about a mobile subscriber, such as reachability status and location information can be accessed from the HLR on the SCP/CSE independent from a call at any time. With this feature, the PLMN operator can implement IN/CAMEL services which take the location of a subscriber into account, e.g., location-based service implemented as an IN/CAMEL service. HLR 2-step interrogation mechanism Using an HLR 2-step interrogation mechanism, CAMEL service handling can be performed before a mobile station roaming number (MSRN) is provided. With this mechanism a more consistent approach for the implementation of MTC services can be provided by preventing unnecessary MSRN allocations. Supporting CAMEL subscription information (CSI) Using the CSI, a CAMEL mobile subscriber can be identified as having subscribed to a CAMEL service. There are two basic CSIs. Originating CSI (O-CSI) for mobile originating calls (MOC) and call forwarding (CF) and terminating CSI (T-CSI) for mobile terminating calls (MTC). Suppression of announcements Suppression of announcements allows suppression of standard GSM announcements given in the backward direction from a foreign visited MSC (VMSC). With this, the PLMN operator can implement IN services or CAMEL services that takes the native language of the mobile subscriber into account. The CSE can suppress foreign non-reachable announcements and provide its own instead, or establish a call to another mobile subscriber. Roaming subscriber table (proprietary) The roaming subscriber table (for O-CSI and T-CSI) is located in the entities HLR and VLR or GMSC. In the HLR it is defined whether or not a O-CSI transmission towards a certain VLR or an O-CSI/T-CSI from a GMSC is allowed. Similarly, the table in the VLR controls the acceptance of a O-CSI from a certain HLR. Additionally, the supported CAMEL phase towards the partner entity is stated in the table (see also section 4.13.25). CSE supported rerouting (proprietary) If a CAMEL dialog is established because of an IN/CAMEL-marked subscriber (via CSI) and the SCP/CSE recognizes that the service cannot be supported by the M-SSP, rerouting to another SCP/CSE, which can support the requested service, takes place. This provides a mechanism to support non-CAP supported services to subscribers roaming outside the home PLMN. The SCP/CSE routes the call to an M-SSP in the home PLMN, which can support advanced CAMEL functions.
74
DRAFT
A50016-D1112-V41-2-7618
Information System
3.3.4.1
Charging Enhancements
In order to support fully the CAMEL standard phase 1, it is necessary to provide a unique call reference number (CRN). Therefore, the CRN is introduced to give the PLMN operator the possibility of correlating the call charge records of the CAMEL subscriber generated in the PLMN using IN dialog, irrespectively of the network element where they are created (e.g., charge records at GMSC, visited MSC/VLR and SCP/CSE). For MOC, the CRN is calculated in the visited MSC/VLR where the call originates from. For MTC, the CRN is calculated in the GMSC where the interrogation is performed. The combination of the MSC ID (E.164 number) and the CRN forms a call reference which is unequivocal PLMN-wide. Both items of data are conveyed to the SCP/CSE.
3.3.5
CAMEL Phase 2
CAMEL phase 2 provides a fully-featured standardized IN environment in a PLMN. Most of the commonly known IN capability set 1 (CS 1) functions are supported with CAMEL phase 2. Using CAMEL phase 2, more sophisticated IN/CAMEL services can be implemented based on pure CAMEL functionality without the need to reroute the calls back to the home PLMN.
3.3.5.1
Functional Network Architecture of CAMEL Phase 2

CAMEL phase 2 involves the following enhanced and new network interfaces (Fig. 3.4): Enhanced network interfaces New operations are introduced to the CAP at the SSP-SCP/CSE interface. The subscriber prole on the MAP on the HLR-VLR interface is enhanced. New network interfaces An interface between a Specialized Resource Function (SRF) and the SCP/CSE with CAP has been introduced. This is needed to control announcements to be played and to send the collected information to the SCP/CSE. A MAP interface between the MSC/VLR network element and the SCP/CSE is introduced for supplementary service notication.
A50016-D1112-V41-2-7618
DRAFT
75
Information System
*) MAP v3 Gateway M-SSP *) CAP/ MAP HLR *) SCP/CSE Fixed network CAP SRF/IP *) M-SSP CAP
LE
Home PLMN (HPLMN)
Visited PLMN (VPLMN)
Fig. 3.4
Functional network architecture of CAMEL phase 2
3.3.5.2
CAMEL Phase 2 Feature Package

The CAMEL phase 2 feature package consists of: Extension of the basic set of detection points (DP) for triggering CAMEL services from the basic call state model The enhancement of these detection points is another step in the evolution towards CAP/INAP CS-1 detection point set. They enable a more evolved call control and reporting mechanism, e.g., the SCP/CSE is able to include final data into the charging ticket after releasing the call. They make more complex services possible through enhanced SCP/CSE - SSP information flows. Conditional triggering With conditional triggering additional triggering criteria can be defined for CAMEL services. A CAMEL service is only triggered if all specified criteria are fulfilled. The conditional triggering criteria are standardized within CAMEL phase 2. Handling conditional trigger criterion at the HLR (e.g., destination number length, destination number leading digits, basic service and call type) for optimizing the interrogation of the SCP/CSE. Conditional trigger criteria as defined by ETSI/3GPP standard can be used by the HPLMN operator. With step 1 of CAMEL phase 2, one conditional trigger criterion could be administered. Now it is possible to offer CAMEL subscribers a variety of conditional trigger criteria. It also allows, for example, comfortable short code dialing with wellknown short codes from the HPLMN outside the HPLMN.
76
DRAFT
The SCP/CSE is not contacted in case the IN/CAMEL service is designed for speech only and it is a fax or a data call. Examples: Some services e.g., home zone indication are applicable for mobile-originating calls only. Therefore, triggering in the case of mo-
A50016-D1112-V41-2-7618
Information System
bile-forwarded calls is useless. In addition, convenient short-code dialing with wellknown short codes from the HPLMN can be provided outside the HPLMN too. Supporting of further CAMEL subscription information (CSI) variants Due to the above described additional CAMEL phase 2 features new variants of CAMEL subscription information (CSI) are introduced, e.g., supplementary service CSI (SSCSI), translation indicator flag CSI (TIF-CSI) and USSD-CSI (see System Description register Network System Concept). Inband information (DTMF), tones or announcements The SCP/CSE is enabled to order the playing of inband information (DTMF), tones or announcements when requested by certain detection points. As an instruction at the call setup request procedure, unsuccessful call establishment procedure, call disconnection procedure and incoming call request procedure, it is possible for the SCP/CSE to order the playing of announcements or tones, voice prompting and information collection towards the calling mobile subscriber. The HPLMN operator is responsible for the administration of announcements. In the case of bilateral agreements the VPLMN operator can also administer announcements. Enhanced charging facilities Enhanced charging facilities are implemented, such as online charging (with AoC functionality), inclusion of information into the charging record and the support of additional charging information to the SCP/CSE. Five different charging application scenarios are envisaged: Online charging The SCP/CSE can control the duration of a call to limit the call charge. When a call is successfully established, the SCP/CSE instructs the underlying network to allow the call for a given time and to contact the SCP/CSE for further instructions or to release the call immediately after the given time. CSE-controlled charge advice information (CAI), so called e-values The CSE is able to send e-values to the PLMN for a certain mobile subscriber. The e-values can be sent several times during an ongoing call and is sent to the mobile subscriber when the GSM AoC supplementary service is subscribed to him. The information ow provided by the CSE can either contain one or two sets of e-values and a timer value when the CAI applies. Including information into the charging record The CSE is able at one or several active service events to download free-format charging information to be transparently output to the call record available at the interrogating PLMN (IPLMN)/visited PLMN (VPLMN) depending on the call scenario. Supporting additional charging information to the SCP/CSE It is possible for the SCP/CSE to request from the VPLMN/IPLMN a call information report to be delivered at the end of the call. The report contains call duration and release cause. Enhanced charging concept The complexity of CAMEL services requires an enhanced charging concept, which also has to cover roaming aspects. In addition, the handling of charging records is simplied for the PLMN operator, e.g., by introducing a call-related sequence number for correlating the charging tickets.
A50016-D1112-V41-2-7618
DRAFT
77
Information System
Handling free-format forwarded-to-numbers (FTN) (not necessarily in international format) at the HLR, e.g., for implementing CAMEL-based global virtual private networks (VPN) across network borders. Forwarded-to-numbers can be handled at the HLR irrespective of the format and is signaled transparently to the SCP/CSE, e.g., call forwarding based on short numbers within the VPN is now possible. This allows a global VPN based on CAMEL to be offered. Support of alerting pattern for mobile-terminating call handling Support of alerting pattern for mobile-terminating call handling gives an indication to the subscriber about a certain level (e.g., reflecting a kind of urgency) or a certain category (e.g., forwarded call or VPN call) of an incoming call. Now, it is possible to indicate to the mobile subscriber whether an incoming call is directed to the private or the business number, for example, or to differentiate on the basis of the calling party subscriber. This feature allows creation of an alternate line service for the combination of business and private number with different ringing. CF-notification to the SCP/CSE When a conditional call forwarding (e.g., CFNRc) occurs in the GMSC, it is necessary to inform the terminating service logic in the SCP/CSE for correct charging of prepaid services. Otherwise the terminating service logic is started independently from the originating service logic. Support of the GMSC address in the initial_DP message Support of the GMSC address in the initial_DP message so that the SCP/CSE is informed about both the GMSC number and the VMSC number in the case of conditional call forwarding. Enhanced suppression of announcements (SOA) CAMEL phase 2 suppression of announcements (SoA) is also applicable if the destination number is changed by the SCP/CSE. CAMEL phase 1 allows suppression of announcements only if the destination number is not changed. CAMEL phase 2 SIEMENS proprietary add-ons In order to complete the functionality, which is standardized by CAMEL and to give the operator a competitive advantage, SIEMENS provides some proprietary add-ons: Handling conditional trigger criteria Handling conditional trigger criteria differently for the HPLMN and the VPLMN (refers to conditional trigger above). Different handling of conditional triggering for the HPLMN and the VPLMN for optimization in IN/CAMEL signaling trafc. The conditional trigger criteria are available outside the HPLMN. Within the HPLMN, it is not necessary for the SSP to evaluate the conditional trigger criteria as the short codes are known at the HPLMN. This allows PLMN treatment of short codes. It is also possible to send the conditional trigger criteria only when roaming inside the HPLMN. VLR number - control of sending the VLR number to the GMSC Until now the VLR number was only sent to the GMSC if the location information was requested in the IN/CAMEL service table (T-CSI). For most of the IN/CAMEL services, the SCP/SCE does not need the whole location information, that is, the VLR number is sufcient. This means, it is not necessary for the HLR to send the corresponding message to the VLR, as the VLR number is already available in the HLR.
78
DRAFT
A50016-D1112-V41-2-7618
Information System
The sending of the VLR number can be controlled service-specically. The VLR number is sent to the GMSC although the request of the location information is not required. In this way, the call setup time is reduced. Comfortable CSI handling The existing corresponding Q.3/MML command is enhanced by a new parameter, which allows easy assignment of new or modied services based on existing services. The VLRs are automatically informed, that is, in the case of assignment of a new or modied originating service, the corresponding O-CSI is immediately sent to the VLR.
Cross-phase issues (relating to the CAMEL phase 2 feature package): At the registration of a mobile subscriber in a VPLMN, the VPLMN indicates in the registration requests to the HPLMN, the CAMEL phase which the VPLMN supports. When a CAMEL phase 2 mobile subscriber roams to a network supporting phase 1 only, the HPLMN takes appropriate actions, e.g., depending on the subscribers CAMEL service prole the registration request can be denied, or only phase 1 can send information to HPLMN. Call setup from a VPLMN which supports only CAMEL phase 1 If the served mobile subscriber requests an MOC which requires the VPLMN to contact the SCP/CSE, the VPLMN indicates to the SCP/CSE which phase of CAMEL the VPLMN supports. If the VPLMN supports only CAMEL phase 1 and the SCP/CSE determines that, as a consequence, a service which is provided for the mobile subscriber not operates correctly, the SCP/CSE takes such action as can be decided by the SCP/CSE operator. Call setup from an IPLMN which supports only CAMEL phase 1 When the IPLMN contacts the SCP/CSE for instructions to handle an MTC, the IPLMN indicates to the SCP/CSE which CAMEL phase the IPLMN supports. If the IPLMN supports only CAMEL phase 1 and the SCP/CSE determines that, as a consequence, a service which is provided for the mobile subscriber not operates correctly, the CSE takes such action as can be decided by the SCP/CSE operator.
3.3.6
CAMEL Phase 3
CAMEL phase 3 enhances the capabilities of CAMEL phase 2. The circuit-switched part of CAMEL phase 3, which is described in this section, allows extension of existing IN services e.g., prepaid service (PPS) also for short message service (SMS) and also to create new IN services e.g., based on notifications of non-traffic events to the SCP/CSE. Packet-switched capabilities of CAMEL phase 3 are also implemented in the current software version of CN. This is the control of packet-switched sessions and PDP contexts and SMS MO over packet-switched domain and packet-switched location services based on service area ID. These functions are described in separate CNps documents.
3.3.6.1
CAMEL Phase 3 Feature Package

The CAMEL phase 3 basic feature package consists of:
A50016-D1112-V41-2-7618
DRAFT
79
Information System
Short message service (SMS) mobile originated interworking An SMS (mobile originated) setup request is notified to the SCP/CSE. This allows the SCP/CSE to: Perform SMS online charging for prepaid subscriber also outside HPLMN As SMS is one of the mostly used features, this represents an important extension of the mass service prepaid. It allows online charging of SMS for the prepaid subscriber. Additionally, the SCP/CSE is able to consider unsuccessful delivery of the SMS to the SMS center (SMSC), which provides the possibility for accurate billing of SMS: Charging for successful SMS, only. Unsuccessful SMS remain uncharged. Due to CAMEL this feature is available also outside the HPLMN. Modify parameter of the short message Due to the high acceptance of SMS by all subscriber it is of high importance for the variety of dedicated services as virtual private network (VPN) or one number service, too. Now it is possible to offer SMS as substantial part of these services, as modication of called or calling party now is possible. The short cut, which is used for dialing in the VPN, can be changed into a long number and the long calling number can be changed into the short cut for display at the called mobile station. Additionally to the modication of the called or calling party it is possible to modify the SMSC address. This allows the PLMN operator to direct the submitted SMS to dedicated SMSC, to distribute the SMS load onto different SMSC or to implement a least-cost-routing mechanism easily. As the mobile subscriber usually does not modify the original assigned SMSC address, this feature is of high importance for load distribution within the SMSC network. Notifications of non-traffic events to the SCP/CSE For introduction of a new class of services notifications of non-traffic events to the SCP/CSE are provided. Mobility management notication Notications to the SCP/CSE are introduced for attach, detach and location update of the mobile station. This feature allows submission of information to the mobile subscriber after switching on the MS about the latest news, e.g., special rates for city calls at the weekend starting with next month or 10% off for all calls at sundays. Additionally, information can be submitted according to the current location, e.g., you are entering the city of Berlin, special tariffs apply. The information can be submitted by SMS, unstructured supplementary services data (USSD) or a speech call. This gives the operator the possibility to distribute information in case of switching on the mobile or location dependent in case of changing the location area. Notication to SCP/CSE of change of subscriber data Notication can be sent to the SCP/CSE which want to be informed when one of the following subscriber data are changed: call forwarding (CF) supplementary service (SS) data, call barring (CB) SS data, operator determined barring (ODB) data and CAMEL subscription information (CSI). For IN/CAMEL services it is important to be informed about the current subscriber conguration at the HLR in order to react in the appropriate way, e.g., if there is call forwarding assigned. Therefore, notications to SCP/CSE of change of subscriber data are introduced. For example a subscriber might have a service that is to only be applicable if the call forwarding state is not active. The sending of a notication to the SCP/CSE can be triggered by the following processes: subscriber data change by administrative procedure, subscriber data
80
DRAFT
A50016-D1112-V41-2-7618
Information System
change by mobile subscriber, subscriber data change by any time modication (ATM) request from another SCP/CSE. This notication can be assigned on a subscriber basis. Supplementary service invocation notication to SCP/CSE With CAMEL phase 3 it is possible that a notication is to be also sent to the SCP/CSE when the supplementary services call completion to busy subscriber (CCBS) has been invoked by the subscriber. This allows e.g., charging of CCBS usage for prepaid subscriber.
SCP/CSE control of subscription data (any time subscription interrogation and modification) Any time subscription interrogation (ATSI) For some IN services it is sufcient for the SCP/CSE to retrieve the current subscriber information stored in the HLR on request and not automatically after change of the subscriber data. Therefore, the ability of the SCP/CSE is enhanced with the ATSI for retrieval of call forwarding (CF) SS data, call barring (CB) SS data, operator determined barring (ODB) data, CAMEL subscription information (CSI) data and CAMEL phases supported by the VPLMN/VLR. As protection from misuse or overload situation the HLR is able to reject this request. The SIEMENS roaming subscriber table (section 4.13.25) in the HLR is enhanced in order to dene the access rights on SCP/CSE base. Any time modication (ATM) The functionality any time modication (ATM) is introduced, which allow the SCP/CSE to modify user data for a particular subscriber at the HLR. The following data can be modied, call forwarding (CF), call barring (CB), state of CAMEL subscription information (CSI) data active/non-active and notication ag of CSI. Below, two scenarios are described: Today, subscriber usually change their CF or CB data at the HLR by means of subscriber controlled input (SCI). In case of complex adjustments due to one number services an internet access is proposed. Such an interface is possible at the SCP/CSE, which could provide direct access to the IN/CAMEL service database. After setting his CF or CB data via internet the SCP/CSE database has to be aligned with the HLR database. This functionality allows the SCP/CSE as master of the IN/CAMEL service to adapt the subscriber data at the HLR. A second scenario is the combination of the ATM with the information of a location update by means of mobility trigger. Depending on the visited PLMN the SCP/CSE is able to activate trigger proles (originating CSI (O-CSI) or visited MSC terminating CSI (VT-CSI)) or not. This explicitly assigns the subscriber a set of features dependent on the PLMN, e.g., the subscriber is allowed to setup calls or not. Subscribed dialed services - network dialed services In CAMEL two types of dialed services are distinguished: Subscribed dialed services Services with IN numbers, which are located at the home PLMN (HPLMN). The corresponding numbers are assigned to the subscriber and are available at home PLMN and visited PLMN. Examples are car rental or airlines from the HPLMN, which provide then worldwide comfortable access via the same IN number. It is possible to assign to the subscriber up to 10 different IN services of the HPLMN. Each entry in the CSI list of subscribed dialed services is associated with an SCP/CSE entity and service key which denes the service to be triggered.
A50016-D1112-V41-2-7618
DRAFT
81
Information System
Network dialed services Services with IN numbers, which exist in the PLMN. Examples are information services as weather forecast, local hotel reservation or a local car rental, - typically 0800 or 0900 numbers. Now, this services can be provided in a multi vendor conguration and also across network borders.
Conditional trigger can be the controlling element for setting up an IN/CAMEL call by means of the dialed digits, the call type or the basic service type, that is, the trigger criteria determine the conditions whether the existence of an O-CSI leads to a dialogue with SCP/CSE or not. For example the dialed digit string is the short cut for the mailbox. In this case the SCP/CSE is contacted on base of the O-CSI for processing the short cut. If no match is recognized, the call does not require IN/CAMEL processing. Subscribed dialed services can be activated in addition to the current IN services based on the O-CSI. With introduction of the dialed IN/CAMEL services a prepaid subscriber is able to dial IN/CAMEL car rental or hotel reservation numbers from his HPLMN in case of roaming. Subscribed dialed services allow to assign up to ten different destination numbers together with the SCP/CSE address for translation of this number. Support of location services This allows information to be provided depending on the current location of the mobile subscriber (see section 4.5.8, Location Services). Furthermore, emergency services can be designed on the basis of this information. Examples are traffic services, route planer, restaurant finder, or guidance for ambulances in emergency situations. Depending on the type of service, different granularities are required: For information services, the location data is sufficient mostly on the service area (consisting of one or more radio cells) base. For emergency services, a granularity of less than one hundred meters is necessary. Special information services also require this granularity. In all cases, the current location is required. To retrieve detailed information about the location of a mobile subscriber, an additional location service infrastructure is necessary. The SCP/CSE (or LCS client) initiates) positioning of the required subscriber via the Gateway Mobile Location Center (GMLC). The location information is delivered to the SCP/CSE (or LCS client) after the mobile subscriber has been positioned. Supporting of further CAMEL subscription information (CSI) variants Due to the above described additional CAMEL phase 3 features new variants of CAMEL subscription information (CSI) are introduced (see System Description, register Network System Concept). Multiple subscriber profile CAMEL phase 3 allows designing of an IN service, which allows to administer different subscriber profiles dependent on time, location area or the called MSISDN. An alternate line service with combination of business and private phone is one example of it. The SCP/CSE receives status information about the supplementary services call hold (CH), call wait (CW), multiparty (MPTY), call completion to busy subscriber (CCBS), connected line presentation identification (COLP) closed user group (CUG) or calling line presentation (CLIP) and is able to control or override the assigned adjustments.
82
DRAFT
A50016-D1112-V41-2-7618
Information System
Terminating- basic call state model (T-BCSM) in the visited MSC For roaming subscriber the roaming leg is charged separately, usually. This is also valid for prepaid subscriber. The T-BCSM in visited MSC allows the prepaid service to apply the correct charge for the roaming leg in a multifilament environment. The T-BCSM in visited MSC is also necessary for multiple subscriber profile (see above). Destination address reporting The destination address available in the visited MSC received from ISUP is provided to the SCP/CSE e.g., for charging purposes and number portability. The ported number received from the number portability server can be included as destination address to SCP/CSE. This is the basis for correct charging. SCP/CSE related congestion control (call gapping) For overload protection SCP/CSE related congestion control is introduced in the CAP v3 protocol. It is possible for the SCP/CSE to initiate congestion control at the serving SSP for the interface between SSP and SCP/CSE. It prevents the SCP/CSE from a general overload. The affected SCP/CSE can be controlled singular, if the service is used as criteria. This results in overload effects on the mobile subscribers of one SCP/CSE, only. The other mobile subscribers of the same service located at other SCP/CSEs are not affected. The mechanism for the congestion control is call gapping on base of service key and SCP/CSE address. If there is a bilateral agreement the call gap operations can apply also between different networks. SIEMENS allows the receiving of operations call gap dependent on the SCP/CSE address taken from the CSI which led to the IN/CSE service. CAMEL phase 3 SIEMENS proprietary add-ons For a better handling of CAMEL phase 3 SIEMENS introduced add-ons to the CAMEL phase 3 standard: Control of mobility management notication CSI (M-CSI) (refers to Notications of non-trafc events to the SCP/CSE - mobility management notication above) This type of functionality is newly introduced by CAMEL. It is assigned by the roaming partner and armed at the visited PLMN. As the operator of the visited PLMN does not have any information about the possibly frequent usage of this trigger a control mechanism is absolutely necessary. SIEMENS offers for prevention from frequent usage a denition of a gap between two mobility management notications for location update. Furthermore, SIEMENS also offers in case of indication, that one roaming partner causes to much mobility management notications, a possibility for ignoring an M-CSI dependent on the origination. Furthermore, the functionality of ignoring a CSI origin dependent at the VLR and the sending of a CSI destination dependent at the HLR is valid for all CSIs. Control of ATSI and ATM (refers to SCP/CSE control of subscription data (any time subscription interrogation and modication above) The comfortable way of administrating and controlling the CAMEL roaming agreements, the universal SIEMENS roaming subscriber table, is enhanced for any time interrogation (ATI) and CAMEL phase 3 elements ATSI and ATM (see below). SIEMENS allows to control the permissions for ATI, ATSI and ATM separately per requiring SCP/CSE.
A50016-D1112-V41-2-7618
DRAFT
83
Information System
Location services - any time interrogation (ATI) (refers to Support of location services above) CAMEL phase 3 ATI, the request for the current location of the mobile subscriber, causes in many cases a pre-paging at the visited PLMN. As pre-paging is a remarkable load for the visited PLMN, control of this request is very important. For some location dependent services it is obviously, that after sending the CSI by the HLR the current location is requested, Therefore, SIEMENS provides the possibility to include the request for the current location already into the T-CSI. This saves the following ATI dialogue SCP/CSE - HLR - VLR. Control of sending of the T-CSI depending of CAMEL capabilities of the visited PLMN With CAMEL phase 3 it is possible to have two special trigger detection points, one in the GMSC (T-CSI) and the other in the terminating visited MSC (VT-CSI). But for dedicated IN/CAMEL services it would be sufcient to have only one terminating IN/CAMEL-trigger, e.g., only the trigger in the visited MSC near to the served mobile subscriber. Therefore, the SIEMENS HLR has the possibility to suppress the sending of the T-CSI if the served mobile subscriber is roaming in a PLMN supporting CAMEL phase 3, that is, suppressing of the T-CSI if the VT-CSI was sent to the visited PLMN during location update.
3.3.6.2
CAMEL Phase 3 Enhancements

The following major features have been added to the functionality already provided in the CAMEL phase 3 basic feature package (see previous section): Detection point abandon in request mode If the originating party abandons before the B party answers, the SCP/CSE is able to interact, e.g., influence the charging. With implementation of the detection point abandon in request mode feature, it is possible to improve the charging of call setup for IN calls. Unsuccessful trigger detection points (TDPs) If originating IN-calls or forwarded IN-calls encounter routing failures or terminating calls encounter busy or no answer events, the SCP/CSE is enabled to interact, e.g., to route the call to a different destination, e.g., following a hunting list. These DPs are now available as TDPs; that is, no previous control relation between Service Switching Point (SSP) and SCP/CSE needs to be open and trigger occurs only if unsuccessful conditions are detected. Unsuccessful trigger DPs help to enhance the call completion rate. Enhancement for treatment of call gapping Default call handling, that is, continue without IN dialog or release call, is extended for T-CSI and VT-CSI in case the call is submitted to call gapping at the SSP. The call gapping feature is used to protect the SCP/CSE from overload. When a TDP is encountered, CAMEL subscription information (CSI) is checked for call gapping criteria if previously activated by the SCP/CSE or administered via Q3/MML in the MSC. Inclusion of complete operator determined barring (ODB) data in ATSI and NSDC
84
DRAFT
Any time subscription interrogation (ATSI) is the feature which the SCP/CSE used to interrogate the HLR to query the subscriber's attributes. Note subscriber data modification (NSDC) is used to inform the SCP/CSE of the change of subscriber data. The
A50016-D1112-V41-2-7618
Information System
scope of subscriber data to be interrogated/changed by these operations include ODB data. Up to now, only those ODB data were included, which were sent to the VLR (SLR in case of packet-switched domain) from the HLR. The parameter set now comprises the complete ODB category, including ODB data for incoming calls and for registration for call forwarded-to numbers.
i
3.3.7
CAMEL phase 3 enhancements constitutes a feature, which allows full standard compliance for inter operability and roaming agreements regarding CAMEL.
CAMEL Phase 4
CAMEL phase 4 enhances the capabilities of CAMEL phase 3. The circuit-switched part of CAMEL phase 4, which is described in this section, allows customized IN/CAMEL services, e.g., new SMS-related services or new IN features, based on updated location information.
3.3.7.1
CAMEL Phase 4 Feature Package (Step1)

The CAMEL phase 4 feature package (step1) consists of: Short message service (SMS) mobile terminated (MT) For terminating short messages, a notification is sent to the SCP/CSE. Depending on the subscribed services, the SCP/CSE can charge or release the short messages before delivery to the mobile subscriber. This feature enables the charging of short messages based on mobile terminating delivery, or the suppression of short message delivery (e.g., in case of screening services or if a prepaid subscriber has an insufficient account). The calling parties number can also be modified by executed CAMEL services, e.g., for virtual private network (VPN) services. A service triggered by mobile terminating short message can affect the further handling of the delivery request, for example: Prevent the short message delivery Continue the short message delivery with modied calling party number Perform charging activities The following applications are conceivable: Charging of SMS MT Standard charging of mobile terminating short messages can be offered to the PLMN operator. Furthermore, services can be charged on the basis of the number of short messages received, for example information services that provide information such as sport results, ight or train delays, updates on stock changes, or weather forecasts. SMS screening Today, customers are inundated with information. Through a positive or negative list stored in the SCP/CSE, only selected short messages are allowed to be forwarded to the subscriber. The SCP/CSE lists can be administered via the Internet or unstructured supplementary service data (USSD). This guarantees the customer full exibility. A typical application is the blocking of unwanted advertisements. Furthermore, this feature can also be used to prevent mobile subscribers live near a country border from repeatedly receiving standard welcome short messages.
A50016-D1112-V41-2-7618
DRAFT
85
Information System
Handover trigger: detection point change of position, detection point alerting and operation play tone Detection point change of position If a mobile subscriber leaves the service area during an ongoing call, this event can be detected in the MSC and reported to the SCP/CSE. The SCP/CSE receives a notication of the mobile subscriber's new position, which comprises the location number, cell ID (2G) or service area ID (3G). The report of a location change can be restricted by specic criteria, e.g., the movement to/from certain locations, or when an inter-system or inter-PLMN handover procedure is involved in the location change. CAMEL services that are triggered by a location change can affect subsequent call handling, for example by performing charging activities or terminating the call. Detection point alerting The feature detection point alerting allows the current mobile subscriber location to be reported to the SCP/CSE at the begin of the alerting phase of a call. At this time the called party has just been paged, that is, the location information is accurate. Operation play tone With the new CAMEL operation play tone, a variable tone sequence can be played to the mobile subscriber. This can serve as a distinct audible indication, for example, if the charging conditions have changed due to the change of the mobile subscriber's location. Conceivable applications of this feature are the introduction of enhanced home zone billing or campus screening services. Home zone billing: A special tariff is offered to subscribers when calling from their home zone. When subscribers leave their home zone during an ongoing call, a tariff change takes place. For example, in the home zone, subscribers can use the mobile network (PLMN) on the same tariff base as the xed network. When subscribers leave the home zone, different tariffs apply. A tariff change can be indicated via a dedicated tone and/or a message on the display of the mobile station (MS). Campus screening: The service campus screening is a special implementation of the home zone billing service. Students are offered special (that is, attractive) tariffs within the campus areas of their university or college. This requires the charging of mobile calls based on the subscribers current location. Any time interrogation (ATI) in HLR for location & state retrieval (also for packetswitched domain) The implementation of the fourth phase of the CAMEL feature (CAMEL phase 4) introduces enhanced procedures for the retrieval of subscriber location and state information for the packet-switched domain. Many intelligent network (IN) services need to obtain subscribers current location and state information. The SCP/CSE retrieves this information by sending an interrogation message to the home location register (HLR). The HLR then obtains the requested data and transfers it to the SCP/CSE. This any time interrogation procedure, which is already used in the circuit-switched domain, is also applicable for mobile subscribers of the packet-switched domain in CAMEL phase 4.
86
DRAFT
A50016-D1112-V41-2-7618
Information System
3.3.8
Special CAMEL Functions

Reduction to CAMEL phase 1 while roaming For (prepaid) subscribers roaming in a certain area of another PLMN the CAMEL phase supported for the O-CSI during location update can be restricted to phase 1. This area has to be defined by creating a special roaming area and for routing an special sending option has to be used at administration. The ISDN numbers to be entered for the roaming area are the addresses of the VLRs receiving the O-CSI (partly qualified numbers are allowed). If VLR or PLMN is found in this area (black list), then the O-CSI is reduced to CAMEL phase1, that is, the behavior is the same as if VLR had indicated supported CAMEL phase 1 during location update. The reduction to CAMEL phase 1 is not applicable to the home PLMN. Suppression of the call reference number by sending options If the feature PPSCRN is active, call reference numbers (CRNs) are generally suppressed in charging tickets or mobile call records (MCRs), but can be activated for mobile subscribers having certain CAMEL services e.g., for subscribers with prepayment of charges (see also section 4.6.6, Special Charging Features). For these mobile subscribers a further special sending option has to be set at administration. Furthermore a special property has to be set in the IN trigger profiles used by these mobile subscribers. Thus the call reference number can be used to distinguish mobile subscribers with prepayment of charges from other subscribers during postprocessing. Roaming restriction table During interrogation the T-CSI is normally sent from the HLR to the interrogating MSC. The roaming restriction table allows to suppress this for a certain CAMEL service depending on the VLR area the mobile subscriber is roaming in (see also section 4.13.25, IN/CAMEL: Roaming Subscriber Table in VLR). For this a special roaming area has to be created. The name of the roaming area equals the service name. The ISDN numbers to be entered for the roaming area are the addresses of the corresponding VLRs. The T-CSI can either be sent only to the specified VLRs or to all but the specified VLRs. Restricting short message delivery to the circuit-switched domain In principle short messages can be delivered via the circuit-switched domain or via the packet-switched domain. As the CAMEL service for SMS-MT is only implemented in the circuit-switched domain, you can restrict short message delivery to the circuit-switched domain using a special sending option. Any time operations Any time operations are started by an SCP/CSE sending a request to the HLR. As the name implies such a request can be sent at any time irrespective of a call. The following any time operations are supported: Any time interrogation (ATI) Retrieve location and status information for a specic subscriber. The HLR requests this information from the VLR (or SGSN) of the subscriber. For details concerning the contents of location and status information. Up to CAMEL phase 3 retrieval of information from the SGSN is implemented as proprietary solution. With CAMEL phase 4 a standardized solution is available (proprietary solution still supported for fallback). Any time subscription interrogation (ATSI)
A50016-D1112-V41-2-7618
DRAFT
87
Information System
Retrieve subscription information for a specific mobile subscriber. Examples for possible interrogations are: Call forwarding data Call barring data Operator determined barring data CAMEL service data CAMEL phases supported by visited network node (VLR (or SGSN)) Any time modication (ATM) Modify data of a certain mobile subscriber. Examples for possible modifications are: Call forwarding: registration, activation, deactivation and erasure Supplementary service call barring: activation and deactivation Assigned CAMEL service: modication of CSI state An any time modication of a CAMEL service in the HLR is automatically conveyed to the VLRs (and SGSNs) of the concerned mobile subscribers.
Multiple subscriber profile Multiple subscriber profile (MSP) is an optional service to enable mobile subscribers to have several profiles associated with a single IMSI, with each profile being a subscription option. Each profile can be used for mobile originated and mobile terminated calls. MSP is provisioned by the prior arrangement with the service provider. Up to four different profiles can be assigned to a mobile subscriber using the MSP feature, which allows the mobile subscriber to separate his telecommunication service needs into different identities (e.g., business and home). Registration of a profile allows mobile subscribers to register a provisioned profile to be used for mobile originated calls and activities. The request to register a profile contains the MSP code and the profile identity and is sent to the SCP/CSE using unstructured supplementary service data (USSD). The registered profile is stored in the SCP/CSE. In response to a successful registration request, the SCP/CSE returns a positive acknowledgement, including the registered profile, using USSD. The mobile subscriber can interrogate the MSP, using USSD, to identify which profiles are provisioned and which of the provisioned profiles is the currently registered profile. The interrogation request contains the MSP code and is sent to the SCP/CSE using USSD. In response to a successful interrogation request, the SCP/CSE returns the profile identity and profile status for each provisioned profile. If the MSP service is not provisioned, the SCP/CSE returns the appropriate service status. Operation play tone With the operation play tone the SCP/CSE invokes an audible notification to be played to the calling party by the M-SSP. The played sound effect comprises a flexible sequence of variable tones and intervals referred to as burst list. This allows operators to enhance CAMEL services with distinct tones or tone sequences that replace the standard, unspecific warning tone.
88
DRAFT
A50016-D1112-V41-2-7618
Information System
4 Network Functions of the Circuit-Switched Domain of Core Network (CNcs)

The services of the PLMN are based on the network functions both in the circuitswitched domain and packet-switched domain. The network functions in the circuit-switched domain of Core Network (CNcs) include: Basic functions of call handling Charging and billing Enhanced functions of call handling, charging and user information Mobile-specic functions of call handling (with mobility management) Fraud prevention/lawful interception functions Special operation and maintenance functions Protocol stacks for transport and signaling
i 4.1
The network functions in the packet-switched domain are described in the System Description, register GPRS/UMTSps.
Overall Functions Both in the Circuit-Switched and Packet-Switched Domain

Separated or Combined Mobility Management
In a Core Network (CN) architecture case either a separated mobility management or a combined mobility management (with Gs interface) is possible. In the 3GPP specifications for the CN architecture the CN consists of both a circuitswitched (CS) service domain and a packet-switched (PS) service domain (Fig. 4.1). This means that there is an individual CS service state machine within the MSC/VLR node and an individual PS service state machine within the SGSN/SLR node. The two peers of the service state machine are working irrespectively of each other. These separated service states in the MSC/VLR node and in the SGSN/SLR node are also available in the MS. In the same way, all location information are separated in the HLR by two individual logical location parts. For example, the following mobility management functions are working irrespectively of each other for the CS and for the PS service domain: Attach/detach Location update - routing area update. With the assistance of a Gs interface, it is possible to combine the mobility management of the CS and PS domain (see combined mobility management, section 4.8.3 and separate CNps documents). In the 3G case, the aim of 3G RAN is to offer a unified set of radio bearers that can be used for CS and PS traffic. This leads one to conclude that only one logical control channel structure is used for all kinds of traffic. The radio resource control (RRC) handling is a 3G RAN internal functionality and the Core Network does not define the type of radio resource allocated.
4.1.1
A50016-D1112-V41-2-7618
DRAFT
89
Information System
HLR PS location CS location
*) Gs interface, optional Gs interface
SGSN/SLR PS service domain PS state
MSC/VLR CS state CS service domain
RAN with distribution functionality RAN
A/Iu interface (separate signaling connections, that is, in 3G case RANAP instances per service domain)
Radio interface (in 3G case one RRC connection) PS state CS state
MS
Fig. 4.1
Separated/combined mobility management (MM)
4.2
Transport and Signaling Handling

Fig. 4.2 shows the basic possibilities of transport and signaling handling. CN internal an SS7 network either on MSC-integrated signaling transfer point (STP) functionality or using stands alone STPs is configurable. The user related signaling is an out band one. So at least a logical separated SS7 network is always configured. This is shown with case I) (RAN to CN transition) and II) (CN internal) in Fig. 4.2. If case III) is applied in a CN the signaling links are exclusively handled via the SS7 network and for the links of case I) and case II) there is no signaling traffic left - there is only user traffic (speech or data) left in that case. Case I): For case I) and a 2G RAN (BSS/GERAN) Release 4 the regarding interface is an SS7 / PCM30 configuration. The n*PCM links configured between BSC/TRAU and MSC include traffic as well as signaling channels. Usually there is no separation on PCM link level between signaling and traffic channels at the transition between RAN and CN. For case I) and a 3G RAN (UTRAN) an Iu interface with exclusively circuit-switched user traffic and signaling is the usual configuration.
90
DRAFT
The to be used network layer protocol is determined by the according type of interface (refer to Fig. 4.5).
A50016-D1112-V41-2-7618
Information System
Case II): By using the MSC integrated STP functionality the SS7 network is integrated part of the MSC inter-meshing. For larger CNs a separated handling of signaling and traffic links can be applied. Refer to section 4.4 for the different possible operation modes. Case III): For larger PLMNs/CNs the SS7 can be configured using separate physical network elements which handles exclusively signaling connections. Refer to section 4.4 for the different possible operation modes of such an SS7 network.
PSTN/ISDN/ PLMN RAN STP-SA III) I) VMSC STP-SA SS7 network STP-SA
II) TMSC
II) GMSC
I)
CS domain (CNcs)
CN
Legend: Signaling link configured over physical separated SS7 network Signaling link configured over physical integrated SS7 network Transport/bearer link
Fig. 4.2
Transport/signaling handling in Core Network
4.2.1
CN Transport Capabilities
Following capabilities are available for intra- and inter-network related transport handling: Narrow-band TDM based This is standard at the present for existing circuit-switched CNs and for PSTN/ISDN and PLMN circuit-switched interworking. For further information refer to section 4.3.2. Broadband ATM based ATM/AAL2 based is available. Refer to section 4.3.3 for general information about ATM based networks. Broadband IP based A VoIP trunking solution using the IP Trunk Gateway (GW) is available. Refer to section 4.3.4 for more information
A50016-D1112-V41-2-7618
DRAFT
91
Information System
4.2.2
CN Signaling Capabilities
Following capabilities are available for intra- and inter-network related signaling handling: Narrow-band TDM based: This is standard at the present for PSTN/ISDN and PLMN circuit-switched interworking. High-speed link (HSL) based: Two types of high-speed links are available (see also section 4.4). In both cases existing PCM30 on PDH links are still usable. Thus allows overcoming performance limits of 64 kbit/s channelized operation. Broadband ATM based: All SSNC based network elements offer ATM/AAL5 based connectivity. Thus allows usage of an ATM backbone network for general SS7 signaling transmission. Broadband IP based: All SSNC based network elements offer SCTP/IP based connectivity. Thus allows usage of an IP backbone network for general SS7 transmission as well as direct inter-working with, e.g., any kind of IP based service domain.
4.2.3
CN Routing
Routing is the process of determining and prescribing the method to be used for establishing telephone connections or forwarding messages. It is a basic MSC functionality necessary for flexible path selection through the PLMN.
Routing
Link CN node
CN node
Link
CN node
Fig. 4.3
CN routing principle
One main criterion for routing is the dialled digit sequence given by the subscriber who wants to set up a call. Amongst other information (e.g., static values in MSC database, signaling information, A-party-number, etc., ...) the dialled number is conveyed by appropriate signaling protocols through the PLMN. Routing in the circuit-switched CN is therefore always a signaling user (usually ISUP and also BICC) related functionality. For TDM based CN there are to consider two basic mechanisms for call routing (except for analog signaling, where only one routing principle is relevant due to missing SS7). Prerequisite to routing is the evaluation of address information. This task is performed by the network node elements. Signaling processing routing (SPR) on signaling point code (SPC) bases on much simpler evaluation logic than call processing routing (CPR) on code point (CPT) basis. For SPR all signaling messages received by the network element, which include an SPC unequal to the own SPC, are not further processed by the
92
DRAFT
A50016-D1112-V41-2-7618
Information System
network element itself. They are simply sent to the partner network element as defined via the network elements SS7 routing database. For CPR the received signaling message must be processed by the network element. The address information is given by a digit sequence. The digit sequence, which is going to be evaluated, is basically the dialled digit string. Optional various other information (e.g., static MSC related values like origin marks or signaled information as it is the A number for example) is used to select the route through the PLMN. Thus allows the support of a more complex routing mechanism for the regarding bearer channel. A bearer channel and its dedicated signaling channels can use the same route or can use different routes within the network. Dependency of network configuration on signaling protocol: For legacy signaling protocols, as it is analog signaling, bearer and signaling routing are identical. This is independent from the in-band signaling variant in detail (MFC-R2, #5, ...). On SS7 basis signaling functionality is carried out using an additional logical network beside the transport network (either integrated or also physically separated, which is of no relevance in the context here). This allows more flexible PLMN design and most important the support of connectionless signaling exchange. Rerouting: This is the case when the initial routing attempt fails and a new route is selected through the network. So if one route fails due to e.g., lack of resources the ongoing call is not terminated. Instead of that a second alternate route is selected to complete the call set-up finally. Rerouting action triggered by cause evaluation from backward signaling is called crank back. To support crank back ISUP or BICC signaling protocol must be used.
4.2.4
Transport and Signaling Handling with Transit-MSC

The transit MSC (TMSC) functionality is a well known property of TDM based MSCs. The content of this section is therefore focused on ATM/AAL2 aspects. ATM/AAL2 capable MSCs support ATM/AAL2 or BICC transit (Fig. 4.4). Prerequisite is the availability of the short cut, which avoids extra transcoding and allows therefore transcoder free operation (TrFO). This offers the possibility to support ATM/AAL2 transit functionality by the integrated CS-MGW part of the MSC. As a result a hierarchical network configuration for an ATM/AAL2 CN (refer to section 4.3.3.2) based on MSCs is feasible, too. Until introduction of TMSC in ATM based CN as mentioned above, this was only possible for a TDM based CN (refer to section 4.3.2) on MSC basis. For user signaling BICC is used by PLMNs as protocol for ATM/AAL2 based transport/backbone networks. The bearer independent call control (BICC) is defined by ITUT. For further information about PLMN specific information of transit MSC functionality refer to section 4.12.5 and for general information about BICC refer to section 4.14.5.1.
A50016-D1112-V41-2-7618
DRAFT
93
Information System
RAN
PSTN/ISDN/ PLMN
BICC VMSC AAL2
TMSC
BICC GMSC AAL2
Point of interconnection (POI)
AAL2
BICC
Transit layer BICC VMSC AAL2 TMSC AAL2 BICC VMSC
CN, CS domain (CNcs) RAN RAN
Legend: Transport/bearer link (AAL2, inclusive bearer signaling Q.2630) Signaling link, call related (BICC) Transport/signaling link (characteristic depends on type of RAN/partner network)
Fig. 4.4
CN configuration with transit MSC in ATM/AAL2 transit layer
4.3
4.3.1
Transport Congurations
Requirements and Principles
Below the relevant technologies used for transmission of signaling and data within the CN and for interworking with partner network(s) are shown. Fig. 4.5 shows the different types of transport technologies in the CN, which are relevant for the circuit-switched (CS) domain. Key characteristics of TDM are a guaranteed bandwidth (64 kbit/s per call/session/transaction with unique coding scheme (A-law coding)) and less transmission delay. This standard firstly introduced as transmission technology between the exchanges within the PSTN (e.g., between transit exchanges within the fixed network area) gave the basis for all further circuit-switched based networks like ISDN (fixed network) and 2G PLMN (mobile network). For 2G PLMN the mobile specific coding of user data (primary speech) has to be considered within a CN configured of EWSD/SSNC based network elements (MSCs). As
94
DRAFT
A50016-D1112-V41-2-7618
Information System
simplest solution (and vendor independent), the necessary adaptation from mobile format (HR, FR, EFR) to A-law is either performed in the visited MSC (for 3G PLMN) or in the origin RAN (for 2G PLMN). Therefore, for mobile-to-mobile calls over a TDM CN, it takes place twice. To overcome this disadvantage (results in speech quality degradation), the tandem free operation (TFO) - refer to section 4.12.4 is available for 2G calls. With 3G PLMN ATM has been introduced on the RAN-side to firstly integrate circuitswitched (CS) and packet-switched (PS) demands in a common way (see also section 4.1) and secondly to have a basis for efficient and flexible handling also of speech calls (which means a guaranteed quality of service (QoS)). In addition, a variety of speech transcoding bit rates are available which strengthens the requirements of flexible bandwidth handling in the CN. With 3GPP Release 4 and the introduction of traffic over ATM CN functionality (refer to section 4.3.3.1), the transcoder free operation (TrFO) is further available for 3G mobile-to-mobile calls, which allows maximum speech quality (TrFO - refer to section 4.12.4). An MSC internal IP based interface for circuit-switched applications is not available inclusively the current software version. As a first step towards IP based CN for CS external IP-Mux equipment is available.
3G RAN
PSTN/ISDN/ PLMN
ATM
TDMoIP
TDM
IP Trunk GW
IP Trunk GW
VMSC
ATM
GMSC
ATM TDM TDM
TDM
CN, CS domain (CNcs)
Other PLMN
2G RAN
Note: MSC as combined network element: MSC-S and MGW
Fig. 4.5
Survey of CN connectivity/technologies in the circuit-switched domain
A50016-D1112-V41-2-7618
DRAFT
95
Information System
TDM based Existing PLMNs or their CNs are all based on TDM/PDH. The usual PCM30 transmission links (2 Mbit/s) with their n*64 kbit/s channels are used for transporting primarily speech traffic. ATM based As simplest approach the ATM backbone is configured as static network where the network configuration of the CS network nodes is implemented on e.g., PVC/AAL1 basis. The benefit is the transparent transmission through the ATM network. A disadvantage is that no bandwidth saving is achievable and the administrative effort for the ATM image of large PCM networks. This variant is only mentioned for completeness and is not part of further description. With the availability of the Nb interface using ATM/AAL2 (refer to section 4.12) at the MSC bandwidth efficient provision of an ATM CN is possible. This allows also compressed speech access from 2G PLMN / other TDM based traffic towards an ATM based CN. IP based For the MSC access to the IP transport level is possible in current software version. This is implemented by usage of the IP-Mux equipment. Driver for these activities is to share the IP infrastructure together with the packet-switched (PS) domain. Benefit would be a common and unique IP infrastructure. This proprietary solution is a first step towards voice over IP (VoIP). An improved, protocol conform solution is available with a later version.
4.3.2
TDM Based
The MSC offers connectivity (n*64kbit/s channels) to other MSCs (or any other network element which handles call related traffic like e.g., VMS) on PCM30 (PDH) and/or STM1 (SDH) basis. Access to SDH based network level is provided by the STMI (synchronous transport module Level 1 interface integrated), which is an MSC internal functionality, or by using external SDH MUX equipment. Regarding the number of PCM30 or STM-1 needed: Also in case of providing external connectivity on STM-1 granularity the MSC internal scalability bases always on n*PCM circuits of the LTGs. This is similar to the approach using external SDH MUX equipment. The number of LTGs relevant for the transit traffic handling is further depending on the MSC configuration (2G, 2/3G and the specific role/function). The following two chapters address simply the basic principles. Real configurations are varying on project specific needs.
4.3.2.1
Flat TDM Based CN Scenarios

With Fig. 4.6 an example for a TDM based CN with flat structure is given. The MSCs are fully meshed. This can be applied for small CNs or PLMNs only (approximately below 10 MSCs in total). MSC I, MSC II and MSC III performs VMSC and GMSC functionality. The resulting possibilities of connectivity for MSC I are shown on behalf of routing possibilities (Route A, Route I-II, Route I-III) of MSC I. For MSC II and MSC III the same is valid but not illustrated within the figure for a better overview. Disadvantage of such a purely flat structure would be that no alternate routing over partner MSCs could be performed (Route I-II-III marked as dotted line connection in Fig. 4.6).
96
DRAFT
A50016-D1112-V41-2-7618
Information System
Introducing transit functionality into the flat CN scenario To overcome such disadvantages the transit functionality is needed. This enhancement of the MSCs would lead a step towards a hierarchical structure of the network. From a theoretical point of view, the transit functionality is no attribute of a pure flat network configuration. However, such a modified flat CN is usually still called a flat structured network. So, alternate routing over partner switches (e.g., Route-I-II-III) is a basic functionality also for flat CNs consisting of more than one MSC. The mobile originating/terminating traffic per MSC area as well as the resulting intraPLMN and inter-PLMN traffic is assumed as relatively low (several 2 Mbit/s circuits) with that example. Therefore only PCM30 based connections are shown. In case of high traffic load within an MSC area, SDH based access using STM-1 connection(s) is possible too by using the STMI functionality of the MSC.
PSTN/ISDN/ PLMN 2G RAN
Route A Point of interconnections (POIs)
MSC I (MSC-S) Route I-II Route I-III MSC III (MSC-S)
MSC II (MSC-S)
Route I-II-III not possible in a purely flat structured network
2G RAN
CN, CS domain (CNcs) 2G RAN
Note: MSC includes VMSC and GMSC functionality
Fig. 4.6
Flat TDM CN configuration example
4.3.2.2
Hierarchical TDM Based CN Scenarios

With Fig. 4.7 an example for a TDM based hierarchical CN is given. The MSCs are not fully meshed. This is usually only applied for larger PLMNs (approximately more than 10 MSCs). The specific configuration as already mentioned is widely project dependent. So dual homing (a VMSC is connected via two TMSCs to the transit layer) as shown with Fig. 4.7 is not necessarily needed. It is also possible that a VMSC is only connected via
A50016-D1112-V41-2-7618
DRAFT
97
Information System
one TMSC to the transit layer. Also the exact configuration of a region can include VMSC(s) which performs intra-regional traffic without using the transit layer. Nevertheless with that example configuration within the regions exclusively VMSC functionality is performed. There is no transition to other networks and no transit traffic handling. The regional traffic uses the transit layer for calls outside the own region. This is valid for intra PLMN traffic as well as for traffic to other networks. In the latter case the GMSC performs the transition towards PSTN/ISDN and other PLMNs. In the example, a fully meshed and redundant transit layer configuration is shown. Furthermore the basic roles of an MSC (VMSC, TMSC and GMSC) are performed by separated network elements for visited-, transit-, and gateway- functionality. In real PLMNs (as already mentioned) a combination of MSC roles in one physical network element is more likely than a strict separation. E.g., the GMSC functionality often can be performed within the MSCs of the transit layer (combination of TMSC and GMSC functionality).
PSTN/ISDN/ PLMN
GMSC (MSC-S) Region A VMSC (MSC-S) TMSC (MSC-S) VMSC (MSC-S) TMSC (MSC-S) VMSC (MSC-S) Region C TMSC (MSC-S) VMSC (MSC-S) Region F 2G RAN TMSC (MSC-S) VMSC (MSC-S) Region E 2G RAN VMSC (MSC-S) Region D 2G RAN
2G RAN
Region B 2G RAN
2G RAN
Transit layer
CN, CS domain (CNcs) Legend: TDM n*PCM30 TDM n*STM-1
Fig. 4.7
Hierarchical TDM CN configuration example
98
DRAFT
To handle the inter-regional and the inter-network traffic the MSCs are capable of SDH based connectivity using STM-1. Region F in the example configuration is identified as
A50016-D1112-V41-2-7618
Information System
area with large traffic volume. Therefore the connection to the transit layer is also configured as STM-1 on SDH basis like it is within the transit layer.
4.3.2.3
Access to the TDM Backbone Network

Usually, there are no direct PCM links between MSCs. Instead, the MSCs are connected via a TDM based backbone CN. Typically, these TDM backbone CNs are SDH based. The SDH backbone is a flexible and software controlled transport network with high reliability in transmission. It is built of SDH switches and covers the physical layer functionality (layer 1). PDH based backbones still exists, but SDH backbones are the main focus today.
2G RAN
PSTN/ISDN/ PLMN
2G RAN MSC II (MSC-S)
Point of interconnection (POI)
BNE
BNE
BNE MSC I (MSC-S) BNE SDH backbone CN
BNE
MSC III (MSC-S)
Legend: BNE = Backbone Network Element (SDH switch) Physical connections TDM PCM 30 Physical connections TDM STM-1 Logical connections
Fig. 4.8
TDM network configuration example - backbone access
A50016-D1112-V41-2-7618
DRAFT
From the MSC (or all CP based network elements) connectivity to the backbone CN is possible either via E1 (PCM30) or STM-1. Fig. 4.8 shows an example for the backbone CN access.
99
Information System
Fully and flexible connectivity between MSCs and their belonging 2G RANs or with point of interconnections (POIs) is supported via the SDH backbone (consider physical and logical connection shown with Fig. 4.8). MSC I shows the access to the backbone network by offering the traffic in portions of E1 PDH links. The backbone network element (BNE) performs the access and the aggregation to the backbone internal used SDH level. The dimensioning of the links bases according network planning. Expansion has to be done in agreement with the backbone CN operator. MSC II shows the access to the SDH level by using appropriate external multiplexing equipment. MSC III finally shows as example the access to the SDH level by using the MSC internal STMI functionality. Which method is most cost efficient depends on the leased line costs and the tariff model of the backbone operator. The aggregation of the traffic load by STMI to STM-1 can result in a throughput quite below the possible throughput of STM-1. However, this aggregation can still be useful depending on the specific tariff of the backbone network operator. E.g., using STM-1 loaded with 50% of maximum bandwidth can be cheaper than ordering the equivalent number of single E1 links. A second advantage of the aggregation is, that the spare capacity could be filled step by step without any further hardware extensions to be requested from the backbone network operator.
4.3.3
ATM Based
The SIEMENS MSC supports an ATM based CN (see section 4.12) in addition to an ATM based 3G RAN. With the introduction of the feature transcoder free operation (TrFO) in the 3G MSC part, double transcoding to TDM and back to AAL2 is not required anymore. TrFO improves the speech quality as compared to a TDM backbone. In case of ATM/AAL2 there is also the possibility to save bandwidth when speech is transported as AMR coded compressed speech rather than as 64 kbit/s uncompressed speech over TDM. This bandwidth saving together with the possibility of TrFO makes the use of an ATM backbone attractive. At the same time, the ATM CN can also be used to transport 2G traffic provided the traffic is converted to AAL2. This 2G traffic would arrive at the 2G/3G MSC node on an A interface and the 2G/3G MSC converts it to AAL2. The ATM CN provides ATM virtual channel connections (VCCs) that can be used as AAL2 paths or as AAL5 signaling VCCs. These VCCs are permanent virtual channels (PVCs) of ATM service category constant bit rate (CBR). They are characterized by their peak cell rate (PCR). For SIEMENS MSCs, the PCR of an AAL2 path is the same in forward and in backward direction (the traffic for the CS domain is assumed to be symmetrical). The current software version supports only PVCs and no switched virtual connections (SVCs). Therefore all AAL2 paths are PVCs. The AAL2 connections are put inside these AAL2 paths. An AAL2 path can support up to 248 AAL2 connections. AAL2 paths and AAL2 bearer control signaling VCCs to the ATM CN use the ATM based Nb interface.
100
DRAFT
A simple signaling protocol for AAL2 bearer control (basically set-up and release of AAL2 connections) is defined in ITU-T recommendation Q.2630. Such signaling traffic uses an AAL5 PVC. All call control issues are the task of the corresponding call control
A50016-D1112-V41-2-7618
Information System
entity, that is, RANAP in the 3G RAN (Iu interface) or BICC in the CN (Nc interface). The BICC signaling traffic can be transported via TDM or ATM. If ATM is used then this signaling traffic is sent inside an AAL5 PVC via the Nc interface. For transporting AAL2 traffic across an ATM backbone there are many possible scenarios. This section describes the most important scenarios that can be supported with the 3G MSC part in current software version. These are flat and hierarchical 3G CNs. Assumptions: In this section we only consider pure ATM scenarios (and not a combined ATM/TDM CN - for ATM/TDM interworking aspects refer to section 4.3.5). All 3G MSCs are a combination of MSC-Server and MGW (integrated solution). The SIEMENS 3G MSC part in current software version provides this combination. ATM CN solutions that are possible for separated MSC-Server and MGW are not described here. Definition of flat and hierarchical 3G (or combined 2G/3G) CNs A 3G CN is considered flat if all the 3G-visited-MSCs (integrated MSCs) have a direct call control relationship with each other. All network elements between them do not modify the content of the call control messages but pass them transparently. In particular no 3G-transit-MSCs are used between the 3G-visited-MSCs. All the call routing is done in the visited MSCs. A 3G CN is called hierarchical if the network is separated into local regions and in addition a layer of 3G-transit-MSCs is introduced. The 3G-visited-MSCs in a local region can still have a direct call control relationship with each other. But the call control traffic between two 3G-visited-MSCs can also pass through a network of 3G-transit-MSCs. Some of the call routing is done in the 3G-visited-MSCs, some is done in the 3G-transit-MSCs. A 3G-transit-MSC for a 3G CN is connected to the 3G MSCs (of its region) as well as to the other 3G-transit-MSC at the call control and at the transport level. A 3G-transit-MSC supports AAL2 switching. In particular it terminates AAL2 paths. The special case of inter PLMN interworking on ATM/AAL2 basis is not included in the following chapters regarding ATM basic configurations.
4.3.3.1
Flat ATM Based CN Scenarios (3G only)

The following Fig. 4.9 shows a flat CN architecture, where all 3G MSCs are fully meshed: between each two 3G MSCs there is at least one AAL2 path set up as PVC. For redundancy reasons there should be at least two AAL2 paths between two 3G MSCs preferably on two different ATM links. In addition one requires at least one AAL5 connection as a PVC for transport signaling. The call control signaling also requires an AAL5 PVC (if ATM is used). These two AAL5 signaling connections can even share the same VPC. For redundancy reasons the AAL5 connections should be doubled. In the Fig. 4.9 the 3G MSCs have direct ATM links in between them. This is not the typical case. Usually, an ATM backbone is used to connect the 3G MSCs (see also section 4.3.3.3).
A50016-D1112-V41-2-7618
DRAFT
101
Information System
3G RAN
Iu 3G VMSC Nc Nb Nc PSTN/ISDN/ PLMN
Nb 3G RAN Iu 3G VMSC Nc GMSC
TDM
Legend: Nb = Q.2630 over AAL5, bearer over AAL2 transport plane Nc = BICC over AAL5 Iu = RANAP over AAL5, Q.2630 over AAL5, bearer over AAL2 transport plane
Fig. 4.9
3G MSCs fully meshed
In the Fig. 4.10 below all MSCs are connected via PVCs to the ATM backbone. For redundancy reasons there should be at least two AAL2 paths between the 3G MSCs and the ATM backbone preferably on two different links.
102
DRAFT
A50016-D1112-V41-2-7618
Information System
3G RAN
Iu
3G VMSC Nc 3G VMSC Nc Nb Nc Nc GMSC TDM
PSTN/ISDN/ PLMN
3G RAN Iu
Nb
ATM backbone CN
Legend: Nb = Q.2630 over AAL5, bearer over AAL2 transport plane Nc = BICC over AAL5 Iu = RANAP over AAL5, Q.2630 over AAL5, bearer over AAL2 transport plane
Fig. 4.10
3G MSCs connected via ATM backbone
The ATM backbone provides only ATM cross connects functionality. All AAL2 connections from one 3G MSC part inside a PVC are routed to the same partner 3G MSC part. In this case the MSCs have to take care of the AAL2 routing. In the ATM backbone no AAL2 treatment is required. In addition there has to be at least one AAL5 connection be set up as a PVC for transport signaling between each pair of 3G MSCs. The call control signaling also needs a PVC for AAL5 if it is transported via ATM. For redundancy reasons the AAL5 connections should be doubled. A flat ATM transport network is suitable only for small CNs (up to 10 MSCs) because for a full meshing, the number of AAL2 paths in the CN is proportional to the square of the number of 3G MSCs. For large CN one would require many PVCs to be set up and administered. A flat transport network is therefore not scalable. In the SIEMENS solution of the above-described CNs there is always an integrated MSC-Server and MGW part. This implies a tight coupling of the Nb and ATM based Nc interface, that is, there is always an Nb and an Nc interface between two neighbor nodes.
A50016-D1112-V41-2-7618
DRAFT
Between the RNC and 3G MSC part the CN is flat because the RNC has a direct signaling relationship to the 3G MSC part (RANAP signaling). However, there is often an ATM (access or backbone) network between the RNC and the 3G MSC part.
103
Information System
Introducing transit functionality into the flat network scenario The configurations shown in the two figures above (Fig. 4.9, Fig. 4.10) have one main disadvantage: If the direct AAL2 paths between two 3G MSCs fail, then AAL2 connections between the two 3G MSC part are no longer possible. This disadvantage can be overcome by introducing transit functionality into the visited 3G MSCs. As in case of the TDM backbone, this enhancement of the MSCs would lead a step towards a hierarchical structure of the CN. However, such a modified flat CN is usually still called a flat structured CN. When each 3G-visited-MSC includes also transit MSC capability, then there are more alternate routes between two 3G-visited-MSCs: The AAL2 traffic between them could not only use the direct AAL2 paths between the 3G MSCs. Instead, the call could be set up via a third visited MSC that would act as a transit MSC (TMSC). This would then result in a 2-hop set-up at the BICC level. One also would need two AAL2 paths. The third MSC that acts as a TMSC would perform AAL2 switching. Such alternate routing is common in TDM CNs. The SIEMENS MSC in current software version also supports this kind of alternate routing.
4.3.3.2
Hierarchical ATM Based CN Scenarios (3G only)

The hierarchical 3G CN consists of local 3G MSCs and 3G-transit-MSCs. The local 3G MSCs are grouped into regions. The transit network interconnects the regions. In this section we assume that all of the 3G MSCs and all of the 2G TMSCs are connected to an ATM backbone via ATM PVCs. Some of the 3G MSCs within one region are directly interconnected. Connecting the 3G MSCs of one region via the 2G TMSCs of the region is also possible. AAL2 traffic from a 3G MSC part to a 3G MSC part outside the region is sent to a 2G TMSC. All 2G TMSCs are interconnected by way of ATM PVCs via the ATM CN. AAL2 connections can pass one or several 2G TMSCs before they arrive at the destination 3G MSC part. The AAL2 connections can use several AAL2 paths, e.g., one between the MSC and the TMSC, one between two TMSCs and one between the TMSC and the MSC. This means that TMSCs need to support AAL2 switching.
104
DRAFT
A50016-D1112-V41-2-7618
Information System
Transit layer T/G 3G MSC T/G 3G MSC T/G 3G MSC
T/G 3G MSC
TDM connections ATM
ATM ATM ATM backbone CN
AAL2 connections
V/G 3G MSC
ATM connections V/G 3G MSC V/G 3G MSC V/G 3G MSC
V/G V/G 3G MSC 3G MSC
V/G 3G MSC
V/G 3G MSC V/G 3G MSC
Regional layer Legend: V/G-MSC = Visited or Gateway MSC T/G-MSC = Transit or Gateway MSC
Fig. 4.11
Hierarchical CN of MSCs with 3G MSC parts
In the Fig. 4.11 above it is assumed that the Nc interface is TDM based and the MSCs are connected via TDM at the BICC level. As in case of the flat CN, an ATM backbone is used to interconnect the MSCs and the TMSCs. The advantages of a hierarchical CN are: It is scalable and it can support more than ten 3G MSCs The routing within a region is easier: The routing tables of one 3G MSC part contain only routing information for the neighboring 3G nodes of the same region and for the routing of the corresponding 2G TMSC. If a new MSC is added within a region, only the routing tables of the region need to be updated. This simplies administration. To increase the availability, it is recommended to use dual homing: about half of the AAL2 paths between a VMSC and the transit layer are routed to one TMSC and the other half is routed to another TMSC. For basic information about network routing refer to previous section 4.2.3.
A50016-D1112-V41-2-7618
DRAFT
105
Information System
4.3.3.3
Access to the ATM Backbone CN (3G only)

In the sections on the flat and hierarchical ATM based CN it was mentioned that usually an ATM backbone is used to interconnect two MSCs. It is also common that an RNC is connected to a 3G MSC part via an ATM access or backbone CN. Concerning the link types, it is common to connect the 3G MSC part to the ATM backbone via STM-1 links. Concerning the used ATM connection types, we provides two basic approaches how an MSC or RNC can be connected to an MSC via an ATM backbone. It is assumed that AAL2 paths and AAL5 signaling VCCs are PVCs. Both approaches are possible with the SIEMENS 3G MSC part: PVC solution: The RNC/MSC is connected to the MSC via PVCs and the backbone network can route each PVC separately. PVP solution: The RNC/MSC is connected to the MSC via a few PVPs (permanent virtual paths) and the PVCs inside the PVPs are transparent to the ATM backbone CN. PVC solution In case of the PVC solution, a large VPC has to be set up between the MSC/RNC and the ATM backbone CN. A second large VPC is needed between the ATM backbone CN and the MSC. When a PVC is to be set up between an MSC/RNC and an MSC, then one PVC segment has to be set up between the MSC/RNC and the ATM CN and one PVC segment between the ATM CN and the MSC (see Fig. 4.12 below). Inside the ATM CN, the two PVC segments can then be connected via a third PVC segment. In this case the ATM CN needs to provide only cross connect functionality. Alternatively, the two PVC segments can be connected via an SPVC (soft PVC). This requires that the ATM CN supports switched virtual connections (SVCs).
VPC PVC 3G MSC or RNC
VPC or SPVC PVC
ATM node
ATM node
3G MSC
3G MSC or RNC
ATM node
ATM backbone CN
Fig. 4.12
PVC solution for connecting RNCs or 3G MSCs to an MSC via an ATM CN
106
DRAFT
A50016-D1112-V41-2-7618
Information System
PVP solution In case of the permanent virtual path (PVP) solution, a PVP segment has to be set up between the MSC/RNC and the ATM backbone CN and another PVP segment between the ATM backbone network and the MSC. Inside the ATM CN, the two PVP segments can then be connected via a third PVP segment or via an SPVP (soft PVP). Using an SPVP requires that the ATM CN supports switched virtual paths (SVP) connections. When a PVC is to be set up between an MSC/RNC and an MSC, then the PVC can be established in one segment inside the already established PVP. The advantage of PVP method is the reduction of administration effort in the ATM CN for setting up the single PVCs.
PVP PVC 3G MSC or RNC
PVP or SPVP PVC
ATM node
ATM node
3G MSC
3G MSC or RNC
ATM node
ATM backbone CN
Fig. 4.13
PVP solution for connecting RNCs or 3G MSCs to an MSC via an ATM CN
Usage of ATM CN for separation of CS and PS domain traffic: The ATM backbone CN can also be used to route the CS domain VCCs to the 3G MSC part and the PS domain VCCs to the SGSN. If there is no ATM CN or no ATM node between the RNC and the MSC, the MSC could also be used to separate the CS and PS domain VCCs. Using the MSC as an ATM cross-connect could achieve this. The MSC supports cross connect functionality for PVCs and PVPs, but only the PVP cross connect functionality is released.
4.3.4
IP Based
MSC external IP interfaces: With current software version the VoIP service can be provided based on external IP concentrator OEM equipment, which is named IP Trunk Gateway (GW) (AXN1600 from AXERRA). The IP Trunk GW maps entire TDM E1 links on top of the protocol stack RTP/UDP/IP/L2/L1. The real time protocol (RTP) payload length can be configured via OAM commands providing the PLMN operator a means to tune the header/payload ratio and the delay. An IP Trunk GW has to be placed on both sides of a replaced E1 link. The IP Trunk GW supports up to 192 E1 ports. The main IP Trunk GW components are the IO mux card (IOM), the intelligent network interface card (INI) and the integrated common processor card (ICP); see Fig. 4.14. Towards the IP backbone the INI cards support 8* Fast Ethernet and 1* Gigabit Ethernet in the 1st release. Next releases also provide STM1/4 interfaces. From the QoS point of
A50016-D1112-V41-2-7618
DRAFT
107
Information System
view layer 3 marking (differentiated services (Diffserv)) and layer 2 marking are supported. In addition multi protocol label switching (MPLS) is supported. To achieve the same service availability for real-time traffic as TDM or ATM systems, redundancy aspects have to be considered on the access towards the IP CN and within the IP CN itself. The IP CN access redundancy can be provided as line redundancy, that is, dual access from the IP Trunk GW to one edge router (ER) or as dual homing, that is, dual access from the IP Trunk GW to two ER. Fig. 4.14 shows the dual homing scenario. In the IP CN itself route redundancy has to be provided to avoid single point of failure in case of core router (CR) outage. The CN route redundancy can be provided either by careful IP CN engineering so that routes emerging at the ERs towards a single destination are not crossing or by introducing redundant multi protocol label switching (MPLS) paths towards a single destination. The IP CN itself has to support the transport of real-time traffic, that is, the introduced delay, delay variation and packet loss have to be kept very low. The required QoS within the IP CN for the real-time traffic can be achieved by having fast wire speed routers, giving IP packets with real-time traffic a higher priority than best effort traffic using the DiffServ approach and using of MPLS paths in the IP CN. The MPLS paths can be set-up end-to-end between the INI cards or edge-to-edge between the ER. The benefit of the1st option is guaranteed bandwidth and fast-forwarding of IP packets also at the IP CN access part. The disadvantage of the 1st option is a higher number of required MPLS paths to provide a full meshed MPLS paths network between all IP Trunk GW via the IP CN. The delay between peers IP Trunk GW is split into three parts; the egress delay at the source, the IP CN delay and the ingress delay at the termination.
TDM CR CR A interface MSC Iu interface ER CR IP Trunk GW IP Trunk GW
ER CR
ER
ER
IP backbone CN
Fig. 4.14
TDM over IP configuration in the CS domain
108
DRAFT
In case that an IP CN route gets blocked due to a faulty HW the IP routing protocols provide new routes to the destination within the IP CN. However, this procedure takes time that is not acceptable for a real-time service (e.g., >10 seconds, it depends on the used routing protocol). A mechanism at the VoIP trunking host (IP Trunk GW) has to be setup (currently not in the scope of IP Trunk GW), which scans the established connections frequently, enabling the host applications in the IP service card (IPSC) to switch rapid to
A50016-D1112-V41-2-7618
Information System
a predefined alternate route. Of course this has to happen at both terminations of a route in parallel. The IP Trunk GW supports static routing only.
4.3.5
Interworking Between TDM and ATM Based Networks

With Fig. 4.15 the variants how to set-up the communication paths between the different type of AN and the CN are shown. The selection criteria which type of CN or which types of communication paths are to handle via which type of CN depends mainly on the required quality of service (QoS) for circuit-switched calls. For more details regarding QoS refer to the last part of this section.
3G RAN CN, CS domain (CNcs)
ATM 2G RAN TDM
ATM backbone CN VMSC Partner PLMN ATM #) TDM TDM backbone CN TDM AN: FS TDM
PSTN/ISDN Legend: #) Special POI: Iu/Nb user protocol must be used exclusively as Framing Protocol
Fig. 4.15
Traffic separation TDM/ATM based CN
Fig. 4.16 as follows illustrates the basic CN scenarios as available in the current software version. On the transition between ATM based AN and TDM based CN transcoding must take place. For pure TDM calls tandem free operation (TFO) is applicable.
A50016-D1112-V41-2-7618
DRAFT
109
Information System
2G RAN
Partner PLMN #) Transcoding
PSTN/ISDN 2G VMSC ATM TDM GMSC 3G RAN
TDM
Partner PLMN
TFO *)
TDM Partner PLMN
PSTN/ISDN
2G RAN
Legend: Transcoding: AMR ATM/AAL2 <--> A-law TDM/64 kbit/s *) for 2G RAN to 2G RAN or 2G RAN to Partner PLMN #) Special POI: Iu/Nb user protocol must be used exclusively as Framing Protocol 3G RAN Transcoding #) Partner PLMN
ATM
3GVMSC
ATM TDM GMSC
3G RAN
#) Partner PLMN Transcoding CN, CS domain (CNcs)
TDM Partner PLMN
PSTN/ISDN
2G RAN
Fig. 4.16
TDM/ATM interworking aspects for an TDM based CN
110
DRAFT
A50016-D1112-V41-2-7618
Information System
Fig. 4.17 shows the CN scenarios on an ATM based CN. Transcoder free operation (TrFO) (refer to section 4.12.4) is available for 3G CN. The TDM traffic from any source can be compressed transported over the ATM backbone CN.
Partner PLMN 3G RAN TrFO #)
ATM
3GVMSC
ATM ATM GMSC
3G RAN
Partner PLMN
Transcoding
TDM Partner PLMN
PSTN/ISDN
2G RAN
Legend: Transcoding: AMR ATM/AAL2 <--> A-law TDM/64 kbit/s TrFO: AMR end-to-end (Iu/Nb user protocol) #) Special POI: Iu/Nb user protocol must be used exclusively as Framing Protocol 2G RAN #) Transcoding 3G RAN Partner PLMN
TDM
2G VMSC
ATM ATM GMSC
PSTN/ISDN Transcoding CN, CS domain (CNcs) TDM Partner PLMN
#) Partner PLMN
PSTN/ISDN
2G RAN
Fig. 4.17
TDM/ATM interworking aspects for an ATM based CN
A50016-D1112-V41-2-7618
DRAFT
111
Information System
ATM in CN QoS considerations Mode restrictions: Tandem free operation (TFO) is not applicable for 2G mobile-to-mobile calls in case of using the compressed mode in the ATM CN. Compressed mode via ATM/AAL2: The Nb interface is able to carry compressed speech traffic from any type of supported RAN or traffic (Tab. 4.1). Type of trafc 3G RAN 2G RAN Inter network FS own PLMN Tab. 4.1 Compressed mode applicable Yes Yes Yes Yes
Applicability of compressed speech mode dependent of type of trafc
To do so, the incoming speech traffic is compressed once again (except 3G RAN derived traffic transcoder free operation (TrFO) takes place if applicable). Therefore, this MSC internal mechanism is similar to external transmission equipment allowing compression such as a digital circuit multiplication equipment (DCME). In difference to that an AMR mode is used for compression, preferable the one with the highest bit rate due to less reduction of speech quality. Control of compressed mode: Within the ATM in CN leg any AMR mode is selectable. Refer to section 4.12 for more information how to control compressed/uncompressed mode. Benefit of the compressed mode mechanism is a notable bandwidth gain. The needed bandwidth within the CN is reduced about 4 times compared to the traditional TDM CN, if all CS traffic is routed over ATM/AAL2.
112
DRAFT
A50016-D1112-V41-2-7618
Information System
4.4
Signaling Congurations
Tab. 4.2 shows the different possible types of signaling backbone networks, which are available in general. Narrow-band n*64kbit/s and high-speed link (HSL) configured signaling network connections are standard at the present. N*64kbit/s signaling links on a granularity base of single 64 kbit/s channels and E1 links are available for all (CS as well as PS) SSNC based network elements. Furthermore there is the possibility to use SCTP/IP based transport for SS7 based signaling (SSNC is mandatory for SCTP/IP usage). Mode I Narrowband (TDM) Mode IIa HSL (TDM) Mode IIb HSL (restricted ATM) Mode III Broadband (ATM) Mode IV Broadband (IP)
MTP user (SCCP/TCAP, MAP, ISUP/BICC, ...) MTP-L3 MTP-L2 MTP-L1 E0 (64 kbit/s) transparent MTP-L3 MTP-L2 MTP-L1 E1 SAAL (1984 kbit/s) AAL5 MTP 3B M3UA SCTP IP Ethernet
cell mapping cell mapping to SDH (STMto PDH (E1) 1) n*64 kbit/s channelized in PCM30 Tab. 4.2 gross 2 Mbit/s in PCM30 gross 2 Mbit/s in PCM30 gross 155.50 Mbit/s in STM-1 100BaseT, ...
Signaling network types in the CN
4.4.1
Mode of Operation within the CN

The PLMN operator defines which destination is to be reached with which protocol as far as available for a determined interface. There is no affect from the signaling user on the choice which transmission type (mode I to IV) has to be selected within the CN. This is in difference to the RAN-side related signaling mode. There, the mode, e.g., 64 kbit/s signaling channel for the A interface, is part of the regarding interface definition. For several OEM network elements in the CN as it is e.g., a voice mail service center (VMSC) or a short-message-service service center (SMS-SC) the to be used signaling mode is defined by mode capabilities of this OEM network elements. 64 kbit/s signaling channels Traditional method to link SS7 based network elements to each other and for interworking with PSTN/ISDN as well as other PLMNs. Granularity is a single 64 kbit/s channel of a PCM system is valid (for packet-switched (PS) node exclusively SS7 signaling occurs).
A50016-D1112-V41-2-7618
DRAFT
Benefit is the reliable and secure transport by least delay over the TDM based network. This signaling network type corresponds with mode I of Tab. 4.2.
113
Information System
High-speed signaling links (HSL interface) Since the level 3 protocol of the message transfer part (MTP) restricts the number of SS7 links between two adjacent network nodes to 16, the maximum possible SS7 bandwidth is currently 16 times 64 kbit/s on conventional narrow band basis per signaling point (SP). The high-speed signaling links (HSL) feature offers the possibility of utilizing the maximum possible transmission rate of a PCM30 system for a single SS7 link. For a PCM30 system this means that the maximum SS7 bandwidth between adjacent network nodes increases from 1 Mbit/s (equal to 16*64 kbit/s) to gross 32 Mbit/s (equal to 16*2 Mbit/s, more exactly 16*1984 kbit/s) in case of PCM30. Another possibility to overcome this restriction is the use of multiple SPC handling as described in section 4.4.2 below. The usage of HSL for CN node interconnections requires HSL support also from the partner node. All network elements that are SSNC based like MSC/VLR or HLR for example are appropriate partners. HSL is therefore a method, which allows capacity increase primary between signaling transfer points of existing, or new to build SS7 overlay networks within traditional PDH environment. The fractional ATM mode is not supported. That means, it is not possible to split a PCM link into n*64kbit/s channelized signaling links, e.g., channel 1 to 10 and configure the remaining channels 11 to channel 31 (in case of a PCM30 link) as HSL. In addition to the extended bandwidth the same benefit as mentioned for the 64 kbit/s signaling channel is valid. Two variants on E1 basis are available: Firstly, the ITU-T based variant (Q.703/Annex A) where the MTP-L2 has been modied to enable full-net bandwidth usage of a PDH/E1 (PCM30) link. This signaling network type corresponds with mode IIa of Tab. 4.2. Secondly the Telcordia/Bellcore dened variant (GR-2878-CORE) where the ATMbased signaling ATM adaptation layer (SAAL) replaces the conventional MTP L2 protocol. The SAAL ATM cells are packed directly into the PCM30 frames for transmission over the PDH/E1 (PCM30) links. This signaling network type corresponds with mode IIb of Tab. 4.2. Broadband a) ATM/AAL5 based: This type enables the set-up of signaling links within ATM backbones or on ATM links, that is, SDH/STM-1 frame congured directly between network elements. QoS, which means loss less transport of signaling messages within dened time appropriate for SS7 signaling, is guaranteed by the QoS principles offered by ATM. The scalability of the signaling link bandwidth per AAL5 depends on the ability of each involved network node element. All SSNC based network nodes (e.g., MSC/VLR) are able to in/decrease the bandwidth within single 64 kbit/s steps (e.g., 128 kbit/s, 192 kbit/s, 256 kbit/s, ). This signaling network type corresponds with mode III of Tab. 4.2. Regarding basic ATM principles refer to section 4.3.3.1. b) SCTP/IP based: This type would allow SS7 access (e.g., INAP/CAP, ISUP) to servers (e.g., SCP/CSE, HLR) over an IP network. The conversion between traditional SS7 addressing mechanism and the IP related addressing principles is an integrated part of the SSNC. The MTP-3 user adaptation layer (M3UA) represents an intermediate layer between SCTP and MTP-3 users. This ensures the seamless operation of local
114
DRAFT
A50016-D1112-V41-2-7618
Information System
user parts, such as SCCP, that rely on MTP-3 functionality. This signaling network type corresponds with mode IV of Tab. 4.2. Regarding QoS aspects refer section 4.3.3.
4.4.2
SS7 Network Addressing

According to the ITU recommendations, the handling of a maximum of 4 SS7 networks in parallel (two national and two international) is supported. The possibility to support a maximum of 32 internal SS7 networks in addition to the mentioned above is available (Fig. 4.18). These multiple SS7 networks are pure network node internal images. That means every SS7 network node internally handles a total number of 32 SS7 networks in parallel. These internal networks are mapped for external signaling to any of the four standard networks. Therefore, within the network all signaling related messages operate with the maximum of four different networks as defined by ITU-T. Seen from a higher network point of view it allows a more clearly arranged signaling network structure.
CN node/ STP SSNC SS7 Network 1 Operator A
SS7 Network n
Operator X
SS7 Network 32
Fig. 4.18
Multiple SS7 networks
A50016-D1112-V41-2-7618
DRAFT
The feature multiple SPCs are available in addition. Up to 255 origination point codes (OPC) can be administered in one network node. This means that a network node can be identified by up to 255 different point codes. These point codes can be arbitrarily distributed among the 32 MTP networks as mentioned above. Fig. 4.19 shows how the networks are separated in a CN node. It also shows that interworking between the internal networks is possible via user parts or SCCP.
115
Information System
CN node
Network 13 ITU-T national network 0 SPC 3
MTP
Network 1 ITU-T international network 0 SPC 10

k2 Networ ational ITU-T n 0 network SPC 11
Network 5 UP/ SCCP ITU-T national network 0 SPC 3

Networ
Network 7 ITU-T national network 0 SPC 2
k9 ITU-T n ational network 0 SPC 1
Fig. 4.19
Multiple SS7 networks and multiple SPCs in the CN node
For call oriented SS7 message routing (e.g., ISUP/BICC) the multiple SPC handling works for incoming and outgoing signaling access to the one physically network node. For non-call related handling incoming signaling messages (e.g., SCCP, TCAP) addressed to different signaling point codes (one primary and different secondary point codes) within the one physical node are possible. For routing of outgoing messages only the primary point code is usable. Basic advantage is that changes within the SS7 network (modification of signaling point codes) is simplified and reduces the impact on routing databases of the single nodes within the CN.
116
DRAFT
A50016-D1112-V41-2-7618
Information System
4.5
Basic Functions of Call Handling - for Trafc over TDM CN

Basic functions of call handling are used for a call setup between a mobile subscriber and another subscriber in a PSTN, an ISDN, a PSDN or another mobile subscriber of the same or another PLMN. Here each call is characterized by a basic telecommunication service (bearer service or teleservice) and possibly one or more supplementary services. The basic telecommunication services define whether or not the call is to be set up as a speech or data service. A distinction is made between two basic call types: Mobile-originated call (MOC) Mobile-terminated call (MTC). A special case based on the two basic types of call is also possible: Mobile-to-mobile call (MMC). All mobile subscribers are also provided with handling functions for IN/CAMEL applications (e.g., pre-paid service).
A50016-D1112-V41-2-7618
DRAFT
117
Information System
4.5.1
Mobile-Originated Call (MOC)

MOCs are outgoing calls from an MS to other networks. With normal call setup, the call is routed in accordance with the dialed digits. In the case of an emergency call (as a special MOC), the call can be routed to the nearest emergency call center in accordance with the location mark number (LMN) stored in the MSC network element. An MSC network element function trunk reservation for special destinations is available for this. Call procedure A location registration, that is, an authentication must take place at the start of an MOC. 1. The MS sends the call setup information dialed by the mobile subscriber to the MSC network element. 2. The MSC network element requests call information (in the main relating to possible relevant restrictions) from the VLR network element via the mobile subscriber identied with the IMSI. 3. If the MSC network element is equal to a GMSC, the MSC network element sets up the call to the xed network exchange (Local Exchange, LE) after allocation of a trafc channel and from there to the called subscriber in the xed network. If the MSC network element is not equal to a GMSC, the MSC network element sets up the call to the gateway exchange (GMSC) after allocation of a trafc channel, and subsequently to the xed network exchange (Local Exchange, LE) and from there to the called subscriber in the xed network Fig. 4.20 shows the call procedure of an MOC to a fixed network subscriber in the circuit-switched domain of CN.
Calling mobile subscriber (MS) PLMN 1
RAN elements
RAN CN
Called subscriber 3 LE
VLR
MSC (GMSC)
Fixed network (e.g., PSTN/ISDN)
118
DRAFT
Fig. 4.20
Call procedure of an MOC to a fixed network subscriber in the circuitswitched domain of CN
A50016-D1112-V41-2-7618
Information System
4.5.2
Mobile-Terminated Call (MTC)

MTCs are incoming calls to a mobile station (MS) from other networks. The calling subscriber does not need to know the current location of the mobile subscriber for an MTC. The mobile subscriber is accessible everywhere in the PLMN by dialing his directory number (MSISDN) as for a subscriber in the PSTN. The mobile-specific functions of mobility management interrogation, paging and searching are used exclusively with an MTC. Interrogation An interrogation takes place in the case of an MTC. If a call has its origin in the same PLMN, the interrogation procedure is started by the originating MSC network element, otherwise (call origin in the xed network) by Gateway MSC (GMSC). In the case of an international call (from one PLMN to another PLMN), an international interrogation can be performed from the originating GMSC. Paging Paging is only used with an MTC. It serves to determine the radio cell in which the mobile subscriber is currently located with the aid of the location area code (LACOD). In addition to the determination of the radio cell, a signaling connection to the MS is set up at the same time. Searching Searching is used for an MTC when the radio cell in which the mobile subscriber is currently located is determined without the LACOD being available. Thus, paging is performed in all radio cells in all location areas that belong to the visited MSC. Fig. 4.21 shows the call procedure of an MTC (with call origin in the fixed network) within the circuit-switched domain of CN. Call procedure 1. A call for a mobile subscriber arrives at the GMSC. 2. With the aid of the dialing information (MSISDN), the GMSC determines the HLR and sets up a signaling connection to it (interrogation). 3. The HLR sends a request to the VLR function in the MSC network element in whose location area the called mobile subscriber is currently located. 4. The VLR network element sends the required mobile subscriber roaming number (MSRN) back to the HLR. The HLR passes on the LACOD to the GMSC. 5. Based on the MSRN, the GMSC sets up the call to the MSC network element, that is, the MSC network element in whose area the mobile subscriber is located at that time. 6. Because the MSC network element does not know the mobile subscriber up to this point, the MSC network element requests the mobile subscriber information from its VLR network element for the call setup. 7. The MS is called by paging all RAN network elements of the location area, because the radio cell in which the MS is located is not known to the MSC network element. 8. This information is passed to the MSC network element in response to the paging. 9. Finally, the call to the MSC network element is set up.
A50016-D1112-V41-2-7618
DRAFT
119
Information System
Called mobile subscriber (MS) 7 RAN elements 8 9 RAN elements
PLMN
RAN elements
7 RAN CN
6 VLR MSC
4 HLR
3 5 2 GMSC 4 1 Calling subscriber
Fixed network (e.g., PSTN/ISDN)
Fig. 4.21
Call procedure of an MTC (with call origin in the fixed network) within the circuit-switched domain of the CN
4.5.3
Mobile-to-Mobile Calls (MMC)

Mobile-to-mobile calls (MMC) (and mobile intern calls (MIC) as a special MMC) are outgoing calls from a mobile station (MS) which are received at another MS. If the MS at which the call is received is connected to another MSC network element in the same PLMN, it is a mobile-to-mobile call (MMC). If the MS at which the call is received is connected to the same MSC network element as the MS from which the outgoing call is made, it is a mobile intern call (MIC). With an MMC or MIC, the calling subscriber (as in the case of the MTC) does not need to know the present location of the called mobile subscriber. Both types of calls are made up of an MOC-half and an MTC-half. Call procedure (intra PLMN case) 1. The MS sends the call setup information (MSISDN) dialed by the mobile subscriber to the MSC1 network element. 2. The MSC1 requests mobile subscriber information from the VLR1 functionality of the MSC1.
120
DRAFT
A50016-D1112-V41-2-7618
Information System
3. The MSC1 determines the HLR from the dialing information (MSISDN) and establishes a signaling connection to it (interrogation). 4. The HLR transmits a request to the VLR2 functionality of the MSC2 network element where the called mobile subscriber is located at that time. 5. The VLR2 functionality of the MSC2 network element sends the requested mobile subscriber roaming number (MSRN) back to the HLR. The HLR forwards the MSRN to the MSC1 network element. 6. Based on the MSRN, the MSC1 network element sets up the call to the MSC2 network element in whose area the called mobile subscriber is located at that time. Steps (7) to (10) are the same as steps (6) to (9) in Fig. 4.20 and Fig. 4.21. Fig. 4.22 shows the call procedure of an MMC in the circuit-switched domain of CN.
Calling mobile subscriber (MS) 1
Called mobile subscriber (MS) 8 RAN elements 9 10 RAN elements
RAN elements
RAN elements
1 RAN CN VLR1 2 MSC1
10
VLR2
MSC2
4 3 HLR 5
PLMN
Fig. 4.22
Call procedure of an MMC in the circuit-switched domain of CN
A50016-D1112-V41-2-7618
DRAFT
121
Information System
4.5.4
Calls to IN/CAMEL applications

The CN allows all mobile subscribers connected to and managed in the MSC/VLR access to IN/CAMEL services. With an MOC, MTC or MMC of a PLMN mobile subscriber, the IN/CAMEL service can be accessed in the M-SSP network node by means of the IN/CAMEL trigger function. Each IN/CAMEL service is given a trigger profile by the administration, that is, a data record which uniquely assigns entries to IN/CAMEL services in the SCP/CSE. Call procedures (for most subscriber-specific IN/CAMEL services for mobile subscribers)
1. Example: The mobile subscriber is roaming inside the HPLMN and has a subscription to a CAMEL service.
In the case of subscription, a CAMEL service mark (CSI) is provided in the VLR by the HLR during a location update (for an MOC) and during an HLR interrogation (for an MTC). 1. The IN/CAMEL service request is made within the context of call setup by internally setting the CAMEL service mark (CAMEL subscription information, CSI). 2. The originating CSI (O-CSI) in the VLR indicates that the call setup process is suspended and an initial contact with the SCP/CSE is made. The call setup phase causes the M-SSP to trigger, that is, an IN/CAMEL service is recognized. The M-SSP checks whether or not the IN/CAMEL service is supported and activated. 3. The M-SSP initiates the transaction (SCCP) dialog to the SCP/CSE using the 3GPP CAP protocol. The service key and the SCP/CSE address (stored in the CSI) are used for routing and transmission to the SCP/CSE. 4. The SCP/CSE interrogates the database and handles the complete service logic. The SCP/CSE sends the result of its database interrogation to the M-SSP. 5. On the basis of the information that it obtains from the SCP/CSE, the M-SSP executes normal routing, generally with the originally dialed directory number and continues with the call setup to the called subscriber. Fig. 4.23 shows an example of an MOC call procedure for a subscriber-specific IN/CAMEL service for a mobile subscriber roaming in the HPLMN.
122
DRAFT
A50016-D1112-V41-2-7618
Information System
PLMN Calling mobile subscriber (MS) 1 RAN elements RAN 2 M-SSP Called subscriber 3 4 HLR SCP CN 5
SMP
IN
Fig. 4.23
MOC call procedure to IN/CAMEL applications when a mobile subscriber is roaming inside the HPLMN
2. Example: The mobile subscriber is roaming outside the HPLMN and has a subscription to a CAMEL service.
In the VLR, a CAMEL service mark CSI is provided during the location update of HLR (for an MOC) in the case of subscription and the HLR interrogation (for an MTC). 1. The IN/CAMEL service request is made within the context of call setup by internally setting the CAMEL service mark (CAMEL subscription information, CSI). 2. The originating CSI (O-CSI) in the VLR indicates that the call setup process is suspended and an initial contact with the home SCP/CSE is made. The call setup phase causes the M-SSP to trigger, that is, an IN/CAMEL service is recognized. The MSSP checks whether or not the IN/CAMEL service is supported and activated. 3. The M-SSP initiates the transaction (SCCP) dialog to the SCP/CSE using the 3GPP CAP protocol. The service key and the home SCP/CSE address (stored in the CSI) are used for routing and transmission to the home SCP/CSE. 4. The SCP/CSE interrogates the database and handles the complete service logic. The SCP/CSE sends the result of its database interrogation to the visited M-SSP. 5. On the basis of the information that it obtains from the home SCP/CSE, the visited M-SSP executes normal routing, generally with the originally dialed directory number and continues with the call setup to the called subscriber.
A50016-D1112-V41-2-7618
DRAFT
Fig. 4.24 shows an example of an MOC call procedure for a subscriber-specific IN/CAMEL service for a mobile subscriber roaming outside the HPLMN.
123
Information System
SCP/CSE 3 2 M-SSP
HLR
M-SSP
Home PLMN (HPLMN)
Visited PLMN (VPLMN)
Fig. 4.24
MOC call procedure to IN/CAMEL applications when a mobile subscriber is roaming outside the HPLMN
Specifics of subscriber-specific IN/CAMEL services for mobile subscribers In the case of subscriber-specific IN/CAMEL services for mobile subscribers, distinctions are made between IN/CAMEL services for MOC and for MTC. These services have to be assigned for a defined mobile subscriber in the HLR. Accordingly, there are different sequences for entering the IN/CAMEL triggering for IN/CAMEL services in the case of MOC and MTC. IN/CAMEL services for MOC (O-CSI used) In the case of an MOC, an IN/CAMEL trigger point for transfer to the IN/CAMEL service is reached by evaluating the O-CSI in the VLR network element (the O-CSI is part of the subscriber data sent to the VLR during location update). With the aid of the service key and the SCP/CSE address contained in the O-CSI, the trigger prole corresponding to the requested service is identied and an SCCP connection is set up to the SCP/CSE to determine further processing of the call request. As additional information, the subscriber location, for example, can be sent to the SCP/CSE. A possible result of this IN dialog can be another directory number to which the call is set up, or the order to set up the connection to the directory number that was dialed originally. The SCP/CSE can also send an order to release the call, e.g., if the account of a subscriber with prepayment of charges is exhausted. IN/CAMEL services for MTC (T-CSI-based) In the case of an MTC, the MSC network element carries out an interrogation of the HLR. The HLR retrieves the T-CSI of the subscriber from its database and checks whether information concerning the location and/or the status of the subscriber is requested from the VLR network element during interrogation (this is administrable for subscribers marked by a T-CSI). Taking these parameters into account, the appropriate information is requested from the VLR network element and sent together with the T-CSI (and, if available, the O-CSI) to the MSC network element. The MSC network element evaluates the service key and the SCP/CSE address contained in the
124
DRAFT
A50016-D1112-V41-2-7618
Information System
T-CSI and sets up an SCCP connection to the SCP/CSE, to determine further processing of the call request.
4.5.5
Optimal Routing
This feature consists of three parts: Optimal routing of mobile-to-mobile calls Optimal routing of early call forwarding Optimal routing of late call forwarding All three parts are network features defined by 3GPP. The following terms are used in this context: A-subscriber / B-subscriber: calling subscriber / called subscriber C-subscriber: the call is forwarded to this subscriber by the B-subscriber VPLMN / HPLMN: visited PLMN / home PLMN VMSC: visited MSC GMSC: the MSC starting mobile interrogation Optimal routing of mobile-to-mobile calls (ORMMC) ORMMC is a network feature which enables the mobile subscriber A calls to be routed directly to another B mobile subscribers current location without going through the home PLMN (HPLMN) of the B-subscriber (Fig. 4.25).
Without optimal routing a call between two mobile subscribers, who are roaming in the same foreign country, is first routed to the home PLMN and then back to the visited PLMN (VPLMN) of the foreign country. With optimal routing of mobile-to-mobile calls the call is routed directly to the B-subscriber without the HPLMN. Therefore, the GMSC of the visited country (visited PLMNA) is making an international interrogation to the HLR of the home country of the called B mobile subscriber (HPLMN-B), which delivers the roaming number to the interrogating GMSC if the requirements for optimal routing are fulfilled. Afterwards, the GMSC establishes the call directly to the called mobile subscriber (visited PLMN-B). There is no need for optimization of the routing of calls originally directed to a fixed network subscriber, because the physical address of a fixed network terminating line cannot differ from its logical address.
A50016-D1112-V41-2-7618
DRAFT
125
Information System
Country Y Country X HPLMN-B (GMSC-B/HLR-B)
VPLMN-A/IPLMN (VMSC-A/GMSC-A)
VPLMN-B (VMSC-B/VLR-B)
Calling mobile subscriber (A-subscriber)
with opt. routing without opt. routing
Called mobile subscriber (B-subscriber)
Fig. 4.25
Principle of optimal routing of mobile-to-mobile call (speech path)
The requirements for optimal routing consists of rstly, a check if the B-subscriber is a mobile subscriber, secondly, if the optimal routing feature is supported and nally, the country code (CC) check, which checks the roaming number against the CC of the GMSC-A and the home PLMN-B. Optimal routing is only allowed if the B-subscriber is located: either in the same country as the A-subscriber is roaming, which is not the home country of the B-subscriber (that is, the country code of the visited PLMN-A and visited PLMN-B are identical, or in his home country while the A-subscriber is located in a different country (that is, the country code of the visited PLMN-B and the home PLMN-B are identical).
Call procedures/message flows: (Fig. 4.26)

1. A roaming mobile subscriber sets up a call in the VMSC-A that routes it to the GMSC-A. 2. If the GMSC-A recognizes the B-subscriber address as belonging to a PLMN (Bsubscriber mobile), it checks the identity of home PLMN-B. 3. If GMSC-A is in a different PLMN from HLR-B (visited PLMN-A not equal home PLMN-B), it starts an (international) interrogation by sending a request for routing information (SRI) to HLR-B; this request contains an indication that it is an optimal routing inquiry. Also a check if optimal routing is allowed in the GMSC is performed. If HLR-B is prepared to accept an optimal routing inquiry from GMSC-A, it checks whether at least one of the three conditions is fullled. the GMSC is in the same country as visited MSC-B the HLR is in the same country as visited MSC-B the GMSC is in the same PLMN as the HLR 4. If the check is positive, HLR-B sends a request for provide roaming number (PRN) to VLR-B. The request contains an indication that it is a request for an optimally routed call.
126
DRAFT
A50016-D1112-V41-2-7618
Information System
5. If the VLR-B supports optimal routing, it returns the roaming number. 6. The HLR-B returns the roaming number further to the GMSC-A. 7. Then the GMSC-A sets up the call to visited MSC-B using the roaming number and MSC-B continues the normal call routing to the called mobile subscriber B.
Home PLMN B (HPLMN-B) HLR-B
GMSC-B
Country Y
Country X
4 3 Calling mobile subscriber (A-subscriber) VMSC-A 1 2 GMSC-A 6 7 Called mobile subscriber (B-subscriber)
VMSC/VLR-B
Visited PLMN A (VPLMN-A) --> interrogating PLMN (IPLMN)
Visited PLMN B (VPLMN-B)
Fig. 4.26
Message flow for optimal routing of mobile-to-mobile calls
Optimal routing of early call forwarding (ORECF) -during mobile terminating callsIf a call forwarding to a mobile or wireline C-subscriber (forwarded-to subscriber) is detected during interrogation it is called early call forwarding. ORECF occurs when the called mobile subscriber has subscribed call forwarding unconditional (CFU) or call forwarding on mobile subscriber not reachable - IMSI detached (CFNRc) because then the HLR-B delivers the forwarded-to number instead of the roaming number and the call is established directly without routing to the home PLMN of the B-subscriber. Instead of the roaming number, the forwarded-to number is checked to fulfil the optimal routing requirements. Early call forwarding is defined as a call forwarding from the visited (and interrogating) PLMN-A before the call has been extended to the visited PLMN-B of the forwarding subscriber. CFU and CFNRc, when the forwarding mobile subscriber is IMSI detached, are examples of early call forwarding. In these cases no paging is performed (Fig. 4.27).
A50016-D1112-V41-2-7618
DRAFT
127
Information System
Country Y Country X HPLMN-B (GMSC-B/HLR-B)
VPLMN-A/IPLMN (VMSC-A/GMSC-A)
Any country
Calling mobile subscriber (A-subscriber) Forwarded-to subscriber (C-Subscriber) (mobile or fixed) with opt. routing without opt. routing VPLMN-B (VMSC-B/VLR-B) Called mobile subscriber (B-subscriber)
Fig. 4.27
Principle of optimal routing of early call forwarding -during mobile terminating calls- (speech path)
Optimal routing is only allowed if the C-subscriber (wireline C-subscriber or HPLMN of mobile C-subscriber) is located: either in the same country as the A-subscriber is roaming, which is not the home country of the B-subscriber. or in the home country of the B-subscriber while the A-subscriber is located in a different country.
Call procedures (message flows):

The handling within GSMC-A is the same as for ORMMC (see also Fig. 4.26). a) If the HLR-B determines that the call has to be forwarded without need to signal to VLR-B then HLR-B returns the forwarded-to number (FTN). This happens in case of call forwarding unconditional (CFU). b) If the HLR-B determines that the call has to be forwarded with need to signal to VLRB (call forwarding on mobile subscriber not reachable (CFNRc) - that is, IMSI detached) the HLR-B sends a request for provide roaming number (PRN) to VLR-B with the indicator that it is an optimal routing inquiry. If the B-mobile subscriber is IMSI detached, VLR-B indicates this in PRN negative response with the result absent subscriber. If the CFNRc should be invoked, HLR-B returns the FTN in send routing information (SRI) acknowledge message. GMSC-A checks the forwarded-to number against the calling party. c) If the GMSC-A determines that the call can be forwarded without contravening the optimal routing charging requirements (see above) it sets up the call using the FTN and routes to GMSC of the C-subscriber (forwarded-to subscriber), which continues the normal call routing.
128
DRAFT
A50016-D1112-V41-2-7618
Information System
Optimal routing of late call forwarding (ORLCF) - during mobile terminating calls If a call forwarding to a mobile or wireline C-subscriber (forwarded-to subscriber) is detected during in the VMSC-B it is called late call forwarding. The feature ORLCF enables to forward the call at the GMSC instead of at the VMSC-B. Therefore, the speech connections to the VMSC-B are reduced. Late call forwarding is defined as a call forwarding after the call has been extended to the visited PLMN of the forwarding subscriber. CFB, CFNRc on no response to paging and CFNRy are examples of late call forwarding (Fig. 4.28).
Without optimal routing calls which have to be forwarded due to a conditional call forwarding are forwarded at the VMSC-B of the served subscriber (except in case of CFNRy with IMSI detach and in case of CFB during recall, which takes place in the GMSC). The roaming leg remains even the call is forwarded back to the GMSC area. So the speech path remains through connected for both the roaming leg and the call forwarding leg. This caused a seizure of two speech connections to the VMSC-B although the call is routed back to the GMSC area.
Country X
HPLMN-B (GMSC/HLR-B) Calling subscriber (A-subscriber)
Country Y
Forwarded-to subscriber (C-subscriber) (mobile or fixed)
VPLMN-B (VMSC-B/VLR-B) Called mobile subscriber (B-subscriber)
with opt. routing without opt. routing
Fig. 4.28
Principle of optimal routing of late call forwarding -during mobile terminating calls- (speech path)
Optimal routing is only allowed if the C-subscriber (wireline C-subscriber or HPLMN of mobile C-subscriber) is located: in the same country as the GMSC or in the same country as the B-subscriber is roaming or in the home country of the B-subscriber
Call procedures/message flows: (Fig. 4.29)
A50016-D1112-V41-2-7618
DRAFT
1. A mobile terminating call (MTC) receives the GMSC. 2. Then the GMSC launches an interrogation to the HLR-B to get a roaming number with the message send routing information (SRI). In the SRI the optimal routing ca-
129
Information System
3.
4. 5. 6.
7.
8.
pability ag is set to indicate, that the GMSC supports optimal routing. Additionally, the call reference number (CRN) is also included in the SRI. If the HLR-B supports optimal routing then it sends a provide roaming number (PRN) to the VMSC-B additional with a specic indication, the GMSC address and the CRN. The VMSC-B responds to the HLR-B with a PRN return (PRN-R) message. The HLR-B responds to the GMSC-B with an SRI return (SRI-R) message including the roaming number. The GMSC constructs a setup message using the roaming number and sends it to VMSC-B. When the VMSC-B recognizes that the call should be forwarded because of CFNRc, CFNRy or CFB then the VMSC-B checks if the GMSC supports optimal routing and the call can be forwarded by the GMSC. Therefore, the VMSC-B sends a new MAP message resume call handling (RCH), which contains the forwardedto number (FTN), the forwarding reason and further parameters like IMSI and CRN to the GMSC (if the GMSC supports optimal routing). When the GMSC receives the RCH message it checks if optimal routing is supported by the GMSC and if charging requirements for optimal routing (see below) are fullled. Then The GMSC checks if optimal routing is allowed with the received FTN. If the ORLCF should be done, then the GMSC sends a corresponding MAP message resume call handling return (RCH-R) back to the VMSC-B indicating that control of the call has been accepted and releases the roaming leg between the GMSC and the VMSC-B. When the roaming leg is released by the GMSC all resources are released in the VMSC-B and the VMSC-B is not anymore involved in this call. The GMSC constructs a setup message using the FTN and sends it to the C-subscriber.
130
DRAFT
A50016-D1112-V41-2-7618
Information System
Visited PLMN B (VPLMN-B)
VMSC/VLR-B
Called mobile subscriber (B-subscriber)
6; 7 Country Y 4
Country X 1 GMSC Calling subscriber (A-subscriber) 2 8 Home PLMN B (HPLMN-B) 5
HLR-B
Forwarded-to subscriber (C-subscriber) (mobile or fixed)
Fig. 4.29
Message flow for optimal routing of late call forwarding -during mobile terminating calls-
Charging requirements for optimal routing Optimal routing of mobile-to-mobile calls is a network feature which enables the calls of mobile subscriber A to be routed directly to another B mobile subscribers current location (without going through the HPLMN of the B-subscriber). The 3GPP standard recommends to apply the following charging requirements: No subscriber is to be pay more for a call which has been optimally routed than he would do under the present routing scheme. At least for the rst phase of support of optimal routing, the charge for one leg of a call is to be paid for entirely by one subscriber. These requirements are followed with simpler criteria for deciding whether the direct route can be used: If the country code (CC) of the destination exchange and the CC of the GMSC are the same, then the direct route can be used; Otherwise, for a call leg which is chargeable to the A mobile subscriber, if the CC of the destination exchange and the CC of HPLMN-B are the same, then the direct route can be used; Otherwise, the HPLMN route is to be used.
A50016-D1112-V41-2-7618
DRAFT
131
Information System
For optimal routing of late call forwarding, the constraints are satisfied if the following criteria are applied: If the country code (CC) of the forwarded-to exchange and the CC of the GMSC are the same, then the forwarded call can be routed directly from the GMSC to the forwarded-to exchange; otherwise, if the CC of the forwarded-to exchange and the CC of HPLMN-B are the same, then the forwarded call can be routed directly from the GMSC to the forwarded-to exchange; otherwise, if the CC of the forwarded-to exchange and the CC of VPLMN-B are the same, then the forwarded call can be routed directly from the GMSC to the forwarded-to exchange; otherwise the forwarded call is to be routed through VPLMN-B.
4.5.6
Carrier Routing Call by Call and Preselected

The feature carrier routing allows calls in deregulated networks to be routed via an alternate network operator (carrier). The subscriber selects the carrier by means of a carrier access code (CAC). The carrier access code is evaluated for routing and used for selecting a specific carrier. Mobile subscribers can dial a carrier access code or can use one pre-subscribed interexchange carrier for routing national or international calls. Therefore, the carrier routing solution supports carrier routing call by call (with dialed carrier access code) and carrier routing preselection (with presubscribed carrier access code which is stored in the subscribers data in the HLR database). In total, the CAC applicable for a call can be determined as follows: Dialed CAC The mobile subscriber dials a CAC before dialing the current called B party number. This CAC is then used for routing to the carrier. Preselected CAC With the basic feature, each mobile subscriber with a subscription for the circuitswitched domain can be assigned one preselected CAC called preselected interexchange carrier (PIC). With the two PICs for mobile subscriber extension feature, two PICs can be administered. This means that if no CAC is dialed, this CAC is used for routing to the carrier. Exchange CAC If a mobile subscriber has no CAC dialed and no presubscribed CAC, then the network provider uses a default CAC (exchange CAC). Fig. 4.30 shows examples for carrier routing.
132
DRAFT
A50016-D1112-V41-2-7618
Information System
Network border
Network border
carrier code =xy Carrier xy LN A called B party address: 89 722 12345 (national) 089 722 12345 dials: 01xy - 089 722 12345 010yz-089 722 12345 Carrier yz Carrier xz LN B
Network border Local network (PLMN) (origination) Carrier network Local network (PLMN) (destination)
Fig. 4.30
Carrier routing Additional features Prepaid (IN/CAMEL) subscriber dials CAC This feature enables a prepaid (IN/CAMEL) subscriber to dial a carrier access code (CAC) together with the B-number (CAC + B#) in order to select a carrier network for routing. It is also possible to control the interworking between IN/CAMEL and carrier dependent routing based on the general IN properties. Depending on these properties, it is possible to use or ignore the dialed CAC when routing or releasing the call. Prepaid subscribers cannot have a PIC. This feature is an extension of the two PICs for a mobile subscriber feature (see above). Example: A mobile originating call (MOC) of a prepaid subscriber who has dialed a CAC before the B-number receives a positive response from the SCP, without any new parameters. After an IN dialog, the call continues with the originally dialed number. Gateway MSC (GMSC) authentication via SCP The GMSC authentication via SCP feature enables the GMSC to authenticate the calling subscriber for carrier routing. If a PLMN acts as the carrier network, it can be necessary to check whether the calling subscriber is allowed to use the carrier routing service of their home PLMN. The advantage of this feature is that the SCP provides a large database for authentication. GMSC authentication is performed if the call originates in another PLMN or in the PSTN, and the PLMNs CAC is recognized as part of the received B-number. Example of successful GMSC authentication via SCP: The GMSC of the PLMN is contacted by another PLMN or PSTN. The called party number in the initial address message consists of the GMSC CAC (the PLMNs CAC for this GMSC) and the normal B-number. The GMSC recognizes the PLMNs CAC and triggers an IN dialog with the SCP for authentication. GMSC authentication via SCP can be performed with the calling subscriber number (A1#). In the case of a permitted subscriber (for example, A1-subscriber), the SCP answers positively, and the call is continued normally and routed to the B-number.
A50016-D1112-V41-2-7618
DRAFT
133
Information System
4.5.7
Number Portability for Mobile Subscribers

The feature number portability allows subscribers to change networks without changing their number and local area code (LAC) or national destination code (NDC) (for mobile subscribers this means without changing their MSISDN, but the mobile subscribers IMSI is changed). This feature supports porting fixed network subscribers (PABX subscribers included) and mobile subscribers. Number portability is only allowed within the same country. In the case of mobile subscribers, all the MSISDNs belonging to the mobile subscriber are ported. The voice mailbox number is also ported, but not the short code to access the mailbox.
Porting-in means mobile subscribers and fixed network subscribers can be ported from a foreign network to the individual network by keeping their old number. Porting-out means mobile subscribers and fixed subscribers can be ported-out from the individual network by keeping their old number.
By introducing the number portability functionality in the PLMN, new subscribers from other PLMNs and from fixed networks can be attracted. In particular, the ability to port subscribers from fixed networks to PLMNs by keeping the subscribers number is a possible way of attracting many new mobile subscribers to the PLMN. Owing to number portability, the network of a ported mobile subscriber can no longer be identified by the national destination code (NDC) as being part of the MSISDN. Therefore, additional information is required to set up calls to ported subscribers: the current network or the HLR of a mobile subscriber has to be determined. The methods available for this task are described in the following sections. Methods of number portability database query The QoD and QoHR methods described below use the number portability (NP) database query to identify the current network, the HLR of a ported subscriber. Mobile subscribers have three possibilities of detecting ported subscribers in the database query: Query on digit analysis (QoD).
This method is applicable to call setups to ported-out mobile subscribers and is intended for networks containing a large number of ported subscribers. A specic number range is marked as relevant for QoD in the MSC. The NP database query is initiated immediately when the digit translation indicates that the Bnumber is within a ported number range. In the QoD method, an NP database query is started and the new switch number of the ported subscriber is sent to the requesting switch before the current call setup. By this query the current network, the HLR of a ported subscriber is determined and the call can be completed. If no corresponding entry is found in the number portability database, the originally dialed number is used to continue call setup. It is then assumed that the called number has not been ported. Query on HLR release (QoHR)
This method is applicable to call setups to ported-out mobile subscribers and is suitable for networks with a small number of ported-out mobile subscribers. In the same way as for QoD, a specic number range is marked as relevant for QoHR in the MSC. In the case of an MTC, interrogation of the HLR is started as usual. If the mobile subscriber is not known in the HLR (HLR answers with unknown sub-
134
DRAFT
A50016-D1112-V41-2-7618
Information System
scriber), a number portability database query is performed to determine the current network of the ported-out mobile subscriber. Query on ISUP release (QoR)
This method is applicable to call setups to fixed subscribers of a PSTN ported out to another network as well as to call setups to mobile subscribers from a PSTN (or from another PLMN). QoR is supported when a specific number range is marked as: QoR and ISUP message release with cause value #14 is received, a number portability database query is performed. For mobile originating calls (MOC) from the PLMN to the PSTN, the call is routed from the PLMN to the (former) PSTN network node of the subscriber in the same way as for a non-ported subscriber. The former network node detects that the subscriber is not known and returns a corresponding message (cause value #14) to the Gateway MSC of the PLMN. The Gateway MSC starts a number portability query, that is, a reroute for QoR in the number portability database. The PLMN routes the call to the recipient network. For mobile terminating calls (MTC) from the PSTN (or another PLMN operator) to the PLMN, the PSTN routes the call towards the PLMN that performs a query on the NP database (if QoD or QoHR). If the NP database entry is found (ported-out subscriber), the PLMN sends a release message (cause value #14) to the PSTN. The PSTN performs a second NP database query at ISUP release. If an NP database entry is found (ported-out subscriber), the PSTN routes the call to the recipient network. Routing numbers In order to route a call for a ported-out subscriber to the appropriate network, a network routing number is prefixed to the number of the ported subscriber. National agreements are necessary to introduce unique routing numbers for all networks concerned. HLRs are also identified by special routing numbers which are prefixed to the number of the ported subscriber. By evaluating the modified number, the call can be routed to the appropriate destination. Number portability databases The number portability feature requires number portability database access. All necessary information of ported-in and ported-out subscribers is stored in this database. There is the flexibility to use an Internal (that is, stand alone) NP database MSC/VLR-based internal NP server HLR/AC-based internal NP server External (that is, central) NP database CP switch-based external NP server SCP-based external NP server. An internal NP database is a server integrated in the triggering switch or in the concatenating HLR. This can also be described as a stand alone NP database.
A50016-D1112-V41-2-7618
DRAFT
135
Information System
An external NP database is a server in another external network node, e.g., external CPswitch or SCP node. This can also be described as a central NP database.
Therefore, the PLMN operator can choose the kind of database to be used. If SCPbased external NP server functionality is already introduced and many subscribers are ported, the SCP database should be kept. In this case, a CP switch-based external NP database server is necessary for non-circuit switched calls (that is, SMS). If there are only a few ported subscribers and queries for non-circuit switched calls are possible and IN is not applicable in the PLMN, the internal NP database is recommended. Network architecture of internal and external number portability (NP) databases Internal number portability (NP) database (MSC/VLR-based or HLR/AC-based)
In the internal NP database, types (MSC/VLR-based or HLR/AC-based) as described below, can be queried via SS7:INAP/CAP and SS7:SCCP. The internal number portability (NP) database affects functions in the MSC or HLR only. The MSC internal NP database is queried via an internal procedure call (or via INAP/CAP for calls from other MSCs). The HLR internal NP database is queried via INAP/CAP for circuit-switched calls and SCCP for non-circuit-switched calls. Fig. 4.31 shows the network architecture of an internal number portability (NP) database structure.
INAP/ CAP GMSC NP server MAP VMSC HLR NP server INAP/CAP/ SCCP *) Recipient network
*) in case that the NP server is HLR integrated
Fig. 4.31
Internal number portability (NP) database (MSC/VLR-based or HLR/AC-based)
CP switch-based external number portability database
In the CP, the switch-based external number portability database as described below, can be queried via SS7:INAP/CAP and SS7:SCCP. If a CP switch-based external number portability database is used, the separate CPswitch is also affected. This separate CP switch-based external number portability database also corresponds to a signaling transfer point (STP). Fig. 4.32 shows the network architecture of a CP switch-based external number portability database structure.
136
DRAFT
A50016-D1112-V41-2-7618
Information System
INAP/CAP INAP/CAP GMSC SCCP CP-switch (STP) NP server
Recipient network
MAP VMSC HLR
Fig. 4.32
CP switch-based external number portability database
SCP-based external number portability database
The SCP can be queried via SS7:INAP/CAP by the GMSC/SSP to support circuitswitched calls. If an SCP-based external number portability database is used, the SCP is also affected and the GMSC node has to support the SSP functionality. There are no changes necessary in the SCP to provide the external NP database. Existing service logics in the SCP are able to cover these requirements. Fig. 4.33 shows the network architecture of an SCP-based external number portability database structure.
INAP/CAP INAP/CAP GMSC/ SSP MAP VMSC HLR SCP
Recipient network
A50016-D1112-V41-2-7618
DRAFT
Fig. 4.33 SCP-based external number portability database
137
Information System
Call processing for number portability To support number portability, it is always necessary that ported numbers are transmitted between all networks by means of a routing prefix. Within the individual PLMN only the MSC (including the CP switch-based NP server) and, if IN solution is used, the SCPs are affected. The HLR must be able to handle subscribers with different LACs or NDCs. The principle of number portability is based on the network and CN identification codes. National agreements are necessary to identify a unique network identification code for each network. For example, 0Dxxx is used as the network identification prefix where xxx identifies the network. Network identification codes are necessary to route a call, terminating at a ported subscribers former network, to its new network. CN identification codes are only handled inside the network to identify in which MSC or HLR of the network, the ported subscriber can be found. Both CN and network identification codes are pre-fixed to the number of the ported subscriber to route to the switch or network with the appropriate identification code. After routing the call to this network, the identification code is cut. Call procedures (in the case of the NP server used) The following example shows the sequence of a call setup to a ported directory number (porting-in of subscribers) using the query on digit (QoD) analysis method with originating call in the individual network (Fig. 4.34). 1. A calling mobile subscriber originates a call to a subscriber directory number (here: 089-12345) via a VMSC1 which was ported-in from a xed network to the PLMN and becomes a mobile subscriber (this number is within a ported number range). 2. In order to prevent the call from being routed to the ported-in subscribers former network, the VMSC1 that administers the number range of the called party sends a query to the internal NP server to identify the new location (HLR). For this, the entire called party number must be collected. The internal NP server informs the requesting VMSC1 of the new HLR identity. The new HLR identity (here: E1) prexes the internal NP server to the local area code and the subscriber number (here: E1 08912345) to identify the right HLR of the ported-in subscriber.
For ported-in mobile subscribers the called number is prefixed with the new HLR-ID prex (here: E1); no network identication code for the GMSC is necessary. 3. The VMSC1 routes the call to the GMSC of the recipient network (PLMN) with the help of a prexed network identication code. Because, for ported-in mobile subscribers, the VMSC1 and GSMC are in most cases the same MSC, only a mobile internal call (MIC) is necessary for connection. 4. Subsequently, the GMSC routes the call to the HLR to request an MSRN. There, the HLR ID E1 is removed again. If the ported subscriber has been created in this location (HLR), call setup can be completed successfully. The HLR provides an MSRN to the GMSC. 5. The GMSC completes the call setup to the called subscriber.
138
DRAFT
A50016-D1112-V41-2-7618
Information System
Donor network (here PSTN)
Recipient network (here PLMN)
VMSC1 GW 2 NP server GMSC 3
5 RAN elements LE 1 RAN elements Calling mobile subscriber 5 VMSC2 HLR
Ported subscriber 089-12345 Called mobile subscriber (ported) 089-12345
Fig. 4.34
Call procedures (in the case of internal NP server used) with ported-in number using the query on digit (QoD) analysis method with originating call in individual PLMN
A50016-D1112-V41-2-7618
DRAFT
Additional Features Support of number portability for SMS-MT and CCBS through SCCP routing If the short message service mobile terminated (SMS-MT) and call completion to busy subscribers (CCBS) are to be supported to ported subscribers, the CP-switchbased external NP database architecture is required. In the case of SMS-MT a routing message is sent to the NP database server (not SCP-based server) with the help of an individual translation type or a xed prex in front of the global title. In the NP database, the number portability query is started and the message is routed to the ported subscriber. In the case of CCBS and if a subscriber activates a CCBS request to a ported subscriber, the SCCP message with the CCBS request message is routed through the NP database server where the number portability query is executed. Implementation of the possibility of sending SMS-MOs for ported-in mobile subscribers Only mobile subscribers in their home PLMN are allowed to use their own SMSC to send a short message. Calling party screening is done by MSISDN, but the portability of mobile subscribers enables ported mobile subscribers to keep their old numbers. Therefore, in case of number portability is introduced, it is not possible to screen the calling party by MSISDN. Instead of MSISDN, IMSI is used for the calling party screening because the MCC and MNC are changed to the values of the network where subscriber is ported into.
139
Information System
140
DRAFT
Tone when call is routed to another PLMN Calls within the same PLMN are charged at a lower rate than calls routed to other operator PLMNs. With the introduction of NP, it is now possible for mobile subscribers to retain their MSISDNs even after switching to another PLMN operator. Hence the calling subscriber is no longer able to determine whether the called subscriber belongs to the same network by simply evaluating the MSISDN. For calls outside a subscribers network (e.g., to ported-out subscriber), a different tariff is charged. To make this more transparent, a warning tone is played to calling subscribers if a call is routed outside the home PLMN. IMSI-MSISDN de-coupling using a special HLR-ID NP and multinumbering do not allow the identication of a subscriber based on the MSISDN because ported subscribers keep the old MSISDN of the original network, but it has a new IMSI from the ported-in network. Therefore, de-coupling of the MSISDN and IMSI must be considered. If all ported-in mobile subscribers are registered in one HLR, some HLRs are full with too many subscribers and others are relatively empty. Therefore, to optimize use of HLR resources and planning of the ported-in mobile subscribers, the reservation of the HLR for ported-in mobile subscribers is required. Up to now, the SCP has sent a location routing number (LRN) for the ported mobile subscriber that enables the interrogation of the HLR. If the ported-in mobile subscribers are distributed among different HLRs, it is not possible to determine in which HLR the ported-in mobile subscriber is registered. To solve this problem, the HLR-ID is used. The SCP sends the HLR-ID of the ported-in mobile subscriber instead of the LRN, for example: DDM H1H2H3H4H5, where DD is hexadecimal D, M is the number for the telecommunications operator, and H1H5 are the rst digits of the MSIN. With an HLR-ID, the SCCP triggers an interrogation to the correct HLR. Routing of the USSD call back to the A-subscriber is dependent on the NDC of the called party number Up to now, the prepaid subscriber has been able to use the USSD call back (UCB) feature to set up a call when roaming in another PLMN. The SCP query is necessary to support this feature for the ported-in subscriber because the UCB center cannot set the prex in front of the A-subscriber to indicate that the A-subscriber is portedin. Modied mailbox routing The structure of the mailbox number is: MSISDN = CC + NDC+ XY + SN. The Xvalue is used to trigger subscriber-related routing (see also section 4.8.9, Subscriber-Related Routing of Service Numbers). With the Y-value, the service is assigned to the mobile subscriber. One X-value and up to 10 Y-values are possible (range 0..9). Today, only one service (mailbox) is used in most PLMNs. With the mobile number portability feature, each PLMN operator has to support the mailbox service codes of all foreign networks. Therefore, modied mailbox routing is implemented to handle different service codes. Modied mailbox address format: The subscriber-dependent format is a special format in the service address table. The subscriber number (SN) of the subscriber is appended to the service address, before being returned within the subscriber routing information result message. The resulting number is the target mailbox system address and is in international format: CC+NDC+M1M2M3M4 +SN (16). NDC+M1M2M3M4 is the routing information for the mailbox system. Different MSISDNs can have the same SN (e.g., MSISDN1=176 1234567, MSISDN2=179 1234567). The mailbox system does not support 4-digit NDCs with the current format of the mailbox (CC+NDC+M1M2M3M4 +SN). Therefore, it is necessary that
A50016-D1112-V41-2-7618
Information System
subscribers with a 4-digit NDC are allocated different mailbox system numbers. It is necessary to introduce a new format for the mailbox address. For this purpose, a special NDC (xyz) has been introduced. This enables network-specic routing based on this number. The new format of the mailbox address is: xyz M1M2M3 NDC SN. The rst digit of the subscriber NDC is deleted (NDC'). Using this schema, the NDC' of the subscriber is interpreted by the mailbox system and thus the number is uniquely dened. Short code handling In the case of call forwarding registration using a short code (e.g., 3311), the short forwarded-to number (FTN) is translated into a long FTN (CC NDC XY SN). The value of XY depends on the NDC. Example: if a ported-in mobile subscriber from PLMN1 to PLMN2 with the basic MSISDN = 49 179 1234567 registers for CF with 3311, the following FTN is stored: 49179 331234567. MSISDN assigned over NDC boundaries Ported-in mobile subscribers keep their old number from the foreign network. If the mobile subscriber wants to get an additional number, it is only possible to allocate the number from the number range of the new network. The mobile subscriber now has two or more MSISDNs of different networks with different NDCs. The HLR always stores the MSISDN in the full international format CC + NDC + SN. When creating multinumbering for subscribers, only the SN for the basic service is entered by the Q3/MML parameter. The CC is entered by the project database and the NDC is entered by the Q3/MML parameter. The basic MSISDN of the mobile subscriber is entered by the basic telephony service and the basic national destination code (NDC) is entered by the appropriate Q3/MML command parameter. Call forwarding registration and short code dialing use this information. In the case of short code dialing or registration of a call forwarded-to number, the short code is translated into a service number with the format: ForwToNumber = CC + NDC + XY + SN. The basic NDC and basic SN of the basic MSISDN are always used irrespectively of the basic service. The XY-value is NDC dependent.
4.5.8
Location Services
The location services (LCS) feature is a new radio access network capability which enables the PLMN to determine the geographic location of an MS to use this information in certain location-based applications.
The location services is primarily an RAN-based feature supported by the current RAN software release. Implementation of this feature is the basis for a wide range of new possibilities for optimizing a network such as detection of hot spots, handover performance analysis, hierarchical radio cell system planning, or automatic capacity adjustment. Further potential LCS application categories are listed below.
Value-added services (use LCS to support various commercial services such as information services, tracking services, navigation services). PLMN internal location services are functions which enhance or support certain O&Mrelated tasks or Intelligent Network services, e.g., location-dependent routing, locationdependent (home zone) billing, location-assisted handover. Emergency services determine the position of a mobile subscriber, e.g., for a car breakdown service.
A50016-D1112-V41-2-7618
DRAFT
141
Information System
Location services network architecture Fig. 4.35 shows the location services network architecture for a 2G PLMN and Fig. 4.36 shows the location services network architecture for a 3G PLMN to support the location services of MSs in the circuit-switched mode.
SMLC Lb interface
HLR Lh interface
MS
BTS
SRNC BSC/ TRAU
MSC/VLR
GMLC
LCS client
Um interface
Abis interface
A interface
Lg interface
Le interface
Fig. 4.35
Network architecture for a 2G PLMN to support location services of MSs
HLR RNC MS Iur interface SRNC SRNC (SMLC) MSC/VLR GMLC Lh interface
NodeB
LCS client
Uu interface
Iub interface
Iu interface
Lg interface
Le interface
Fig. 4.36
Network architecture for a 3G PLMN to support location services of MSs
The MSC/VLR contains the functionality responsible for mobile subscriber subscription authorization and for managing call-related and non-call related positioning requests of location services. The MSC is accessible to the GMLC via the Lg interface. The location service functions of MSC are related to charging and billing, location service co-ordination, location request, authorization and operation of the location services.
142
DRAFT
The Serving Mobile Location Center (SMLC) performs a key control function for the introduction of location services (LCS) implemented PLMN subsystems. For a 2G PLMN the SMLC is connected via Lb interface to the BSC. For a 3G PLMN the serving RNC (SRNC) fulfills the LCS functional entity of a serving mobile location center (SMLC) and thus there is no necessity of an external Lb interface. The SMLC and GMLC are con-
A50016-D1112-V41-2-7618
Information System
nected through the visited MSC. The SMLC manages the overall co-originating and scheduling of resources required for the location of an MS. It also calculates the final location estimate and estimates the achieved accuracy. There can be more than one SMLC in one PLMN. SMLC receives location requests from its associated serving BSCs/RNCs and determines the positioning calculation method to be used. This determination is based on the quality of service (QoS) parameters, capabilities of the network, and the MSs own location capabilities. The SMLC calculates the final location estimate and accuracy and returns this data to the requesting serving BSC/RNC.
In the 3GPP Release (Release 4), in 3G PLMN the serving RNC can control a number of location measurement units (LMUs) for the purpose of obtaining radio interface measurements to locate or help locate mobile subscribers in the area that it serves. This is used for the release 4 positioning method observed time difference of arrival (OTDOA) which uses measurement of 3G RAN time framing. The SRNC is administered with the capabilities and types of measurement produced by each of its LMUs. Signaling between an SRNC and LMU is transferred using the Iub interface, sometimes the Iur interface and also the Uu interface for possible stand-alone LMUs. The SMLC reports the location information together with the time of day and the estimated errors of the location of the MS to the client. The client is allowed to specify QoS parameters when requesting the service (e.g., accuracy). The location request message from a client can specify any of the following reporting events: Direct; immediately report the specified MS's current location. The MSs location is specified either by its current cell global identifier (CGI) for 2G and service area identifier (SAI) for 3G or by returning the geographical coordinates of the radio cells center as an estimate of the MSs geographical coordinates. The form of location reporting is specified in the location request message. If CGI/SAI reporting is specified, the location reported is normally the CGI/SAI derived from the cell ID of a radio cell from the MS's active set. If the MSs active set comprises more than one radio cell, then the smallest radio cell is selected to increase the accuracy of the location estimate. If geographical coordinate reporting is specified, the cell ID is determined in the same way as for CGI/SAI reporting and the coordinates of the center point of the selected radio cell are returned as the MS location. The Gateway Mobile Location Center (GMLC) provides external LCS clients with access to the PLMN and its location service capability. There can be several GMLCs in one PLMN. The GMLC stores LCS subscription information on a per-LCS-client basis. It uses this information when receiving an LCS request to identify the requesting LCS client and to authorize it to use the specified request. The GMLC requests information from the HLR of the MS to be located. It uses the subscribers privacy information to verify that the LCS client is allowed to position the MS. The visiting MSC (VMSC) address and international mobile subscriber identity (IMSI) for this MS are used to route the location request to the VMSC currently serving the MS. The GMLC receives the final location estimates and determines whether they satisfy the requested QoS for the purpose of retry/reject. It can transform a received location estimate to local coordinates before sending it to the requesting LCS client. Furthermore, the GMLC generates LCSrelated charging and billing data.
A50016-D1112-V41-2-7618
DRAFT
143
Information System
The LCS client provides the mobile subscriber with location dependent services. It interacts with an LCS server to obtain location information of the MS.
For the LCS in the circuit-switched CN there is also the possibility of a SIEMENS proprietary solution with the help of CAMEL phase 1/phase3 based network elements SCP/CSE in the role of an LCS client. For this see separate CNps documents. There the combined mobility management feature Gs interface extension and CAMEL phase 3 pre-paging are used between circuit-switched domain and packet-switched domain. Positioning method The location information can be requested by (and reported to) a client within the MS, or by a client within or attached to the Core Network (CN). In addition, LCS can be offered without subscription to basic telecommunication services and are applicable to any target MS whether or not it supports LCS. For 2G PLMN there are three positioning methods that can be used in LCS: The standard/enhanced cell identication timing advance (CITA/E-CITA) method The enhanced observed time difference (E-OTD) method for the US market The Global System Positioning (GPS) based method For 3G PLMN there are two positioning method that can be used in LCS: The service area ID (SAI) method The observed time difference of arrival (OTDOA) method The Global System Positioning (GPS) based method
According to 3GPP Release 99, the current LCS implementation for 3G is using the service area ID (SAI) method, offering an accuracy of about 500 m up to 2000 m depending on the radio cell size (that is, more accurate for smaller cell in urban areas). A service area can be an area consisting of one ore more radio cells belonging to the same location area. In case of a service area is equal to one radio cell the SAI identifies a determined sector or antenna of a radio cell in the 3G RAN network. For the 3GPP Release 4 the more accurate positioning method observed time difference of arrival (OTDOA) is implemented on the 3G RAN side. The CN side is able to support both positioning methods. Network positioning procedure The network positioning procedure is triggered by the GMLC. It consists of the following sub-procedures: Location preparation procedure, to verify the privacy restrictions of the mobile subscriber, to reserve network resources and determine the positioning method according to the requested QoS and the capabilities of MS and network. Positioning measurement procedure, to perform measurements from which the position of the MS can be calculated. Location calculation and release procedure, is initiated after the measurements are completed and is concerned with calculating the MSs location, releasing all involved network and/or MS resources and sending the charging information to the CN. The messaging and processes in each sub procedure depend on the source of the location request. According to 3GPP Release 99 and Release 4, the following cases can be distinguished: Mobile terminating location request (MT-LR) The LCS application invokes the positioning procedure and receives the location estimate. Privacy is an issue.
144
DRAFT
A50016-D1112-V41-2-7618
Information System
Mobile originating location request (MO-LR) for self location The MS itself invokes the positioning procedure and receives the location estimate; optionally, the location estimate can also be transferred to a third party. Network induced location request (NI-LR) not yet released for CN The network invokes the positioning procedure autonomously.
4.5.8.1
Mobile Terminating Location Request (MT-LR)

A mobile terminating location request (MT-LR) enables an external location service client to request the location of a specific identified MS. The request is sent first to a Gateway Mobile Location Center (GMLC) where a query is performed to the HLR to obtain the visited MSC address. Then the GMLC sends a request for the MS location to the visited MSC, which obtains the location (from the Serving Mobile Location Center (SMLC)) and returns it to the GMLC. Small extensions of the MT-LR procedure in the MSC/VLR also support provision of the current location for emergency or lawful surveillance. To enable an MS user to control which external location service clients are allowed to receive the MS location via an MT-LR, privacy subscription options are provided in the HLR and downloaded to the VLR. The capability of notification and verification of location by a target MS is subscribed to by an MS user in the HLR and forms an extension to the other LCS privacy options above. When subscribed to, an MT-LR request from a commercial LCS client is not notified of the target MS with the normal notification such as the client identity (e.g., E.164 address) and, if provided by the GMLC, the client name. A notified MS also has the subscription option of verifying to the visited MSC whether or not the location is to be allowed. Call procedure in a 2G PLMN (CN) A mobile terminating location request (MT-LR) is characterized by the fact that the LCS client is external to the PLMN (e.g., fleet management center). This CN subfeature enables an external location service client to request the location of a specific identified MS. 1. An external LCS client requests the current location of a target MS from a GMLC. The GMLC veries the identity of the LCS client and its subscription to the LCS service requested and derives the MSISDN/IMSI of the target MS to be located and the LCS quality of service (QoS) from either subscription data or data supplied by the LCS client. For a call related location request, the GMLC obtains and authenticates the LCS clients called party number. 2. The GMLC sends a request to the home HLR of the target MS to be located with the IMSI/MSISDN of this MS. The HLR then returns the current MSC address for the particular MS. 3. The GMLC sends a message to the MSC/VLR indicated by the HLR. This message carries the type of location information requested (e.g. current location), the MS subscriber's IMSI, LCS QoS information (e.g., accuracy, response time) and an indication of whether the LCS client has the override capability. For a call related location request, the message also carries the LCS client's called party number. For a value added LCS client, the message carries the client name if available and, for a call unrelated location request, the identity of the LCS client. 4. For a call unrelated location request from a value added LCS client, the visited MSC veries that the GMLC included the LCS client identity (that is, client address) as required in step 3. If the location request is allowed for a non-speech circuit call, it is
A50016-D1112-V41-2-7618
DRAFT
145
Information System
5.
6.
7.
8. 9.
10. 11.
12.
146
DRAFT
up to the SMLC to decide, on the basis of the applicable position methods and requested QoS, whether positioning is possible. The MSC/VLR then veries LCS barring restrictions in the MS user's subscription prole in the VLR. In verifying the barring restrictions, barring of the whole location request is assumed if any part of it is barred or any requisite condition is not satised. If the target MS supports any MS based or MS assisted positioning method(s), the MS also provides the BSC and MSC/VLR with the positioning method(s) it supports via controlled early classmark sending. If the location request comes from a value added (that is, commercial) LCS client and the MS subscription prole indicates that the MS must either be notied or notied with privacy verication and the MS supports notication of LCS, an LCS location notication invoke message is sent to the target MS indicating the type of location request (e.g. current location), the identity of the LCS client and whether privacy verication is required, that is,: Notication only location already allowed Notication with verication location allowed if no response from MS Notication with verication location not allowed if no response from MS Optionally, after sending the location notication invoke message, the MSC/VLR can continue the location process in parallel. The target MS noties the MS user of the location request and, if privacy verication was requested, the target MS indicates to the MS user whether the location request is allowed or is not allowed in the absence of an MS user response and waits for the user to grant or withhold permission. The MS then returns an LCS location notication return result to the MSC/VLR indicating, if privacy verication was requested, whether permission is granted or denied. The MSC/VLR returns an error response (with cause value unauthorized LCS client) to the GMLC if privacy verication was requested and either the MS user denies permission or there is no response with the MS subscription prole indicating barring of the location request in the absence of a response. The MSC/VLR sends a request message to the serving BSC. The request message contains the location type (indicating that a location estimate is requested), the requested QoS and the requested priority (low priority for a commercial or PLMN operator location request and high priority for emergency services or lawful interception). The BSC sends a request to the SMLC. The BSC can add additional measurement data to the message to assist with positioning. The SMLC determines the positioning method and instigates the particular message sequence for this method. When location information best satisfying the requested location type and QoS has been obtained, the SMLC returns it to the serving BSC in a perform location response. The BSC sends a response to the MSC/VLR. The MSC/VLR returns the location information and its age to the GMLC, if the MSC/VLR has not initiated the privacy verication process in step 6. If step 6 has been performed for privacy verication, the MSC/VLR returns the location information only, if it has received a location notication return result indicating that permission is granted. The GMLC returns the MS location information to the requesting LCS client. If the LCS client requires it, the GMLC rst transforms the universal location coordinates provided by the MSC/VLR into a local geographic system. The GMLC can record billing for both the LCS client and inter-network revenue charges from the MSC/VLRs network.
A50016-D1112-V41-2-7618
Information System
Fig. 4.37 shows in a 2G PLMN the general network positioning for a mobile terminating location request (MT-LR).
SMLC
HLR
8 MS 9 10, 7 5 4 11, 6 MSC/VLR 3 GMLC 1 2 12
BTS 5 5
SRNC BSC/ TRAU
LCS client
Fig. 4.37
General network positioning for an MT-LR in a 2G PLMN
Call procedure in a 3G PLMN (CN) A mobile terminating location request (MT-LR) is characterized by the fact that the LCS client is external to the PLMN (e.g., fleet management center). This circuit-switched domain CN subfeature enables an external location service client to request the location of a specific identified MS. 1. An external LCS client requests the current location of a target MS from a GMLC. The GMLC veries the identity of the LCS client and its subscription to the LCS service requested and derives the MSISDN/IMSI of the target MS to be located and the LCS quality of service (QoS) from either the subscription data or data supplied by the LCS client. For a call-related location request, the GMLC obtains and authenticates the called party number of the LCS client. 2. The GMLC sends a request to the home HLR of the target MS to be located with either the IMSI/MSISDN of this MS. The HLR then returns the current MSC address for the particular MS. 3. The GMLC sends a message to the MSC/VLR indicated by the HLR. This message carries the type of location information requested (e.g., current location), the MS subscriber's IMSI, LCS QoS information (e.g., accuracy, response time) and an indication of whether the LCS client has the override capability. For a call related location request, the message also carries the LCS client's called party number. The message can optionally carry the identity of the LCS client. 4. The MSC/VLR then veries LCS barring restrictions in the MS user's subscription prole in the VLR. In verifying the barring restrictions, barring of the whole location request is assumed if any part of it is barred or any requisite condition is not satised. If the MS is in idle mode, the Core Network performs paging, authentication, and ciphering. 5. The MSC sends a location reporting control message to the SRNC (or SLMC). This message includes the type of location information requested, the MS's location capabilities, and requested QoS. 6. The SRNC (or SLMC) calculates the location estimate (based on the service area ID (SAI), cell coverage, and cell ID).
A50016-D1112-V41-2-7618
DRAFT
147
Information System
7. When a location estimate has been obtained, the SRNC (or SLMC) returns it to the MSC in a location report message. 8. The MSC returns the location information and its age to the GMLC. If the SRNC does not return a successful location estimate, the MSC returns the last known location of the target MS, if known, and the LCS client requests the current or last known location. The MSC then releases the mobility management connection to the MS, if the MS was previously idle, and the MSC records billing information. 9. The GMLC returns the MS location estimate to the requesting LCS client. If the LCS client requires it, the GMLC rst transforms the universal location co-ordinates provided by the MSC into a local geographic system. The GMLC records billing for both the LCS client and inter-network revenue charges from the MSC's network. Fig. 4.38 shows in a 3G PLMN the general network positioning for a mobile terminated - location request (MT-LR).
HLR
MS 6 NodeB 4 4 SRNC SRNC (SLMC) 7, 5 4 4 8 MSC/VLR 3
2 9 GMLC 1
LCS client
Fig. 4.38
General network positioning for an MT-LR in a 3G PLMN
Full LCS privacy subscription The following LCS privacy classes, subscribed to by an MS in the subscriber location privacy profile (SLPP) in the HLR, are defined in the 3GPP standards with the indicated meaning in terms of allowing or disallowing location: Universal class Allow positioning by all LCS clients. Call related class Allow positioning by specic identied value added LCS client or groups of value added LCS client to which the MS originated a call. For all clients in the call related class, or for each identified LCS client or group of LCS clients, one of the following subscription options (GMLC restrictions) applies: Location request allowed only from GMLCs identied in the SLPP Location request allowed only from a GMLC in the home country Location request allowed from any GMLC (default case) For each identified value-added LCS client or group of LCS clients in the privacy exception list, one of the following subscription options applies: Positioning allowed without notifying the MS user (default case) Positioning allowed with notication to the MS user Positioning requires notication and verication by the MS user; positioning is allowed only if granted by the MS user or if there is no response to the notication
148
DRAFT
A50016-D1112-V41-2-7618
Information System
Positioning requires notication and verication by the MS user; positioning is allowed only if granted by the MS user For all value-added LCS clients sending a call-related MT-LR that are not explicitly identified in the privacy exception list (SLPP), one of the following subscription options applies: Positioning not allowed Positioning allowed without notifying the MS user (default case) Positioning allowed with notication to the MS user Positioning requires notication and verication by the MS user; positioning is allowed only if granted by the MS user or if there is no response to the notication Positioning requires notication and verication by the MS user; positioning is allowed only if granted by the MS user Location request not allowed Call unrelated class For each identified value added LCS client or groups of value added LCS clients in the privacy exception list one of the following GMLC restrictions applies: Location request allowed only from GMLCs identied in the SLPP Location request allowed only from a GMLC in the home country Location request allowed from any GMLC (default case) For each identified value-added LCS client or groups of value added LCS clients in the privacy exception list one of the following subscription options applies: Positioning allowed without notifying the MS user (default case) Positioning allowed with notication to the MS user Positioning requires notication and verication by the MS user; positioning is allowed only if granted by the MS user or if there is no response to the notication Positioning requires notication and verication by the MS user; positioning is allowed only if granted by the MS user Location not allowed For value-added LCS clients sending a call-unrelated MT-LR that are not explicitly identified in the subscriber's privacy exception list (SLPP), one of the following subscription options applies: Positioning not allowed (default case) Positioning allowed with notication to the MS user Positioning requires notication and verication by the MS user; positioning is allowed only if granted by the MS user or if there is no response to the to the notication Positioning requires notication and verication by the MS user; positioning is allowed only if granted by the MS user PLMN operator class Allow positioning by specific types of PLMN operator clients within or association with the VPLMN (that is, where the GMLC is in the VPLMN), identifying the following types of clients: Clients providing a location-related broadcast service O&M client in the HPLMN (when the MS is currently served by the HPLMN) O&M client in the VPLMN Clients recording anonymous location information without any MS identier
A50016-D1112-V41-2-7618
DRAFT
149
Information System
Clients enhancing or supporting any supplementary service, IN service, bearer service, or teleservice subscribed to by the target MS subscriber If the MS subscribes to the PLMN class, a location is allowed if the client within the VPLMN, or the client identied by the GMLC, either matches a generic type of client contained in the MS's SLPP or is otherwise authorized by local regulatory requirements to locate the MS.
4.5.8.2
Mobile Originating Location Request (MO-LR)

Common procedures and signaling are defined in 3GPP Release 99 and Release 4 to support a circuit-switched MO-LR request from an MS for each of the following: Location estimate (basic self-location) Transfer of location assistance data Transfer of location deciphering keys for broadcast assistance data Transfer to third party (that is, LCS client) Location estimate (basic self-location) The mobile originating location request (MO-LR) procedure is based on existing call-independent supplementary services. An MO-LR enables a specific identified MS to request its own location. A MS sends an MO-LR invoke message to the MSC indicating a request for geographic position. The MSC then uses a normal location procedure to obtain a location estimate and returns this to the MS. This capability allows self-location by an MS without the need to support autonomous self-location using broadcast assistance data. It is useful for a simple low tier MS, if a user has not subscribed to autonomous self-location, or if a network does not provide the broadcast data.
Call procedure (for 2G PLMN and 3G PLMN):

The specific MO-LR procedure for self-location of an MS is shown below. 1. If the MS is in IDLE mode, the MS sends a service request indicating a request for call-independent supplementary services to the BSC or SRNC. The BSC or SRNC includes the current location destination data and sends it across the A or Iu interface to the MSC/VLR. 2. The MSC/VLR instigates authentication and ciphering if the MS is in IDLE mode. If the target MS supports any MS-based or MS-assisted positioning method(s), the MS provides the BSC or SRNC and MSC with the positioning method(s) it supports via controlled early classmark sending. 3. The MS sends a message for call-independent supplementary services to the MSC/VLR containing an LCS MO-LR invoke. The invoke component contains the MO-LR type (location estimate) and LCS QoS information (e.g., location accuracy, response time). The MSC/VLR checks that the MS has permission to request its own location in the MS's subscription prole in the VLR. 4. The MSC/VLR sends a request message to the BSC or SRNC. This message contains the location type (indicating that a location estimate is requested), the requested QoS, and the priority (set to low priority). 5. The BSC or SRNC sends on a perform location message to the SMLC. The serving BSC/RNC can add additional measurement data to the message to assist positioning. 6. The SMLC instigates positioning of the MS (messages for this concern the SMLC, RAN, and MS, but not the MSC/VLR).
150
DRAFT
A50016-D1112-V41-2-7618
Information System
7. When a location estimate best satisfying the requested QoS has been obtained, the SMLC returns a perform location response to the BSC or SRNC. This message carries the location estimate and, optionally, positioning data for a billing record. 8. The BSC or SRNC sends on a perform location response to the MSC/VLR. 9. If location was successful, the MSC/VLR returns a message to the MS containing an location MO-LR return result and carrying any location estimate obtained by the SMLC. If the MS does not continue or terminate the transaction, the MSC terminates the transaction after a certain time-out period. Fig. 4.39 shows the mobile originated - location request (MO-LR) to perform self-location.
HLR
MS BSC/ TRAU SRNC or SRNC 7 5
9 1, 2, 3
BTS or NodeB
9 1, 2, 3
4, 8, 9 1, 2, 3
MSC/VLR
GMLC
LCS client
6 SMLC
Fig. 4.39
MO-LR to perform self-location
Transfer of location assistance data With this variant of the MO-LR procedure, an MS requests assistance data for enhanced observed time difference of arrival positioning (E-OTD) (2G only) or observed time difference of arrival (OTDOA) (3G only) or global positioning system (GPS) and, in the case of GPS, should indicate which types of assistance data are needed. The GPS-specific indications are useful because some types of GPS assistance data can be lengthy (e.g., up to around 700 octets for ephemeris data) - leading to long signaling delays in transmission over the radio interface (for 2G RAN, e.g., if only a stand-alone dedicated control channel (SDCCH) is assigned). In addition, the PLMN can charge an MS based on the specific assistance data provided. The assistance data is provided directly from the SMLC to the MS using radio resource (RR) level signaling. A confirmation that assistance data was sent is returned to the MS by the MSC/VLR in the MO-LR return result. This capability is particularly useful to an MS with autonomous self-location capability to speed up initial location when the MS is first powered on in a new location (and the user does not want to wait until all necessary broadcast messages have been received) or for MS with autonomous self-location and if the network does not broadcast assistance data (enables charging for assistance data). Transfer of location deciphering keys for broadcast assistance data
A50016-D1112-V41-2-7618
DRAFT
Ciphering of key portions of broadcast assistance data can be employed by an SMLC to restrict access to MS users who subscribe (in the HLR) to receipt of deciphering keys from the SMLC. This provides a way of charging for broadcast data - e.g., flat rate or by usage. A necessary corollary of ciphering is the ability of the MSC/VLR and SMLC to
151
Information System
support delivery of deciphering keys to an MS that requests delivery by using a variant of the MO-LR request. The SMLC ciphers defined portions of each broadcast message using the 56-bit DES algorithm with a 56-bit cipher/decipher key and a 16-bit ciphering serial number that is included (un-ciphered) in each broadcast message. The SMLC is required to use the same cipher/decipher key in each location area, although different keys can be used for E-OTD (in 2G) or OTDOA (or 3G) versus GPS data (in the same location area). The SMLC can change the cipher/decipher key (e.g., according to O&M instructions) at periodic intervals. The cipher/decipher key being used in any location area is indicated to the MS user using a single-bit identification mechanism (alternating 0/1 value). When the MS sees the identification bit change in a location area (or on first powering on), it requests the new key from the MSC/VLR using the MO-LR procedure. Transfer to third party (that is, LCS client) A mobile originating location request (MO-LR) enables a specific identified MS to request its own location and forward this information to a third party. This guarantees a high level of privacy as the request is initiated by the mobile subscriber. An MS sends an MO-LR invoke message to the MSC indicating a request for his geographic position to be transmitted to a third party (that is, to another LCS client). The MSC then uses a normal location procedure to obtain a location estimate and sends this to the requested third party via GMLC. The MSC/VLR sends the location in the subscriber location report to the GMLC. After the GMLC acknowledges that it has received the location estimate, the MSC/VLR returns the location estimation in an MO-LR return result in the event of an MO-LR request for a successful transfer to third party (TTTP). This capability provides extremely easy usage and greater privacy for the user because it is initiated by the user. The support of an MO-LR request for transfer to third party is implemented for terminals according to the 3GPP Release 4.
4.5.9
Full-Rate and Half-Rate Channel Connections (2G only)

Only full-rate connections are supported in GSM phase 1 PLMNs, that is the traffic data is transmitted at a data rate of 22.8 kbit/s via the radio interface. Provision is made for supporting half-rate channel connections in GSM phase 2/2+ (the transmission rate on the radio interface is 11.4 kbit/s). The 2G CN and RAN supports half-rate channels for speech services. For data services, half-rate channels are supported by the RAN but not by the CN. If the MSC is used as a gateway MSC to a satellite network (GSC), the MSC supports both full-rate and half-rate channel connections for data services. If an RAN, in the same way as the SIEMENS BSS, operating according to these criteria is available, all base stations (TRAU/BSC/BTS) must be capable of phase 2/2+ signaling if the MSC is also intended to operate effectively with phase 2/2+ signaling (e.g. with MSC-controlled handover). Only in this case it is possible for a seizure of a half-rate channel initiated by the mobile station via the RAN to be received by the MSC and be positively acknowledged by the RAN side. In this case, the base station sets the halfrate channel in the RAN itself.
152
DRAFT
The SIEMENS BSS permits dual-rate operation, that is full-rate (FR) and half-rate (HR) operation at the same time. If a full-rate is upgraded to full-rate and half-rate, changes to the hardware must be made in the BSC and TRAU and changes to the software in the BTS, BSC and TRAU. In particular, the half-rate transcoders which operate at a user
A50016-D1112-V41-2-7618
Information System
data rate of 6.5 kbit/s (compared with 13 kbit/s for full-rate operation) have to be upgraded in the TRAU. Tab. 4.3 shows the differences when sub multiplexing traffic channels at the 2G RAN internal interfaces. Rate mode FR Abis Asub A
4 TCH/F to 1x64 kbit/s 4 TCH/F to 1x64 kbit/s 1 TCH/F to 1x64 (1 TCH/F = 16 kbit/s) (1 TCH/F = 16 kbit/s) kbit/s (1 TCH/F = 64 kbit/s) 8 TCH/H to 1x64 kbit/s 4 TCH/H to 1x64 kbit/s 1 TCH/H to 1x64 (1 TCH/H = 8kbit/s) (1 TCH/H = 16 kbit/s) kbit/s (1 TCH/H = 64 kbit/s) Sub multiplexing of user channels to the 2G RAN interfaces
HR
Tab. 4.3
The enhanced full-rate channel connections (EFR) continue with the CN and RAN (section 4.5.10). The simultaneous function of EFR, FR and HR is also known as triple mode operation.
4.5.10
Enhanced Full-Rate Channel Connections (2G only)

The 2G CN and RAN provide the necessary signaling for using GSM phase 2+ compatible mobile stations with enhanced speech quality codec versions, which has a better connection quality compared to that in fixed networks. The PLMN operator can activate/deactivate this support in the PLMN and in this way control the use of the new speech quality codec version. The functional sequence is as follows (Fig. 4.40). The mobile station sends a list of speech quality codec versions to the MSC which it supports (1). Up to 6 speech quality codec versions are supported which can be assigned according to the priorities determined by the MS. At the start, the codec versions full-rate (FR), half-rate (HR) and enhanced full-rate (EFR) is probably all equally available to mobile subscribers. The MSC transmits this list to the BSC (2) which analyzes it and selects the most recent version that can seize the traffic channel in the direction of the MS. The MSC has to assign the trunks on the A interface. If not all TRAUs in the PLMN support EFR, the pooling feature has to be activated and administered in the MSC and RAN in order to introduce EFR efficiently. At least one TRAU supporting EFR must be available per BSC.The MSC has to assign the trunks on the A interface corresponding to the channel type requested by the MS and has to handle circuit identity code/circuit pool tables to take the BSS TRAU configuration into account.The version currently selected by the BSC is signaled back (3) to the MSC and is available to be passed on to the new BSC (intra-MSC handover) or to the new MSC (inter-MSC handover) in the case of a possible subsequent MSCcontrolled handover.
A50016-D1112-V41-2-7618
DRAFT
153
Information System
MSC/ VLR 1 3
Phase 2+
2 RAN
Phase 2+
1 Radio interface
MS
Fig. 4.40
Enhanced full-rate channel connections
4.5.11
Pooling for Circuit Allocation on A Interface (2G only)

Circuit pool for circuit allocation on the A interface is a feature that offers the possibility of providing new services in the same way as the high-speed circuit-switched data (HSCSD) and further, new application and new speech codecs (e.g., EFR), without major changes to the RAN architecture. Pool is defined as a group of circuits, that is, time slots on the A interface (TSLA) supporting the same channel types or speech coding algorithms. The 2G GSM circuit pool solution is necessary for the HSCSD service to avoid blocking problems in the assignment phase (due to the fact that one circuit on the A interface corresponds to more than one circuit on the Asub interface). It allows the RAN systems to follow the evolution of transcoding boards and to support the coexistence of transcoding boards of different versions in the field. Therefore, the existing TRAUs in the PLMN need not to be replaced by new TRAUs, each supporting both the existing and the new features or codecs. Instead, only additional TRAUs (at least one per BSC) have to be installed with the capacity required to support the new features and as an add-on to the existing TRAUs. Calls requiring the standard features or codecs still use the existing TRAUs, while calls requiring the support of advanced features or codecs (EFR, HSCSD) is served by the additional new TRAUs. As a result, the MSC has to assign the trunks on the A interface corresponding to the channel type requested by the MS and has to handle circuit identity code/circuit pool tables to take RAN TRAU configuration into account. As an example, the following Tab. 4.4 reports some of the pool types described by the 3GPP standard that could be interesting for RAN. Pool Circuit pool number 1 Supported channels and speech coding algorithms Full-rate (FR) speech version 1 FR data (up to 9.6 kbit/s)
154
DRAFT
Tab. 4.4 Circuit pool types
A50016-D1112-V41-2-7618
Information System
Pool Circuit pool number 20
Supported channels and speech coding algorithms Full-rate (FR) speech version 1 FR speech version 2 (EFR) FR data (up to 14.4 kbit/s) Half-rate (HR) speech version 1 HR data Full-rate (FR) speech version 1 FR speech version 2 (EFR) FR data (up to 14.4 kbit/s) Half-rate (HR) speech version 1 HR data HSCSD max. 2 x FR data (up to 14.4 kbit/s)
Circuit pool number 21
Tab. 4.4
Circuit pool types
4.5.12
Support of Adaptive Multirate (AMR) Codec

All existing GSM speech codecs (HR, FR and EFR) operate at a fixed coding rate, while channel error protection is added at a fixed rate. The codec types are chosen as a compromise between best radio transmission quality and robustness against transmission errors. This is done once at the beginning of a call. Where the transmission quality changes, no dynamic changeover to another codec is possible. The adaptive multi-rate (AMR) codec exploits the implied performance compromises by adapting the speech and channel coding rates according to the quality of the radio channel. This gives the best transmission quality and better robustness against transmission errors. These benefits are implemented when operating in full-rate and in half-rate mode. In addition to speech quality improvements, the need to enhance capacity by allocating half-rate channels to some or all mobiles is also recognized. The radio resource algorithm, which is enhanced to support adaptive multi-rate (AMR) operation, allocates a half-rate or full-rate channel depending on channel quality and traffic load in the cell to obtain the best balance between speech quality and network capacity. This is the case at call setup and during a call. Where the transmission quality changes, the codecs are adapted. In order to allow operation of adaptive multi-rate (AMR) codec beyond BSC area borders without re-initialization, assigned codec parameters have to become part of the handover message. For example, assigned speech coding and channel coding have to be transferred from the originating RAN towards the target RAN. For this reason, a new mechanism is introduced in the MSC for the handover message called old RAN to new RAN information.
In 3G (that is, via Iu interface) only AMR codec is used, but no HR, FR and EFR.
A50016-D1112-V41-2-7618
DRAFT
155
Information System
4.5.13 4.5.13.1
Handling the Subscriber Telecommunication Services Bearer Services in 2G

The bearer services are used only for pure data services. The bearer services provide the necessary basis for the operation of these pure data services. Tab. 4.5 below shows the implemented bearer services. Bearer service Asynchronous circuit-switched duplex data services data CDA (circuit duplex asynchronous) Transmission rates 300 bit/s to 9600 bit/s (or 28.800 bit/s with application of 14.4 kbit/s codec and HSCSD) 300 bit/s to 9.600 bit/s 1200 bit/s to 9.600 bit/s
Dedicated PAD access Synchronous duplex data services CDS (circuit duplex synchronous) Tab. 4.5 Implemented bearer services
The above-mentioned bearer services can be administered in one fixed transmission rate each or in the case of general bearer service no fixed transmission rate (e.g., BS20). In the case of BS20, it allows the mobile subscriber to use the transmission rates of BS21 to BS26. (300 to 9.600 bit/s) with application of 14.4 kbit/s codec and HSCSD, a maximum transmission rate of 28.800 bit/s is possible. Data compression as per ITU-T V.42 allows the effective data transmission rates for bearer services BS2x and BS4x to be increased (see System Description, register Network System Concept, section Basic Telecommunication Services). For these data services, the MSC incorporates an interworking function (IWF) which forms the interface between the fixed networks and the 2G PLMN. The bearer services on the mobile subscriber and fixed network subscriber side must also be matched (converted) at the fixed network interface. 2G PLMN provides interworking of all mobile subscriber bearer services and the following two fixed network bearer services: 3.1 kHz audio Unrestricted digital (UDI) The traffic channels for these data services are fed via special interworking equipment (IWE) in the MSC which has functions such as rate adaptation, modem and codec in layer 1, as well as protocol execution functions in the upper layers. Data CDA (BS21, 22, 23, 24, 25, 26)/(BS20) Given the fact that almost all data services in the public telecommunication networks (PSTN) are based on the use of modems, a partner modem is necessary in the 2G PLMN. This modem is part of the IWE in the MSC. This corresponds to the application of a fixed network bearer service 3.1 kHz audio.
156
DRAFT
This modem therefore operates remotely from data terminal in the mobile station (MS). For data transmission via the radio interface, the speech coder/decoder (transcoder), specially designed for speech transmission is replaced by a special channel coder/decoder. Since the transcoder is suitable only for coding speech tones it is impossible to transmit modem tones without signal mutilation.
A50016-D1112-V41-2-7618
Information System
Fig. 4.41 shows the protocol model for asynchronous data transmission with the relevant GSM bearer service (data CDA) and the fixed network bearer service (3.1 kHz audio) to the traffic channel in the 2G PLMN. A modem is selected in the IWE to convert the digital data into modem signals. A codec function with an A law conversion is supported for converting the modem signals to a form suitable for the 64 kbit/s digital interface to the fixed network.
MS Data terminal MT
TRAU (in the RAN)
MSC (with IWF) (in the CN) User protocol
Data terminal
RLP (optional) User data rate Layer 2 22.8 kbit/s (9.6 kbit/s) TAF FEC FEC RA 64 kbit/s Layer 2 64 kbit/s
PSTN/ISDN (fixed network)
Modem RA (Codec)
Network node
Modem
R interface
Radio interface
A interface
Fixed network bearer service (PSTN: 3.1 kHz audio)
a/b interface
R interface
Fig. 4.41
Protocol model for asynchronous data transmission with GSM bearer service (data CDA) and fixed network bearer service (3.1 kHz audio) To give the call from the mobile subscriber to the fixed network subscriber greater flexibility when using of modem data rates and to allow it greater success in setting up calls, the autobauding feature is available on a project-specific basis. Autobauding is the automatic detection of the user data rate by the analog modem involved, regardless of the GSM bearer service subscribed to. The appropriate user data rate for the two modems involved is determined by starting at the highest rate for the called modem and, after appropriate agreement from both modems, falling back to the rate that the calling modem can handle (data rate fall back), if required. The radio link protocol (RLP) can be introduced (optionally) between the MS and the, MSC in layer 2 for additional transmission security. It operates with automatic repeat request (ARQ). The price for the improved transmission quality is variable throughput and variable transmission delay. The use of this protocol means that the bearer service is non-transparent. A transparent bearer service exists when RLP is not used. A rate adaptation function (RA) translates the traffic data rate on the mobile subscriber side (in the TRAU function in the RAN and MSC) to the relevant 64 kbit/s data rate of the A interface. This involves adaptations such as from the asynchronous to synchronous data stream. In the case of a transition to the fixed network (ISDN) bearer-service unrestricted digital (UDI) the RA function in the MSC translates in the direction of the fixed network side (Fig. 4.42).
A50016-D1112-V41-2-7618
DRAFT
157
Information System
MS Data terminal MT
TRAU (in the RAN)
Data terminal
RLP (optional) User data rate Layer 2 22.8 kbit/s (9.6 kbit/s) TAF FEC FEC RA 64 kbit/s RA RA RA Layer 2 64 kbit/s
ISDN (fixed network)
Network node
RA
R interface
Radio interface
A interface
Fixed network bearer service (ISDN: unrestricted digital (UDI))
a/b interface
R interface
Fig. 4.42
Protocol model for asynchronous data transmission with GSM bearer service (data CDA) and fixed network bearer service (unrestricted digital (UDI)) Data CDS (BS31, 32, 33, 34) This bearer service allows the mobile subscriber access to a PSDN and particularly to an X.32 port (Fig. 4.43) or to a packet handler (PH) (Fig. 4.44). Data transmission up to the X.32 port or PH uses the CDS principle which is the synchronous and duplex mode. A call to an X.32 port in the PSDN is made using X.32 signaling. A call to a packet handler (PH) in the PSDN is made using X.31 signaling, in which case it is possible to chose between circuit-switched (X.31 case A) and packet-switched (X.31 case B). When X.31 case B is used, the 2G PLMN (MSC/IWF) undertakes call conversion. In X.31 case A, the MS addresses the X.32 part with a number (in the same way as a telephone number). In X.31 case B, the MSC routes the call to the X.32 part according to a routing table, because the call is a bearer service BS3x.
158
DRAFT
A50016-D1112-V41-2-7618
Information System
MS Data terminal
TRAU (in the RAN) MT
MSC (with IWF) (in the CN) User protocol PSDN (Fixed network)
Data terminal
RLP User data rate Layer 2 22.8 kbit/s (9.6 kbit/s) TAF FEC FEC RA 64 kbit/s Layer 2 64 kbit/s Modem RA (Codec) Modem X.32 Port Network node
R interface
Radio interface X.32
A interface
Fixed network bearer service (PSTN: 3.1 kHz audio)
R interface
Fig. 4.43
Protocol model for synchronous data transmission with the GSM bearer service (data CDS) and packet data access via X.32 signaling
MS Data terminal
TRAU (in the RAN) MT
Data terminal
PSDN (Fixed network) RLP User Layer 2 data rate TAF FEC Layer 2 22.8 kbit/s (9.6 kbit/s) FEC RA 64 kbit/s RA 64 kbit/s RA RA PH
Network node
R interface
Radio interface X.31
A interface
Fixed network bearer service (ISDN: unrestricted digital (UDI))
R interface
Fig. 4.44
Protocol model for synchronous data transmission with the GSM bearer service (data CDS) and packet handler (PH) using X.31 signaling
A50016-D1112-V41-2-7618
DRAFT
159
Information System
Dedicated PAD access (BS41, 42, 44, 45, 46) This bearer service allows the mobile subscriber to access a PSDN via a packet assembler/disassembler (PAD). Data is transmitted to the PAD in accordance with the CDA principle, that is asynchronous, circuit-switched and in duplex mode. The advantage of this is that the mobile subscriber can manage with a simple data terminal without a packet protocol function (e.g., X.25). The MSC sets up a call to a dedicated PAD which can be situated at a different location. This can be in an MSC, at a gateway/packet interworking MSC linked to the PSDN, in a fixed network switching node linked to the PSDN or in a PABX connected to the MSC. A dedicated PAD is not part of the scope of delivery of the 2G PLMN. When a call is requested with this bearer service (with the mobile subscriber specifying a short code for a defined PAD profile), routing to the PAD is automatically implemented by the MSC. The fixed network bearer service unrestricted digital (UDI) or 3.1 kHz audio can be used according to the specific project (Fig. 4.45).
MS Data terminal TRAU (in the RAN) MT MSC (with IWF) (in the CN) User protocol
Data terminal
PSDN (Fixed network) RLP (optional) User data rate Layer 2 22.8 kbit/s (9.6 kbit/s) TAF FEC FEC RA 64 kbit/s Layer 2 64 kbit/s Modem/ RA PAD Network node
Modem/ RA RA
R interface
Radio interface
A interface
Fixed network bearer service (ISDN: unrestricted digital (UDI) PSTN: 3.1 kHz audio)
R interface
Fig. 4.45
Protocol model for packet data transmission with the GSM bearer service (dedicated PAD access)
160
DRAFT
A50016-D1112-V41-2-7618
Information System
High-speed circuit-switched data (HSCSD) service HSCSD is a 2G feature (that is, according to 3GPP standards) and allows higher transmission rates for circuit-switched data services corresponding to the following two components: increasing the net data transmission rate of one 2G trafc channel by about 50% from 9.6 kbit/s to 14.4 kbit/s and combining of several trafc channels on the radio interface for the same call. For HSCSD application, the general bearer service BS20 is administered for the mobile subscribers in the HLR. Thus, general bearer service BS20 is a condition for HSCSD.
14.4 kbit/s channel coding (TCH/F14.4):

A modified channel coding algorithm enables data throughput to be increased with the aid of puncturing which removes some bits from data stream according to a defined procedure. The increased data throughput reacts less robustly to interference which is only sensible on the radio cell borders. The modified channel coding algorithms also results in the new rate adaptation (RA) function in the traffic channel and a new forward error correction (FEC) method on the radio interface. The new rate adaptation (RA) function is then carried out using the A-TRAU format, which is why it is called rate adaptation A (RAA). In total the 14.4 kbit/s channel coding involves changes in the MS, RAN (i.d. TRAU codecs) and MSC (that is, IWF). The gross data rate at the radio interface remains at 22.8 kbit/s. Fig. 4.46 shows the protocol model for asynchronous data transmission with GSM bearer service (data CDA) and fixed network bearer service (3.1 kHz audio) for one traffic channel in the 2G PLMN.
MS Data terminal MT
TRAU (in the RAN)
MSC (with IWF) (in the CN) User protocol PSTN/ISDN (fixed network) Layer 2
Data terminal
RLP (optional) User data rate Layer 2 22.8 kbit/s (14.4 kbit/s) TAF FEC FEC RA 64 kbit/s
Modem RA (Codec)
64 kbit/s
Network node
Modem
R interface
Radio interface
A interface
Fixed network bearer service (PSTN: 3.1 kHz audio/V.34)
a/b interface
R interface
Fig. 4.46
Protocol model for asynchronous data transmission with the GSM bearer service (data CDA) and fixed network bearer service (3.1 kHz audio/V.34) for one HSCSD traffic channel (TCH/F14.4) HSCSD is provided for the asynchronous general bearer service (BS20) for transparent and non-transparent transmissions. The non-transparent transmissions are defined by a new radio link protocol (RLP) version. The new RLP version 2 is a multi-link version which includes the old single-link versions 1 and 0. Because no constant data rate is necessary for HSCSD, the number of combined channels can vary during a transmis-
A50016-D1112-V41-2-7618
DRAFT
161
Information System
sion. This can be necessary if a speech call is to be set up, which is seized completely by a data call. In this case, the BSC or MS could reduce data connection by about one traffic channel to enable the setup of the requested speech call. Digital (unrestricted digital, UDI) and analog (V.34 modem) interworking towards the fixed network is supported as well as data compression and autobauding.
Channel combining:
In the current software versions, the CN supports the combination of up to 2 channels. It is possible to combine channels with TCH/F9.6 as well as with TCH/F14.4 channel codings. Symmetric as well as asymmetric configurations are supported. Asymmetric means that 1 traffic channel can be used uplink and 2 traffic channels can be used downlink. Asymmetric configurations are only applicable for non-transparent transmissions according to the 3GPP standards. With the A interface circuit pooling functionality, the MSC can assign traffic channels on the A interface according to the channel type requested by the MS (e.g., TCH/F14.4, TCH/F9.6, TCH/F4.8, TCH/F2.4 (FR data), TCH/H4.8, TCH/H2.4 (HR data), TCH/FS (FR speech) and enhanced FR (EFR speech)). Different channel types are grouped in a predefined circuit pool on the A interface (that is groups of trunks) which is connected to a transcoder rate adaptation unit (TRAU) capable of performing the appropriate channel coding in the different transcoding boards (TRAC). E.g., Circuit pool number 20 supports full-rate (FR) speech version 1, FR speech version 2 (EFR), FR data (up to 14.4 kbit/s), half-rate (HR) speech version 1, HR data. During call setup, the MSC receives the channel requirements for the call from the MS. According to the channel requirements received, the MSC assigns an A interface circuit pool capable of supporting the required channel coding. Fig. 4.47 shows HSCSD channel combining on the basis of circuit pools (in the case of channel coding type TCH/F14.4).
2x 16 kbit/s channel BTS BSC 2x 16 kbit/s channel TRAU 1x 64 kbit/s channel MSC
2x TCH/F14.4 MS T A F
Internet PSDN (X.25)
TRAC
IWF
PSTN/ISDN (fixed network)
Radio interface
Abis interface
Asub interface
A interface
Fig. 4.47
HSCSD channel combining on the basis of circuit pools
4.5.13.2
Bearer Services in 3G
The bearer services provide the necessary basis for the operation of data services.
162
DRAFT
A50016-D1112-V41-2-7618
Information System
General asynchronous bearer service BS20 - Mobile circuit-switched data (MCSD) service in 3G With the mobile circuit-switched data (MCSD) service BS 20 in 3G feature, SIEMENS introduces the standardized asynchronous general bearer service 20 (BS20) in its 3G solution. With BS20, the PLMN operator is able to offer its mobile subscribers a wellknown circuit-switched data service with higher bit rates in an 3G environment. Existing applications that already run on asynchronous circuit-switched data services in 2G can now also be used in an 3G environment without larger adaptations within the infrastructure of the end user. With this service existing in 2G as well as in 3G additional a handover scenario between 3G PLMN and PSTN/ISDN is possible for this kind of circuitswitched data services and all running applications (Fig. 4.48).
Fixed subscriber
MS
3G RAN
MSC
MS
PSTN/ISDN (Fixed network)
2G RAN
MSC
Fig. 4.48
Connection architecture for mobile circuit-switched data (MCSD) service BS 20 in 3G
An interworking function (IWF) between 3G PLMN and PSTN/ISDN is provided. This is achieved by using the existing IWE:HS. Data is received from the RNC by the TRAU server card, type D (TSCD) via the AAL2 break server (A2BS). On the TSCD, data in the Iu packet data unit (PDU) is converted to an interface format for sending it over time division multiplex (TDM) to the IWE:HS. For this interface format, the 3GPP standardized A-TRAU frame format is used. Because the Iu interface only defines data rates of 14.4 kbit/s, 28.8 kbit/s and 57.6 kbit/s, the newly defined A-TRAU frame also uses these data rates. This also means that the lower data rates on the mobile station side cannot be supported by 3G PLMN. The lower data rates on the fixed network side can still be supported and only rely on the information on the bearer capability (BC) fixed network user rates (FNUR) element. As such, the lower data rates can only be supported in the non-transparent mode.
A50016-D1112-V41-2-7618
DRAFT
163
Information System
General synchronous bearer service BS30 - 64 kbit/s:
BS30 is supported in two representations: - 64 kbit/s unrestricted digital (UDI) multimedia - 64 kbit/s bit-transparent Both kinds of the service can be used for MOC, MTC, and MMC. The following section describes only the kind 64 kbit/s unrestricted digital (UDI) multimedia. See also the description of the feature service change and UDI fallback (SCUDIF) in section 4.5.14. This bearer service provides real-time multimedia services with a transmission rate of 64 kbit/s. It is implemented by the special bearer capability parameters transparent, synchronous, circuit-switched, full duplex and unrestricted digital and uses the 3G PLMN which enables significantly higher rates over the radio interface. This service is based on the ITU-T standard H.324 with extensions for mobile transmission (H.324/M). This standard is not compatible with the H.324 standard and, therefore, only mobile-tomobile calls are possible (Fig. 4.49). For real-time transmission the call is transparent, that is no radio link control (RLC) is applied to radio interface (Uu).
3G RAN
MSC
MSC
3G RAN
MS
MS
Fig. 4.49
Connection architecture for 3G-H.324/M to 3G-H.324/M calls Multimedia functionality is transparent for the 3G PLMN, apart from identifying it as a 64 kbit/s multimedia call during the call setup. Direct multimedia telephony mode selection is assumed. The evaluated solution is to consider a pipe solution between the two MSs. In-band multimedia codec negotiation between the two MSs takes place after a mobile call setup has taken place. This call setup follows the normal procedures with the assistance of the special bearer capability parameters as described above. The AAL2 signaling protocol which supports the dynamic establishment and release of individual AAL2 point-to-point connections is required to set up the bearers on the Iu interface. The received AAL2 cells, carrying the multiplex packet data units (PDU) is terminated in the TRAU server card, type D (TSCD) within the MSC network element. Because of our mobile-to-mobile concept, our 3G PLMN does not need any transcoding.
4.5.13.3
Teleservices in 2G
Teleservices cover both speech and data services. The speech services comprise the teleservices telephony and emergency call, data services the teleservices fax (group 3) and the short message service. A combination of speech and data service is possible with the teleservice alternate speech and fax (group 3).
164
DRAFT
A50016-D1112-V41-2-7618
Information System
Telephony (TS11) The teleservice telephony is quite simply the speech service. As expected, it is the most used teleservice. The 2G PLMN was optimized for it. A speech coder/decoder (transcoder) was developed specially for the speech service which operates at 13 kbit/s in full-rate mode in a 22.8 kbit/s traffic channel. The TRAU function in the RAN performs speech transcoding in the 2G PLMN (Fig. 4.50).
Mobile station MT TRAU (in the RAN) MSC (with IWF) (in the CN) User protocol Telephone
PSTN/ISDN (Fixed network) User data rate Speech transcoder 22.8 kbit/s (13 kbit/s) Speech transcoder 64 kbit/s 64 kbit/s Network node
R interface
Radio interface
A interface
Fixed network teleservice (PSTN: speech)
a/b interface
Fig. 4.50
Transmission model for speech transmission with GSM teleservice (telephony) Emergency call (TS12) The teleservice emergency call is a special speech service and is always carried as an MOC. An emergency call can be set up (with or without inserted smart card) by means of an SOS key on the MS or by entry of an emergency call number. The call to the emergency call center is automatically set up by means of a location mark number (LMN) assigned in the database of every MSC cell. The LMN describes the digit combination for routing to the nearest emergency call center. Automatic telefax, group 3 (TS62) This teleservice is a data service and provides the application of standard group 3 telefax equipment. Adaptation of the telefax equipment to the 2G PLMN is performed by means of fax adapters (FA) at the mobile station and the interworking function (IWF) (Fig. 4.51). The main task of the fax adapter involves supervising and dealing with ITUT protocol T.30. Communication between the fax adapters is performed by means of specially defined protocol elements.
A50016-D1112-V41-2-7618
DRAFT
165
Information System
MS
TRAU (in the RAN)
MSC (with IWF) (in the CN) Fax G3 (with modem) PSTN/ISDN (Fixed network)
Fax G3
MT
User protocol
FA
22.8 kbit/s (9.6 kbit/s) TAF FEC FEC RA
64 kbit/s Modem RA FA (Codec)
FA 64 kbit/s Network node Network node (for PSTN) TA (for ISDN)
R interface
Radio interface
A interface
Fixed network bearer service (ISDN/PSTN: 3.1 kHz audio)
R/S interface
Fig. 4.51
Fax adapter function for teleservice telefax (group 3) On the MS side, the FA performs an adaptation sequence between a special fax terminal and the terminal adapter function (TAF). The TAF in turn performs an adaptation sequence between the FA and the current radio transmission. The fax data is transmitted from the MS to the IWF in the MSC in digital form with the ISDN bearer service 3.1 kHz audio. Fax modems are required in the IWF for interworking with this ISDN bearer service and the fax equipment on the fixed network side. These fax modems transmit traffic data in the form of a 3.1 kHz speech-band signal to the partner fax modem. If the partner fax-modem is on the ISDN side, a terminal adapter (TA) with a 3.1 kHz audio capabilities is used. In the event of inadequate transmission quality in the transparent telecommunication service, the telefax units initiate a reduction in the transmission rate. This reduction is detected by the T.30 supervision and leads to a change in the channel operating mode at the radio interface (channel mode modify (CMM) procedure). The bit rate adaptation in the IWF must also be changed. Fax terminals and CMMs perform a fallback from 9600 bit/s to 7200 bit/s or 4800 bit/s or 2400 bit/s. CMM is performed from the fallback 7200 bit/s to 4800 bit/s on. Short message service (TS21, 22) (mobile-terminated and mobile-originated, PP) The teleservice short message service (for point-to-point connections) permits the transmission of messages of up to 160 characters between the mobile station and another mobile station or fixed network terminal or vice versa. The short message service center (SMS center) acts as a kind of intermediate store for the short messages (Fig. 4.52). It functions as a message store and provides facilities for forwarding messages to various applications (store and forward). By way of example, the SMS center transmits with a single connection one or more received short messages to the mobile subscriber after he has left and reentered the 2G PLMN.
166
DRAFT
A50016-D1112-V41-2-7618
Information System
2G PLMN
HLR/AC
Intermediate network PSTN/ISDN or PSDN (or other PLMN) SMS center SMS-IWMSC
RAN
MSC/VLR
SMS-GMSC
MS
SMS operator
Fig. 4.52
Network architecture for the short message service Control and signaling channels are used instead of normal traffic channels for the transmission of the short messages between the 2G network elements in the short message service. The implementation of the short message service (SMS) in 2G PLMN is based on the network elements MS, 2G RAN and MSC which have additional functions for the transmission of short messages between the MS and at least one short message service interworking MSC (SMS-IWMSC) function / short message service gateway MSC (SMSGMSC) function for the short message service. With the additional feature SMS absent subscriber enhancement for MAPv3 communication between the MS, MSC and SMSC is enhanced over their respective interfaces. Over the E interface, the capability to use MAP version 3 for SMS-MO and SMS-MT is introduced (upgraded from MAPv2). Over the A interface, formerly unused optional parameters existing in the SMS RP-layer protocol is put to use to support the MAPv3 enhancement. When the SMS-MT happens and the mobile subscriber is absent, the MSC can reply the subscriber absent reason back to the SMSC (the reason can be paging no response via the MSC or IMSI detached). The HLR can receive the subscriber absent reason from the SMSC (see also in the System Description, register Network System Concept, section PLMN organization/Codes of 2G PLMN) the reason can be for the circuit-switched CN or for the packet-switched CN. The additional feature SMS MAP version negotiation introduces a new mechanism that reduces the number of MAP version negotiation procedures between the SMS Interworking MSC (SMS-IWMSC) and the SMS Center (SMSC). When originating an SMS, the MSC/VLR initiates a MAP dialog towards the SMSC. Currently, the MAP version to be used for the dialog cannot be administered. Thus, all dialogs start using the highest version supported by the MSC/VLR. However, different SMSCs can support different MAP versions. Each time the acceptable MAP version needs to be negotiated (fallback procedure). Now the MSC/VLR stores the acceptable MAP version for any relevant SMSC address after initial agreement. If a subsequent short message is originated to the same SMSC again, the MSC/VLR retrieves the stored MAP version which had been initially accepted by the SMSC and starts the MAP dialog.
A50016-D1112-V41-2-7618
DRAFT
167
Information System
Short message cell broadcast (TS23) The short message cell broadcast teleservice allows messages to be broadcast from a Cell Broadcast Center (CBC) to those mobile stations (MS) located within a defined service area. In the SIEMENS Base station System (SBS), the CBC which sets up the connection to the 2G RAN (that is, BSC) is integrated in the RC (Fig. 4.53). In addition to the CBC, the RC also comprises what is known as a cell broadcast entity (CBE), which is used for administering short messages. In addition to the integrated CBC solution, the BSC has an interface in the SBS to the external Cell Broadcast Center (CBC), so that a PLMN operator can fall back on the CBCs of other manufacturers. A mobile subscriber can use different message classes to select only those short messages he requires, while those messages he does not require are still received, but not displayed. This teleservice allows the PLMN operator to sell cell broadcast capacities for distributing such information as traffic reports, weather updates and commercials, for example. He can, for example, also use this service for displaying regional tariffs.
PLMN OMS-B RC (CBC + CBE) BTS OMT BTS O interface
2G RAN
CN
BTS
BSC
TRAU
MSC
BTS
Abis interface
Asub interface
A interface
Fig. 4.53
Network architecture for short message cell broadcast Voice group call service (VGCS) (TS91)
A description of VGCS/VBS can be found in the System Description, register GSM-R, section Operational Voice Communication. Some applications require the setup of point-to-multipoint connections in a mobile network, this means a phone call with one speaker and many listeners such as a broadcast can be used for example by railway, taxi or security companies. Together with the enhanced multi level precedence and preemption (eMLPP) supplementary service these services form the advanced speech call item (ASCI) services recommended by 3GPP. The VGCS can be applied to many types of group communication. Especially shunting team communication, train radio, and emergency communication needs this functionality. A mobile or fixed subscriber can require a group call. This is built up on a common
168
DRAFT
A50016-D1112-V41-2-7618
Information System
channel to all listeners, saving system capacity. All members of a group can listen. If a member requires the talk function press-to-talk (PTT), a duplex connection is established for as long as required. A VGCS is characterized by the following key points: A group call number combines all members of a dedicated group. Call in dened groups: for each group call a service area composed of a number of radio cells is assigned. Point-to-multipoint connection in real-time: dialing the group call number initializes the parallel setup of connections into all radio cells of the assigned service area. All members of this group being in the service area is paged to receive a notication of the ongoing voice group call. Depending on the call ID and priority, members of a group call can decide to join the call. Several speakers, many listeners: during the call the current speaker can change. If the current speaker stops speaking, he has to indicate that he is releasing the uplink. This indication is sent to the listeners. Those listeners who want to become the next speaker have to send a corresponding request, while using the press-to-talk (PTT) button. The MSC controlling the call decides on a rst come rst served basis about the next speaker. A timer that terminates the connection if no party wants to talk. Voice broadcast service (VBS) The VBS is used to broadcast railway emergency calls within predefined areas. It can be accessed from both fixed and mobile subscribers and is established as a half-duplex connection (one speaker many listeners). A VBS is characterized by the following key points: A group number combines all members of a certain group. Call in dened service areas: for each broadcast call, a service area composed of a number of radio cells is assigned. Point-to-multipoint connection in real-time. dialing the broadcast call number initializes the parallel setup of connections into all radio cells of the assigned service area. All members of this group in the service area is paged to receive a notication of the ongoing voice broadcast call. Depending on the call ID and priority of a group call (e.g., emergency broadcast) members of the group call can decide whether or not they would like to join the call. One speaker, many listeners: during the call the current speaker remains the same.
A50016-D1112-V41-2-7618
DRAFT
In the current software release, the ASCI step 3 and step 4 according to the ETSI/3GPP specification is supported, which provides the following improvements: - Moving/overlapping group call area (only in case of high priority/emergency calls) - Group call release when the call is put on hold by dispatcher - Improvement in start to talk condition handling - Choice in number of dispatchers allowed to talk - Transfer of originator information to dispatchers - ASCI call termination by authorized dispatcher only for VGCS - ASCI one channel model only for VGCS - Transfer of UUS1 subscription information to VPLMN
169
Information System
4.5.13.4
Teleservices in 3G
Teleservices cover both speech and data services. Telephony The teleservice telephony is currently the speech service. In 2G PLMNs, it is the most frequently used teleservice. The 3G PLMN also supports teleservice speech telephony. As speech coder/decoder (transcoder) the 2G well-known adaptive multirate (AMR) transcoder is reused for the 3G PLMN for the speech service which operates at 13 kbit/s for the user signal. The TRAU server card, type D (TSCD) function in the MSC network element performs the speech transcoding (Fig. 4.54 shows that together with traffic over TDM CN).
MS
3G RAN
MSC (with TSC) (in the CN) User protocol Telephone
MT
User data rate Speech transcoder
TRAU server card (TSCD) (13 kbit/s) Speech transcoder 64 kbit/s
Network node
R interface
Radio interface
Iu interface
Fixed network teleservice (PSTN: speech)
a/b interface
Fig. 4.54
Transmission model for speech transmission with UMTS teleservice (speech telephony) Emergency call (TS12) The teleservice emergency call is a special speech service and is always carried as an MOC. An emergency call can be set up (with or without inserted smart card) by means of an SOS key on the MS or by entry of an emergency call number. The call to the emergency call center is automatically set up by means of a location mark number (LMN) assigned in the database of every MSC cell. The LMN describes the digit combination for routing to the nearest emergency call center. Short message service (TS21, 22) (mobile-terminated and mobile-originated, PP) The teleservice short message service (for point-to-point connections) permits the transmission of messages of up to 160 characters between the MS and another mobile station or fixed network terminal, or vice versa. The short message service center (SMS center) acts as a kind of intermediate store for the short messages (Fig. 4.55). It functions as a message store and provides facilities for forwarding messages to various applications (store and forward). By way of example, the SMS center transmits with a single connection one or more received short messages to the mobile subscriber after he has left and re-entered the PLMN.
170
DRAFT
A50016-D1112-V41-2-7618
Information System
Control and signaling channels are used instead of normal traffic channels for the transmission of the short messages between the 3G network elements in the short message service. The implementation of the short message service (SMS) in 3G PLMN is based on the network elements MS, 3G RAN and MSC which have additional functions for the transmission of short messages between MS and at least one short message service interworking the MSC (SMS-IWMSC) function /short message service gateway MSC (SMSGMSC) function for the short message service.
3G PLMN
HLR/AC
Intermediate network
3G RAN
MSC/VLR
SMS-GMSC
SMS center
PSTN/ISDN or PSDN (or other PLMN)
SMS-IWMSC
MS
SMS operator
Fig. 4.55
Network architecture for short message service With the additional feature SMS absent subscriber enhancement for MAPv3 communication between the MS, MSC and SMSC is enhanced over their respective interfaces. Over the E interface, the capability to use MAP version 3 for SMS-MO and SMS-MT is introduced (upgraded from MAPv2). Over the Iu interface, formerly unused optional parameters existing in the SMS RP-layer protocol is put to use to support the MAPv3 enhancement. When the SMS-MT happens and the mobile subscriber is absent, the MSC can reply the subscriber absent reason back to the SMSC (the reason can be paging no response via the MSC or IMSI detached). The HLR can receive the subscriber absent reason from the SMSC (see also in the System Description, register Network System Concept, section PLMN organization/Codes of PLMN) the reason can be for the circuit-switched CN or for the packet-switched CN. With the additional feature SMS MAP version negotiation, a new mechanism is introduced that reduces the number of MAP version negotiation procedures between the SMS Interworking MSC (SMS-IWMSC) and the SMS Center (SMSC). When originating an SMS, the MSC/VLR initiates a MAP dialog to the SMSC. Currently the MAP version to be used for the dialog cannot be administered. Thus, all dialogs start using the highest version supported by the MSC/VLR. However, different SMSCs can support different MAP versions. Each time the acceptable MAP version needs to be negotiated (fallback procedure). Now the MSC/VLR stores the acceptable MAP version for any relevant SMSC address after initial agreement. If a subsequent short message is originated to the same SMSC again, the MSC/VLR retrieves the stored MAP version which had been initially accepted by the SMSC and starts the MAP dialog.
A50016-D1112-V41-2-7618
DRAFT
171
Information System
4.5.13.5
Supplementary Services
Supplementary services extend the functionality of the basic telecommunication services (bearer services and/or teleservices). The supplementary services possible in the PLMN are given in the System Description, register Network System Concept, section supplementary services. All implemented supplementary services are available for the speech services. For data services (bearer services and data teleservices), important supplementary services are possible.
4.5.14
Service Change and UDI Fallback (SCUDIF) (3G only)

SCUDIF is not yet released in current software version. The service change and UDI fallback (SCUDIF) feature is available to 64 kbit/s UDI multimedia calls and allows users to achieve successful call establishment when end to end circuit-switched (CS) multimedia is not possible (fallback to speech) or when signaling of the feature is not possible in the network (fallback to preferred service or speech). Furthermore, it allows the users to swap between a multimedia service and basic speech during an established call. This refers also to the used transport bearer.
This feature is useful for all circuit-switched multimedia applications based on bearer service 30 transparent multimedia for 64 kbit/s UDI, e.g., video telephony. This feature enables the following: A calling terminal to attempt multimedia call and build up a speech connection if the former multimedia call attempt fails (fallback at call setup by the calling terminal). The called terminal to accept the less preferred service (multimedia or speech) as a single service without interrupting the call setup (fallback at call setup by the called terminal). The call setup to proceed with the preferred service (multimedia or speech) or with speech as single service if the network does not support the feature signaling (fallback at call setup by the visited MSC). The called terminal to negotiate the preference of the services during the call setup, that is, to turn a multimedia call into a speech call (with service change) and vice versa (bearer capability (BC) negotiation by the called terminal). A speech call to be turned into multimedia by either of the parties, and back to speech, by means of a successful in-call modication procedure (service change). Any of the users to reject a multimedia request from the other party while in speech mode (rejection of service change).
4.5.15
User Information (Tones, Announcements and Indications)

Tones, announcements and indications advise the calling subscriber in the PLMN (mobile subscribers and WLL subscribers or wired ISDN subscribers in the CSC) and in the ISDN/PSTN network (fixed network subscriber) of defined statuses of the call setup. Information about call states in the form of announcements, tones and indications to the MS are of particular importance and these lead to the cleardown (release) of a circuitswitched call if the dialed destination is not reached. Furthermore, additional information such as convenience tones or service indications can accompany the call setup. Tones and announcements are project-specific in the PLMN (in the MSC network element). Additional tones are also generated in the MS terminal (supervisory tones according to
172
DRAFT
A50016-D1112-V41-2-7618
Information System
3GPP standard). For IN applications there is an Specialized Resource Function (SRF) which allows such facilities as user-defined IN announcements. The PLMN operator can assign various specific announcements to all the important clearing down/call cancellation causes (in particular MAP causes) defined in the 3GPP standards, and additional project-specific causes. Thanks to an extremely specific range of call cancellation-related announcements, the PLMN operator can offer the mobile subscribers a correspondingly high standard of user convenience. Announcements caused by external release This service (sometimes called who called (WHC)) is implemented on voice mail service (VMS) side and it is activated if called subscriber does not have call forwarding (CF) to VMS (that is, call back to VMS is active for all subscribers). After detection of CF to WHC service, an ISUP connection to WHC platform is established and WHC service is activated. The same scenario occurs if a called subscriber has CF to VMS, but calling party hangs up (slams down) before leaving voice message. WHC service does not open this ISUP connection, but utilizes needed parameters from correlating ISUP message and releases that connection. The release message contains predefined release cause (this release cause values can be different according to different scenarios and depends on customer request). The benefit for the PLMN operator, who uses this feature, is that the calling party is informed about WHC service with a CN announcement and he not initiates a new call again. This reduces unnecessary load in the PLMN. Also, a notification to the called party about the missed call is sent. When MSC gets release message (RLC) and cause the specific 2G/3G PLMN charge - free announcement must be played (that is, the subscriber you have dialed is currently not on, but he is notified about this call.). When the mobile subscriber becomes reachable again, he is informed about lost calls during unreachable period with SMS message (created by WHC service).
4.5.16
Support of DTMF for Mobile Subscribers

3GPP standards define the support of dual tone multifrequency (DTMF) signaling for mobile subscribers. In a 2G PLMN, the 2G MSC or 2G MSC part must support DTMF in the MS to land direction, but not vice versa. This facility is also requested for 3G. The use of DTMF is permitted only if the speech telephony teleservice is used and alternate speech telephony/facsimile teleservice. The responsibility for checking this lies in the mobile station. There are tow possibilities to transfer DTMF tones: Outband Inband
Within the reduced system architecture of MSC/VLR in current software version only the DTMF reception (detection and removal) remains as functionality in the CS-MGW. The DTMF tones is inserted in the MSC Server by the LTG. Outband transfer of DTMF tones is done on A interface, Iu interface and Nc interface (which is used for traffic over ATM CN - see also 4.12.1, MSC Server (MSC-S) Part and Circuit-Switched Media Gateway (CS-MGW) Part). Inband transfer of DTMF tones is done on TDM backbone with SS7:ISUP and Nc interface (which is used for traffic over ATM CN).
A50016-D1112-V41-2-7618
DRAFT
173
Information System
4.6
Charging and Billing - for Trafc over TDM CN

The charging and billing functions follow the corresponding requirements of 3GPP standards. Charging Charging is an overall term for the whole accounting function and the limited pre-billing functions within the network elements or in co-operation with add-on service platforms (e.g., IN/CAMEL). Such pre-billing functions are for example zone and charge determination.
The term accounting is sometimes used as a synonym to charging. Charging can be subdivided into two following categories: Ofine method The ofine method is the traditional one. The PLMN operator performs the communication service, that is, the resource usage by the mobile subscriber, before payment by the responsible mobile subscriber. The charge is calculated at the earliest after nishing of the communication service or service part. Further delay depends on the billing processing. that is, the PLMN operator goes in submission. Online method The online method is the contrary method. The charge is calculated during running of the communication service. On the one hand the result can be used for advice (see supplementary service advice of charge, AoC) to the service lifetime, on the other hand mobile subscriber supervision and pre-paid service can be done. In contrast to the ofine charging method the charge is calculated before or during network usage. In case of pre-paid service the mobile subscriber goes in submission (gives a credit) by pre-charge of an account. This account is counted down during the communication service. Charging is done for two purposes: Mobile subscriber charging The main purpose is mobile subscriber charging. The mobile subscriber, who was (ofine charging) / is (online charging) responsible for the communication service or service part, is debited with a related bill. For that mobile subscriber and communication service related data are collected and processed for the relationship mobile subscriber (user) - PLMN operator (network). Mobile subscriber charging is done within the network elements of the visited network (e.g., MSC). Inter-administration charging The second purpose is the inter-administration charging between different PLMN operators. If a communication service covers different administration areas (networks) a charge balancing for mutual resource usage is done. For that communication service related data at the network gateways are collected and processed for the relationship PLMN operator - PLMN operator. Inter-administration charging is done on the network gateways of the involved neighboring networks (e.g., circuitswitched domain: Gateway-MSC). But also the mobile subscriber charging output can be used for making inter-administration billing.
174
DRAFT
Billing
Billing is the function of the Administration and Billing Center (ABC), that is, outside of the network elements. The charging related data delivered by the network elements are correlated with a relevant tariff model in order to create the bill. The bill is used for pay-
A50016-D1112-V41-2-7618
Information System
ment demand to the mobile subscriber, responsible for the whole communication service or service part. Charging and billing principles The following charging and billing principles exist: For charging the related data are collected within these network elements where the user access to the PLMN is done and where additional services (e.g., supplementary services and IN/CAMEL services) are used for modication and enhancement of the origin communication service request. The related data are collected within these network elements (that is, MSC) where additional peripheral equipment (e.g., recording of voice mailbox via MSC transit call tickets) is connected. The related data are collected at the network gateways in case of internetwork services. Mobile subscriber charging can be also used, if the information is sufcient, which is not collect directly at the gateway. The related data are not exchanged via administration (network) borders. Only unique identier (charging ID) can be exchanged between the network elements involved into the communication service signaling. Such unique identiers comply with different standards and can be used for charging data correlation from one or different networks. Billing for the mobile subscriber is always done from the home PLMN (HPLMN) operator (or service provider). In the case of a roaming mobile subscriber within a visited PLMN (VPLMN) or service usage within a foreign network the charging data has to be forwarded from the visited to the home PLMN operator (or service provider). Data exchange is done between the ABCs via the transferred account procedure (TAP) procedure by using of a clearinghouse. The tariff modelling and price building is the task of the PLMN operator (or provider). Charging has the task to provide the necessary information about the communication service in order to classify which tariff model has to be used for anyone. The charge for inter-administration communication services is done between the ABCs. The charge is a sub-amount received via mobile subscriber billing. The billing base of circuit-switched domain is the duration of resource usage. The using of the mobile subscriber charging can do the inter-administration charging. In addition the inter-administration charging within circuit-switched domain is supported via the CPplatform basis function IACHASTA (section 4.6.4). Charging covers the following main functions within the network elements: 1. Charging collection function Collection of charging related data Generation of charging records at dened communication service events Formatting of the charging records 2. Charging gateway function / interface to billing domain Storage of the charging records on non-volatile memory Interface provision to ABC 3. Special charging features Online charging by network element based zoning or IN/CAMEL based charge calculation Charging of prepaid subscriber Distance related charging Subscriber dependent digit processing and feature control (SDDPFC)
A50016-D1112-V41-2-7618
DRAFT
175
Information System
4.6.1
Charging Collection Function (Generation of Call Data Recordings)

In the circuit-switched domain of the PLMN (that is, CN), detailed call data is generated for the mobile subscriber during every call transaction. The call data recordings can be used for charge registration, network management and supervision purposes. After the call data recordings have been generated they can be provided with customer-specific data record formatting. For different kind of subscribers, that is, mobile subscribers (and WLL-subscribers or wired ISDN subscribers at CSC) Mobile call record (MCR) data records are used for mobile subscribers. The recording of charge data by the IN/CAMEL network node M-SSP is usually also performed by automatic charge data recording. This is described, in more detail under IN/CAMEL charging collection function (section 4.6.6). The billing basis of circuit-switched calls is the duration of resource use.
The charging collection function general data collector (GDC) is implemented on the MP-platform. The GDC is also used in packet-switched of CN (CNps) as collection service for collecting data for charging, lawful interception (only CNps), and in the future traffic measurement, etc. Automatic raw charge data recording The call charges for mobile subscribers in the PLMN can be recorded by automatic raw charge data recording. Generally, automatic charge data recording generates at least one regular charge data record for every successful call or the use of a service. MCR raw charge data recordings for mobile subscribers Regular MCR charge data records are generated for the following kinds of circuitswitched calls: MOC (for the calling mobile subscriber) MTC (for the called mobile subscriber) Mobile-to-mobile (one data record each for the calling and the called mobile subscriber) Emergency calls Direct access calls Transit calls. Additionally, MCR raw charge data records are generally generated for all successful transactions of the following types: Subscriber controlled input (SCI) Short message service (SMS) - mobile originated (MO)/terminated (MT) Location service requests. This MCR raw charge data record contains all the important call information, including: Type of call (e.g., MOC, MTC) Date, time and duration of call (where applicable, e.g., not at SMS) Identity of calling mobile subscriber (IMSI, MSISDN) Identity of called mobile subscriber (IMSI, MSISDN) Telecommunication services used. The regular MCR raw charge data records are generated in the visited MSC network element or Gateway MSC (GMSC).
176
DRAFT
At visited MSC (VMSC) MCR charge data records are generated for: MOC Emergency call
A50016-D1112-V41-2-7618
Information System
MTC Call forwarding (VLR detected) SMS SCI (usage of supplementary services) Location services
At interrogating gateway MSC (GMSC) MCR charge data records are generated for: Call forwarding (HLR detected) Roaming (interrogation) Terminating CAMEL trigger (section 4.6.6) Location services Transit trafc (if no other record is generated at this network node) In order to permit immediate calculation of the charges in the MSC, it is possible to dene tariffs and zones, that is combinations of parameters (that are also used by the supplementary service advice of charge (AoC), see also section 4.6.6) from which the number of charge units can be calculated as a function of the duration of the call. This data is then also contained in the MCR data record together with the calculation parameters. MCR raw charge data record types There are the following main types of MCR: Call records: Call charging is applicable to all MOC (including emergency calls), MTC, SMS-MO/MT and location services (terminating). Roaming records: Separate MCR records is generated for HLR interrogations if the HLR interrogation returns an MSRN. These records are called roaming records that can be used e.g., for inter-network charging verication purposes. Transit records: Whenever a call is routed over an MSC and the call does neither originate nor terminate in this MSC, then a charging record (transit record) can be generated in this MSC to allow the PLMN operator to trace calls throughout his network. If no roaming record is generated a transit record can be generated. The roaming record and transit record are mutually exclusive.
Customer-specific data record formatting If necessary, the regular mobile call record (MCR) can be converted into a customerspecific data record format before being transferred to a particular Administration and Billing Center (ABC). In the ABC data records are processed according to their use (e.g., for calculating the total charges to the mobile subscriber served). The corresponding process is MP-platform based. The MCR raw data records are formatted into call detail record (CDRs) using ASN.1 format and stored on MP disk file on the main processor MP:OAM (or optional MP:OAMD) and downloaded with FTP via an Ethernet link (TCP/IP). A maximum transfer rate of 1 Mbit/s can be achieved. It allows a higher transfer rate and the use of a new IP-based protocol for connecting the Administration and Billing Center (ABC) to the MSC. Simple ticket layout administration For more flexibility in ticket layout usage SIEMENS supports to configure the layout of the call detailed records (CDRs).
A50016-D1112-V41-2-7618
DRAFT
The simple ticket layout administration feature allows the layout of call detail records (CDRs) to be administered for the circuit-switched domain of CN. The following charging items can be administered on the MP-platform: Data record format version used for the charging gateway protocol
177
Information System
Layouts for different client records
In the same time schedule, the administration interface of the SGSN is adapted to become the same kind as the interface being used at MSC in the CN. Thus, a common administration interface for CDR layout administration for MSC (based on MP-platform) and SGSN is made available.
4.6.2
Charging Gateway Function (CGF) / Interface to Billing Domain

The circuit-switched (and packet-switched) communication networks support the following basic functionality for connection to the billing domain: Storage of charging information (tickets and meter) on non-violate memory Standardized interface Within the packet-switched domain standardization, this function is called charging gateway function (CGF). Within the circuit-switched domain, this term was not defined; however, this function has existed for a long time. There are two types of CGF: Distributed CGF localized within the network elements Central CGF as external device, also called charging gateway (CG) Distributed CGF As the ticket storage medium the local hard disk of network element is used. For that a pre-allocated range is reserved by administration. The configurations for MSC depend on the network element HW architecture. For files containing tickets the following configurations are possible in the circuitswitched domain: - MSC (with CP+MP-platform): MP:OAM hard disk with file array system - MSC (with CP+MP-platform): MP:OAMD/ACCIO (charging) hard disk with file array system As ticket transfer interface the O&M interface of the network elements with file oriented procedure is used. For files containing tickets the following configurations are possible: - MSC (with CP+MP-platform): TCP/IP with FTP FTP supports the pull mechanism, that is, the remote Administration and Billing Center (ABC) has to request the file transfer. Centralized CGF The ticket storage medium is outside the network elements, which handle the user traffic, on an independent device, that is, a local disk isn't required. Such independent devices are billing mediation device (BMD) but also hot billing server. Additionally, the HOP can work optionally with network element local storage capability as a fallback facility in case of interface failure. The HOP supports two modes - near real time and real time mode.
Near real time billing is supported as network element feature for all charging. It needs a transaction-oriented procedure for ticket bundle transfer. It is an alternative transport mechanism to the file-oriented principal (e.g., FTP):
178
DRAFT
- MSC (with CP+MP-platform):
Hot operation protocols (HOP or GTP/CGP via TCP/IP
A50016-D1112-V41-2-7618
Information System
Real time billing is supported as the subscriber feature hot billing for limited amount of mobile subscribers. It needs a transaction-oriented procedure for single ticket transfer:
- MSC (with CP+MP-platform): Hot operation protocols (HOP or GTP/CGP via TCP/IP
4.6.3
Charging with Hot Operation

The general data collector (GDC) for circuit-switched services, that is supported on the MP-platform, make either the SIEMENS proprietary hot operation protocol (HOP) or the standardized data transfer protocol GTP/CGP (well known form packet-switched CN at the Ga interface) via TCP/IP available.
The PLMN operator of an MSC have the choice, either to use the HOP based solution for circuit-switched hot operation features, or to use the GTP based solution (also called charging gateway protocol (CGP). The hot operation protocols creates a push mechanism - transaction oriented - over TCP/IP. The hot operation protocols provide the PLMN operator with the necessary transfer protocol to implement hot billing functionality as real-time and near-real-time billing. The term hot operation covers all cases in which MCR data records are, in addition, generated and/or formatted and transmitted to a dedicated processing center via the Ethernet (with TCP/IP) while a call is still in progress or immediately after it has ended. The following four applications exist for this: Hot billing data records Hot billing data records which are gathered in the MSC permit the system operator to produce detailed charge statements at short notice irrespective of the normal rhythm of data post-processing. In the case of hot billing, the charge data records generated for an MOC, MTC, call forwarding (CF), emergency call, SCI and SMS in the MSC are formatted immediately after the end of the call and sent to a Administration and Billing Center (ABC) over the Ethernet (with TCP/IP). The normal charge processing via the regular charge data records is not affected or changed by this processing of the MCR data. Emergency call trace data records Emergency call trace data records which are gathered in the MSC permit the system operator to send call data records for emergency calls to a Administration and Billing Center (ABC) immediately, as in the case of hot billing. IMSI trace data records IMSI trace data records permit the PLMN operator to trace the activities of a mobile subscriber in the PLMN for network management and supervision purposes. These data records can be sent to a trace center immediately after creation (see section 4.13.2).
A50016-D1112-V41-2-7618
DRAFT
Interception data records are not transferred via HP or GTP/CGP protocol but are transferred Q3 notication based via TCP/IP protocol to a monitoring center (see section 4.10.8, Lawful Interception Package). The same is with immediate printout. The immediate printout feature allows certain messages to be printed directly to a special printer located at the MSC. It is a prerequisite for activation of the following features: Generation of printouts for emergency call trace, generation of printout for charging failures, and enhanced threshold reporting.
179
Information System
4.6.4
Interadministrative Procedures for Billing/Revenue Accounting (IACHASTA)

A large proportion of telephone communication is conducted at national and international long-distance level. Depending on a PLMN telecommunication structure, mobile subscribers can leave a PLMN service area at the national or international level when they call a subscriber in the service area of another PLMN or the PSTN. For interadministrative charging between different PLMN operators the traffic between the service areas is registered. The revenue accounting is based on the volume of traffic. It records call data coming from a specific origin, going to a specific destination, or a combination of both. Charging is based on the traffic volume and encompasses call data from all (only possible for IACAMA registrations) or selectable traffic relations. These traffic relations can be stored in the database as origins, destinations or origin-destination combinations. Thus the IACHASTA (interadministration charging and statistics) function is a flexible procedure for charge accounting between different PLMNs and permanent networks within a country, or between different countries. The principle of this procedure is: suitable metering procedures for recording the connection trafc and suitable output formats of the metered data. This procedure can either be used in the GMSC or in the gateway switching center of the PSTN/ISDN. IACHASTA operates in the following sequence: Registration of call data per call for predened trafc relations Storage of this data Output of registered call data to postprocessing for further processing The advantages of IACHASTA are the simple and straightforward handling of the database by defining the metered data as single-sided or double-sided registration points. Additional functions such as statistical metering and trunk metering are contained in the main functions. IACHASTA uses the following main functions: IACMET (Interadministration charging and statistics with meters) enables the output of sum records onto meters. IACAMA (Interadministration charging and statistics with AMA tickets) Facilitates the output of exact and comprehensible recordings for each single connection. This can be interesting, for example, when comparing different transit networks. The revenue accounting is based on the volume of traffic. It records call data coming from a specific origin, going to a specific destination, or a combination of both. Charging is based on the traffic volume and encompasses call data from all (only possible for IACAMA registrations) or selectable traffic relations. These traffic relations can be stored in the database as origins, destinations or origin-destination combinations. The interadministration charging tickets can be stored on MSC either on: hard disk of MP:OAM or MP:OAMD/ACCIO using sequential access method le array (SAMAR) les or hard disk of CP platform using le array system
180
DRAFT
A50016-D1112-V41-2-7618
Information System
4.6.5
Charging for IN/CAMEL Subscribers

The introduction of highly-developed Intelligent Network (IN)/Customized Application for Mobile Network Enhanced Logic (CAMEL) services in a PLMN (circuit-switched domain) requires an expansion of the previous circuit-switched charging concept. The basic idea is for both parties involved, that is, the IN service user (calling line/party) and the service subscriber (called line/party) to share the charges accrued in a variety of very flexible ways. The question of Who pays for what? must always be answered in a service-independent and service subscriber-specific arrangement. There are basically two ways of charging for IN/CAMEL calls: Charge recording based on the M-SSP Charge recording via the SCP/CSE and SMP.
Although in CN (circuit-switched domain), both charging scenarios are possible, this system description only describes call charging based on M-SSP. For call charging based on SCP/CSE and SMP, only the information relevant for CN (circuit-switched domain) is described here. This function is part of the SIEMENS intelligent networks (IN) systems which is described in more detail in separate documentation. Charge recording based on the M-SSP Charge recording for the service user (calling line/party) with M-SSP This is based on the existing charge functions (see automatic charge data recording) in the PLMN. The SCP/CSE can inuence the charge recording, e.g., by transmitting/determining the zone numbers and AOC parameter to be used. The SCP/CSE can particularly inuence the charge recording for IN service users very exibly by transmitting transparent data by means of INAP/CAP signaling (send charging information). INAP/CAP signaling also takes the GSM bearer capability information into consideration to allow, for example, a service provider to charge at different tariffs. Altogether the SCP/CSE can overwrite anything that is administered in the M-SSP for charging purposes. Within this function (inuencing the charge recording with SCP/CSE), the IN solution of the GSM supplementary services AOC information level (AOCI) and charging level (AOCC) achieves a special subfunction for an MOC. This function allows the SCP/CSE to directly inuence the AOC charging parameter and therefore transmit the current charge information to the mobile subscriber. The SCP/CSE receives the necessary modied interfaces in the M-SSP for accepting this charging information from the INAP/CAP signaling (send charging information). Disadvantages of the 3GPP standard solution for AOC can be improved with this IN-AOC solution, e.g., the subscriber authorization data of the service user or the relevant service provider or the tariff model can be used here. Charge recording for the service subscriber with M-SSP In addition, the M-SSP can set a tariff for the service subscriber. The generation of this data record is controlled by the SCP/CSE. Another feature charging for IN/CAMEL service interworking enables the IN/CAMEL service logic to react to charging events that cannot be foreseen (e.g., tariff changes). The control for this charging application is done entirely by the M-SSP. With this feature the PLMN operator can create new applications which allow charging for the interworking of different IN/CAMEL services. For instance, charging for the interworking of IN prepaid service (PPS) and premium services can be dealt with. In the case where a call which has already been initiated with IN dialog (M-SSP with SCP/CSE) leads to a further IN/CAMEL service (and therefore to a further IN dialog)
A50016-D1112-V41-2-7618
DRAFT
181
Information System
during the remaining call processing sequence, the individual IN/CAMEL services can be charged individually to the service user in the M-SSP. In the event that a mobile subscriber has forwarded a call, which in turn leads to an IN dialog (the mobile subscriber therefore becomes an IN service user), IN-specic charge data can be recorded for the mobile subscriber in the call forwarding (CF) charge data record in the M-SSP. A special feature billing based on MCR makes the MCR more suitable for charging IN/CAMEL calls by adding IN/CAMEL-specic parameters (e.g., SCP/CSE destination routing address, SCP/CSE transparent data and service key). Using this feature enables the PLMN operator not only to charge calls for the use of PLMN resources (air time), but it also allows IN/CAMEL service-dependent charging. The billing center is no longer forced to handle an additional data stream of IN/CAMEL charge records with new les or new charge record types and there is no need to correlate them with the standard call records. In addition, this feature even makes it possible to apply charging features to standard MCR, such as hot billing, and also to IN/CAMEL calls.
Specifics of IN/CAMEL charge data for CAMEL-based calls are described in the relevant sections of CAMEL phases (e.g., provision of a unique call reference number (CRN) or online charging feature with the aid of the AoC supplementary service in connection with the IN prepaid service (PPS)). Charge recording via the SCP/CSE and SMP (for the service subscriber) Charge recording via the SCP/CSE and SMP is based on the generation of data records for each IN/CAMEL call. The required data is gathered in the SCP/CSE (using the call data supplied by the M-SSP which is sent at regular intervals to the SCP/CSE). The SCP/CSE generates the customer-specific records from this data. Generally speaking, charge data recording via the SCP/CSE is used for charging the service subscriber. The SCP/CSE buffers the charge data record and forwards it to the SMP. There it is stored for further use. Online charging for the mobile subscriber-specific IN/CAMEL application prepaid service (PPS, see section 3.3.1.3) is an important case where the call charges are not only recorded in the SCP/CSE but deducted from the sum of money stored for the mobile subscriber. The mobile subscriber can interrogate the sum of money stored in the SCP/CSE current account using either USSD or DTMF. It is also possible to make a charging record.
4.6.6
Special Charging Features

Charging for prepaid subscribers By the help of IN/CAMEL charging (see above) charging of a prepaid subscriber is implemented (see also section 3.3.1.3, Support of Prepaid Service for Circuit-Switched Services). Charging for fixed (wired) subscribers on a CSC For calls terminating to/originating from fixed (wired) subscribers the following charging records can be generated at the MSC: SUB originating call record SUB terminating call record
182
DRAFT
A50016-D1112-V41-2-7618
Information System
Charging for PABXs on a CSC For calls/transactions terminating to/originating from PABXs the following charging records are generated at the MSC: PABX originating call record PABX terminating call record Zoning and tariffs For the determination of online-charging a distinction is made between: Charge unit collection and Advice of charge (AoC)
Charge unit collection is performed in the MSC. The amount of charges calculated can be stored in the mobile call record for the respective connection. Advice of charge (AoC) is performed by the mobile station. The mobile subscriber is thus informed of the charges for a current connection. Two different kinds of AoC are applicable (AoC information level and AoC charging level). For details refer System Description, register Network System Concept. Both procedures yield a number of charge units as result.
The charge units are calculated depending on the usual parameters like call duration, call destination, date and time. A database has to be defined which allows the MSC and the MS to calculate charge units depending on these parameters. A tariff is a set of parameters which allow calculation of call charges depending on the call duration. These parameters do not explicitly depend on day, time or call event. The valid tariff for a connection is determined by means of zoning. This means that for any possible call event (for example dialing a digit combination for MOC) and for any possible day and time a mobile zone point and a mobile zone have to be set up, which link this call event to a tariff. The zoning of a connection is normally done in the visited MSC, but zoning information can be received as well from another MSC or from the Intelligent Network. For calls to the IN/CAMEL, zoning is usually performed by the SCP/CSE. Details on IN/CAMEL charging see above. The generation of mobile call records can also be controlled by means of zoning. Zoning is applicable for the following events: Mobile originating call (zoning in the originating MSC) Mobile terminating call (if zoning wasnt performed in the originating MSC) Call forwarding Transit calls Call attempts Short message service Subscriber controlled input
A50016-D1112-V41-2-7618
DRAFT
183
Information System
Subscriber dependent digit processing and feature control (SDDPFC)
SDDPFC provides a very comprehensive and flexible way of modifying standard call control. Since SDDPFC is evaluated before current digit processing, the standard behavior expected under normal circumstances can be changed significantly. Therefore, caution is advised when using this feature. A detailed description of SDDPFC is given in the section 4.7. Only the charging-relevant parts are mentioned here. When defining an action with a Q.3/MML command, information for charging control of that action can be given. A special parameter specifies if further zoning information is given in this action. Zoning information contained in an SDDPFC action can be: Zoning characteristics Mobile zone Take over zoning information Generation of MCR records required Distance related charging This function, distance-related charging (DRC), records charges directly from the calls, especially from mobile-to-mobile calls (MMC), depending on the distance between the A subscriber and the B subscriber. In this way a call for the mobile subscriber is cheaper if the call partners are nearer to each other (e.g., within a city with one city tariff) compared to a connection between opposite ends of a country. Even the combination of distance-related to e.g., calender/time of day is conceivable for an MCR. Local information about the call partners is provided for data post-processing. The total charges for a connection from the A subscriber and the B subscriber are usually achieved with the combination of MOC and MTC charge records in a Accounting and Billing System (ABC). Until now, only time and calender related charges (e.g., evening tariff, business tariff) have been used to make the PLMN attractive for mobile subscribers. The introduction of the DRC function enables mobile subscribers to use distance-related charge tariffs. DRC is applied to call charging for mobile subscribers who either introduce an MOC, resulting in a mobile-to-mobile call (MMC) or in a call into a PSTN, or introduce call forwarding (CF). The roaming charge records (ROA) contains the destination point of a connection (B subscriber) for calls within the same PLMN. The MOC and CF charging records contain a tariff value at the beginning of the connection for calls which end outside the PLMN (e.g., a connection in the PSTN). Data records for DRC usually contain the following additional parameters: General call identity, C-ID Call related number, CRN Charging origin, CO Tariff class, TC. The C-ID and CRN are needed in data post-processing for identifying the charging records of a connection or a connection branch. The C-ID represents the first charging record and the CRN describes all the following charging records. The CO value, represents the charge value of the A or B, which can be administered on the basis of base station cells. Up to 150 different charging areas (based on base station radio cells) can be administered. The information about the CO is sufficient for mobile internal calls (MIC) that is, calls which originate and terminate in one and the same MSC network element. For all other
184
DRAFT
A50016-D1112-V41-2-7618
Information System
calls the charging records belonging to one connection, but coming from different MSCs (mobile-to-mobile call, MMC) are correlated with the parameter TC. General call identity (C-ID) To correlate all charging records of a call within the own PLMN in the postprocessing center a general call identity (C-ID) is included in each record by the MSC's. The MSC which sets up the call in the PLMN first generates a general call identity. This unique ID is signaled in forward direction together with the destination number to the next MSC if necessary. So all involved MSCs include the same call ID in all generated billing records which are related to this call. Later the Administration and Billing Center (ABC) is able to correlate the billing data of all records of a call from one or different MSCs. It is also possible to generate a new ID at every call forwarding for the call forwarding record and all other following records. So an own general call identity is assigned to each leg of a call that has to be charged. Furthermore it is possible to mark each billing record which is not the first of the call. All generated records of a call contain the same ID like general call identity. But the ID of the following records is marked and is called call related number. The general call identity is applicable within the same PLMN by usage of ISUP signaling only. Call reference number (CRN) If interrogation has to be done for a mobile subscriber a call reference number (CRN) is generated if MAP v3 applies. A CRN is also generated if a mobile subscriber originates a call which leads to an IN/CAMEL dialog (O-CSI, dialed IN/CAMEL number) or a short message transmission (O-CSI/SMS-MO-CSI only), or if a short message transmission is started towards him (SMS-MT-CSI). The CRN is available in the GMSC (interrogation), VMSC (MOC, MTC, SMS-MO, SMS-MT), and in the SCP/CSE. In addition to the functionality of the CRN with IN/CAMEL calls, the CRN is generated for each call coming in at an GMSC if MAP v3 is available. The CRN is then also be available in the VMSC. CRN generation in CDRs of labelled IN/CAMEL mobile subscribers This feature controls the writing of the call reference number (CRN) in the call detail records (CDRs) of IN/CAMEL subscribers. For mobile subscribers labelled by certain properties set by the PLMN operator, the CRN is written in the CDR. Otherwise it is removed. This feature can be used to distinguish CDRs of prepaid mobile subscribers from those of postpaid mobile subscribers. Nevertheless this feature can be applied to other cases, e.g., to distinguish CDRs of virtual private network (VPN) mobile subscribers. The PLMN operator benefit is the ability to use the CRN to differentiate the CDRs of labelled IN/CAMEL mobile subscribers. Thus, CDRs with CRN can be sorted and handled in a different way. For prepaid service, this feature is of a great advantage, since the phone number range need not be used any more as a criterion for differentiation of prepaid and postpaid mobile subscribers in the Administration and Billing Center (ABC). Mobile subscribers can then be migrated from postpaid to prepaid and vice versa while keeping the same phone number.
A50016-D1112-V41-2-7618
DRAFT
Unified handling of general call identity (C-ID) and call reference number (CRN) Both features general call identity and call reference number have different properties which are listed in the following: General call identity (C-ID)
185
Information System
Unique for all records of the whole call within the PLMN Transported via ISUP as a proprietary solution Not known outside the PLMN The general call identity is available in all normal subscriber MCR charging records of the call within the PLMN but not in SCP/CSE and not in M-SSP (INA charging records). Call reference number (CRN) Unique for all records relating to a particular subscriber involved in a call Transported via MAP and CAP The call reference number is available in the subscriber records of the originating and terminating switches of the call, in HPLMN and VPLMN, but not in transit records. Moreover it is available in SCP/CSE and in M-SSP (INA charging records).
Now a network option allows to combine the advantages of both features in order to make the correlation of all MCR charging records (normal subscriber, SCP/CSE, M-SSP (INA)) possible. If the network option is active the general call identity is taken when a call reference number is necessary, and vice versa. Thus, an SCP record (with a call reference number) can be correlated with a Transit ticket (with a general call identity). Call duration treatment In the following both normal MCR charging records in MSC and INA charging records in M-SSP are considered. In difference to MSC billing records, IN/CAMEL records are characterized by the fact that the record generation is initiated by the SCP/CSE by means of the operation FurnishChargingInformation. Main part of an MCR charging record in MSC In general, the start time stamp is set with the seizure of a trafc channel. If a ISUP answer message is received (possibly to be forwarded in backward direction), the time stamp is updated. The call duration measurement starts when the start time stamp is set. The measurement of the call duration is stopped when dened events occurs on the connection where the billing record is related to. The time stamps as well as the call duration in the main part of partial records that belong to one sequence appear as an uninterrupted time sequence of the entire call. The call duration value always corresponds to the time stamp, that is, in a sequence of partial records a time stamp is always equal to a previous time stamp + call duration. CAMEL related data of an MCR charging record in MSC The CAMEL related data is included in MCR charging records with IN invocation. The call duration measurement is started when the start time stamp is set. The call duration measurement in the CAMEL common data is stopped by the same events that stop the measurement of the call duration in the main part of the respective MCR charging record in MSC. INA charging record in M-SSP An INA charging record in M-SSP is started under dened conditions. A new partial INA charging record is started only when the intermediate record timer expires. The measurement of the call duration is started when the start time stamp is set. The call duration measurement in INA charging record is stopped by the same events that stop the measurement of the call duration in the main part of the respective MCR charging record, except subscriber controlled (SCI) operation. The time stamps as well as the call duration of partial INA charging records that belong to one sequence appear as an uninterrupted time sequence of the entire call. The call duration value always corresponds to the time stamp, that is, in a sequence
186
DRAFT
A50016-D1112-V41-2-7618
Information System
of partial records a time stamp is always equal to a previous time stamp + call duration. Rened granularity of time stamp and duration Both time stamp and duration are available with a granularity ner than 1 s. The provision of time stamp and duration in rened granularity is available as special codings of the corresponding parameters and can be administered via the billing data base. As default setting, a rened accuracy of 0.1 s is available. The nest supported accuracy is 0.01 s. Special data base adaptations are necessary. All general rules as described above remain valid. However, it is recommended to use like accuracy for time stamp and duration parameters in order to avoid inconsistencies in a sequence of partial records
Call duration before answer in call detail record This feature performs the writing of the call duration before the reception of the answering signal from the B party in the call detail records (CDRs). This duration is calculated for the main types of CDRs generated for subscriber charging. The PLMN operator can consider the duration of the call before the reception of the answering signal, in other words the call set-up duration, for the charging of its mobile subscribers. Indeed the call set-up duration is an indication on the resources provided by the PLMN operator to the mobile subscribers for the call set-up. So mobile subscribers can be charged according to it. Call record sequence numbering A unique record sequence number per storage file is included in the charging record. There are separate sequence counters for non-IN charging records and IN charging records. In case of multiple call records, e.g., partial records for long duration calls, each partial record contains a unique sequence number. The following kinds of mobile records are generated: MCR charging record: A sequence number is added to every generated record. Hot operation (HOTOP) charging record: This is the same record as an MCR charging record, sent via TCP/IP (hot billing), so the sequence number must be the same one as the MCR sequence number. MCRI charging record (at hot operation immediate printout): This record has never a sequence number. INA charging record: A sequence number is added to every generated record. Intermediate records numbering The idea is to have a mechanism to give a sequence number data field for intermediate records. Each time an intermediate record is generated, this field is incremented. The field can be used for all charging records - MCR, HOTOP (hot operation hot billing), and ITR (hot operation IMSI tracing) - that have intermediate records and is available only in records which are not single, that is, in first_intermediate, intermediate and last records. Partial charging record generation Whenever the recording of a call is split into more than one record, partial records as a sequence of a first intermediate record, optional intermediate records, and a last record are generated except in case of in-call modification where each call phase after in-call modification is treated like a separate call. All partial records get a partial record correlation ID (PRCID).
A50016-D1112-V41-2-7618
DRAFT
187
Information System
The generation of partial records can be required due to several reasons which are listed below: Depending on call duration In-call modication BS30 service change (that is, service change and UDI fallback (SCUDIF)) Follow-on calls HSCSD calls Transfer calls Change of charge parameters Inter-PLMN handover/relocation (in case of feature support of multiple PLMN on MSC/VLR) Data services To charge data calls properly, a lot of parameters are collected and registered in the appropriate charging records. Following specialities should be mentioned: Bearer service dedicated PAD For the bearer service dedicated PAD a similar option as for OACSU can be activated: When the MS has dialled a short code for the bearer service dedicated PAD, this can be marked in the MODPAD charging record by means of a special call transaction type (instead of MOC in standard case). Autobauding modems When autobauding modems are used to setup a data service call, the user rate signaled can differ from the rate really used by the MS. The user rate signaled is recorded in the charging record. The maximum user rate being possible over the radio interface for this connection is recorded in the charging record. High-speed circuit-switched data (HSCSD) (2G only) HSCSD and TCH/F14.4 (traffic channel/full rate) enables higher user rates on the A interface. TCH/F14.4 allows a user rate of 14.4 kbits/s on one channel. This is implemented by providing a new channel coding. The MOC and MTC charging records contain an indication whether HSCSD was invoked and the according number of used channels, the MS access rate and the channel coding. Whenever HSCSD data are changed a new MOC / MTC charging record is written. In this case the record sequencing (first intermediate / intermediate / last records, sequence numbering) applies in contrast to in-call modification where at each modification single records are written. Charging for ASCI calls (2G only) The VGCS and VBS services allow speech conversation of a predefined group of service subscribers located within a predefined area. Service subscribers located outside the group area not takes part in an ongoing VGCS or VBS and cannot initiate any group or broadcast call. ASCI calls are supported within several MSC's while the MSC where the ASCI call was initiated is called the anchor MSC. The other MSC's which are involved in the ASCI call are called remote MSC's.
188
DRAFT
The dispatchers and any initiating service subscriber are connected to a conference bridge. All downlinks are additionally connected to one port of the conference device. The speech signal distribution over all downlinks is handled with the broadcast facility of the switching network.
A50016-D1112-V41-2-7618
Information System
For an ASCI call no charging records is written for the subscribers taking part in a VBS or VGCS. Instead one summary ASCI charging record is written per ASCI call in each involved MSC which contains the following data (all parameters are available in the AMSC, the bold ones are also available in the R-MSC): InitiatorID Initiator type Initiating IMSI Teleservice indicator Dialled number Group call reference Number of cells in group Number of cells with success Number of dispatchers in group eMLPP priority Number of remote MSC's in group Number of remote MSC's with successful set up VGS speech codec In case dispatchers participate in the group or broadcast call, the normal charging records is generated additionally in all MSC's which are in the call paths to and from the dispatchers and which differ from the anchor MSC. Supplementary service record control Chargeable supplementary services (SSs) actions are subject to respective billing. For each programming action (registration, activation, erasure, deactivation, interrogation) a separate charging record is created. This record is called the subscriber controlled input (SCI) record (exception: SCI at a PABX is not recorded). The invocation/activation of any particular service during a call processing transaction is noted in the charging record for additional charging. Furthermore, for some supplementary services the invocation/activation can be noted in a separate charging record. This record has the same format as an SCI record, but the field call transaction type contains a special value for SS invocation/SS activation. Handover There is no impact on any charging aspect described in this document in case of Handover. Changes of handover related data are not included in the charging records (e.g., radio cell identifiers, transmission mode). The controlling MSC is informed and has control over all actions concerning the MS as long as the call is not released. In the context of support of multiple PLMN, the events of an inter-PLMN handover are recorded in the records (see following topic). Multiple PLMN With the introduction of this feature an MSC can be logically split to serve more than one RAN (RAN sharing mode) and/or to support mobile subscribers of different PLMNs with the functionality of their home networks. The MCR charging records are enhanced with a new parameter indicating the serving PLMN. Furthermore, inter-PLMN handovers are recorded by providing the target cell and corresponding handover time stamp. Dependent on data base settings, inter-PLMN handovers are recorded upon each occurrence while a partial charging record is generated, or by collecting a sequence of handovers in one record, while a partial charging
A50016-D1112-V41-2-7618
DRAFT
189
Information System
record is also generated if the administered max. number of inter-PLMN handovers has been reached. Directed retry (2G only) When the assignment of a traffic channel is requested by an MS and the BSC is not able to support this request immediately then a traffic channel on a radio cell other than the serving cell is assigned. Directed retry does not influence the charging record parameter location number. Charging supports this feature in a way that the new served cell is stored in the charging records if applicable. Cell dependent charging The feature cell dependent charging provides the possibility to include the cell ID in the billing record where the call has been established. The cell ID is entered in the following format according to 3GPP standard: Mobile country code (MCC) Mobile network code (MNC) Location area code (LAC) Cell identication (CI) Cell dependent charging increases the flexibility of charging models for the service providers. With cell dependent charging the charging information depends not only on time, weekday and call destination, but could be specific for the originating radio cell. As an example, calls from fairs, conferences and other mass events could be charged differently based on a tariff scheme applicable just for this specific area, identified by a number of radio cells. The feature advice of charge (AOC) can use this feature enhancement. So the regional tariff structure can also be reflected in the AOC parameters transmitted to the mobile equipment. Location services Location services can be charged both for successful or unsuccessful location service requests and mobile originated (MO) and mobile originated (MT) location service requests, all switchable separately by network options. Additionally, separate switches exist for the charging of location services for own (HPLMN) or foreign subscribers. The presence of the location estimate in the MCR charging record is also switchable. Mobile number portability (NP) Mobile subscribers (as well as fixed network subscribers) have the possibility to select a new network provider by keeping the same number (MSISDN). To perform this, the numbers of the changing subscribers have to be ported to the new network provider. So the ported subscriber gets a new IMSI while he is further reachable with his old MSISDN. Whenever an mobile number portability (NP) query has been done, the query result is a location routing number (LRN) which usually is the received number with a certain prefix. There are several combinations possible between the mentioned options. Examples for MOC: If the received digits are ported in from another network and they are not within a ported number range (PNR), the call is routed to the subscriber's old network from where the call is rejected with a certain release cause (QoR), leading to the NP que-
190
DRAFT
A50016-D1112-V41-2-7618
Information System
ry in the own network (MOC charging record with NP impact). The LRN then leads to the HLR interrogation. If the digits are within a PNR, the NP query is done (QoD) and the call can be routed further with the LRN, e.g., leading to HLR interrogation (MOC ticket with NP impact). If the received digits are ported out to another network and they are not within a PNR (normal MOC charging record without NP impact), the HLR interrogation takes place leading to unknown subscriber. Then the NP query is performed (QoHR), and the call is routed to the ported-to network with the LRN (additional transit charging record with NP impact). If the digits are within a PNR, the NP query is done (QoD) and the call is routed to the ported-to network with the LRN.
Charging supports mobile number portability (NP) by storing all digits necessary for routing in the charging records. The result of the mobile number portability query (LRN) appears in a data field of the record. The MSC address of the switch which performed the mobile number portability query is stored in an additional data field, if the first mentioned field is present. Carrier routing If carrier routing applies, the chosen carrier access code (CAC) is provided in the corresponding charging record in order to support inter-operator billing business. Of course, the dialled CAC is also part of the dialledOtherParty if applicable. A dialled CAC is only supported for originating services, that is, mobile originating call (MOC) and direct access originating call (DAOC) charging records. For call forwarding (CF) only a preselected CAC applies; a forwarded to number (FTNO) must not contain a CAC because the FTNO has to be entered in international format. If a mobile subscriber is provided with originating CAMEL subscription information (O-CSI) and translation info flag CSI (TIFCSI) then also an FTNO including CAC is accepted and processed in the SCP/CSE. The CAC is provided in the following charging records: MOC, EMY, ROA, CF, DAOC, and Transit while only MOC and DAOC charging records might contain a dialled CAC. Tariff information received backward from the selected carrier cannot be processed in the MSC, e.g., for advice of charge (AoC) as the tariff models of the carriers are not known to the MSC, and the tariff information is defined different in PLMN and PSTN, and an interface is not standardized so far. A charge band number received from the carrier must not be processed in the MSC, either. Optimal routing Two categories of optimal routing are supported: Optimal routing of mobile-to-mobile calls or HLR detected CF (early CF) (ORMMC/ECF) Optimal routing of VLR detected CF (late CF) (ORLCF) In order to enable the PLMN operator to consider optimal routing aspects in the mobile subscriber billing, the billing records are extended by new parameters: ORMMC/ECF The corresponding parameter is available in charging records MOC, MTC, ROA, TCR, and CF. In the charging records ROA, TCR, and CF it indicates that MSRN/FTNO result from an international interrogation. In the MOC charging record it indicates that an international interrogation has been done with the dialled number (other party). An additional parameter contains the result of the international interrogation, so the
A50016-D1112-V41-2-7618
DRAFT
191
Information System
information is available where the call leg was nally routed to. In the MTC charging record it indicates that an international interrogation had been done before for this mobile subscriber. ORLCF The corresponding parameter is available in roaming (ROA) and call forwarding (CF) charging records. It indicates that a VLR detected CF has been handled in the GMSC. In the ROA charging record it indicates that the call had been routed to the VMSC as dened by the MSRN, but nally was handed back to the GMSC, that is the roaming leg was not present in the further call. In the CF charging record it indicates that the ticket was generated in the GMSC instead of the VMSC, therefore location and service relevant data (like cell ID or teleservice, which are usually available in CF records due to VLR detected CF) cannot be available.
With conventional routing, usually the calling subscriber has to pay for the leg to the called subscriber's HPLMN, while the called subscriber has to pay for the leg from his HPLMN to the VPLMN. With optimal routing it is finally up to the PLMN operator whether the benefit of the optimization is credited to the subscriber (in order to attract subscribers), or whether the optimization lowers the PLMN operation and inter-operator charging costs. Multinumbering (multi MSISDN) The function multinumbering is used for interworking between PLMNs and other networks (e.g., PSTN). Multinumbering means that a set of MSISDN numbers is assigned to one mobile subscriber. Each MSISDN number is associated to a specific GSM bearer capability information which represents normally a telecommunication service. One of these numbers is used as the basic MSISDN number. For charging in the MSC, the use of the feature multinumbering is only reflected in the contents of the following fields in the charging record: MSISDN' in served party identity other party third party Double IMSI The double IMSI feature makes it possible to have 2 IMSIs per subscriber, both IMSIs having the same or each its own MSISDN. Both IMSIs are linked in the HLR while only one IMSI is active and one is inactive. The latter becomes active upon location update or registration. When the MSISDN of the inactive IMSI is called, the HLR switches to the active IMSI and retrieves the corresponding MSRN. The MSRN is returned to the GMSC together with the active IMSI. This means that the GMSC knows the dialled inactive MSISDN and the active IMSI. Therefore the roaming (ROA) charging records and MTC charging records always contains the active IMSI while the active or inactive MSISDN is available according to the following table which bases on the following assumptions: A-party initiates call B-party active C-party inactive A-party calls C-party; the HLR routes the call to B-party
192
DRAFT
Preemption
Due to the features queuing and preemption it is possible that a call is released when another call with a higher priority level needs the radio resources to be freed. The forced
A50016-D1112-V41-2-7618
Information System
release of an MS due to higher priority call is recorded in its charging record by means of a reason for call failure (RCF). The value of the RCF is transparently copied into the call record. Off air call setup (OACSU) Even when OACSU is used for effective use of the radio interface resources the charging principles for MOCs have to be kept. That means, also in that case at the visited MSC of the charged mobile subscriber the call duration measurement starts when the traffic channel has been successfully assigned. A MOC charging record is marked when OACSU was used. Record suppression Options exist to suppress unwanted records by means of manufacturer switches. These options exist for the following charging records: Mobile terminating call (MTC) charging record for subscribers roaming in the HPLMN. With this option, MTC charging records for own subscribers are suppressed while MTC records for mobile subscribers roaming in a VPLMN are generated. Mobile originating short message service (SMS) point-to-point charging record (for home and/or foreign trafc (served IMSI and/or short message service center (SMSC) not belonging to the HPLMN) and for successful SCP/CSE query if applicable) Mobile terminating short message service (SMS) point-to-point charging record (for home and/or foreign trafc (served IMSI and/or short message service center (SMSC) not belonging to the HPLMN)) Transit record PABX incoming/outgoing record Digital service telephone incoming/outgoing charging record
4.7 i
Enhanced Functions of Call Handling, Charging and User Information - for Trafc over TDM CN
The enhanced functions of call handling, charging and user information described in sections 4.7.1 to 4.7.8 are pure CN (circuit-switched domain) functions on the whole and are based on the subscriber-dependent digit processing and feature control (SDDPFC) functionality. Section 4.7.9 to 4.7.12 describes an SCP-controlled IN function.
4.7.1
Flexible Routing of Calls in the CN (Circuit-Switched Domain)

The standard procedure provided to handle normal call setup assumes that, for a call, a digit translation is affected first. Subsequently, a particular destination is reached, for example via a specified destination and route, or a defined procedure is triggered by means of a particular traffic type. In the case of calls involving mobile subscribers and where the defined features are available the call data can be modified prior to the digit translation. This produces one of the following results: Modication of the entry data for digit translation and routing control, followed by the start of the normal procedure (that is, digit translation, etc.). Modication of data for call charge registration. Bypassing digit translation by means of direct transition to an IN service. Control (that is, application or prohibition) of specic features.
A50016-D1112-V41-2-7618
DRAFT
193
Information System
A consequence of this flexible routing of calls in the CN (subscriber-dependent digit processing and feature control, SDDPFC) is therefore that specifications derived from other entries in the database of CN nodes can be modified. In other words, it can lead to partly or completely different behavior than would have been expected under normal circumstances. For precisely this reason, this powerful and highly useful feature should be used with the greatest of care! The following steps must be taken to administer flexible routing of calls in the CN: Denition of the features of calls which lead to special treatment for exible routing (that is, the properties of calls that trigger subscriber-dependent behavior). Denition of actions for special treatment for exible routing. Denition of how multiple actions required at the same time are to be treated (priority, mutual exclusion).
4.7.2
A-Directory Number-Dependent Routing, Charging and Barring in the CN

These CN functions expand the flexible routing of calls in the CN (subscriber-dependent digit processing and feature control, SDDPFC) with a feature control (FC) element. It consists of the part functions: A-directory number-dependent routing. A-directory number charging (zoning). Black list for barring connections and white list for allowing connections. These three functions can be applied for: An MOC. MTC, at the GMSC (directory number of the called subscriber can inuence routing the GMSC to MSC). Call forwarding at the GMSC. The function of the A-directory number-dependent routing and charging can be used not only in the originating MSC, but also in the transit MSC. Approximately 20000 different directory numbers can be saved in the database in relation to this function. The operator can administer individual A-directory numbers which begin with the same digit combination. For example, entering 1234 into the database allows the same routing/call charging/barring of all A-directory numbers which begin with 1234. Possible uses for this part function are: Allow the routing of certain subscribers to certain destinations. Routing of special subscriber groups by means of abbreviated numbers which can only be used by subscribers who are administered in the database for routing dependent on A-directory numbers. Routing or zoning of special subscriber groups (e.g., all customers of a certain service provider) via selected trunks. In this way, the service provider can only select special (long distance carriers) for his customers. Preventing the routing of certain subscribers with the PLMN and the blacklist function, if the PLMN operator is also acting as transit operator for other networks.
194
DRAFT
A50016-D1112-V41-2-7618
Information System
4.7.3
IMSI/MSISDN-Dependent Routing
The feature IMSI/MSISDN-dependent routing allows the PLMN operator to create many new applications by routing calls IMSI/MSISDN-dependent. Therefore, routing becomes much more flexible and offers new possibilities by using this feature. It allows setting up of different groups of mobile subscribers inside the PLMN by structuring the IMSI or MSISDN or something which is much more interesting, it is possible to treat roaming subscribers differently depending on the PLMN from which they come. IMSI/MSISDN evaluation is done by the SDDPFC translator prior normal digit translation. This feature is not designed to evaluate whole IMSI or MSISDN numbers but should be used to evaluate only parts of the numbers to identify the country and/or PLMN from which the mobile subscriber comes (evaluating of MCC and MNC of IMSI or CC and NDC of MSISDN) or to determine a certain group of individual subscribers by evaluating a few more digits after MNC/NDC. It is also possible to evaluate whole IMSI or MSISDN numbers, but the max. amount of IMSI or MSISDN numbers which can be evaluated is about 2000. The feature is applicable for the following type of calls: MOC Routing-dependent on calling mobile subscribers IMSI/MSISDN. MTC Routing-dependent on called mobile subscribers IMSI or dependent on calling mobile subscribers MSISDN. Call forwarding (CF) Routing-dependent on forwarding mobile subscribers IMSI/MSISDN. Incoming calls from another exchange In this case the A-number of the calling subscriber can be evaluated and can therefore affect routing (the A-number is not necessarily the MSISDN if the caller is a nonmobile subscriber). The following examples show how this feature can be used for new applications: Multiple Voice Mail Service (VMS) access In PLMN with more than one Voice Mail Center (VMC), it is necessary to divide the subscribers into the different centers. This can be done by evaluating the IMSI/MSISDN of the mobile subscriber. Regardless of which VMC, the mobile subscriber belongs to, he can dial a PLMN-wide unique number for message retrieval. By evaluating the IMSI/MSISDN of the subscriber the call can be routed to the correct VMC. If a mobile subscriber activates call forwarding to his mailbox, a unique forwarding number can be used irrespectively of the mailbox to which he belongs. Special service destinations (for certain mobile subscribers) It is possible to allow the use of some services for special groups of mobile subscribers which are identified by their IMSI/MSISDN. Typical examples of these applications are: Distribute calls (e.g., PLMN service hotline) to different operator positions dependent on the calling subscriber Special subscribers (business customers) are allowed to use internal services such as stock exchange news, directory assistance, weather forecast etc. (see Fig. 4.56).
A50016-D1112-V41-2-7618
DRAFT
195
Information System
individual PLMN
normal mobile subscriber: Calls to special services restricted or charged
MSC/VLR
RAN
special mobile subscriber: Calls to special services possible or free of charge
Fig. 4.56
Special service destinations
Partial support of foreign PLMN numbering plans Short codes used in other PLMNs can be offered to roaming mobile subscribers, while individual subscribers can still use the same number for other purposes. As an example, mobile subscriber from country A is roaming in country B. The number 988 is used for directory assistance in country A, but in country B 988 is used for other purposes. That means that normally a subscriber from country A roaming in country B cannot dial 988 (but 221) in country B to reach directory assistance. By evaluating the IMSI/MSISDN of roaming mobile subscribers (e.g., MCC and MNC) the number 998 can be routed to a different destination (e.g., to directory assistance in country A) as it is done for home mobile subscribers. This can be done for roaming mobile subscribers from certain PLMNs. e.g., the individual PLMN supports all special numbers from PLMN A and B for roaming mobile subscribers. Restriction of call forwarding for roaming mobile subscribers from certain PLMNs It is possible to restrict call forwarding to special (long distance) destinations for roaming mobile subscribers from certain PLMNs for fraud prevention. Blocking of certain destinations for home/foreign mobile subscribers It is possible to allow certain destinations only for roaming or only for home mobile subscribers. e.g., customer service center only for home mobile subscribers.
4.7.4
Subscriber Data-Specific Routing

The feature subscriber data-specific routing allows the PLMN operator to create many new applications by mobile subscriber-dependent call routing. Certain groups of subscribers can be set up. Every subscriber group can be routed differently even if the same number is dialed. Therefore, routing becomes much more flexible and offers new possibilities by using this feature. It allows different groups of mobile subscribers to be set up inside the PLMN by using the mobile subscriber category or some national supplementary service values. Digit
196
DRAFT
A50016-D1112-V41-2-7618
Information System
translation of any number dialed by a mobile subscriber belonging to a certain group can be done by considering the group membership. Dependent on the group membership of a subscriber it is necessary to set some data which can be considered by digit translation. mobile subscriber data evaluation is done by SDDPFC translator prior to normal digit translation. To implement this behavior the dialed short code digits is modified into a E.164 number if the mobile subscriber belongs to the mobile subscriber category. Every time a subscriber from a certain group initiates a call, the membership to a certain group can be analyzed during call setup and therefore a special routing for every group is possible. Analysis of group membership is possible for MOC and call forwarding in the visited MSC. The following examples show how this feature can be used for new applications: Different private numbering plans for different mobile subscribers A private numbering plan can be applied to subscribers belonging to a specific company. e.g., a mobile subscriber (company employee) wants to reach every company location within a country by dialing the same short codes as he is used to dialing in his office originating from the PABX. mobile subscriber A dials 555 to reach destination X and subscriber B dials 555 to reach destination Y (Fig. 4.57).
Company B location abroad individual PLMN PLMN customer (Company A) MSC/VLR 555 PABX individual mobile subscriber (group1) PABX 555 individual mobile subscriber (group2) PLMN customer (Company B)
12345
12345
12345
12345
Company A location abroad
Fig. 4.57
Different private numbering plans for different mobile subscribers
Preselection of different carriers for different groups of mobile subscribers Business customers select long distance call carriers of their choice. This can even be combined with time frames (e.g., 00:00-12:00 carrier A, 12:00-00:00 carrier B). If a mobile subscriber belonging to group A, for example, initiates a long distance call, it is routed via network A, but if a mobile subscriber belonging to group B initiates the same call, it is routed via network B to the desired destination. It is also possible to combine this subscriber-specific routing with time-dependent routing.
A50016-D1112-V41-2-7618
DRAFT
197
Information System
Re-routing of certain calls for special mobile subscribers Certain groups of mobile subscribers can be routed via service centers (e.g., to send a payment reminder before the call).
4.7.5
Number Length-Dependent Routing

The feature number length-dependent routing makes it possible to route calls depending on the length of the called party address digits. Therefore, it provides the option of transforming ambiguous digit combinations into unambiguous combinations using the number length as an additional indicator. This feature provides the option of enhancing the PLMN numbering plan by allowing ambiguous code points. It is possible to evaluate the length from 1 to 16 digits. Length evaluation is done by the SDDPFC translator prior to normal digit translation. This feature is urgently needed in all countries with numbering plans which allow ambiguous digit combinations. This feature is applicable for MOC, MTC, transit call and call forwarding.
4.7.6
Subscriber Data-Specific Charging Generation

The feature subscriber data-specific charging generation typically provides the option of deciding whether a ticket should be suppressed for calls to certain destinations performed by certain mobile subscribers.
Generally, with the subscriber-dependent digit processing and feature control (SDDPFC) functionality (see section 4.7.1), the standard zoning functions can be implemented (e.g., other tariffs for dedicated subscriber). This feature allows different groups of subscribers to be set up inside the PLMN. This can be done by using the mobile subscriber category, national supplementary service values or ranges of IMSI/MSISDN. Depending on those groups (and in combination with the call type and the digits) it is possible to check whether a ticket should be suppressed for a certain call. Either IMSI or MSISDN evaluation (see section 4.7.3, IMSI/MSISDNDependent Routing) can be used. The following example shows how this feature can be used for new applications: Ticket suppression for certain mobile subscribers to special service destinations Such destinations could, for example, be info services, that is, hotlines.
198
DRAFT
A50016-D1112-V41-2-7618
Information System
individual PLMN
normal mobile subscriber: Calls to special services charged (charge generation)
MSC/VLR
RAN
special mobile subscriber: Calls to special services free of charge (not charge generation)
Fig. 4.58
Special service destinations are free of charge for certain subscribers
4.7.7
Subscriber-Specific Advice of Charge

With the feature subscriber-specific advice of charge it is possible to consider the tariff model of the PLMN that the mobile subscriber belongs to for advice of charge. The reason is that different tariff models exist within the PLMN and up to now, advice of charge couldnt consider all those different tariff models. Because of this, advice of charge was offered for only one particular tariff model at most. By using this feature, advice of charge can be offered to every mobile subscriber within the PLMN.
This functionality can also be implemented with IN AOC (see section 4.6.1). Different tariff models can be administered in the following way via SDDPFC: All IMSIs of a certain tariff model are within one range. Depending on the IMSI range and the dialed number, the correct zone value and after that the tariff is determined. All mobile subscribers belonging to a certain tariff model get a certain indication in the HLR (e.g., mobile subscriber category or national supplementary service value). Depending on this, the indication mobile zone value and after that the tariff is determined. It is possible to create a maximum of 512 different zones. For example, this means if there are 5 different tariff models in the PLMN, 102 different zones can be created for every tariff model. If different tariffs for AOC are to be offered to different mobile subscribers and the different tariff groups cannot be identified by certain IMSI ranges, it is necessary for the administration of the different mobile subscriber groups to be possible in the HLR via mobile subscriber category or national supplementary service values.
4.7.8
Multilingual Announcements
The feature multilingual announcements allows the PLMN operator to offer announcement to the mobile subscribers in their preferred languages. The selection of the correct announcement language is done by the MSC depending on the mobile subscriber. For
A50016-D1112-V41-2-7618
DRAFT
199
Information System
operator services, it is furthermore possible to connect an operator who is speaking the language of the calling mobile subscriber even if every subscriber is dialling the same operator service number. This implies that not every operator within the PLMN has to speak several languages. This functionality can be explained best by using an example. PLMN1 is an Englishspeaking country and PLMN 2 is a French-speaking country. So the announcement/operator services in PLMN 1 are offered in English to home mobile subscribers. However, to roaming subscribers from PLMN 2 the announcement/operator services are automatically offered in French. This is done by evaluating the mobile subscribers IMSI/MSISDN during announcement/operator service call setup. Assume as a second example, that PLMN 3 is a German-speaking country. The announcement/operator services in PLMN 3 are offered in German to home mobile subscribers by default. Special mobile subscribers require those services in English. In that case, a PLMN-defined subscriber-specific information stored in the HLR such as mobile subscriber category or national supplementary service value has to be evaluated during announcement/operator service call setup. For connecting an announcement in the correct language it is necessary to analyze specific subscriber information (that is, IMSI/MSISDN). The SDDPFC translator evaluates the IMSI/MSISDN.
4.7.9
IN: Influenced Management of Call Legs (Leg Management)

Leg management provides the functionality for creating, connecting, disconnecting and releasing call legs under the control of the SCP. A leg is a representation of a communication path towards an addressable network entity, as viewed by the SCP. A leg is therefore a party in the call, and should be handled in a way that has a minimum effect on other legs. There are several properties that can be associated with legs (for example, user busy monitoring). In order to meet customer requirements for IN service-initiated services, such as wakeup services, which require more sophisticated call configurations (e.g., SCP initiated call, user interaction (UI) with the called party etc.), a general leg management functionality is introduced which is able to process leg-oriented operations. With the introduction of the new functionality, the following IN services can be executed by the SSP: IN services controlled callback (e.g., callback lists in the SCP) Least cost routing Opinion poll Wake-up service Advertising via phone.
4.7.10
IN: Call Party Handling and Midcall Trigger

Call party handling Call party handling (CPH) is a mechanism which allows creation of flexible IN services based on IN capability set 2 (CS-2) leg management. It provides a subset of CS-2 leg management operations, in the same way as a subset of CS-2 operations is applicable for PLMNs. Only IN services based on playing announcements or user-interactive dialogs (UID) to both parties independently from each other or parallel ringing for two Bparties can be implemented.
200
DRAFT
A50016-D1112-V41-2-7618
Information System
Midcall trigger For further extension of the trigger detection point set and as add-on for the function set of CPH, the midcall trigger is introduced to give a direct indication from the calling party to the SCP. The calling party is able to input DTMF tones as a reaction to a request by the IN service.
The midcall trigger function has to be supported by the appropriate SCP software version. The same is valid for the following applications. Possible applications A variety of new applications can be generated based on call party handling (CPH) and midcall trigger. The following services are conceivable: Personal number service with parallel ringing for two B parties As universal number service two telephone numbers ring in parallel to increase the reachability of the subscriber. The subscriber could administer his two numbers for parallel ringing by user interactive dialog, USSD phase 2 or the Internet. No additional time-dependent adjustments or call forwarding is necessary. The following combinations are conceivable: Fixed private phone and private mobile Fixed business phone and business mobile Fixed private phone and business mobile Fixed private phone and business phone Business phone and private mobile Private mobile and business mobile. This service generates additional revenue through a monthly fee and additional charges owing to increased reachability. Reverse charging call (R-call) It is possible to change the chargeable party from the calling to the called party. Before setting up a reverse charging call, the B party has to conrm the acceptance of the call charges. This is performed via an user interactive dialog between the IN service and the B party. After successful validation, the call setup can be completed as usual and the call can take place. One typical service application is a call from a child (e.g., prepaid or mobile subscriber) to his parents when the account is nearly empty or only to save money. The parents usually accepts the charges, as otherwise the call would not be set up. In addition, the call duration is considerably longer than if the child had to pay for the call. In this way, additional charges again occurs. Announcements for the A and B party during stable call for advertisements A service can be offered to prepaid subscribers to play advertisement announcements every nth minute for charge-free calls. The advertisement can be played according to the subscribers prole that is registered together with the application to this service. Additional revenue is generated on account of additional airtime or longer call duration than conventional charged calls. An application fee or a monthly fee is also conceivable. Automatic call setup by SCP This service provides automatic call setup for business subscribers to arrange a meeting by phone: for people who are hard to reach or
A50016-D1112-V41-2-7618
DRAFT
201
Information System
give a daily call for share rates or a call in the case of predened rates of a share package. Additional revenue is generated owing to additional chargeable calls. Typical call procedures for parallel ringing Parallel ringing allows parallel call setup to two B subscribers, in which case it is possible to include a fixed subscriber as the B party. This functionality is important for a personal number service. Examples for parallel ringing are a multi-SIM service or the inclusion of music instead of the ringing tone for MTCs (personal ring back tone). 1. The calling mobile subscriber sets up a mobile originating call (MOC) to the M-SSP and an IN call is triggered. 2. The M-SSP invokes an IN call to the SCP. 3. The service logic in the SCP initiates a call setup to a B1 party via M-SSP. 4. The M-SSP completes the call setup to a B1 party. 5. The call setup to the B2 party is immediately started by the SCP. 6. The M-SSP completes the call setup to a B2 party. 7. In this example the rst B party, who goes off-hook is the B2 party that signals it to the M-SSP. 8. The M-SSP forwards the B2 answer message to the SCP. 9. The SCP initiates the call connection control with the A party to the M-SSP. 10. The M-SSP completes the call connection from the A party to B2 party. Fig. 4.59 shows the call procedure of parallel ringing for two B parties
Called mobile subscriber (B1 party)
4 10 M-SSP 1
Calling mobile subscriber (A party)
2, 3 5
SCP
10 Called fixed subscriber (B2 party) 7, 8 8, 9
PLMN
Fig. 4.59
Call procedure of parallel ringing for two B parties
4.7.11
IN: Announcement in Parallel to Call Setup

Announcements are played by the network to inform the subscriber about special situations, e.g., the called party is not reachable or wrong dialed number, or
202
DRAFT
A50016-D1112-V41-2-7618
Information System
to provide additional service information, e.g., indication of account nearly empty for prepaid subscribers, as an indication for home zone billing that the caller is within or outside the home zone or dedicated greetings for an IN service.
Until now, these announcements have only been possible sequentially before call setup or if the call is released afterwards (except service announcements as for call forwarding (CF), call waiting (CW) or call hold (CH)). This feature allows playing IN announcements while continuing the call setup to the called party. No time is lost on account of sequencing an announcement and call setup. The announcement is terminated at the latest after the called party answers and the user is connected to the called party. The feature is implemented entirely in the M-SSP. It is controlled by the service logic (SCP). For an appropriate announcement handling, new announcements have to be recorded. Call procedures of IN announcement in parallel to call setup This feature plays an announcement to the calling subscriber and, in parallel, performs the call setup to the called subscriber controlled by the SCP. After 'nswer from the called party, the calling party is connected to the called party and the announcement is immediately released. Therefore, the call setup time is reduced considerably compared with a sequential announcement and call setup. 1. The calling mobile subscriber sets up a mobile originating call (MOC) to the M-SSP and an IN call is triggered. 2. The M-SSP invokes an IN call to the SCP. 3. The service logic in the SCP initiates an appropriate message to the M-SSP for control of the standard announcement. 4. In parallel to the call setup to the called subscriber (B party), the M-SSP controls the standard announcement equipment (OCANEC) to play a single standard announcement to the calling subscriber (A party). Fig. 4.60 shows the call procedure of IN announcement in parallel to call setup.
A50016-D1112-V41-2-7618
DRAFT
203
Information System
Called mobile subscriber (B party)
4 5 M-SSP 1
Calling mobile subscriber (A party)
SCP
3 4 PLMN 5
Announcement equipment (OCANEC/DAS)
Fig. 4.60
Call procedure of parallel ringing for two B parties
4.7.12
IN: Advanced Interworking with Supplementary Services

IN services serve the mass market, and a considerable amount of charges to the total revenue of a PLMN operator is contributed by the prepaid service. Further IN services, such as personal number or call hunting services, extends the service spectrum of successful operators. Therefore, advanced interworking with supplementary services is required. SCP-controlled call forwarding (CF) For personal number services or generally call hunting services control of call forwarding is required. Owing to call forwarding into another hunting group, the service could get out of control. Call setup times could increase dramatically, regardless of the misrouted calls. Therefore, the SCP is able to suppress the normal call forwarding handling and suppress the signaling of call forwarding information at the ISUP or A interface in the backward direction. Restriction of connected line identification presentation (COLP) The requirement for premium-rate calls is not to display the connected line. Otherwise, the calling party would be able to dial the real number directly and save a lot of money. The service would then be reduced to the absurd. Therefore, in the case of specific services, e.g., premium-rate calls, the connected line identification is replaced by the dialed number. User-to-user signaling service 1 (USS1)
204
DRAFT
This is introduced for transmission of information between an operator center and the SCP UUS1.
A50016-D1112-V41-2-7618
Information System
It allows, for example, competitive offering of operator-assisted connect service in the network, which requires effective routing and proper charging. Effective routing means a direct route between the calling and the called party without unnecessary loops. Proper charging provides separate charging for the connection to the operator assistance center and the subsequent call to the called party. Call transfer (CT) interworking with prepaid and virtual private network (VPN) subscribers Without this feature, a prepaid or virtual private network (VPN) subscriber is not able to use the call transfer (CT) supplementary service. This feature is implemented by moving the IN dialog from the LTG:BSSAP to a loop LTG, that is, to skip the IN dialog in the BSSAP and route the call internally to the loop LTG where the IN trigger takes place. In order to minimize the number of rerouting to the loop LTG (additional hardware necessary), it is necessary to reroute the calls only for subscribers who have subscribed to the call transfer (CT) supplementary service. Appropriate administration steps via SDDPFC complete this feature.
4.7.13
IN: Audible Checking of Announcements

A convenient means of checking user interaction (UI) announcements stored in the MSC/VLR is provided. Before a service (e.g., IN), which requires announcements is launched, authorized personnel are able to check whether the correlation between an announcement ID and an current announcement is correct (e.g., prepaid announcement: Your account balance is 23.03 Euros). The tester listens to the complete announcement, regardless of the fact that the announcement can be technically merged from several pieces (combinations of standard announcements and announcement with variable parts). In addition, if more than one UI LTG exists in an MSC/VLR, it is selected by the test mobile equipment. Testing is performed via a mobile or fixed phone with dual tone multi frequency (DTMF) capability. The MSC/VLR triggers this test service with the help of SDDPFC. The MSC/VLR software utilizes internal IN means without interfacing the SCP/CSE. Instead, internal software is used. Announcements can be checked according to the following test call procedure: 1. The test call is initiated by a mobile or xed phone dialing a special prex + selection code. The special prex (example: 0123456) identies the requested feature at the dedicated MSC/VLR, while the selection code (example: 11) selects a specic UI LTG. 2. In order to prevent non-authorized access, the calling party address is checked, which needs to be administered at the MSC/VLR via O&M means in advance. 3. The tester receives an announcement or special tone, which prompts him/her for further input (example: start input). 4. DTMF input requests for dedicated announcements, which can consist of several parts and comprise standard and variable announcements (example: *1999*600001000#). 5. The tester listens to the requested announcement (example: Your prepaid account balance is 10 Euros). 6. The call is terminated. Steps 3 and 5 can be repeated several times for testing different test sequences before the call is terminated.
A50016-D1112-V41-2-7618
DRAFT
205
Information System
4.8
Mobile-Specic Functions of Circuit-Switched Call Handling - for Trafc over TDM CN

The mobile-specific functions of circuit-switched call handling comprise the functions which result from the architecture of the PLMN network. These functions apply to mobile subscribers. These include: Radio access security and user authentication Authentication (2G only) Authentication and key agreement (AKA) (3G only) Data integrity (3G only) User/signaling data condentiality (ciphering) User identity condentiality (TMSI reallocation) Checking the mobile equipment identity Mobility management (MM) (separated) IMSI attach/detach Location management MM with the MTC (paging, interrogation) Combined mobility management Handover (and relocation in 3G) Categorization of handover (and relocation in 3G) Interfrequency handover (3G only) Hard handover / soft handover (3G only) Relocation of serving RNS (3G only) GSM900-GSM1800 multiband handover (only 2G) Intersystem handover from 3G to 2G and from 2G to 3G Service based handover from GSM to UMTS / UMTS to GSM Inter PLMN handover Directed retry (MSC controlled) (2G only) Roaming International / national roaming agreements Flexible roaming Network access subscription Subscription restriction (including roaming area restriction and regional subscription) Equivalent PLMN list Sharing of mobile network resources (infrastructure sharing) Support of multiple PLMN Network information and time zone (NITZ) Cell-oriented routing of service numbers Subscriber-related routing of service numbers Off-air call setup (OACSU) for CN switching node Queuing and priority for trafc channels Catastrophe handling for trafc channels Overload handling for trafc channels.
4.8.1
206
DRAFT
Radio-Access Security and User Authentication Management
The radio-access security and user authentication management functions protect: Radio-access to the mobile services Disclosure of information on the radio path
A50016-D1112-V41-2-7618
Information System
The radio-access security and user authentication management functions safeguard: authentication of the mobile subscriber (2G only) authentication and key agreement of the mobile subscriber (3G only) data integrity of the mobile subscriber (3G only) condentiality of the user data on the radio interface (ciphering) condentiality of the mobile subscriber identity (TMSI reallocation) and checking of the mobile equipment identity (IMEI check).
4.8.1.1
Authentication (2G only)

Authentication is an integral part of the overall safeguarding system in the 2G PLMN. It cannot be described in complete isolation from the other security-related functions. The following confidentiality functions (e.g., ciphering of the user information on the radio interface) are also relevant. Authentication is an important part of the security measures which prevent unauthorized access to the 2G PLMN and its services. Successful authentication is the precondition for the use of the services of the 2G PLMN by a mobile subscriber. Without previous authentication, only emergency calls can be made with mobile equipment.
2G mobile stations carries SIM chip cards. During inter-system handover, security parameters must be transported to the target entity (e.g., RNC, MSC) via the appropriate protocols. When handing over from 2G to 3G, the security keys must be converted because the 3G UMTS authentication consists of 5 parameters (unlike 2G GSM, where the authentication vector consists of 3 parameters). In the case of a 2G mobile subscribers inter-system handover from 2G to 3G, it is necessary to convert the 2G GSM security parameter Kc into the 3G UMTS security parameters CK and IK if 2G GSM authentication has been established. If a 3G mobile subscriber roaming in the 2G PLMN needs to be handed over to a 3G PLMN, a new authentication procedure is necessary. Because the 2G security context of the 3G mobile subscriber, which is derived from the 3G security context, information is lost. Therefore, the 3G security context cannot be reconstituted. Authentication is based on the fact that every mobile subscriber is assigned individual parameters (individual subscriber authentication key Ki and triplets consisting of random number RAND, signed response SRES, cipher key Kc) and version numbers of rigidly defined algorithms (A3, A8). The precomputed triplets and algorithms are stored in the PLMN (HLR/AC) in addition to the Ki. The algorithms A3 and A8 are stored in addition to the parameter Ki on the chip card (SIM) in the mobile station. The security parameters SRES and Kc are calculated independently in the MS. SRES is subsequently used in the VLR for the current authentication comparison. Kc is used as the encryption parameter in the MS (see section 4.8.1.4, User/Signaling Data Confidentiality (Ciphering).) Reasons for the start of an authentication procedure are all types of call setup between mobile station and network, e.g.: IMSI attach Connectionless activation of supplementary services Exchange of short messages Location updates with change of the VLR service area
A50016-D1112-V41-2-7618
DRAFT
Interoperation of all logical network components of the CN (that is AC, HLR, VLR, 2G MSC or 2G MSC part) is necessary, for preparing and performing authentication. The first measures are taken during the creation and definition of the mobile subscriber in the Personalization Center for SIM (PCS), that is to say still before the point at which the mobile subscriber is known in the current 2G PLMN.
207
Information System
Call procedure:
1. The MS requests a call from the MSC/VLR. The VLR initiates an authentication. 2. If the mobile subscriber data is not yet known to the VLR, the VLR also requests the triplets from the HLR with this data. 3. The HLR itself requests these triplets from the AC and sends the requested data to the VLR. 4. The VLR essentially sends the random number RAND of a triplet via the MSC and 2G RAN to the MS. 5. The MS calculates the value for the signed response SRES from the current RAND with the aid of the values of algorithm A3 and the individual subscriber authentication key Ki which are stored on the chip card (SIM). The MS also calculates the value of the cipher key Kc using RAND, A8 and Ki. 6. The MS sends SRES to the VLR. 7. The VLR compares the SRES which was precomputed in the PLMN with the SRES received from the MS. If the two SRESs agree, authentication has been performed successfully. If authentication was unsuccessful, an entry can be made in the security le of the VLR. Fig. 4.61 shows the authentication procedure.
7 3 VLR 2 4 6 1 HLR 3 AC
MSC
1 2G RAN
1 Radio interface
MS
Fig. 4.61
Authentication procedure
4.8.1.2
Authentication and Key Agreement (AKA) (3G only)

In the circuit-switched domain of the 3G PLMN, authentication and key agreement (AKA) form an integral part of the overall safeguarding system and are necessary to authenticate a mobile subscriber and to provide the required parameters for ciphering and integrity handling to the mobile subscriber.
208
DRAFT
A50016-D1112-V41-2-7618
Information System
The authentication and key agreement (AKA) mechanism for 3G PLMN is built to maximize compatibility with 2G PLMN and to facilitate migration from 2G to 3G. The 2G mechanism has been enhanced to protect against a number of attacks that have become possible owing to the fact that base station equipment has become available to attackers. Authentication and key agreement mechanism contains: Authentication Authentication is seen here as a mechanism between USIM and AC to provide user(USIM) to-network authentication and network-to-user authentication. Sub-functions of authentication are: Generation of authentication vector by AC Distribution of authentication vector between VLR and HLR/AC Distribution of authentication vectors between VLR's Authentication protocol between USIM and 3G MSC/VLR Resynchronization protocol between USIM and HLR/AC Reporting of authentication failures from 3G MSC/VLR (or 3G SGSN/SLR) to HLR/AC (this is not within the scope of that software release) Reporting of authentication failures from 3G SGSN to the operator Handling of authentication parameters in the different scenarios for interoperation between UMTS (3G) and GSM (2G). Key agreement Key agreement is seen here as a mechanism between USIM and HLR/AC to agree on the integrity key (IK) and the ciphering key (CK) to be used. Key agreement in the context of AKA is only the generation of the integrity key (IK) and the ciphering key (CK). Sub-functions of key agreement are: Generating the integrity key (IK) and the ciphering key (CK) by AC Handling the integrity key (IK) and the ciphering key (CK) in the different scenarios for interoperation between 3G and 2G Using the integrity key (IK) and the ciphering key (CK) in the different handover scenarios. Authentication Authentication forms an important part of the security measures which prevent unauthorized access to the 3G PLMN and its services. Successful authentication is the precondition for using the services of the 3G PLMN by a mobile subscriber. Without previous authentication, only emergency calls can be made with mobile equipment.
A50016-D1112-V41-2-7618
DRAFT
3G mobile stations carries USIM chip cards. During inter-system handover, security parameters must be transported to the target entity (e.g., RNC, MSC) via the appropriate protocols. When handing over from 2G to 3G, the security keys must be converted because the 3G UMTS authentication consists of 5 parameters (unlike 2G GSM, where the authentication vector consists of 3 parameters). In the case of a 2G mobile subscribers inter-system handover from 2G to 3G, it is necessary to convert the 2G GSM security parameter Kc into the 3G UMTS security parameters CK and IK if 2G GSM authentication has been established. If a 3G mobile subscriber roaming in the 2G PLMN needs to be handed over to a 3G PLMN, a new authentication procedure is necessary. Because the 2G security context of the 3G mobile subscriber, which is derived from the 3G security context, information is lost. Therefore, the 3G security context cannot be reconstituted.
209
Information System
Authentication is based on the fact that every mobile subscriber is assigned individual parameters (individual subscriber authentication key K (security key, K) and quintets consisting of random number (RAND), extended (signed) response (XRES), cipher key (KC), integrity key (IK), authentication token (AUTN). The precomputed quintets (authentication vectors) are stored in the PLMN (HLR/AC) in addition to the authentication key K. The security parameter RES is calculated independently in the MS. XRES is subsequently used in the VLR for the current authentication comparison. At the same time the USIM computes the cipher key (CK) and integrity key (IK), using the received RAND and K and stores them.
The security parameters of a quintet are formed according to the following equations using the algorithm functions f1 to f5: XRES = f2 (RAND,K) CK = f3 (RAND,K) IK = f4 (RAND,K) AK = f5 (RAND,K) MAC = f1 (RAND,K, AMF, SQN) The AK and MAC results in the AUTN (authentication token) parameter. The RAND parameter is the fifth quintet security parameter. (Legend: AK (anonymity key), MAC (message authentication code); authentication management field (AMF), sequence number (SQN)) The key lengths of both the integrity key and the cipher key are significantly longer than those in 2G, to keep ahead of the growing computational power of attackers. Reasons for the start of an authentication procedure are all types of call setup between MS and network, e.g.: IMSI Attach Connectionless activation of supplementary services Exchange of short messages Location updates with change of the VLR service area. Interoperation of all logical network components of the CN (that is, AC, HLR and VLR, MSC network element) is necessary for preparing and performing authentication. The first measures are taken during the creation and definition of the mobile subscriber in the personalization center for USIM (PCS), that is to say still before the point at which the mobile subscriber is known in the current 3G PLMN. Fig. 4.62 shows the authentication procedure in the circuit-switched domain of the 3G PLMN.
Call procedure:
1. The MS requests a call from the MSC network element. The VLR initiates an authentication. 2. The VLR requests the quintets from the HLR (or previous VLR) with this data. 3. The HLR itself requests these quintets from the AC and sends the requested data to the VLR. 4. The VLR essentially sends the random number RAND and authentication token (AUTN) of a quintet and key set identier (KSI) via the MSC network element and 3G RAN to the MS. 5. The MS then rst veries the AUTN. In the case of a successful outcome the MS calculates the value for the response RES. 6. The MS sends RES to the VLR.
210
DRAFT
A50016-D1112-V41-2-7618
Information System
7. The VLR compares the stored XRES which was precomputed in the 3G PLMN with the RES received from the MS. If they are equal, authentication has been performed successfully. The MSC/VLR then uses the cipher key (CK) and the integrity key (IK) which were stored in the selected authentication vector. If authentication was unsuccessful, an entry can be made in the security le of the VLR.
7 3 VLR
HLR
AC
3 2 4 6 1 MSC
1 3G RAN
4 6 1 Radio interface
MS
Fig. 4.62
Authentication procedure in the circuit-switched domain of the 3G PLMN
Key agreement Key agreement in the context of AKA is: On the MS side: the generation of the integrity key (IK) and the ciphering key (CK) On the CN side: the selection of the integrity key (IK) and the ciphering key (CK) in the VLR.
4.8.1.3
Data Integrity (3G only)

In the circuit-switched domain of the 3G PLMN, data integrity together with authentication (described in the previous section) and user identity confidentiality (described in the following section) is an integral part of the overall safeguarding system in the 3G PLMN. Most mobility management (MM) and call control (CC) signaling information elements are considered sensitive and their integrity must be protected. An integrity function is applied to these signaling information elements transmitted between the MS and the CN. The authentication and key agreement (AKA) mechanism uses quintets including an integrity key (IK). Therefore, support of MS with USIM chip cards is secured.
A50016-D1112-V41-2-7618
DRAFT
211
Information System
Data integrity procedure ensures that the receiving entity is able to verify that the signaling data has not been modified in an unauthorized way because it was sent by the sending entity and that data origin of the signaling data received is indeed the one claimed. For this a stamp, which is derived from the integrity key (IK), is added to signaling messages that are sent over the radio interface between the RNC and 3G MSC part network element.
This handling is not only supported for mobile subscribers (USIM) but also enhanced for 2G mobile subscribers (SIM) roaming in the 3G RAN. Data integrity procedure Data integrity handling is supported between the MS and the RNC/MSC network element. For this the integrity key (IK) agreement is done during authentication in the MSC network element and the integrity algorithm agreement is done after authentication in the MSC network element. Fig. 4.63 shows the principle of data integrity in the circuit-switched domain of 3G.
MSC
6 3G RAN
5 Radio interface
MS
Fig. 4.63
Principle of data integrity in the circuit-switched domain of 3G
1. The MSC network element starts data integrity handling by providing the integrity algorithm to the RNC through an appropriate message. 2. Data integrity function is started in the RNC. 3. The RNC sends a security control request message to the MS. 4. Data integrity function is started in the MS. 5. The MS sends a security control response message to the RNC. 6. After successful initiation of data integrity the RNC responds with an adequate response to the MSC network element.
212
DRAFT
A50016-D1112-V41-2-7618
Information System
4.8.1.4
User/Signaling Data Confidentiality (Ciphering)

The confidentiality of user/signaling data on the radio interface is a function that prevents the user/signaling information exchanged on the traffic channels from being made available or revealed to unauthorized persons, bodies or processes. This function protects the confidentiality of user/signaling information on traffic channels by ciphering the user/signaling data on the radio interface, and is used for speech and data communication. This ciphering of the user/signaling information extends only to the path MS to RAN and not to the entire call. The end-to-end protection of user data is the responsibility of the user. Ciphering and data integrity function are started simultaneously.
In case of 3G PLMN this handling is not only supported for 3G mobile subscribers (USIM), but also enhanced for 2G mobile subscribers (SIM) roaming in the 3G RAN. 2G PLMN The cipher key Kc is computed in the MS (chip card with SIM) during the authentication procedure described in section 4.8.1.1 (in Fig. 4.61) with the aid of the individual subscriber authentication key Ki, the random number RAND and algorithm A8 of the cipher key Kc. This means that this parameter is also available in the MS without having to be sent via the radio interface. On the PLMN side, the 2G RAN is responsible for ciphering and the VLR transfers the required Kc. After authentication, both sides can now begin ciphering the messages to be sent via the radio interface. Ciphering algorithm A5 is used for ciphering. The CN supports the algorithm variants A5/1, A5/2 and the new, stronger ciphering algorithm A5/3, and A5/0 (no ciphering). It is thus possible to operate a GSM phase 2/2+ PLMN, which can operate all existing mobile stations and base station (send/receive). This avoids mobile stations from being connected in non-ciphered mode A5/0 via the radio interface. With ciphering algorithm A5/3, PLMN operators can fulfill their obligations as members of the Global System for Mobile Communications Association (GSMA) and provide their customers with the strongest ciphering algorithm available for GSM (2G). 3G PLMN The cipher key CK is computed in the MS (chip card with USIM) during the authentication procedure described in section 4.8.1.2 (in Fig. 4.62) with the aid of the individual subscriber authentication key K (secret key, K), the random number RAND and algorithm f3 of the cipher key CK. This means that this parameter is also available in the MS without having to be sent via the radio interface. On the PLMN side, the 3G RAN is responsible for ciphering and the VLR transfers the required CK. After authentication, both sides can begin ciphering the messages to be sent via the radio interface. Ciphering algorithm f8 is used for ciphering.
4.8.1.5
User Identity Confidentiality (TMSI Reallocation)

The purpose of this function is to exclude the possibility of an unauthorized person determining which mobile subscriber is using a particular resource (radio channel) on the radio interface by monitoring data exchange on the radio interface. This is intended to guarantee a high level of confidentiality for user and signaling messages, while also offering protection against tracking the mobile subscriber's position. For this reason, the IMSI is replaced in the responsible VLR by a TMSI which can also be exchanged for another TMSI after the call has been set up. The TMSI is unique in the VLR service area.
A50016-D1112-V41-2-7618
DRAFT
213
Information System
The TMSI reallocation e.g., is performed after a VLR change. A TMSI can be reallocated either by a mobile management (MM) common procedure (stand-alone TMSI reallocation) or implicitly by a location update procedure using the TMSI. TMSI reallocation is always required: at the initial activation of an MS (no TMSI is allocated yet, so the IMSI is sent) during a location update when an MS roams into another VLR area when the MS uses an old TMSI that was used before VLR recovery and when the MS uses a TMSI that is not correlated with an IMSI. TMSI reallocation is performed in the following way: The mobile subscriber sends the TMSI together with the location area identity (LAI) to the VLR when accessing the network, e.g., during a location update. The VLR allocates a new TMSI to the mobile subscriber and sends it in a coded form (ciphered) to the mobile subscriber. The mobile subscriber stores the new TMSI and sends an acknowledgement to the MSC/VLR to release the old TMSI in the subscriber database and within the TMSI/IMSI correlation table.
4.8.1.6
Checking the Mobile Equipment Identity

There are two variants of IMEI check: Basic IMEI check Reduced IMEI check Basic IMEI check The international mobile equipment identity (IMEI) can be checked in the PLMN when an MOC or an MTC are initiated, or a location update is performed (see section 4.8.2.2, Location Management), and for an IMSI attach (see section 4.8.2.1, IMSI Attach/Detach) to determine whether the mobile equipment being used is authorized in the PLMN.
Call procedure:
1. The MSC requests the IMEI from the MS during call setup. 2. The MSC sends the IMEI received from the MS to the EIR with the request to check the IMEI. 3. The EIR sends the results of the check (category white or gray or black) back to the MSC. 4. Depending on the test result, call setup (MOC, MTC) is continued or canceled. In the event of the categories gray and black, the PLMN operator is also informed of the check result. Fig. 4.64 shows the basic IMEI check procedure. Reduced IMEI check The concept of reduced IMEI check is introduced to enhance the basic IMEI check. The number of IMEI check procedures usually cause a reasonable signaling load on the A and Iu interfaces (and corresponding radio interfaces) as well as on the F interface (MSC - EIR). The dynamic capacity limit, that is, the maximum number of requests per time which can be handled, of the EIR can quickly be exceeded. This feature allows now to reduce significantly the number of IMEI checks being triggered by the MSC/VLR. The PLMN operator can configure the MSC/VLR in that way that (in case of MOC, MTC, location update, etc.) an IMEI check is not triggered at every event. The rate of IMEI checks per mobile subscriber can be adjusted by means of Q3 tasks/MML commands,
214
DRAFT
A50016-D1112-V41-2-7618
Information System
so that e.g., only every 2nd, 5th or 10th trigger event an IMEI check is really performed, which would decrease the signaling load on the mentioned interfaces quite significantly. In our example it would lower the signaling load on the F interface and at the EIR about 50%, 80% or 90%. The reduced IMEI check is a feature of the MSC/VLR only. An EIR just need to support the standardized basic IMEI check functionality, that is, to respond to IMEI check requests from the MSC/VLR. The enhanced functionality related to this feature does not need further support of other PLMN elements. This feature does not have any negative performance impact on the MSC/VLR. Rather, it allows the PLMN operator to enhance the number of mobile subscribers for which IMEI check can be performed with respect to the EIR capability.
EIR
3 MSC
2 4
SC
2 RAN
2 Radio interface
MS
Fig. 4.64
IMEI check procedure
4.8.2
Separated Mobility Management

Separated mobility management (MM) means a mobility management within an isolated circuit-switched domain of a PLMN, that is, without a Gs interface to a packet-switched domain of a PLMN. Therefore, no interference between circuit-switched domain and packet-switched domain of a PLMN is possible. The basis for the sections IMSI attach/detach (section 4.8.2.1); Location management (location update) (section 4.8.2.2) and Circuit-switched mobility management with the MTC (section 4.8.2.3) is separated mobility management.
A50016-D1112-V41-2-7618
DRAFT
215
Information System
4.8.2.1
IMSI Attach/Detach
If the mobile subscriber has inserted/removed his chip card (and therefore the IMSI) or turned the mobile station on or off, the VLR is informed of the activated/deactivated state of the mobile station with the function (explicit) IMSI attach/detach.
Call procedure:
1. The mobile station sends a detach request to the MSC network element which detaches the associated IMSI in the VLR. 2. In connection with the location update procedure, the MS sends an attach request for this to the MSC network element which in turn attaches the relevant IMSI in the VLR. The IMSI attach procedure resets the detached state again. The VLR then sends an attach acknowledgment to the MS via the MSC network element. 3. Knowing whether the mobile station is in the active or inactive state is important in the case of an MTC following interrogation (HLR requests the MSRN from the VLR). Therefore, there is no need to provide the called mobile subscriber with an MSRN in the case of an MTC when the IMSI detached state is entered and consequently the paging procedure is not started. Naturally, in this case the mobile subscriber does not receive any messages via the incoming call because it was unsuccessful. If the IMSI attached state is entered in the VLR for the mobile subscriber, an MSRN is made available for the MTC and the paging procedure is performed. Fig. 4.65 shows the IMSI attach/detach procedures.
HLR 3 VLR
3 22 GMSC
MSC
1 RAN
2 Radio interface
MS
Fig. 4.65
IMSI attach/detach procedures
216
DRAFT
Implicit IMSI detach: If the VLR establishes in the case of an MTC that the MS has not been connected to the PLMN for a certain time, the IMSI detached state is likewise entered. This function runs irrespectively of the explicit detach and can also be used alone.
A50016-D1112-V41-2-7618
Information System
Automatic IMSI detach: The automatic IMSI detach procedure is performed when the MS used by the mobile subscriber needs to be barred from service (e.g.: stolen equipment, defective equipment causing problems with the PLMN). The EIR returns the IMEI status to the MSC. When the MSC learns that blacklisted equipment is using the PLMN, the call is rejected and the VLR sets the mobile subscriber (that is, IMSI) using the MS to detached.
4.8.2.2
Location Management
Location management is the main function of roaming. Location management includes the following procedures: Location update Roaming authorization check Location cancellation. Information on the mobile subscribers location is stored in the home location register (HLR) and the visitor location register (VLR) of the Core Network (CN) on the one hand, and in the mobile station (MS) on the other. To specify more precisely: The HLR only stores the identity of both the VLR and the MSC in which the mobile subscriber is currently registered. The VLR stores the identity of the location area in which the mobile subscriber is currently, on the assumption that it has been updated successfully. The MS (more explicitly the subscriber identity module: (U)SIM card) stores the identity of the location area where the last successful location update was performed. It remains stored even when the MS is not activated. The location update procedure makes it possible to keep consistency between the three functional network elements. Additionally this procedure verifies the mobile subscribers roaming permissions in the current location. Location update procedure The location update procedure is initiated exclusively by the MS. It provides the VLR and HLR with information about the current location of the mobile subscriber.
Call procedure of a simple location update with change of VLR in the same PLMN: A mobile subscriber can move in a radio cell which is served by another VLR.
1. By detecting all neighboring base stations (BTS/NodeBs) and continuously analyzing the available measurement results, the MS can determine when a change of radio cell must be initiated. The MS sends a location update request to the selected new VLR via the RAN and the MSC network element. 2. For identication, the mobile subscriber uses the ISDN mobile subscriber identity (IMSI) and the previous international location area identity (LAI). The new VLR requests the unused triplets/quintets from the previous VLR. 3. The new VLR performs authentication. 4. The new VLR requests the mobile subscriber data from the HLR. 5. The HLR sends the relevant mobile subscriber data to the new VLR. 6. The HLR initiates the deletion of the mobile subscriber data entries in the previous VLR.
A50016-D1112-V41-2-7618
DRAFT
Fig. 4.66 shows the sequence of a location update procedure with change of VLR in the same PLMN.
217
Information System
2 4 Previous VLR 6 HLR 5 1 MSC MSC New VLR 3
1 RAN RAN
1 Radio interface
MS Roaming (changing from one radio cell to another)
MS
Fig. 4.66
Location update procedure with change of VLR in the same PLMN
Furthermore there are possible location updates in national PLMN and in international PLMNs. Roaming authorization check Depending on the roaming definitions in the HLR and MSC/VLR, the HLR and the MSC/VLR check during the roaming authorization check whether or not to accept the mobile subscribers registration in the new VLR (see also section 4.8.6.1, Roaming Definitions for Own and Foreign Mobile Subscribers). If roaming is not allowed, the location update is rejected and the mobile subscriber informed by the indication location update not allowed. Roaming authorization check in the HLR To perform roaming authorization, the HLR checks whether or not the mobile subscriber has the necessary authorization to set up or accept a call at the current location according to: Subscription restriction, plus possibly permitted or barred roaming areas Network access subscription Zone codes for regional roaming restrictions (The HLR supplies the VLR with the zone code list (if available), which is then checked in the VLR.) If the mobile subscriber is currently located in a prohibited area, the subscriber-associated data is removed from the VLR database (or marked as barred if the PLMN is essentially permitted and only the current location is not permitted). From then on, the mobile subscriber is no longer able to set up or accept calls. Roaming authorization check in the VLR
218
DRAFT
A50016-D1112-V41-2-7618
Information System
To perform roaming authorization, the VLR checks whether or not the mobile subscriber has the necessary authorization to set up or accept a call at the current location according to: Flexible roaming National roaming Zone codes for regional roaming restrictions (Based upon the zone code list received, the VLR checks that the new location area has been assigned to a zone code from that list.) If the mobile subscriber is currently located in a prohibited area, the subscriber-associated data is removed from the VLR database (or marked as barred if the PLMN is essentially permitted and only the current location is not permitted). From then on, the mobile subscriber is no longer able to set up or accept calls. The VLR informs the HLR about the update result in order to store it in the HLR database. Location cancellation procedure After a preceding update procedure has recorded a change of VLR and the new VLR has been supplied with the mobile subscriber data, the HLR initiates the location cancellation procedure. This deletes the mobile subscriber data in the old VLR.
4.8.2.3
Mobility Management with the MTC

The mobility management functions of circuit-switched domain (IMSI attach/detach, location registration) are described in sections 4.8.2.1 and 4.8.2.2. The following mobility management functions are also available for an mobile terminated call (MTC): Interrogation Paging and searching Pre-paging with special MSRN for busy mobile subscriber This functions are also described by the description of the MTC (section 4.5.2). Interrogation for mobile subscriber An interrogation takes place in the case of an MTC. If a call has its origin in the same PLMN, the interrogation procedure is started by the originating MSC, otherwise (call origin in the fixed network) by the Gateway MSC (GMSC). In the case of an international call (from one PLMN to another PLMN), an international interrogation can be performed from the originating GMSC.
Procedure: With the aid of the dialing information (MSISDN), the originating MSC or GMSC determines the HLR and sets up a signaling connection to it (interrogation). After that the HLR sends a request to the VLR in whose location area the called mobile subscriber is currently located. The VLR sends the required mobile subscriber roaming number (MSRN) back to the HLR. The HLR passes on the LACOD to the GMSC. Based on the MSRN, the GMSC sets up the call to the visited MSC, that is, the MSC in whose area the mobile subscriber is located at that time.
Paging (and searching) for mobile subscriber
A50016-D1112-V41-2-7618
DRAFT
Paging is only used with an MTC. It serves to determine the radio cell in which the mobile subscriber is currently located with the aid of the location area code (LACOD). In addition to the determination of the radio cell, a signaling connection to the MS is set up at the same time.
219
Information System
Searching is used for an MTC when the radio cell in which the mobile subscriber is currently located is determined without the LACOD being available. Thus paging is done in all radio cells in all location areas belonging to the visited MSC. Procedure (for paging): After interrogation and setting up the connection from GMSC to the visited MSC, the visited MSC does not know the mobile subscriber up to this point, the visited MSC requests from its VLR the mobile subscriber information for the call setup. The MS is now called by paging at all RAN network elements of the location area, since the radio cell in which the MS is located is not known to the visited MSC. This information is passed to the visited MSC in response to the paging.
Pre-paging with special MSRN for busy mobile subscriber Despite the use of the detach feature, there is a relatively high rate of unsuccessful (not answered) call attempts due to no paging response (= MS not reachable). If, therefore, such a situation can be detected during mobile subscriber roaming number (MSRN) allocation; these calls are released in the Gateway MSC (GMSC) without setting up a further connection to the visited MSC. In this way, the number of unsuccessful call setups can be reduced, while increasing the long distance incoming call answer rate (LDICC) ratio.
Procedure: The called mobile subscriber must already be paged (when idle) or the mobile subscriber state is going to be checked during provide roaming number handling. Only if the paging response has been received or the mobile subscriber has call waiting (CW)/call forwarding busy (CFB)/call completion to busy subscriber (CCBS), is the mobile subscriber roaming number (MSRN) allocation being started and an MSRN returned via HLR to the GMSC. If there is no paging response, the cause absent subscriber is sent back to the HLR as a response to provide roaming number message. If the called mobile subscriber is busy, the new special number is sent back from the VLR to the HLR as an MSRN (also called MSRN-A). The resource, which was allocated in the visited MSC, is released. An unsuccessful response directs the call to a new destination, e.g., call forwarding not reachable (CFNR) or an announcement. Advanced pre-paging: An improved paging process is available, which reduces the network load due to the suppression of ISUP initial address messages (IAM) for the case that paging was not successful or the mobile subscriber is busy. This is achieved with changes on the A interface message flow, which ensures that the IAM message is only sent by the Gateway MSC, if the paging process was successful. If the paging of the terminating mobile subscriber was not successful the error cause sent back to the Gateway MSC indicates that the call can be released. For busy subscriber a special MSRN is sent back to the Gateway MSC and the call can be routed to an announcement. Therefore the call establishment and the request for the required resources is avoided if the paging was not successful.
220
DRAFT
A50016-D1112-V41-2-7618
Information System
4.8.3
Combined Mobility Management (CS-Side)

The network resources can be used more efficiently by a combined mobility management of the packet-switched domain and the circuit-switched domain of a PLMN by introducing the Gs interface. The Gs interface has to be supported by the MSC/VLR and the SGSN/SLR. The difference to other interfaces is that the Gs interface is subscriberdependent, that is, both MSC/VLR and SGSN/SLR keep a flag for each mobile subscriber whether the Gs interface is available or not. This is useful because a combined mobility management is not necessary, if the 3G PLMN provides the Gs interface and the mobile subscriber is only allowed to be attached to one service. The SGSN/SLR part of the Gs interface is not part of the next feature. This part is described in separate CNps documents. In a PLMN which supports the Gs interface, special mobile stations, that is, packetswitched class A and class B mobile stations, can initiate a combined mobility management. This means that the Location update/routing area update Attach and Paging procedures need only be performed in the packet-switched domain of the PLMN. After completion of the procedure, the SGSN informs the MSC/VLR about the action. Class A mobile stations support the use of data connections at the same time as speech connections, while class B mobile stations support only one of the two connection types at a time. The Gs interface gives a mobile subscriber who has a class B mobile station with an ongoing data connection the option of disconnecting data connection and accepting an incoming speech call. The main gain of the interface is traffic reduction on the radio interface. If the interface is available, the signaling traffic to the MS is processed by the SGSN, e.g., a combined routing area/location update request is sent to the SGSN which updates its data and forwards the request to the MSC which updates the VLR and sends a response to the SGSN. Interworking with the HLR is done with SGSN. A further advantage is the possibility of reaching an MS operating in class B node during a packet-switched session by the MSC/VLR in the case of paging. In addition, the paging procedure of the SGSN is more efficient because the MS is paged in the radio cell if it is in STANDBY (2G)/CONNECTED (3G) state. If the Gs interface is not available, the SGSN informs the mobile station that the combined mobility management failed. The mobile station then performs the same procedure again in the circuit-switched domain. This would cause additional signaling load on the radio interface. Gs interface state model (2G case) The standard defines a state model for the Gs interface. The state of the Gs interface is subscriber-specific. According to the current status of the Gs interface the MSC/VLR determined the necessary action, e.g., trigger regular or combined location update. The SIEMENS implementation of this state model in the VLR can be described in Fig. 4.67:
A50016-D1112-V41-2-7618
DRAFT
221
Information System
Location update over A interface one of the tree states Detach over A interface Location update request sent Gs-Null
Paging sent over A interface
Location update request received
Paging reject received
Location update accept sent Gs associated Location update accept received Gs LA update
Paging sent
Fig. 4.67
Gs interface state model in the VLR (2G case)
Gs Null state: After the mobile station performed a location update via the A interface, the Gs interface state is set to Gs-null state in the VLR. The Gs-null state is also set after a successful paging on the A interface. Gs LA Update-present state: After the MSC/VLR received a location update request via the Gs interface, the state of the Gs interface is set to Gs LA update-present state. Gs Associated state: After the location update is performed and the location update accept is sent over the Gs interface to the SGSN the Gs interface state is set to Gs associated state.
Gs interface state model (3G case) The 3GPP standard defines a state model for the Gs interface. The state of the Gs interface is subscriber-specific. According to the current status of the Gs interface, the MSC/VLR determines the necessary action, e.g., trigger regular or combined location update. The SIEMENS implementation of this state model in the VLR can be described as in Fig. 4.68.
222
DRAFT
A50016-D1112-V41-2-7618
Information System
Paging failure received Location area update request received from the 3G SGSN Gs-Null Send paging Send location area update reject Paging failure Paging failure Gs-LA-update requested Send paging
Location area update request received from the 3G SGSN Gs-Associated Send paging Send location area update accept
Fig. 4.68
Gs interface state model in the VLR (3G case)
Combined paging (3G only) Circuit-switched (CS) paging is a paging, triggered by an MSC via the Gs interface. If the MSC knows that a mobile subscriber is also attached in an SGSN, it can be advantageous to page this mobile subscriber via the SGSN, because not the whole location area has to be paged, but only a single routing area. For 3G, there is no null routing area. In 3G, there is only one paging channel available for CS and PS. The 3G paging messages for PS and CS have the same format. The paging coordinator function for CS and PS is done by the RNC. Therefore, no requirement exists for paging mobile subscribers in a (3G) null routing area. In the case of mobile subscribers, the SGSN knows only the location area and the routing area of the mobile subscriber for paging. The current radio cell information is maintained by the RNC. The RNC moves the location area and routing area to a radio cell. Consequently, the SGSN always addresses the routing area for 3G paging. Furthermore, paging to a single radio cell, as for 2G CS paging, cannot be performed by an SGSN for 3G CS paging.
4.8.4
Support of Dual Transfer Mode (DTM) (2G only)

For 2G packet-switched data services, the 3GPP standard defines three classes of mobile stations (MS): class A, class B, and class C mobile stations. Class A executes signaling and traffic for both circuit-switched and packet-switched (GPRS) operation both simultaneous and independent. To do this, a class A mobile station uses two independent receivers/transmitters, that is, the MS has simultaneously a timeslot allocated for a circuit-switched service and an active packet-switched temporary block flow (TBF). This mechanism is called dual transfer mode (DTM). For more information, see the System Description Network System Concept. Dual transfer mode is a subset of class A mode of operation and is only possible if there is radio resource allocation coordination in the
A50016-D1112-V41-2-7618
DRAFT
223
Information System
PLMN, that is, between the RAN and the CN. The DTM feature is optional for the MS and the PLMN and it is only applicable for MSs that support GPRS or EGPRS. PLMN operators have expressed their need for MSs that support GPRS or EGPRS to be recognized by standardization bodies so that they can offer services that require the simultaneous existence of a circuit-switched connection and a packet-switched session. This is particularly important during the co-existence of 2G GSM/GPRS with 3G UMTS because these capabilities exist in 3G UMTS. However, 3G UMTS coverage is not available in some areas where there is 2G GSM/GPRS coverage (for example, deep inside buildings or when roaming in a 2G PLMN). Coverage is a vital service for PLMN operators to be able to sell 3G UMTS class A services. It is therefore necessary to be able to imitate class A services in areas with only 2G GSM coverage. On the other hand, the provision of class A services with 2G RAN technology is also essential for PLMN operators without 3G UMTS coverage. Provision of IMSI to the BSC by MSC over A interface To enable the implementation of the GPRS class A mode of operation, the 2G RAN is required to perform the coordination of the allocation of radio resources for both domains. This coordination is performed with the IMSI as described in the following section. The IMSI has to be provided to the BSC during: Call establishment The BSC triggers the establishment of the SCCP connection with the MSC. The MSC has to provide the IMSI to the BSC in a new message: Common ID message. Session management Both in the READY and the STANDBY states the SGSN has to send the IMSI or TLLI. External handover The IMSI has to be included in the handover request message from the MSC to the target BSC. Like 3G UMTS, the A interface is modified so that the BSC knows the IMSI associated with each SCCP connection to the MSC. This means that the BSC can ensure that packet paging messages are delivered to MSs that have a connection to the MSC. The same functionality can be reused to deliver MSC-originated pages to MSs in packetswitched transfer mode while the PLMN is in mode of operation II (that is, no Gs interface). The MSC supports the dual transfer mode (DTM) of MSs as described in 3GPP Rel-6 for a multi-slot configuration. This means that circuit-switched connection and a packetswitched session are performed in separate timeslots. Because the paging coordination function for combined mobility management function paging is located in the 2G BSC, the IMSI is provided to the BSC by the MSC using an appropriate message (common ID message).
4.8.5
Categorization of Handover (or/and Relocation in 3G Case)

Classification of handover in 2G
224
DRAFT
i
Handover: A handover is the transfer of a user's connection from one radio channel to another (can be same or different radio cell). The term handover is used in GSM.
Generally we can classify a handover by one or more of the following criteria:
A50016-D1112-V41-2-7618
Information System
Handover type
RAN perspective
CN perspective
BSC handover - intra-BSC handover - inter-BSC handover Inter-system MSC handover - 2G MSC to 3G MSC handover (within combined MSC node) - 2G MSC to 3G MSC handover (between separated 2G MSC nodes) Handover direction - forward handover - backward handover Handover sequence - first handover - subsequent handover Tab. 4.6 Classication of handover/relocation x x x x x x x x x x x x x
Classification of handover/relocation in 3G
Relocation (SRNS relocation): An SRNS relocation is the change of the Iu instance. It should be noted that SRNS relocation was previously known as streamlining.
Generally we can classify a handover/relocation by one or more of the following criteria: Handover/relocation type RNC handover - intra-RNC handover - inter-RNC handover (with/without Iur interface) 3G MSC SRNS relocation - intra-3G MSC SRNS relocation - inter-3G MSC SRNS relocation Inter-system MSC handover - 3G MSC to 2G MSC handover (within combined MSC node) - 3G MSC to 2G MSC handover (between separated 3G MSC nodes) Classication of handover/relocation x x x x x x x x x x x RAN perspective CN perspective
A50016-D1112-V41-2-7618
DRAFT
Tab. 4.7
225
Information System
Handover/relocation type 3G hard handover 3G soft handover Handover direction - forward handover - backward handover Handover sequence - first handover - subsequent handover Tab. 4.7 Classication of handover/relocation
RAN perspective x x
CN perspective
x x
x x
x x
Forward handover/backward handover Forward handover RAN perspective: Not applicable for (3G) circuit-switched call. A type of handover initiated by the MS. The MS sends the request for establishment of a new radio link in the new radio cell, that is, it does not use the current radio link for performing handover but a radio link of the new radio cell. The RAN has to provide the trafc channels after the handover on air, which can be not successful. The RAN needs information to nd previously allocated serving processes (either within the same RAN or within another). CN perspective: This kind of handover is not supported within the context of 3G. The CN has to provide the trafc channels after the handover on air, which can be unsuccessful. The CN needs a user-id or an identier of the previous serving process as backward index, to get data from the previous serving protocol entities. GPRS implicitly uses this mechanism while performing a routing area update (RAU) procedure. However, inter-system handover scenarios between 3G UMTS and 2G GPRS can have to rely on forward handover mechanisms. Backward (hard) handover RAN and CN perspective: The CN performs the SRNS relocation procedure (3G only). A type of handover initiated by either the MS or the PLMN. The MS or an appropriate PLMN entity sends the request for establishment of a new radio link in the source radio cell, that is it uses the current radio/xed link for performing handover. The new trafc path down to the reservation of the new radio channel is done in advance. Subsequently the MS changes to the new radio channel. If this works, the communication is guaranteed to proceed. SRNC relocation (only 3G)
226
DRAFT
RAN and CN perspective: The CN performs the SRNS relocation procedure. SRNC relocation is a procedure after handover between RNCs is covered within the 3G RAN. Signaling and traffic is lead from the MSC to the serving RNC (SRNC), to target RNC (DRNC) and then towards the MS. A prerequisite is the support of the Iur interface between RNCs. Independent from the time of the current handover, the SRNC can request SRNC relocation from the CN (no time constraints). This procedure sets up a target Iu leg to the DRNC and subsequently releases the source Iu connection.
A50016-D1112-V41-2-7618
Information System
4.8.5.1
2G to 2G Handover (2G only)

2G to 2G handover is the passing on of a call from radio cell to radio cell within the 2G PLMN. The physical connection between MS and 2G RAN or between MS, 2G RAN and CN is changed. This process is always started whenever a new radio cell provides better transmission quality, e.g. because the mobile subscriber moves into the new radio cell during a call, or the transmission quality changes for some ore other reason. This method ensures that the call is always assigned to the most suitable radio path. Different types of handovers are distinguished according to the arrangement of the old and new radio cells within the 2G RAN network. Several handovers in succession can be necessary while a call is in progress. A distinction is made between the first handover and subsequent handovers. BSC-controlled handover In BSC-controlled handovers a distinction is made between: Intra-cell handover An intra-cell handover is a handover between channels within a radio cell which is controlled by a single BSC. Inter-cell handover An inter-cell handover is a change between old and new radio cells which belong to the same Base Station Controller (BSC). This process is performed solely by the BSC, which also informs the Mobile-services Switching Center (MSC) about the new radio cell. See also to speed handover algorithms for introducing underlay or overlay 2G RAN network layer (System Description, register RAN GSM/GPRS). An additional special form of BSC-controlled handovers is represented by the following function: Speed-sensitive handover algorithms for introducing underlay 2G RAN network layer (with micro radio cell geometries) or overlay 2G RAN network layer (with umbrella radio cell geometries) To expand the capacity of radio networks which already provide a good overall area coverage a new approach is chosen: the hierarchical 2G RAN network architecture. A hierarchical 2G RAN network architecture usually features two levels of radio network structures: Overlay 2G RAN network layers, and Underlay 2G RAN network layers While the already existing network serves as the overlay 2G RAN network and gives blanket coverage of virtually the whole 2G RAN network area, the underlay BSS network consists of a large number of small cells to cope with local trafc loads and slow moving mobile subscribers (see Fig. 4.69). The base of such an eased network integration builds a speed sensitive handover algorithm to detect the speed of the MS and keep the fast ones in the umbrella radio cells and the slow ones in the micro radio cells. It is clear that from a network point of view fast moving mobile stations are not only car-mounted mobile stations, but also MSs which frequently cross radio cell boundaries. The speed of the mobile station is detected by a timer which is started when the MS passes a micro radio cell border. If the timer expires before the MS leaves the radio cell, it is classied as low speed MS and vice versa. When performing a handover, the subscriber is handed over to the radio cell of his hierarchical level, with the classication process (low/high speed) starting again, once a radio cell border is passed.
A50016-D1112-V41-2-7618
DRAFT
227
Information System
The advantages of this feature are: Optimization of multi-supplier networks Serving the users who move at high speed in the umbrella radio cells A frequent handover between the small radio cell is avoided The handover load on the system decreases The completion rate and service quality increases Global coverage by umbrella radio cells Global redundancy for the several micro radio cells by umbrella radio cells
Umbrella radio cell (in the overlay network)
Micro radio cell (in the underlay network)
= logical BTS = BSIC = physical BTS(E)
Fig. 4.69
Underlay/overlay radio cells
MSC-controlled handover With each MSC-controlled handover (equivalent to an inter-BSC handover), the traffic signal is passed from the first or the preceding switching element to a new switching element. In contrast to this, the call control (including call recording and signaling via the signaling connection control part (SCCP)) remains in the original (first) switching element after each MSC-controlled handover during the entire duration of the call. This principle is known as the anchor principle in accordance with the 3GPP standard. The MSC-controlled handover procedure supports both the GSM phase-1 and the GSM phase 2/2+ except inter-MSC handover which uses MAP-handover procedures version 1. The MSC-controlled handover procedure is divided into four parts: Request for handover Resource assignment Initiation of handover execution Completion of handover performance In MSC-controlled handovers a distinction is made between: Intra-MSC handover Old and new radio cells belong to the same MSC. Inter-MSC handover Old and new radio cells belong to different MSCs.
228
DRAFT
A50016-D1112-V41-2-7618
Information System
An inter-MSC handover differs from an intra-MSC handover mainly due to the fact that interoperation of the participating MSCs is necessary during the individual parts of the operation (request, resource assignment, execution). In particular, it is necessary to differentiate between The rst handover from MSC-A to MSC-B A subsequent handover back to MSC-A A subsequent handover to a further MSC-B' The following functions constitute special additional forms of the MSC-controlled handover: GSM900/GSM1800 multiband handover The useful signal is transmitted from a rst or previous switching element of a 2G PLMN, functioning on a radio interface with, e.g., 900 MHz to a new switching element of the same 2G PLMN which functions on a radio interface with e.g., 1800 MHz.
Core Network (CN)
2G RAN
BTS 900 MHz
BSC (Manuf. A)
BTS 900 MHz
BTS 900 MHz MSC Intra-MSC Multiband Handover BTS 1800 MHz
BSC (Manuf. A)
BTS 1800 MHz
BTS 1800 MHz Inter-MSC Multiband Handover BTS 900 MHz
MSC
BSC (Manuf. B)
BTS 900 MHz
BTS 900 MHz
Fig. 4.70
Multiband handover
A50016-D1112-V41-2-7618
DRAFT
This function permits a multiband handover as well as an intra-MSC handover and also an inter-MSC handover (Fig. 4.70). Not only the CN also the 2G RANs work with multiband handover. From the aspect of CN the complete support of BSS network elements in both frequency ranges of 900 MHz and 1800 MHz (even from dif-
229
Information System
ferent manufacturers) is guaranteed with multiband operation. The mobile stations must be able to function in both frequency ranges (e.g. standard 900 MHz, additional 1800 MHz) and must be compatible for GSM phase 2/2+. Each 2G RAN network element in multiband handover functions in a certain frequency range and each 2G RAN network element must support multiband handover. The characteristics of the mobile station (frequency range, power class etc.) are transmitted from the old 2G RAN network element to the new 2G RAN network element with the information element classmark 3 according to GSM phase 2 via the MSC. Intra-MSC SDDCH handover The stand-alone dedicated control channel (SDCCH) is used for the transfer of short messages (SM), multiple short message transactions (MUST), unstructured supplementary service data (USSD) and subscriber-controlled input (SCI). Without the intra-MSC SDDCH handover, the transfer of this information is interrupted if a mobile station moves from one BSC area to another one. This feature provides the intra-MSC handover of the SDCCH from one BSC to another BSC connected to the same MSC for SM, MUST, USSD and SCI mobile originating (MO) and mobile terminating (MT). This allows a continuous use of these services and a load reduction in the MSC.
USSD is seen as a superior bearer for WAP, as there is a significantly reduced response time by the server, because no SMSC is involved in the transport. These WAP sessions are expected to have a mean duration of 5 to 10 minutes. For a moving subscriber with an ongoing WAP dialog, the probability of crossing a BSC area boundary is significant. For these cases the intra-MSC SDCCH handover is very valuable, as it avoids interruptions of the WAP session.
4.8.5.2
Hard Handover (3G only)

A hard handover is a handover in which the MS is required to either tune its radio equipment or reestablish synchronization. A hard handover applies to the FDD and TDD mode. Hard handover is the passing on of a call from radio cell to radio cell. The physical connection between the MS and the 3G RAN is changed. This process is always started whenever a new radio cell provides better transmission quality, e.g., because the mobile subscriber moves into the new radio cell during a call, or the transmission quality changes for other reasons. This method ensures that the call is always assigned to the most suitable radio path. Different types of hard handover are distinguished according to the arrangement of the old and new radio cells within the 3G RAN network. Several hard handovers in succession can be necessary while a call is in progress. A distinction is made between the first hard handover and subsequent hard handovers. For 3G RAN (RNC)-controlled hard handover see System Description, register RAN UMTS. MSC-controlled hard handover A type of MSC-controlled hard handover is a 3G MSC relocation of serving RNS (see section 4.8.5.3).
230
DRAFT
A50016-D1112-V41-2-7618
Information System
4.8.5.3
3G to 3G Handover/Relocation (3G only)

The process relocation is generally the same as the process handover. Relocation is a short form of MSC relocation of serving RNS or SRNS relocation. The difference is that the 3G RAN (that is, RNS) is able to cancel relocation which must be confirmed by the MSC.
The terms for the procedure formerly known as handover in 2G GSM are: Handover: handover is used in 2G CNcs and inter-system handover between 2G CNcs and 3G CNcs. SRNS relocation: the same procedure in 3G CNcs (RANAP) is called SRNS relocation. Often the term relocation alone is used. It is the same. As 3G CNcs re-uses handover software the term handover is used for software and procedures dealing with relocation. This can cause confusion. The best is to understand handover and relocation as being similar. There are two kinds of SRNS relocation: Intra-MSC that is, the relocation of the Iu interface termination from one RNC to another inside the MSC Inter-MSC that is, the relocation of the Iu interface termination from one RNC to another changing the MSC. Intra-MSC relocation of SRNS The serving radio network subsystem (SRNS) relocation procedure is used to move the RNS Core Network (CN) connection point at the RNS side from the serving RNC (SRNC) to the target RNC (DRNC), from a standing still position or while performing a hard handover decided by the RNS or a radio cell re-/selection in the RNS. The Iu links are relocated in the procedure. If the DRNC is connected to the same MSC as the SRNC, an intra-MSC relocation of SRNS procedure is performed. If the location area is changed, the procedure is followed by an MSC location area update (LUP) procedure without MSC change. The MSC detects that it is an MSC LUP without MSC change by noticing that it also handles the old location area. In this case, the MSC has the necessary information about the MS and there is no need to inform the HLR about the new MS location. The relocation takes place by setting up a new Iu connection to the target RNC (DRNC) and subsequently releasing the former serving side Iu connection (Iu control signaling, transport signaling and data transport). Circuit forwarding takes place between the serving RNC (SRNC) and the DRNC after a new Iu connection has been established (Fig. 4.71).
A50016-D1112-V41-2-7618
DRAFT
231
Information System
(RANAP+AAL2L3) new Iu interface
DRNC
MSC
old Iu interface (RANAP+AAL2L3)
SRNC
Fig. 4.71
intra-MSC relocation of SRNC
Inter 3G MSC relocation of SRNS The serving RNS (SRNS) relocation procedure is used to move the RNS Core Network (CN) connection point at RNS side from the serving RNC (SRNC) to the target RNC (DRNC), from a standing still position or while performing a hard handover decided by the RNS or a cell re-/selection in the RNS. The Iu links are relocated in the procedure. If the DRNC is connected to an MSC other than the SRNC, an inter-MSC relocation of the SRNS procedure is performed. The procedure is followed by an MSC location area update (LUP), with MSC change procedure. The MSC detects that it is an MSC LUP with MSC change by noticing that it does not handle the old location area. In this case, the MSC has to inform the HLR about the new MS location. In case the DRNC belongs to another MSC area, the serving MSC has to cope with inter-CN node interface procedures based on E interface. With the procedures to set up the connection between serving and target MSC, the Iu relocation procedures are piggypacked. The target MSC serves the target Iu connection. There is no difference for the serving and target RNC between intra-MSC and inter-MSC relocations of SRNS. All call control and mobility management functions remain within the source MSC. This is called the anchor principle. The E interface can be seen as an elongated Iu interface (Fig. 4.72).
232
DRAFT
A50016-D1112-V41-2-7618
Information System
MSC-B
DRNC
(MAPv3) E interface (RANAP+AAL2L3) old Iu interface
MSC-A
SRNC
Fig. 4.72
Basic inter-MSC relocation of SRNC
The inter 3G MSC relocation scenarios are defined in 3GPP specifications. Other connected 3G MSC must also support MAPv3 for handover context and inter-MSC 3G to 3G relocation. Only 64 kbit data calls are relocated from a serving RNS to a target RNS. Relocation of all other data services is rejected. Supported inter-MSC relocation scenarios are: 1. 3G to 3G handover from MSC-A to MSC-B (basic inter 3G MSC relocation) - (see Fig. 4.72) During a basic inter-MSC SRNS relocation, the MSC-A initiates and controls all the SRNS relocation procedure, from its initiation (reception of SRNS relocation required from RNS on Iu interface) until its completion (reception of SRNS relocation complete from MSC-B on E interface). 2. 3G to 3G handover between RNC's in MSC-B (subsequent intra-MSC relocation within MSC-B) - (see Fig. 4.73)
DRNC
MSC-B
(RANAP+AAL2L3) new Iu interfaces
DRNC
MSC-A
SRNC
A50016-D1112-V41-2-7618
DRAFT
Fig. 4.73 Subsequent intra-MSC relocation within MSC-B
233
Information System
3. 3G to 3G handover from MSC-B to MSC-B or back to MSC-A (subsequent interMSC relocation) - (see Fig. 4.74)
MSC-B
DRNC
(MAPv3) E interface
MSC-B
DRNC
MSC-A
SRNC/ DRNC
Fig. 4.74
Subsequent inter-MSC relocation (back to MSC-A or to a third MSC)
During a subsequent inter-MSC SRNS relocation back to MSC-A, the MSC-B controls the SRNS relocation procedure until the termination in MSC-A of the handover radio resources allocation (sending of relocation request acknowledge from MSCA to MSC-B). Then all SRNS relocation related messages terminate at MSC-A (e.g., relocation detect/complete from target RNS (DRNC), relocation cancel from serving RNS (SRNS)). During a subsequent inter-MSC SRNS relocation to a third MSC, MSC-A works towards MSC-B' as described above in the basic case and towards MSC-B as described above in the subsequent case.
4.8.5.4
Inter-System Handover from 2G to 3G or 3G to 2G

For many 2G PLMN operators, frequencies are becoming short because of strong growth in the number of 2G mobile subscribers. The inter-system handover feature allows PLMN operators that use both technologies to make best use of their UMTS islands. A PLMN operator is given additional flexibility in terms of network capacity. The 2G (GSM) PLMN load concerning speech calls is relieved. In geographical areas of high subscriber concentration, where the 2G PLMN load has reached a maximum value, e. g., in major cities, this functionality could decrease the subscriber load of the 2G (GSM) PLMN. Furthermore, 3G (UMTS) PLMN usage can be more efficient and sub-
234
DRAFT
A50016-D1112-V41-2-7618
Information System
scribers can be attracted to (additional) 3G services. Thus, 3G features can be offered even to 2G mobile subscribers (prerequisite: mobile subscribers must have MSs).
Circuit-switched speech and data call transactions are handed over from 3G to 2G. Only circuit-switched speech call transactions are handed over from 2G to 3G. MAPv3 (R99) is used on the E interface for inter-system inter-MSC handover. In the case of 3G to 2G inter-system handover where the target MSC is a 2G MSC or 2G MSC part (which supports only MAPv2), a fallback mechanism to MAPv2 is implemented. After handover from 3G to 2G has taken place, subsequent 2G handover and inter-system handover to 3G (both inter-MSC and intra-MSC) is possible. After handover from 2G to 3G has taken place, subsequent 3G handover and inter-system handover to 2G (both inter-MSC and intra-MSC) is possible. After SRNS relocation has occurred in 3G MSC part, handover to 2G is possible. During call setup to/from dual mode MS within 3G or 2G the necessary system information elements which enable inter-system handover to the other system have to be transported to the Core Network (CN). During inter-system handover, radio interface-specific parameters have to be exchanged between a target GSM BSC/UMTS RNC and a serving UMTS RNC/GSM BSC. This means if inter-system handover from 3G to 2G is in progress, GSM-specific radio resource parameters are transported within an RANAP message to the RNC containing the radio resource control (RRC) handover message to the RNC. The comparable process is valid in case of 2G to 3G inter-system handover. To fulfill the security concept, we have to consider two scenarios in each case of handover direction: 2G to 3G If (during call setup) a 2G security context was established (Kc stored), the 2G MSC or 2G MSC part must derive the 3G parameter CK/IK from Kc. If a 3G security context was established (CK/IK stored in 3G MSC part), the 2G MSC or 2G MSC part sends the stored 3G parameter CK/IK to the target RNC in the intra-handover case and derives Kc from CK/IK and sends all the keys in the inter-MSC handover case (if MAPv3 is used on E interface) to the target MSC. 3G to 2G If (during call setup) a 3G security context was established (CK/IK stored in 3G MSC part), the 3G MSC part must derive the 2G cipher key Kc from the stored CK/IK. If a 2G security context was established (Kc stored), the 3G MSC part sends the stored 2G cipher key Kc towards the target BSC in the intra-handover case and derives CK/IK from Kc and sends all the keys in the inter-MSC handover case (if MAPv3 is used on the E interface). There are two kinds of inter-system handover from 3G to 2G/2G to 3G: Call remains within the combined MSC node (intra-MSC handover), that is, serving RNC/BSC and target BSC/RNC are connected to the same MSC node Call is handed over between separated 3G MSC part of a 2G/3G MSC node and 2G MSC nodes (inter-MSC handover), that is, serving RNC/BSC and target BSC/RNC are not connected to the same MSC node. Inter-system handover (intra-MSC, without MSC network node change) 2G to 3G handover The 3G RAN node (RNC) serving the MS, in the case of intra-MSC inter-system change, is served by the same MSC node. If the location area is not changed, the MS triggers a selective location update (LUP) the rst time when uplink or downlink
A50016-D1112-V41-2-7618
DRAFT
235
Information System
speech data is sent. Paging before selective LUP has to be done in both systems (2G and 3G). Fig. 4.75 shows the conguration of an intra-MSC inter-system handover 2G to 3G.
(BSSAP) old A interface
serving BSC
2G/3G MSC
new Iu interface (RANAP+AAL2L3)
target SRNC
Fig. 4.75
Intra-MSC inter-system handover 2G to 3G
The important intra-MSC inter-system handover procedures are: Upon detecting a trigger, serving BSC sends a BSSAP handover requiring message to the 2G MSC or 2G MSC part 2G MSC or 2G MSC part requests 3G RAN radio bearers from target RNC RNC conrms allocation of 3G RAN radio resources to 2G MSC or 2G MSC part 2G MSC or 2G MSC part forwards serving BSC MS hands over Target RNC reports the successful handover to MS 2G MSC or 2G MSC part releases previously allocated bearer resources and forwards this request to serving BSC 2G MSC or 2G MSC part and BSC releases previously allocated bearer resources within 2G PLMN 3G to 2G handover The 2G RAN node (BSC) serving the MS in the case of intra-MSC inter-system change, is served by the same MSC node. If the location area is not changed, the MS triggers a selective location update (LUP) the rst time when uplink or downlink speech data is sent. Paging before selective LUP has to be done in both systems (GSM and UMTS). Fig. 4.76 shows the conguration of an intra-MSC inter-system handover 3G to 2G.
236
DRAFT
A50016-D1112-V41-2-7618
Information System
(BSSAP) new A interface
target BSC
3G/2G MSC
old Iu interface (RANAP+AAL2L3)
serving RNC
Fig. 4.76
Intra-MSC inter-system handover 3G to 2G
The important intra-MSC inter-system handover procedures are as follows: Upon detecting a trigger, serving RNC (SRNC) sends an RANAP handover/relocating requiring message to the 3G MSC part 3G MSC part requests 2G radio bearers from target BSC BSC conrms allocation of GSM radio resources to 3G MSC part 3G MSC part forwards serving RNC MS hands over Target BSC reports the successful handover to MS 3G MSC part releases previously allocated bearer resources and forwards this request to serving RNC 3G MSC part and serving RNC releases previously allocated bearer resources within UMTS. Inter-system handover (inter-MSC, with MSC network node change) During inter-system handover from 2G to 3G / 3G to 2G the call is handed-over between separated 2G MSC node or 2G MSC part of 2G/3G MSC nodes and 3G MSC part of 2G/3G MSC nodes (inter-MSC handover), that is, serving BSC/RNC, and target RNC/BSC are not connected to the same MSC node.
In case of inter-system inter-MSC handover, the 3G MSC part behaves towards the 2G MSC node or the 2G MSC part in the same way as a 2G MSC node or the 2G MSC part behaves towards the 3G MSC part in the same way as a 3G MSC part. 2G to 3G handover The 3G RAN node (RNC) serving the MS, in the case of inter-MSC inter-system change, is served by different MSC nodes. In this case, the location area changes. Therefore, the MS initiates a 3G location update (LUP) procedure after terminating the call. The LUP procedure is either a combined routing area update (RAU)/location update (LUP) or only an LUP.
Supported inter-MSC inter-system scenarios are: 1. 2G to 3G handover from 2G(/3G) MSC-A to 3G(/2G) MSC-B (basic inter-MSC inter-system handover) - (see Fig. 4.77) Fig. 4.77 shows the conguration of an inter-MSC inter-system handover 2G to 3G.
A50016-D1112-V41-2-7618
DRAFT
237
Information System
3G(/2G) MSC-B
target RNC
E interface (MAPv3)
2G(/3G) MSC-A
serving BSC
Fig. 4.77
Basic inter-MSC inter-system handover 2G to 3G
During a basic inter-MSC inter-system handover, the MSC-A initiates and controls the complete inter-system handover procedure, from its initiation (reception of handover required from BSS on A interface) until its completion (reception of complete from the MSC-B on the E interface). 2. 2G to 3G handover within 2G/3G MSC-B (subsequent intra-MSC inter-system handover within 2G/3G MSC-B) - (see Fig. 4.78)
target RNC (RANAP+AAL2L3) new Iu interface
2G/3G MSC-B target BSC (MAPv3) E interface (BSSAP) new A interface
2G(/3G) MSC-A (BSSAP) old A interface
serving BSC
Fig. 4.78
Subsequent intra-MSC inter-system handover 2G to 3G within 2G/3G MSC-B
238
DRAFT
3. 2G to 3G handover from 2G(/3G)-MSC-B to 3G(/2G)-MSC-B or back to 2G(/3G) MSC-A (subsequent inter-MSC inter-system handover) - (see Fig. 4.79 and Fig. 4.79)
A50016-D1112-V41-2-7618
Information System
3G(/2G) MSC-B
target RNC
(MAPv3) E interface (BSSAP) old A interface
2G(/3G) MSC-B
target BSC
(MAPv3) E interface
2G(/3G) MSC-A
serving BSC
Fig. 4.79
Subsequent inter-MSC inter-system handover 2G to 3G (to a third MSC)
During a subsequent inter-MSC inter-system handover to a third MSC, MSC-A works towards MSC-B, as described above in the basic case and towards MSC-B, as described above in the subsequent case.
A50016-D1112-V41-2-7618
DRAFT
239
Information System
2G(/3G) MSC-B
target BSC
(MAPv3) E interface
2G(/3G) MSC-A
serving BSC
target RNC
Fig. 4.80
Subsequent inter-MSC inter-system handover 2G to 3G (back to MSCA)
During a subsequent inter-MSC inter-system handover back to MSC-A, the MSC-B controls the inter-system handover procedure until the termination in MSC-A (e.g., relocation detect/complete from target RNC). 3G to 2G handover The 2G RAN node (BSC) serving the MS, in the case of inter-MSC inter-system change, is served by different MSC nodes. In this case, the location area changes after terminating the call. Therefore, the MS initiates a 2G location update (LUP) procedure. The LUP procedure is either a combined routing area update (RAU)/location update (LUP) or only an LUP. Fig. 4.81 shows the conguration of an inter-MSC inter-system handover 3G to 2G.
Supported inter-MSC inter-system scenarios are: 1. 3G to 2G handover from 3G(/2G) MSC-A to 2G(/3G) MSC-B (basic inter-MSC inter-system handover) - (see Fig. 4.81)
240
DRAFT
A50016-D1112-V41-2-7618
Information System
2G(/3G) MSC-B
target BSC
E interface (MAPv3)
3G(/2G) MSC-A
(RANAP+AAL2L3) old Iu interface
serving RNC
Fig. 4.81
Basic inter-MSC inter-system handover 3G to 2G
During a basic inter-MSC inter-system handover, the MSC-A initiates and controls the complete inter-system handover procedure, from its initiation (reception of SRNS relocation required from RNS on Iu interface) until its completion (reception of handover complete from the MSC-B on the E interface). 2. 3G to 2G handover within 2G/3G MSC-B (subsequent intra-MSC inter-system handover within 2G/3G MSC-B) - (see Fig. 4.82)
target BSC (BSSAP) new A interface
2G/3G MSC-B target RNC (RANAP+AAL2L3) new Iu interfaces
(MAPv3) E interface
3G(/2G) MSC-A
serving RNC
Fig. 4.82
Subsequent intra-MSC inter-system handover 3G to 2G within 2G/3G MSC-B
A50016-D1112-V41-2-7618
DRAFT
3. 3G to 2G handover from 3G(/2G) MSC-B to 2G(/3G) MSC-B or back to 2G(/3G) MSC-A (subsequent inter-MSC inter-system handover) - (see Fig. 4.83 and Fig. 4.84)
241
Information System
2G(/3G) MSC-B
target BSC
(MAPv3) E interface
3G(/2G) MSC-B
target RNC
(MAPv3) E interface
3G(/2G) MSC-A
serving RNC
Fig. 4.83
Subsequent inter-MSC inter-system handover 3G to 2G (to a third MSC)
During a subsequent inter-MSC inter-system handover to a third MSC, MSC-A works towards MSC-B as described above in the basic case and towards MSC-B, as described above in the subsequent case.
242
DRAFT
A50016-D1112-V41-2-7618
Information System
3G(/2G) MSC-B
target RNC
(MAPv3) E interface
3G/2G MSC-A
serving RNC
target BSC
Fig. 4.84
Subsequent inter-MSC inter-system handover 3G to 2G (back to MSCA)
During a subsequent inter-MSC inter-system handover back to MSC-A, the MSC-B controls the inter-system handover procedure until the termination in MSC-A (e.g., handover detect/complete from target BSC, relocation cancel from source RNC).
4.8.5.5
Service Based Handover from 2G to 3G/3G to 2G

This feature gives the PLMN operator the possibility to recommend an inter-system handover of a call from 2G PLMN to 3G PLMN and vice versa. The MSC informs the Radio Access Network (RAN) in the respective assignment and handover (relocation) request messages about the recommendation to perform a handover / relocation (3G only). The handover/ directed retry (2G only)/ relocation (3G only) itself has to be initiated by the RAN. The decision to perform an inter-system handover is left to the RAN. Which type of call is to be handed over and which call is to remain in the 2G PLMN or 3G PLMN is defined by an entry in the MSC database for: speech (TS11) and circuitswitched asynchronous data services (BS20). For BS20, a distinction is made between calls with an air interface user rate (AIUR) of: 9.6 kbit/s / 14.4 kbit/s < AIUR < 57.6 kbit/s. A subfeature enables the PLMN operator to trigger the service based handover procedure based on MCC/MNC (IMSI triggered). The IMSI trigger is implemented for speech calls only. Service-based handover can be administered in MSC/VLR by Q3 tasks/MML commands.
A50016-D1112-V41-2-7618
DRAFT
This feature comprises two independent switchable sales features: Service based handover from 2G to 3G - for 2G speech calls Service-based handover from 3G to 2G - for 3G speech calls
243
Information System
Service-based handover from 3G to 2G - for 3G data service BS20
The reason is to keep the worthy 3G resources on the radio interface, free of calls, which can be handled with similar quality in the 2G PLMN. If a lot of speech calls use the 3G PLMN, then a parallel high speed data application from another subscriber in the same radio cell is limited in its maximum bandwidth. So moving the speech calls or the slow data calls into 2G offers full 3G bandwidth to high speed 3G data users. Service based handover from 2G to 3G for 2G speech calls The use of service based handover from 2G to 3G relieves the radio interface of permanent high load situations in certain areas by handing over calls of either all or certain subscribers (depending on the MCC/MNC) to 3G. The radio interface is then available for a higher rate of other 2G services, such as data services (HSCSD or GPRS). As speech calls are handed over to 3G (without subscriber notice), successful usage of services is possible more easily due to increased network capacity.
Call procedure:
With the introduction of the service based handover from 2G to 3G feature, handover is requested by the Core Network (CN), and not by the Radio Access Network (RAN), as up to now. But apart from the handover trigger, the mechanisms used for the execution of the handover are the same as for the existing 2G PLMN - that is 3G inter-system handover. If the feature is activated and the value ...should_handover_to_UMTS... is selected in the current 2G MSC area, the 2G MSC hands over all speech calls (TS11 service) directly after call setup to the 3G target cell recommended by the MS. Service based handover usage is possible for either all subscribers or for a certain group of subscribers, depending on the subscribers combined MCC and MNC (country / network code). Service based handover can be administered in 2G MSC/VLR using the Q3 tasks/MML commands. Service-based handover from 3G to 2G - for 3G speech calls In order to take advantage of his existing 2G infrastructure and reserve the expensive radio resources for the high data rates needed for 3G applications, it is useful for an operator to hand over all speech calls from 3G to 2G as early as possible.
Call procedure:
In contrast to the standard handover scenario, where a handover is requested by the MS as a result of poor radio conditions, the Core Network (CN) starts service-based handover due to service conditions. A speech call (TS11), which has been established in 3G PLMN, is handed over to 2G if the feature service based handover 3G to 2G - for 3G speech calls is activated and the value ... should_handover_to_GSM ... is chosen. The handover procedure is started after a short period of time (several seconds), which is needed by the MS and 3G RAN to measure available 2G radio cells. The decision to hand over the call is made in the CN, depending on the call type and service-based handover status. The service-based handover is performed using the standard inter-MSC inter-system handover functionality. Service-based handover can be administered in MSC/VLR by Q3 tasks/MML commands.
244
DRAFT
A50016-D1112-V41-2-7618
Information System
Service-based handover from 3G to 2G - for 3G data service BS20 calls With this feature, 2G mobile subscribers are able to use low data connections even if they are currently logged on to an 3G radio cell. It is now possible to migrate all 2G mobile subscribers who have 3G equipment (MS) to 3G PLMN without to informing them: Speech services are directly supported by the 3G PLMN and, using this feature, GSM data connections are also available when logged on to a 3G PLMN. Circuit-switched low data rate calls are a typical 2G feature and the only means of transferring data in a classical 2G PLMN. By means of this feature, this service can also be offered to 2G mobile subscribers currently logged on to a 3G PLMN. Thus, 3G RAN resources are no longer used after handover and are therefore fully available for high data rate services.
Call procedure:
This feature allows a handover from 3G to 2G to be requested by the Core Network (CN). During assignment, a directed retry handover to 2G PLMN is started by 3G RAN. The channel assignment is not established between MSC/VLR and 3G RAN, but between MSC/VLR and 2G RAN. The channel assignment is finished after successful handover to 2G. Service-based handover can be administered in MSC/VLR by Q3 tasks/MML commands and in RNC (the call type has to be set to non-speech).
4.8.5.6
Inter PLMN Handover

PLMN operators tend to seek partnerships in other countries or operate in several countries. This enables them to offer inter-PLMN handover for circuit-switched domain only to their subscribers or partner network subscribers, in accordance with their roaming agreements. If roaming agreements between GSM1800 and GSM900 operators (both 2G PLMN operators) exist, handover between both networks is usually possible. In general, GSM1800 operators do not have full countrywide coverage, in contrast to GSM900 operators. This feature allows GSM1800 operators to gain extended coverage (and thus attract more mobile subscribers) and the GSM900 operators to increase revenue. In less densely populated areas, operators can share investment and operating costs (as well as revenue) and are also able to offer full coverage (better service) to their customers. An existing 3G PLMN operator can set up a 3G PLMN in an urban area, or an 3G PLMN operator can cooperate with an existing 2G PLMN operator. This enables enhanced coverage for 3G mobile subscribers during an active call (circuit-switched call). Basic inter-PLMN handover Inter-MSC handover with international radio cell format is available with the following special characteristics: No separate trafc measurement (inter-PLMN handover is registered via the counter for inter-MSC handover) No support of charging Flexible inter-PLMN handover
A50016-D1112-V41-2-7618
DRAFT
Until now, it has not been possible to restrict or allow inter-PLMN handover for a certain group of subscribers according to operators national or international roaming agreements.
245
Information System
Flexible Inter-PLMN handover allows an inter-PLMN handover for the circuit-switched domain depending on: Target (MCC and MNC of target PLMN) Subscriber IMSI (mobile country code (MCC) / mobile network code (MNC)) with substantial improvement of administration possibilities for the PLMN operators. Evaluation of the allowance (white list)/ restriction (black list) of flexible inter-PLMN handover for the specific subscriber is performed in the MSC-A (anchor MSC: MSC, where the call is established). Subsequent handover is possible. Flexible inter-PLMN handover considers all 2G or 3G inter-PLMN handover possibilities in circuit-switched domain: 2G to 2G, 3G to 3G, 2G to 3G or 3G to 2G handover. Thus, inter-PLMN handover can be offered for an PLMN operators own subscribers and for partner subscribers. In the case of partner subscribers who cross PLMN borders, call connections are maintained without a handover for as long as possible and are then aborted unsuccessfully due to a loss of radio connection. The mobile subscriber has to perform a location update in the new PLMN and set up a new call, which can be charged at a different rate. This leads to a higher standard of service for an PLMN operators own subscribers.
Basic inter-PLMN handover is needed as prerequisite - flexible inter-PLMN handover is only an add-on allowing to restrict the basic inter-PLMN handover feature to groups of subscribers.
4.8.5.7
Directed Retry (MSC-controlled) (2G only)

The directed retry procedure allows the 2G PLMN to select the optimum cell for the MS. The process of directed retry involves the assignment of an MS to a radio channel on a radio cell other than the serving radio cell. Directed retry occurs, if the BSC is not able to support a traffic channel (TCH) request for a particular MS in the required radio cell immediately. Directed retry enables a handover from a stand-alone dedicated control channel (SDCCH) to a traffic channel (TCH) into an overlapping neighboring radio cell or into an umbrella radio cell. Therefore, a directed retry handover is initiated to finish the call setup in another radio cell than the requested one. As a result, directed retry increases the number of successful call setups whenever there is an alternative radio cell available. Directed retry, as described here, is an MSC feature. The MSC-controlled directed retry covers the cases inter-BSC and inter-MSC. BSC and MSC must support this feature. The BSC has to send an appropriate message with handover cause directed retry. Directed retry is already implemented in the BSC, as a BSC-controlled feature (see System Description, register RAN GSM/GPRS), for the case where the new radio cell is under the domain of the same BSC. Possible applications for MSC-controlled directed retry are as follows: Overlay/underlay topology for hot spot areas Areas within a given radio cell within an unusually high traffic request profile are called hot spots. Typical locations are airport restaurants, railway stations, ferry harbors, stock exchange halls, shopping malls and road crossings with daily rush-hour car traffic congestion. These hot spots are well suited to being supported by micro base transceiver stations (BTS) with one or two radio carriers providing between 7 and 15 traffic channels. In overload situations, the existing umbrella radio cell and the hot spot micro-BTS
246
DRAFT
A50016-D1112-V41-2-7618
Information System
can take over from each other even though the requesting mobile station has selected the overloaded radio cell. Capacity gain for the whole network On average the following working assumptions can be made for a typical 2G PLMN: 1. In general 25% of the area covered by a single radio cell is overlapped by other radio cells to make sure that handover works ne. 2. 60% of all BTS connected to a given BSC overlap with radio cells connected to other BSCs. 3. 50% of the overlap areas apply to those radio cells located at the border of a location area (2.) is overlapped by other location areas. As a result, approximately 10% of the total area covered by a 2G PLMN is affected by directed retry in the 2G MSC node or 2G MSC part of a 2G/3G MSC node and profit from synergy effects in overload situations.
4.8.6 4.8.6.1
Roaming Definitions Roaming Definitions for Own and Foreign Mobile Subscribers
Roaming means that the mobile subscriber can move freely within a public land mobile network (PLMN) or in the international service area. The mobile subscriber always remains accessible, subject to any allocated roaming restrictions, and can set up outgoing calls at any time or receive incoming calls (provided these possibilities are not barred by the traffic restrictions supplementary services). During the location update procedure the visited VLR first verifies if restrictions apply due to national roaming agreements or flexible roaming by checking the appropriate databases (that is, HLR and VLR). 1. Roaming restrictions on the basis of the denition of international roaming agreement The service providers of several PLMNs, belonging to different countries, can make international roaming agreements. this type of agreement offers mobile subscribers the ability to access normal services at specic locations outside their home PLMN and in a PLMN outside their own country. 2. Roaming restrictions on the basis of the denition of national roaming agreement The service providers of several PLMNs, belonging to the same country, can decide on national roaming agreements. Such agreements offer mobile subscribers the facility to access normal service in specic locations outside their home PLMN or equivalent PLMN, but still in a PLMN of their own country. 3. Roaming restrictions on the basis of the denition of exible roaming A service provider can also use the optional exible roaming feature. This feature allows the PLMN operator to select roaming subscribers according to their home PLMN (HPLMN), their network access subscription, and the radio resource in use. This is a more advanced feature than national roaming services. 4. Roaming restrictions on the basis of the network access subscription / subscription restriction When mobile subscribers are roaming, the HLR always checks the network access subscription/subscription restriction before informing the visited VLR that the location update is accepted. The network access subscription/subscription restriction is entered in the HLR, where it is stored in each mobile subscribers data records.
A50016-D1112-V41-2-7618
DRAFT
247
Information System
5. Roaming restrictions on the basis of the denition of roaming areas If the mobile subscriber also possesses a roaming area list and parts of the VLR-ID (CC, CC+NDC, CC+NDC+vvv) are contained in this list, roaming either is or is not permitted as regards the HLR (depending on whether the list has a positive or negative ID). 6. Roaming restrictions on the basis of the denition of regional zones Further checks can also be conducted (e.g., for regional subscription) in the location MSC/VLR if the HLR tests prove positive. This also applies to national roaming agreements. Roaming authorization checks are performed on the basis of the definitions made for roaming in the HLR and in the MSC/VLR. In the HLR, the roaming definitions can be made for own mobile subscribers. The roaming definitions for foreign mobile subscribers are based on agreements between the PLMN providers and have to be configured in individual options in the MSC/VLR. It is possible to administer the following roaming options in the HLR for own subscribers (depending on project data - some of these options cannot be available): Subscription restriction In the home PLMN only In the own national PLMN and all foreign PLMNs In all national and foreign PLMNs Additional, a roaming area can be assigned that refers to a list of sites in which the mobile subscriber is allowed or not allowed to roam. Regional roaming restrictions dened by zones codes A mobile subscriber is assigned from one to ten zone codes per PLMN. In the MSC/VLR, these zone codes are assigned location areas or radio cells. The mobile subscriber can roam only in the corresponding areas. Network access subscription species the types of radio access network a mobile subscriber is allowed to use 2G RANs only (BSS) 3G RANs only (UTRAN) Both 2G and 3G RANs The following options concerning roaming can be administered at the MSC/VLR (depending on project data - some of these options cannot be available): Flexible roaming for all mobile subscribers in the MSC area allows the PLMN operator to control the roaming of his own, foreign national and foreign international mobile subscribers into his PLMN. National roaming for foreign national mobile subscribers in the MSC area allows the operator to restrict roaming of foreign national mobile subscribers into his network (this feature can easily be replaced by exible roaming). Mapping of regional areas in the MSC onto the HLR zone codes Regional areas consist of either location areas or radio cells. Equivalent PLMN list for all mobile subscribers in the MSC area The PLMNs in this list should be handled by the mobile station as equivalent to each other. Home environment support with the multiple PLMN feature (see section 4.8.7.1) Home environment support means that from the mobile subscribers point of view there is no difference between their home networks and foreign networks that provide home environment support
248
DRAFT
A50016-D1112-V41-2-7618
Information System
Subscription restriction (+ roaming area restriction + regional roaming restriction) The PLMN operator can issue the following roaming restrictions for all mobile subscribers in the HLR within the context of what is known as a subscriber agreement (see section 4.13.8): Roaming in all PLMNs nationally and internationally Roaming only for the MS's home national PLMN and all other international PLMNs Roaming exclusively in the home PLMN Roaming in a dened selection of PLMNs: roaming areas are dened which each contain one or more PLMNs. Assigning this type of roaming area to a mobile subscriber restricts the subscriber to precisely the given PLMNs. There are two features to narrow down the above restriction: Roaming area restriction The mobile subscriber is assigned a roaming area name by referring to a site list. This list can include up to 200 ISDN numbers, by which several VLR area sites are dened. Regional subscription The mobile subscriber is assigned a zone code list per PLMN in the HLR. This can comprise of up to 10 regional subscription zone identities (RSZIs). Each RSZI identies a regional subscription zone where the mobile subscriber either is or is not allowed to roam, depending on the assignments in the VLR database (which can either be dened as a combination of radio cells or location areas). The basis of this mobile subscriber agreement (subscription restriction) is a roaming agreement between the home PLMN (HPLMN) and the different PLMNs (VPLMN) that are visited. An international service area encompasses several national 3G service areas with one PLMN or more PLMNs and corresponding administrative agreements between PLMN operators. A prerequisite for international roaming is the use of signaling system no.7 (SS7) in the international telephone network. Network access subscription The network access subscription feature enables a PLMN operator of a combined 2G/3G PLMN to allow or restrict 3G radio access for its mobile subscribers depending on their subscription type. The network access subscription provides information within the mobile subscribers own PLMN (home PLMN) that is administrable on a per subscriber basis (explicit subscription). This subscription can also be interpreted in the following way: 3G access allowed / 3G access not allowed. The 3GPP standards do not define any standard for network access subscription; it is a proprietary solution. Network access subscription is set by a flag in the HLR mobile subscriber subscription. The network access subscription is stored as part of the mobile subscriber data in the HLR database and can range from permitting access only for 2G or only for 3G radio access networks or permitting access via both radio access networks. The network access subscription works together with the flexible roaming feature if the flexible roaming feature is activated in the MSC/VLR. Flexible roaming
A50016-D1112-V41-2-7618
DRAFT
This feature enables a PLMN operator to allow/restrict network areas for its own or foreign subscriber categories (access type specific) and, therefore, offers an additional means of optimizing network resources.
249
Information System
Flexible roaming is a feature which allows a PLMN operator to allow/restrict roaming in its PLMN, or in certain areas of its PLMN (areas to be defined on LAC granularity) for all roaming mobile subscribers (that is, the PLMN operators own mobile subscribers, foreign national mobile subscribers, and foreign international mobile subscribers), depending on four criteria: Type of subscription (2G or 3G; only applicable in combination with the general mobile subscriber subscription) Type of the used access interface (A, or Iu interface) Location (LAC) Home PLMN (that is, the MCC/MNC has to be evaluated) Flexible roaming is applicable for 2G and 3G; however, it provides the greatest benefits in a combined 2G/3G PLMN. It needs to be implemented in all MSC/VLRs. If the network consists of a circuit-switched domain and a packet-switched domain (this is the case in a 3G PLMN and in combined 2G (GSM/GPRS) PLMN, the implementation of the equivalent packet-switched feature is also required.
This feature can be used for certain infrastructure sharing scenarios as well as for virtual network operator (see also section 4.8.7), whereas infrastructure sharing in general is one of the most powerful tools for optimized resource management. Infrastructure sharing is highly important as a measure to speed up network roll-out and, at the same time, achieve considerable CAPEX and OPEX savings. Infrastructure sharing scenarios: e.g., roaming cooperation between two or more national PLMN operators. International/national roaming agreements International/national roaming includes the option of restricting the use of telecommunication services for mobile subscribers who are resident in another PLMN in their individual MSC/VLR area. A restriction of this type is defined at the location areas level in the relevant MSC/VLR network node. International/national roaming controls the access of foreign national or international mobile subscribers to the VPLMN depending on their mobile country code (MCC) and mobile network code (MNC) within a special identified location area. The national roaming subfeature only works for national applications, which means that the MCC of the mobile subscribers IMSI has to be the same as the MCC for MSC identification. The international roaming subfeature also allows mobile subscribers with different MCCs to access the network.
The above flexible roaming feature has a functionality similar to the national roaming subfeature; however, national roaming cannot distinguish between different network types (2G and 3G). National roaming also covers only national HPLMN-IDs. The flexible roaming feature can easily replace the national roaming subfeature, but these two roaming features can also exist in parallel. Equivalent PLMN list Under normal circumstances, mobile subscribers are dedicated to their home PLMN, and the visited PLMNs are owned by only one PLMN operator and identified by a single combination of mobile country code and mobile network code. In the telecom world of today, there is however a need for MSs to treat a number of PLMNs in an equivalent way. This is possible, provided that the mobile station (MS) meets the 3GPP R99 or later standard.
250
DRAFT
A50016-D1112-V41-2-7618
Information System
There are a number of advantages in using an equivalent PLMN list. Infrastructure sharing, for example: Two 3G PLMN operators with independent access infrastructure in parts of a country sharing the access infrastructure in those parts where they do not each have their own PLMN Two 2G PLMN operators sharing a common 3G infrastructure One operator operating two PLMNs with different PLMN codes (e.g., a 2G and 3G access infrastructure) The possibility for international operators to dene their different PLMNs in different countries as equivalent to each other regarding international roaming of their mobile subscribers The ability to create a common look-and-feel (and possible tariffs) for customers when roaming abroad. This prevents mobile subscribers from changing to a foreign PLMN operator with probably higher international roaming tariffs. The equivalent PLMN list feature allows the PLMN operator to define PLMNs (MCC, MNC), which the mobile station (support of 3GPP R99 or later necessary) is intended to regard as equivalent to its home PLMN (HPLMN). The MS not changes to its home PLMN from a radio access network (RAN), which broadcasts a VPLMN code that is in the equivalent PLMN list. This mechanism makes a VPLMN equivalent to the HPLMN for PLMN selection, cell selection, and cell reselection. Additionally, this function enables international PLMN operators to define their different PLMNs in different countries as equivalent to each other, with regard to the international roaming permissions of their mobile subscribers. Up to 1000 EPLMN lists, including a base entry, are defined in the MSC-database by Q3 tasks/MML commands. During location update, precisely one EPLMN list with up to 5 MCC/MNC-combinations has sent from the visited MSC to the MS, independent if it is an own or an foreign mobile subscriber. The list depends on the subscribers HPLMN_ID (up to 8 digits of IMSI) and (optional) the current location area code (LAC). If the HPLMN_ID of a mobile subscriber is not found, a list of base entries is sent. The MS stores the list on its (U)SIM card. (Exception: If a member of the list already exists in the forbidden PLMN the MS does not store it.) The equivalent PLMN list overrules a preferred network list that can also exist on the (U)SIM card. The code of the PLMN that sends the list is always added. If no EPLMN list is contained within the location update message, the existing list is deleted.
4.8.6.2
Roaming Definitions for Own or Foreign CAMEL Mobile Subscribers

Because of the CAMEL definition, the basis of the applicability of those CAMEL services in various PLMNs (VPLMN) that are visited, is a separate roaming agreement between the HPLMN and the VPLMN. During location update of foreign PLMN CAMEL mobile subscribers, the CAMEL roaming agreement status of the mobile subscribers PLMN has to be checked in the visited VLR. The PLMN operator can administer all PLMNs whose roaming mobile subscribers are allowed to subscribe to CAMEL in the operator PLMN in a separate table.
4.8.6.3
A50016-D1112-V41-2-7618
DRAFT
Roaming Definitions for WLL Subscribers
For WLL subscribers in a CSC, roaming is basically governed by the same principles as for mobile subscribers. The only difference is the roaming restrictions applicable from
251
Information System
the outset to all WLL subscribers, e.g., roaming is only allowed within a defined location area.
4.8.7
Sharing PLMN Resources (Infrastructure Sharing)

To reduce investment costs for network equipment and allow fast service coverage roll out, the sharing of PLMN resources is becoming important for new networks. The following table summarizes the different scenarios and their relevance for the Core Network (CN): Shared Site resource BTS / Node B no --Multioperator RAN no Multiple RAN at one MSC / Multi-operator CN yes Equivalent PLMN list National/flexible roaming Common shared network yes Equivalent PLMN list National/flexible roaming Roaming cooperation
CN affected
no ---
yes Equivalent PLMN list National/flexible roaming Inter-system and interPLMN handover
A/Iu flexibility *) Inter-system and interPLMN handover
*) The feature A/Iu flexibility is not available with current software version (it is specified with 3GPP Rel-5 feature from standardization) Tab. 4.8 Methods of infrastructure sharing and CN relevancy
In practice, the different methods shown in Tab. 4.8 can be combined for a specific scenario/configuration. Network sharing and roaming cooperation are summarized as follows: Both variants (equivalent PLMN list (see section 4.8.6.1), national/flexible roaming (see section 4.8.6.1)) do not request any new type of interface in terms of the CN architecture. Network sharing and roaming cooperation are based on circuit-switched entities (see line CN related features in Tab. 4.8). At most additional logical functionality (network entity and interfaces) is needed depending on the sharing variant in detail. For the variant which bases on the support of multiple PLMN-IDs by single CN entities (MSC/VLR and HLR) refer to the following section 4.8.7.1. The main difference is the use of an additional third common used network (RAN and CN) for shared network configuration. In both cases, different roaming and handover-related functionality of circuitswitched and handover entities is required.
4.8.7.1
Support of Multiple PLMNs in an MSC/VLR

Multiple PLMN (via parallel handling of several PLMN-IDs, that is, MCC/MNC), is supported by the CN network element MSC/VLR. It can be understood as splitting one phys-
252
DRAFT
A50016-D1112-V41-2-7618
Information System
ical MSC into several logical MSCs, serving one PLMN each. Within a CN this feature could be applied per single MSC.
This feature is of proprietary nature and not specified in any standardization document. Fig. 4.85 shows the primary network configuration with an MSC/VLR which is capable to support more than one PLMN in parallel. This feature allows different usage from CN sight. Simplest to connect more than one RAN, each with different PLMN-ID, per MSC. All idle/connected mode aspects like roaming, handover are still handled as this would be different PLMNs and supported by completely separated PLMNs. Additionally it is possible to enable home PLMN (HPLMN) environment for subscribers belonging to different PLMNs. From MSC/VLR point of view serving different PLMNs means that one physical MSC/VLR acts as different logical MSC/VLRs with respect to: Radio Access Network (RAN) The RAN consists of several radio cells, which are grouped in location areas (LAs) and which are identied by the location area identier (LAI). The LAI consists of the PLMN code and the location area code (LACOD): LAI = MCC + MNC + LACOD As the LAI contains the PLMN code, it is the main criterion to distinguish between the different RANs within the MSC. Mobile subscriber handling In case of multiple PLMN support by the MSC, the MSC has to control the access of a mobile subscriber to all supported PLMNs, especially in case of an inter-PLMN/intra-MSC location area update (LAU). The mobile subscriber is identied by the international mobile subscriber identication (IMSI), which contains the PLMN code as well: IMSI = MCC + MNC + MSIN Based on the IMSI (and the LAI), the MSC decides, if home environment support is granted to mobile subscriber. This can be congured by the PLMN operator in a exible and transparent way by means of the home environment matrix. Handover control The support of an inter-PLMN/intra-MSC-handover is a supported basic element of the feature support of multiple PLMNs in MSC/VLR. Roaming restrictions The feature exible roaming (see section 4.8.6.1, Roaming Denitions for Own and Foreign Mobile Subscribers) offers a huge exibility in controlling the roaming behavior of mobile subscribers in the MSC/VLR. Since it works well together with the feature support of multiple PLMN in MSC/VLR, all inter-PLMN roaming restrictions can be administered in the MSC/VLR. It is possible to administer roaming restrictions based on LAI, IMSI-range and radio interface (2G or 3G). Charging Charging information is provided in one single charging le. Each charging record in the le contains the respective PLMN code information (PLMN-ID).
A50016-D1112-V41-2-7618
DRAFT
253
Information System
PLMN A
PLMN J
HLR A CN A
HLR J CN J
CS domain
VMSC SPa
CS domain
SPI) RAN I)
SPX) RAN X)
MCCI)/MNCI)
MCCX)/MNCX)
Legend: RAN = 2G or 3G PLMN ID = MCC/MNC SPI) .. SPX) Signaling point per RAN SPa Signaling point MSC
Signaling Traffic (speech and data)
Fig. 4.85
Basic configuration for multiple PLMN support
Following scenarios/configurations, as described in the sub topics as follows, are to consider: I) Support of RANs of multiple PLMNs Radio Access Networks (2G or 3G) broadcasting different PLMN-IDs (MCC, MNC) can be connected to one single MSC/VLR. This enables different PLMN providers to share their infrastructure on the basis of the MSC/VLR. The RANs continue to belong to separate PLMNs, and the shared MSC/VLR act as different logical MSC/VLRs with respect to RAN and mobile subscriber handling. Consequently, roaming between these RANs is considered as a PLMN change by default. II) Support of home environment for external mobile subscribers
254
DRAFT
With the feature support of home environment for external mobile subscribers, it is possible to provide mobile subscribers of up to ten PLMNs, that is, mobile subscriber origins, the functionality of their home PLMNs. From the mobile subscribers point of
A50016-D1112-V41-2-7618
Information System
view, there is no difference between their home PLMNs and foreign PLMNs that provide home environment support. The home environment support can be set individual for each roaming subscribers home PLMN and the PLMN of a shared RAN in the home environment control matrix. For example home environment support is set for each RAN area or for the whole MSC area or individual for each combination of subscriber's home PLMN and PLMN of a shared RAN. Home environment support per RAN (default home environment support) As a default each mobile subscriber receives home environment support in the RAN area which broadcasts the PLMN-Id (MCC, MNC) of the subscribers IMSI, that is, home environment support in the own RAN area of a shared MSC. Roaming between the RAN areas of a shared MSC is considered as PLMN change with all consequences. Mobile subscribers that are in the HLPMN in one location area can become international or national roamers by roaming towards another location area served by the same MSC. Home environment support per MSC (MSC and RAN sharing) All RAN areas of the MSC (broadcasting different PLMN-IDs) are shared between multiple PLMNs. All mobile subscribers, whos IMSIs indicate a PLMN-ID supported by the MSC, are considered as at home in the complete MSC area. Inter-PLMN, intra-MSC handover is supported as well as inter-MSC, inter-PLMN handover. This reduces the signaling load with respect to the number of inter-PLMN/inter-MSC handover respective inter-PLMN/inter-MSC changes.
Enhancement of network identity and time zone: Within shared networks, mobile subscribers require correct information about their roaming state, as this determines the charging tariffs and services currently available to them. When mobile subscribers roam in PLMN service areas that provide home environment service, this must be apparent by displaying the mobile subscribers' HPLMN names in the MS. On the other hand, if mobile subscribers roam in PLMN service areas in which they are handled as foreign roamers, this should also be reflected correctly by displaying a foreign PLMN name. The feature network information and time zone can be used to provide mobile subscribers with valid and up-to-date network information. This functionality is achieved by a database enhancement, which allows network information to be provided depending on the LA (and hence the PLMN service area) in which the mobile subscribers roam. See also the following section 4.8.7.2.
Possible applications Infrastructure sharing / fusion or cooperation of PLMN operators Operation of a 2G GSM900 and 2G GSM1800 PLMN with different MCCs/MNCs with one MSC Operation of a 2G and 3G PLMN with different MCCs/MNCs with one MSC Operation of different PLMNs in one MSC Provision of home environment service for mobile subscribers of different PLMNs Change of network identications Operation of different MCCs/MNCs during period of transition
4.8.7.2
Network Identity and Time Zone

A new feature network identity and time zone (NITZ) has been introduced to support mobile subscribers with an improved time zone and network identity handling. This new feature allows a serving PLMN to transfer its current identity (network name), local time,
A50016-D1112-V41-2-7618
DRAFT
255
Information System
time zone (difference between local time and GMT), and daylight saving time (adjustment for summer time (0 +1h or + 2h) to an MS registered in the VLR. With this new feature, PLMN operators can provide the following benefits for their customers: Changes of time information are automatically updated and displayed on the MSs. This feature allows the PLMN operator to offer mobile subscribers the automatic update of accurate time information in the case of: Time adjustment for summer or wintertime. A mobile subscriber enters a new area located in a different time zone. Today, if time information changes, customers have to manually adjust time information. Providing the new network identity in case the mobile subscriber enters a new PLMN. In addition to the scenario dened by the standard, the SIEMENS solution provides optimum support of virtual network operation (VNO) and international PLMN operator groups by selecting the broadcast network name depending on the HPLMN of the mobile subscriber. Updates of the information available in the MS if the MS is registered in the PLMN in combination with one of the following events: The PLMN changes its local time zone (LTZ), e.g., between summer and winter time. The PLMN changes its identity. Using the virtual network operation concept and the mechanism of the equivalent PLMN list (see section 4.8.6.1), the PLMN operator can support these features with the introduction of the network identity and time zone feature. This feature allows the PLMN operator to assign familiar or equal network names for PLMNs belonging to the preferred network infrastructure. This familiarizes and ties their customers to the infrastructure supported by the home PLMNs operator, even in a foreign environment.
4.8.8
Cell-Oriented Routing of Service Numbers

Cell-oriented routing of service numbers (with short codes) enables certain MOCs to be routed to different destination directory numbers as a function of the location of the mobile subscriber (that is, originating radio cell of the MOC). A short code service number can therefore be defined which is uniform in the entire PLMN for a specific service provider. A mobile subscriber who dials this short code service number is connected to the service station assigned to his current location. An example of a service station is the vehicle recovery service. With this function it is possible to establish a number of service providers and assign the associated local directory numbers to the service number. A small number of the total service numbers possible can be defined as emergency numbers. This makes it possible to implement further emergency call services in addition to the teleservice emergency call. These emergency numbers can be given priority, in the same way as the directory numbers of the teleservice emergency call.
4.8.9
Subscriber-Related Routing of Service Numbers

Subscriber-related routing of service numbers (with short codes) provides the option of routing specific MOCs in the originating MSC to a personal service application in a service center as a function of the directory number of the calling mobile subscriber. Examples of personal service applications in the service center are voice mailboxes.
256
DRAFT
A50016-D1112-V41-2-7618
Information System
The mobile subscriber selects a short code which is valid throughout the PLMN and the MSC automatically determines the mobile subscriber-specific service number (MSISDN of the calling mobile subscriber + service indicator SI (=XY). The originating MSC uses this service number to start a kind of interrogation at the HLR of the calling mobile subscriber. The HLR provides the MSC with a mobile subscriber service address of the service center as the routing address. The MSC routes the call to the service center, therefore setting up the call. The mobile subscriber can expand the short code with defined digits (short code sub-addressing) to specify a service and to select various services in the service center as an example. The additional digits are not used for routing in the CN. Use of the flexible routing of calls in CN feature (see section 4.7.1) for certain types of connections can, in addition, modify the use of subscriber-related routing of service numbers. Subscriber-related routing is also possible with multiple PLMNs in an MSC (see section 4.8.7). The different PLMNs can use different service indicators X, since these are stored according to the PLMN. The different PLMNs can use their own short numbers for their specific services. If home environment support (see section 4.8.7.1) is provided for multiple PLMNs in one MSC, and a short number is used by more than one PLMN, then this short number must lead to the same service code Y.
4.8.10
Off-Air Call Setup (OACSU) for CN Switching Nodes

For an MOC, the CN provides three different strategies for assigning the radio resources at the radio interface. The first two strategies lead to the immediate assignment of the radio interface, while the third strategy leads to a delayed assignment. In the case of a basic MOC, the traffic channel (TCH) between the calling mobile station and the MSC at the radio interface is assigned or through-connected immediately after the call is opened, even though it still is not known whether or not the call is set up at all. The immediate assignment of the radio interface can ensue in two different stages (very early assignment or normal assignment). If the off-air call set-up (OACSU) feature is used, the assignment of a suitable traffic channel (TCH) at the radio interface is always delayed until the called subscriber accepts the incoming call. The call is not delayed for the mobile subscriber who is called, although the call can sometimes be diverted temporarily to a recorded message unit, until the call has been fully established, that is, also through-connected via the radio interface. This allows radio resources to be saved at the radio interface if multiple calls are to be set up at the same time. The OACSU feature is implemented in accordance with the 3GPP standards. If the OACSU feature is implemented and activated in the MSC, it is triggered with each MOC by the telephony teleservice. The OACSU feature is bypassed for international and emergency calls.
4.8.11
Queuing and Priority for Traffic Channels

There are separate queuing and priority mechanisms in the CN and the RAN. The CN mechanisms is described below.
A50016-D1112-V41-2-7618
DRAFT
257
Information System
CN (MSC) controlled queuing and priority Queuing Queuing is performed in the CN when a trafc channel is requested and if all trafc channels in the RAN are busy. The trafc channel assignment is marked and assigned as soon as a trafc channel becomes available in the RAN. In this way, the trafc channel capacities in the RAN are used more efciently by increasing successful assignment of call attempts. Queuing is controlled and managed in the CN network elements (MSC, VLR, HLR). Queuing takes account of the following call types: MOC/MTC (except for an MTC for international calls) and in-call modication (ICM), that is, for a speech/data change on a trafc channel service change and UDI fallback (SCUDIF) (3G only) Queuing is allowed for all basic telecommunication services except for the short message service. Priority The seizure requests for trafc channels in the queue are not processed on the rst come, rst served basis, but use a far more advantageous priority-based strategy. This involves introducing in the relevant CN network elements, priority levels which effect seizure decisions. Three types of priority levels can be distinguished: Priority levels associated with an individual subscriber (For management purposes, the PLMN operator can assign these subscriber-dependent priority levels to a mobile subscriber.) Priority levels associated with a type of event: The events referred to in this document are events requiring trafc channels, e.g., at call initiation, during handover. (These event-related priority levels cannot be assigned by the PLMN operator, and are implemented by installation personnel instead in collaboration with the PLMN operator specically in CN network nodes.) Priority levels associated with the enhanced multilevel precedence and preemption (eMLPP) supplementary service For all priority level types 14 priority levels are available.
4.8.12
Catastrophe Handling For Traffic Channels

This feature enables members of the emergency services, such as the medical, fire and police departments, to gain immediate access to the PLMN when major accidents and natural disasters have occurred. To implement this catastrophe feature, the PLMN operator must activate the supplementary service feature enhanced multilevel precedence and preemption (eMLPP) in the PLMN. The feature eMLPP is used for the transmission of the subscriber priority (ISUP parameter MLPP). This action has the following effect in the PLMN: All explicitly announced emergency service members and department numbers are immediately allocated the highest priority level. This ensures, that all emergency service calls are handled with the highest priority and all calls are set up immediately. These calls encounters no setup delays due to a lack of resources and is not preempted by other calls. The activation duration of this supplementary feature is completely under the control of the network operator. After the network operator has deactivated the supplementary feature, the initial subscriber priority conditions are restored.
258
DRAFT
A50016-D1112-V41-2-7618
Information System
4.8.13
Overload Handling For Traffic Channels

The purpose of overload handling is the supervision of resource overload of the network nodes in the circuit-switched domain of the CN (MSC/VLR network elements, HLR/AC network elements) and the network elements in the RAN. Overload handling has access to the results of performance management (load information) and initiates overload control measures. Overload handling in the circuit-switched domain of the CN (circuit-switched domain) CP platform-based: Overload supervision functions in the circuit-switched domain of the CN nodes monitors the events which affect the trafc load status of such a network node. Any necessary trafc restriction can be increased independently in such CN nodes in steps up to a maximum level, as long as the overload exists. With a decreasing overload, the trafc restriction is successively reduced to a minimum until the CN node returns to normal operation. Overload levels which are denitive for the internal automatic overload handling are dened for overload handling. Therefore, the MSC network element signals its load situation to the BSC/RNC via the A/Iu interface and, if necessary, instructs the BSC/RNC to limit its trafc volume. Overload situations in the BSC/RNCs are also sent to the CP which can then reduce the trafc to these nodes. The PLMN operator receives messages relating to the existence and the extent of the overload via the Switch Commander (SC)/craft terminal local (CTL), to permit additional overload actions to be initiated by entering Q3 tasks /MML commands manually on the SC/CTL, if necessary. MP platform-based: The relevant circuit-switched control plane MP-based subsystems (that is, MP:RANAP/BCF, MP:AAL2, etc.) uses an individual overload reduction mechanism (see also System Description, register GPRS/UMTSps). It operates in a stand-alone manner and is self-sufcient. Overload situations can occur in every network element, and particularly in the CN and RAN processors, on the SS7 transmission paths and on the radio channels. Overload supervision encompasses the detection of an overloaded resource, the recording of information concerning the overloaded SS7, the recording of data on the overloaded RAN, the evaluation of the load and the initiation of countermeasures. The incrementation and decrementation guard timers enable the PLMN operator to adjust network sensitivity with respect to overload. For this purpose, the time between the transmission of two overload messages from the MSC/VLR to the BSC/RNC can be administered. Several overload levels are defined for overload control. The corrective action to be taken depends on the applicable overload level, the type of call and the authentications of the mobile subscriber. The highest overload level restricts the entire traffic. It is used during a system start-up.
Overload treatment restricts the incoming traffic, depending on the overload level which can be progressively increased as long as the overload condition exists. When the overload condition ceases to exist, the overload level and therefore the traffic restriction is progressively reduced.
A50016-D1112-V41-2-7618
DRAFT
The maintenance functions monitor the events which affect the traffic volume conditions. The PLMN operator is notified of the existence of an overload condition.
259
Information System
4.9
Functions for Expanding PLMN Capacity (2G only)

On the assumption that a 2G PLMN is already in operation, 2G PLMN provide various possibilities for expanding the 2G PLMN capacity.
4.9.1
Standard Functions for Capacity Expansion

The following which have already been described elsewhere to a certain extent belong to the standard functions for expanding capacity: Use of base station antennas in omnidirectional/sectorial radio cell structure in multicell operation (see System Description, register RAN GSM/GPRS). This antenna type of operation provides optimum coverage of the service area. Directed retry (see section 4.8.5.7). These functions provide for more effective trafc per connection channel. Frequency hopping (see System Description, register RAN GSM/GPRS), transmit power control (see System Description, register RAN GSM/GPRS). These functions provide a more effective frequency re-use. Discontinuous transmission (DTX)/voice activity detection (VAD) (see System Description, register RAN GSM/GPRS)
4.9.2
Supplementary Functions for Capacity Expansion

Supplementary functions which assist a more comprehensive capacity expansion, are described below. Dual-rate operation Dual-rate operation in 2G PLMN means the function of half-rate and full-rate channel connections at the radio interface (see section 4.5.9). A greater traffic volume relating to the PLMN area is achieved by a greater number of connection channels per frequency carrier. This permits an enormous increase in subscriber capacity, but on the condition that many mobile subscribers use end devices in the PLMN with half-rate codec. The subscriber end devices, however, must have fullrate and half-rate codecs. The capacity increase from using half-rate codecs takes effect when the penetration by end devices with half-rate codecs is proportionately great. Adaptive multi-rate (AMR) speech codec The AMR can flexibly trade speech quality and capacity because the AMR codec (having a high source bit rate) offers speech quality comparable to that of the EFR codec, while the lower source bit rate codecs (also available as half-rate channels) have significantly improved intrinsic speech quality as compared to the previous HR codec. This feature optimizes the trade-off between best speech quality and capacity demand. The flexibility of AMR provides important benefits such as: Improved speech quality in both half-rate and full-rate codecs by means of codec adaptation, that is, varying the balance between speech and channel coding for the same gross bit rate. The ability to trade speech quality and capacity smoothly and exibly by a combination of channel and code adaptation. Improved robustness against channel errors under bad radio signal conditions in the full-rate codec. This increased robustness against errors and hence against interfer-
260
DRAFT
A50016-D1112-V41-2-7618
Information System
ence can be used to increase capacity by operating a tighter frequency reuse pattern. This allows the optimization of networks for high quality or high capacity. The enhanced speech quality provides PLMN operators the opportunity to address new user segments. Corporate and residential markets can be targeted with the speech quality offered by AMR. The enhanced speech quality can also be used as a distinguishing benefit in comparison to other cellular PLMN operators. Enhanced pairing for half-rate (HR) channels This 2G RAN feature, enhanced pairing for half-rate channels is based on the concept of full/dual rate traffic channels which allows the reorganization of half-rate channel pairing in cases where no traffic channel (TCH) full-rate channel is available. This reorganization is performed by an intra-cell handover of the half-rate channel, thus being able to offer full-rate channel capacity. This functionality is also provided for AMR half-rate channels. This feature optimizes allocation of network resources by pairing single halfrate channels, which ensures the allocation of full-rate channels when required, e.g. for data services or MS that do not support half-rate channels. Radio cell-dependent activation of half-rate traffic channels In terms of efficiency, traffic channel/half-rate (TCH/HR) channels should only be realistically allocated during high traffic peaks in a radio cell, when additional capacity is needed. The 2G RAN feature 'radio cell load-dependent activation of half-rate traffic channels in one radio cell supports automatic assignments of HR channels when the number of available traffic channel/full rate (TCH/FR) goes below a predefined threshold. This function allows the PLMN operators the option of only allocating half-rate channels during high traffic peaks, when additional capacity is currently needed, offering flexibility and improving system resource efficiency. The allocation of half-rate channels according to the current radio cell load is also provided for AMR half-rate codecs. Hierarchical radio cell structures 2G PLMN have an hierarchical radio cell structure in the 2G RAN with one or more underlay networks. The lowest network layer consists of many micro cells, and a top layer network consists of macro cells, which each cover several micro cells relating to the PLMN area. See also System Description, register RAN GSM/GPRS and 4.8.5.1. A hierarchical radio cell structure is also needed for multiband operation. A greater traffic volume relating to the PLMN area is achieved due to a larger number of BTSs per PLMN area. Subscriber capacity can be multiplied (e.g. 10x) by such a radio cell structure in 2G RAN by using of micro cells. The 2G PLMN has its own micro-BTS for this purpose. The micro cell also has the advantage that increased capacity is available immediately after the additional base stations become operational. GSM900 extended-band operation The 2G PLMN has a GSM900 extended-band operation. GSM900 extended-band operation means supporting the GSM frequencies (900 MHz band) via the GSM900 primary band, up to the limits of the home PLMN (see also System Description, register Network System Concept, section GSM Radio Interface).
A50016-D1112-V41-2-7618
DRAFT
A greater traffic volume relating to the PLMN area is achieved due to a larger bandwidth per PLMN area. A precondition for this function, however, is that the PLMN operator can licence not only the GSM900 primary band but also the GSM900 extended band. The subscriber terminal devices must be compatible for the expanded GSM frequency band.
261
Information System
Multiband operation The 2G PLMN has multiband operation GSM900/GSM1800. Multiband operation means the support of GSM900 frequencies in the 900 MHz band and GSM1800 frequencies in the 1800 MHz band within the home PLMN (see section 4.8.5.1). A greater traffic volume relating to the PLMN area is achieved due to a larger bandwidth per PLMN area. A precondition for this function, however, is that the PLMN operator can licence not only the 900 MHz band but also the 1800 MHz band. The subscriber terminal devices must be compatible for both frequency bands (multiband mobile station). Expansion of capacity due to using multiband mobiles takes effect when penetration by such multiband mobiles is appropriately high. Common broadcast control channel (BCCH) for GSM900/1800 multiband operation This 2G RAN feature enables the use of a common BCCH for GSM900/1800 in a multiband network, the main advantage being the improvement of the spectral efficiency for this multiband network as compared to the present situation which requires the presence of a BCCH in each band of operation. This solution helps save radio capacity, improve coverage and avoid new BCCH planning activities since one BCCH can be used for both bands. This feature enables PLMN operators to be able to configure a single cell with the frequencies required for both GSM900 and GSM1800 bands, while having a common BCCH in only one of the bands. The BCCH can either belong to the GSM900 or the GSM1800 band. The PLMN operator can configure a single cell with frequencies in both GSM900 and GSM1800 bands while the radio cell still has one common cell identity. In order to optimize signal reception within the concentric cell feature, the BTS selects an intra cell handover from the complete area (GSM900) to the inner area (GSM1800) or vice versa. 24 transceivers (TRX) per cell and handling of GSM900/1800 radio cells The ever increasing need for capacity due to the success of 2G PLMN and the exponential growth of subscriber base demands for high capacity sites. This 2G RAN feature introduces a new concept of mixed cells (GSM900/1800), which allows PLMN operators to increase the number of transceivers (TRX) supported by each radio cell from 12 to 24 (maximum number of TRXs for a BS-240/241 with a rack extension). This feature satisfies customer requests for increased cell capacity. It also allows optimum use of the hardware capacity provided by the BS-240/241. Having a mixed radio cell with a common BCCH (GSM900/1800) with a higher number of TRXs, offers the PLMN operator simpler and more flexible network configurations. Support of second cell broadcast channel Since PLMN operators are increasingly using short message service (SMS) cell broadcasting (SMS-CB) services, cell broadcasting requires more capacity. This 2G RAN feature does just that by offering a second cell broadcast channel making way for the expansion of SMS-CB services for mobile subscribers. The 3GPP standard introduced an extended cell broadcast channel, which is designed to fully use the capacity of the stand-alone dedicated control channel (SDCCH). A cell broadcasting (CB) message can now be broadcasted on two different cell broadcasting channels (CBCH), the basic and the extended. An MS is always able to read the basic channel; whereas the ability to read the extended channel is optional. The scheduling of
262
DRAFT
A50016-D1112-V41-2-7618
Information System
the two channels is independent. The indication whether a message is sent on the basic or on the extended channel is included in the message. Smooth channel modification The smooth channel modification 2G RAN feature supports the allocation of a traffic channel (TCH) or stand-alone dedicated control channel (SDCCH) on a call-by-call basis depending on the current traffic situation. This allows radio resources to be used for speech, data, signaling and short message services (SMS) depending on the current needs without any interruption of other service. Concentric radio cells The 2G PLMN can use concentric radio cells. Two concentric, logical radio cells are equivalent to one radio cell (see System Description, register RAN GSM/GPRS). A greater traffic volume relating to the PLMN area is achieved due to a greater frequency reuse.
4.10
Fraud Prevention/Lawful Interception Functions - for Trafc over TDM CN

As with every technical device, a mobile radio system such as the 2G or 3G PLMN is susceptible to fraudulent use. A number of potential problem areas with respect to fraudulent use are outlined in the following: Abuse of call forwarding (call forwarding, CF, without a subscription restriction) Abuse through multiple call forwarding Criminal mobile subscribers use the time available right through to invoicing (particularly abroad) Roaming mobile subscribers run up high bills which can no longer be collected Abuse of multiparty services. Indications of possible fraudulent use include: Call-forwarded calls are still active even though the subscription restriction has ended Call forwarding is activated an unusually frequent number of times High bills are generated over a relatively short period Registration of unusually long calls. To prevent and minimize fraudulent use of the mobile radio functions, the 2G or 3G PLMN incorporates the following fraud prevention functions.
4.10.1
Barring a Mobile Subscriber SCI from Forwarding Calls to International Diversion Directory Numbers (Service Directory Numbers)
Barring with operator-determined barring (ODB) only prevents direct calls from being set up (MOC or MTC). In order to prevent the corresponding directory numbers from being used for call forwarding, it is possible to define specific directory numbers for premium rate calls and operator-specific barring. These numbers also bar the mobile subscribers in question from forwarding calls. To prevent mobile subscribers from initiating calls that generate high costs (e.g., premium rate), it is possible to use a special feature that works on the basis of ODB.
A50016-D1112-V41-2-7618
DRAFT
263
Information System
In the HLR, this feature prevents mobile subscribers from registering (on SCI basis) a call forwarding operation to a corresponding service directory number which has been barred for the mobile subscriber by ODB. This means, that the mobile subscriber can no longer initiate this type of call forwarding. The mechanism employed to prevent SCI registration (to a service directory number barred with ODB) is the same as that used in the tables for the barred directory numbers for call forwarding feature (section 4.13.11). The solution described here is based on preventing SCI registration of call forwarding in the HLR to a prohibited diversion destination, because the call cannot be set up to the diversion directory numbers barred with ODB in the case of SCI invocation.
4.10.2
Monitoring Calls in the MSC Forwarded with Call Forwarding (CF) and Call Transfer (CT)
Mobile subscribers with the call forwarding (CF) or call transfer (CT) supplementary services can set up multiple calls in succession and subsequently forward these. Once the calls have been forwarded, the mobile subscriber is no longer party to the call. The abuse of this facility which allows a single mobile subscriber to set up as many calls as he likes in quick succession and to maintain these at one and the same time can be prevented in the MSC by monitoring all the calls set up using call forwarding (CF) and call transfer (CT). When this monitoring feature is activated, (manageable) thresholds become valid at the same time which determine the number of calls that can exist simultaneously which have been forwarded by an home mobile subscriber using CF and/or CT. For one mobile subscriber, a maximum of 10 forwarded calls can exist at the same time. Provided that this feature has been activated, all the forwarding operations performed in the MSC using either CF or CT are listed in a file. In the MSC, specific calls recorded by this feature can be identified and cleared down, if necessary.
4.10.3
Variable Starting Time Criterion for Charge Registration of Mobile Subscribers with AOCC (AOCC Time Stamp)
The implementation of AOCC which has been configured according to the 3GPP standard in the past and the associated criterion for the starting time of charge registration of AOCC can sometimes lead to a problem: If a mobile subscriber sets up a call to a teleinfo service or premium rate service and terminates it before charge registration commences in the MSC, the PLMN operator must pay the service provider the share of the charge he has agreed on, while he himself receives no payment from the mobile subscriber because no charge data record has been generated in the MSC. Thanks to an advance in the supplementary service functionality of AOCC which leads to a change in the starting time criterion for charge registration in the MSC, a reliable charge data record can be generated in the MSC for the above-mentioned areas of abuse. This implementation of the extended supplementary service functionality of AOCC is a proprietary solution that constitutes a deviation from the 3GPP standard which cannot be used by phase 1 mobile stations. Depending on the particular project, it is possible to incorporate either the AOCC solution that conforms with the 3GPP standard or the proprietary AOCC solution.
264
DRAFT
A50016-D1112-V41-2-7618
Information System
4.10.4
Fraud Prevention for the First Second of a Call

The fraud prevention for the first second of a call feature allows the PLMN operator to bill calls that last less than one second. This is done by generating charge data records as soon as the B subscriber lifts the handset.
4.10.5
Restricting the Call Duration

A real-time comparison in the MSC can be used to restrict a call when a defined threshold of a charge unit or call duration is reached.
4.10.6
Display of Current Mobile Subscriber Data in the VLR

This function permits the PLMN operator to monitor the mobile subscriber data currently managed in a VLR. This data is identified via the relevant IMSI for this purpose. Data records which can be displayed contain for example: IMSI and MSISDN Status of IMSI attach/detach Local area code (LACOD) Data on telecommunication services Data on operator-determined barring (ODB).
4.10.7
Security Enhancements for Fraud Prevention

There are the two new security enhancements for fraud prevention in the current software version: AC key management security boost Logging of access to AC database AC Key Management Security Boost Authentication and ciphering in PLMNs is based on the subscriber-specific secret key Ki, located on the (U)SIM card and in the AC database. For subscriber data security, the Ki key is encrypted for transport and initially loading to the AC as follows: the Ki key is encrypted with algorithm A4 and K4 key - called A4(Ki). Public key cryptography with the asymmetric K7 key is used to guarantee approved entering of the new K4 key. For periodic change of the public/secret K7 keys, the initial loading of the keys are done by Q3 tasks/MML commands or by chip card interface (see also section 4.13.3, Security-Relevant AC Operator Functions). The current software version introduces a new security enhancement feature (see also section 4.13.4). This AC key management security boost feature provides a higher level of security for the asymmetric A7 algorithm. The A7 RSA algorithm (RSA was invented by Ron Rivest, Adi Shamir, and Leonard Adleman), used for the K7 key is increased from currently 512 bits up to 1024 bits, 2048, and 4096 bits. The A7 RSA algorithm, of up to 1024, 2048, and 4096 bits, can be used in parallel with the 512-bit algorithm. With this feature, the PLMN operator is provided with greatly improved key management security and therefore reduces the probability of fraud for mobile subscribers. In general, the PLMN operator can keep the PLMN on the necessary security level to protect the
A50016-D1112-V41-2-7618
DRAFT
265
Information System
mobile subscriber data from fraudulent attacks. This means, the A7 key of the operator's PLMN is more reliable, offering customers reliable network security.
For this feature, at least the IOP:AUC2 is required for enhanced key management, using RSA (A7) algorithm of up to 2048 bit. To perform the best activation time and performance for IOP:AUC, the IOP:AUC3 should be used. Logging of Access to AC Database Authentication and encryption in telecommunication networks is based on the Ki subscriber-specific secret key, which is located on the (U)SIM card and in the AC database. For subscriber data security, the Ki key is encrypted for storage in the AC as follows: the Ki key is encrypted with algorithm A2 and key K2 - called A2(Ki). The current software version introduces a new security enhancement feature (see also section 4.13.4). The logging of access to AC database feature provides the tracing back of actions, which enable access to the A2 encrypted Ki key in the AC database. Security-relevant events are logged for all accesses to the A2 Ki key, e.g., in case of creation, display, update, activate, and deletion of the encrypted Ki key. The generated security log files that are protected against manipulation are transferred via FTAM to the AC and the content of the security file is encoded according ASN.1. Therefore, the file is protected by means of FTAM protection mechanism and ASN.1 encoding. After the encoded ASN.1 file has been decoded, the security records are stored in a readable text file. The security log file also includes data about the event, which access the Ki key. Therefore, the following data is mandatory logged for every triggered event which leads to access of the Ki key: Event ID Date and time of the triggered event Operator (User) ID Terminal ID Network component (to which the event is belonging) This feature enables the PLMN operator to reveal fraudulent actions against the subscribers encrypted Ki key. The PLMN operator can review the log files to prevent further fraudulent actions and can therefore find the source of the fraudulent attack to the AC database. In addition, the PLMN operator can choose logging of more security-related events and extend data within these events, which provide more flexible logging procedure of security-related events. In general, the PLMN operator can keep the PLMN at the necessary security level to protect the subscriber data from fraudulent attacks. This means, the operators PLMN is provided with a reliable and secure A2 Ki key and are able to offer customers reliable network security.
266
DRAFT
A50016-D1112-V41-2-7618
Information System
4.10.8
Lawful Interception Package

This feature package ensures that government interception requirements are fulfilled in most countries. Therefore, this feature is mandatory so as to attain or keep the mobile network operator license. The functionality and content of this package has been discussed with and agreed on by international authorities and the regulatory bodies in various countries. In a former software version the feature provided the first step of a generic interception solution which replaces former solutions. Other steps complete it and it is completed further with the subsequent releases. For administration it is possible to choose the former solution (standard administration) or current generic solution (enhanced administration). Lawful interception involves using a monitoring function to trace calls from/to a mobile subscriber so that user and signaling information is provided in unencrypted form via separate stub connections to a monitoring center (MC) in the ISDN/PSTN (Fig. 4.86). The consumer in the MC is represented by a law enforcement agency (LEA). Generally, the MSISDN is the basis of selection for an intercepted call. However, it can happen that the MSISDN isnt always available for the consumer (LEA). In this case, the IMSI can be used to identify a mobile subscriber, whether to be intercepted or not. A subjects call content can be delivered to MC using independent channels for the transmitting and receiving paths which make it possible to separate the two traffic directions for speech. To identify which subscriber gave which information, different links for different speech directions can be used. Lawful interception is possible for mobile subscribers. For mobile subscribers, these monitoring methods extend to mobile subscribers of their individual PLMN and to roamers from other PLMNs. In the case of the mobile subscribers to be monitored, the monitoring methods relate to the following activities (e.g.,): MSC/VLR MOC/MTC or MIC/MMC (for all bearer services or teleservices) Short message service (SMS) Subscriber controlled input (SCI) Call forwarding on not reachable (CFNRc) / IMSI detach Call hold Call wait (CW) Multiparty service (MTPY) User-to-user signaling service 1 (UUS1) GMSC Call forwarding unconditional (CFU). Call content recording in the monitoring center (MC) The functions implemented in the monitoring center (MC) include: Recording of information for a monitored call (call content) DTMF tones included, sent by the monitored subscribers Online presentation of call data and the contents of a monitored call Filing into archives and recording for long-term monitoring operations Evaluating and copying the recorded calls. There is an option of ensuring that the call content of intercepted calls is delivered only to legitimate monitoring centers. The calls are separated from the other traffic by using the closed user group functionality. If this optional feature is bought and activated it only
A50016-D1112-V41-2-7618
DRAFT
267
Information System
has to be used for German MCs. For all other MCs there is the option for using it if it has to be used. S-tickets Additional data describing the call which cannot be transferred via the stub line and data from calls without traffic channel signaling is transferred as S-tickets via an X.25 (or TCP/IP) connection to a Lawful Interception - Interception Management System (LIIMS). It is possible to include the IMSI into the S-ticket if available. These data records are created for calls with a traffic channel (MOC/MTC) and for actions not related to the traffic channel (SMS). In addition to the existing S-ticket for lawful interception, it is possible to generate Srecords in the MSC/VLR in the case of the following trigger points (e.g.): Location update Handover between radio cells Subscriber controlled input (SCI) The S-tickets contain the directory numbers of the call subscribers, destination directory numbers for forwarding, the location code for the subscriber at the call time (cell ID, location area code) if available and optionally the location code for location update with VLR change. Variants of call content recording and/or S-ticket delivery There are the following possibilities of delivery: S-tickets only Call content (to MC) and S-tickets Call content (to MC) only. Certain PLMNs require only the knowledge of the spoken word and the involved parties without having any S-tickets. Restricted lawful interception makes use of this fact, therefore an LI-IMS and X.25 (or TCP/IP) network is not necessary. If no LI-IMS is used for administration, other equipment has to be used for interception administration, e.g, an Operation and Maintenance Center. Another form of a Restricted lawful interception provides the capability to deliver call identifying information (other party address information) over the signaling channel in association with call setup to MC without using the S-tickets. This feature offers a costeffective interception solution without X.25 (or TCP/IP) networks.
The generic interception solution offers the options of administering S-tickets in a standard way (such as former solution) or in an enhanced way (with the possibility of administration of new trigger points for new events and layout of the S-tickets in the MSC). For enhanced administration S-tickets can be generated e.g., for failed call attempts and events such as end of call, call answered, etc. With a new option, the MSISDN of the intercepted subscriber is not submitted in the enhanced signaling subaddress field. (Within the LI-IMS, the functionality of removing the subscriber identity has to be supported as well.) To assign the call unambiguously to MC using the S-tickets, a unique number (call-ID) is inserted both in all S-tickets and the called party sub-address. In this way, a PLMNwide unique number generated on a per-call basis is provided that can be used to match S-tickets to the related monitored call. The feature multimonitoring enables the monitoring of the call content by more than one consumer (LEA). For this, a special call processing is used which generates the duplication and distribution of the call content.
268
DRAFT
A50016-D1112-V41-2-7618
Information System
The enhanced feature multiple MCs per S-ticket subscriber makes it possible to connect one marked subscriber via up to five links to different MCs at the same time and generate one S-ticket per event (IMS duplicates the S-tickets for every subsequent MC). This functionality is used for countries where different authorities should be able to monitor subscribers independently. With the option sum signal, it is possible to deliver the sum of all speech signals of a multiparty (MTPY) call including the content of the observed mobile subscriber to the MC (LEA) on one single line/channel. Therefore, it is possible to save one/two additional line(s)/channel(s) per party to the MC (LEA). It is possible to administer whether or not the call is monitored after a call transfer (CT). In cases where observation of the transferred call is not allowed, the interception stops immediately after a call transfer and an end S-ticket is sent to LI-IMS. In cases where the interception of the transferred call is allowed, the call continues to be observed until it is released. Another new feature interception of user-to-user signaling (UUS) enables the user-touser signaling (UUS) information associated with a monitored call to be reported to the LI-IMS with the help of an S-ticket. UUS information is retrieved during setup and in the release phase of a call from associated messages and signaling. Security To ensure that the right MC (LEA) is connected, the COLP (connected line identification presentation) functionality is used on the connection of MSC to MC. Therefore, the MSC checks the information in the COLP information element sent by the MC which is requested at a project level for lawful interception call legs. With MC administration this feature can be switched on/off per MC. If it is activated for an MC, a second ISDN number can be administered for the MC which is also considered as allowed value for the connected line. If COLP authentication fails, call content is not provided. Execution sequences Three independent procedures are provided for lawful interception functionality (see Fig. 4.86): Enhanced administration (1): Identifying the mobile subscriber as an S-subscriber. The identication is undertaken in the network components MSC/GMSC in the S-le by Q3/MML from the LI-IMS via the X.25 (or TCP/IP) interface. S-le administration is also possible in exceptional cases via an Q3/MML interface (directly in PLMN network nodes). Call processing (2): Connecting call stubs to the consumer (law enforcement agency, LEA). One or two call stubs via which the trafc channel information (speech/data) is transmitted are connected to the consumer (LEA) on the call to be monitored. S-ticket generation and transfer (3): Supplementary data describing the call (S-ticket) is generated at the start of monitoring and other trigger points and transferred over an X.25 (or TCP/IP) connection using CMISE to the LI-IMS where the S-tickets are transferred to the monitoring center (MC) via FTAM.
A50016-D1112-V41-2-7618
DRAFT
269
Information System
LI-IMS (1) OSS PSDN (X.25) (MML) (1) Recording, evaluation for consumers (LEA) PSTN node Monitoring center (MC)
(3) PSDN (X.25) FTAM (3) PSDN (X.25) CMISE
(2)
PLMN network node (MSC/VLR)
SS7
(2) ISDN/PSTN
PLMN RAN
PSTN node (e.g., EWSD)
Calling mobile subscriber Called subscriber
Fig. 4.86
Lawful interception with interception for a mobile-originated call (MOC) - in case of X.25 interfaces
HLR interception for roamers If an intercepted mobile subscriber is roaming in an area without access to the local MSCs (outside the intercepted PLMN), no MSC within the intercepted PLMN is able to provide information. Only the HLR is given notice of location updates. With the function HLR interception for roamers switched on, it is possible to provide Stickets from the HLR to MCs (LEAs) via the interception management system (IMS) if the mobile subscriber is roaming in an area without access to the local MSCs and location update is happening. Therefore, the MCs (LEAs) are given notice of the country/PLMN in which their target is roaming.
4.11
Call Handling Functions in the Optional GSM MGW and GSM MSC-S - for Trafc over TDM CN (2G only)
The main objective of this feature is to provide local switching. This functionality keeps the traffic in the originating region, which, on the one hand, minimizes the number of lines between the optional GSM MGW and the MSC (or GSM MSC-S functionality) and,
270
DRAFT
A50016-D1112-V41-2-7618
Information System
on the other hand, optimizes traffic flow between the mobile network and the fixed network.
The GSM MGW concept targets remote locations with a high portion of local traffic. The GSM MGW provides the transport functionality, while call control is performed by the GSM MSC-S functionality of the MSC. This approach represents the first proprietary step towards implementing 3GPP Rel-4 (or later) architecture with its separation of control and transport. The concept of GSM MGW and GSM MSC-S described in this section is a proprietary solution of 3GPP Rel-4 (or later) architecture with its separation of control and transport. It differs from the concept of CS-MGW and MSC-S described in the following section 4.8, Mobile-Specific Functions of Circuit-Switched Call Handling - for Traffic over TDM CN, because the CS-MGW and MSC-S implements the original 3GPP Rel-4 (or later) architecture step by step. Here in the current software version the MSC-S and CS-MGW are still implemented as an integrated internal solution. The GSM MGW requires specific hardware for providing the local switching functionality and the proprietary interfaces (remote timeslot interchange (RTI)). At the controlling MSC (or GSM MSC-S functionality), the component host timeslot interchange (HTI) and message buffer (MB) type D are necessary. To support traffic to/from GSM mobile subscribers, the GSM MGW has to be controlled by a SIEMENS MSC with GSM MSC-S functionality and the same software release version that the GSM MGW uses. Optionally, fixed subscribers can also be connected to the GSM MGW.
When optional fixed subscribers are implemented the stand-alone service for fixed subscribers is available, but not for 2G mobile subscribers. This means that calls between fixed subscribers via different LTGs (ISDN-PAs to ISDN-PABXs) connected at the same GSM MGW node are also possible without GSM MSC-S support (unlike 2G mobile subscriber calls, which are generally not possible without GSM MSC-S support). As charging is performed by the MSC/GSM MSC-S and, in this case, no connection is available to the MSC/GSM MSC-S, charging of fixed subscriber calls is not possible when standalone service is used. It provides two types of interfaces: The GSM MGW provides all common interfaces, which are provided by the MSC: An interface (for access of mobile subscribers), PSTN interface, and MSC - MSC interface on the TDM base. These are standardized interfaces, which can be connected to other PLMN suppliers. The GSM MGW is controlled by the GSM MSC-S functionality via a SIEMENS proprietary control interface. The transport on GSM MGW - GSM MSC-S interface and between different GSM MGWs is complies with common standards, that is, in the case of speech channels to the GSM MSC-S, 64-kbit/s connections are used as usual.
4.11.1
GSM MGW Functions

The optional GSM MGW provides the transport and switching functionality of an MSC while call control is mainly done by the GSM MSC-S functionality. The GSM MGW is connected to the GSM MSC-S functionality via the GSM MGW control interface.
A50016-D1112-V41-2-7618
DRAFT
The GSM MGW is capable of switching GSM voice and circuit-switched data traffic for the following cases: Local mobile-to-mobile trafc (local MIC)
271
Information System
Mobile-to-xed trafc (MOC) and xed to mobile trafc (MTC) Trafc between different GSM MGW (local MMC or MOC/MTC) Long distance trafc from GSM MGW to the controlling GSM MSC-S or to a transit MSC
Additionally, the GSM MGW does not perform SS7 processing, therefore, a SIEMENS MSC (or GSM MSC-S functionality) is required for control of the GSM MGW. The GSM MGW comprises several interconnection possibilities: Interface trunks Trunks between the GSM MSC-S and the GSM MGW for GSM MGW control, SS7 signaling, and user data transport, optionally. Sidedoor trunks Trafc between different GSM MGWs without leading the trafc via the MSC-S. Backdoor trunks Trafc to the PSTN or other MSCs. A interface Trafc to the BSC. The signaling on interface trunks is proprietary; on backdoor trunks and the A interface (and analog/digital line interface), signaling complies with common standards (e.g., ISUP, BSSAP), which allows interworking with standard-compliant nodes of other vendors. Calls to pooled equipment (e.g., DSU, ATCO LTG, LI LTG, UI LTG, CPH LTG) are routed to the GSM MSC-S and from there returned to the MSC MGW in the direction of the communication partner (see also section 4.11.2, GSM MSC-S Functions). This type of equipment is best located at the MSC due to capital expenditure (CAPEX) and operational expenditure (OPEX). Independent switching functions of GSM MGW - connection types The GSM MGW has a large number of independent switching functions for GSM mobile subscribers and optional fixed subscribers connected to the GSM MGW node.
The below connection types show for a GSM mobile subscriber in case of backdoor trunks the MOC case. The MTC case uses the same way of traffic trunks in general, but in reverse direction and utilizing the additional mobility management processes of interrogation and paging. It is possible to connect via backdoor trunks to another PLMN, although this variant seems not favorable due to traffic model considerations. In case of an optional fixed subscriber connection to the GSM MGW node (see above) the following shown examples of connection types for GSM mobile subscribers are also valid for fixed subscribers on GSM MGW node in principle. In the case of an optional fixed subscriber connection to the GSM MGW node, the following examples of connection types for GSM mobile subscribers are also valid for fixed subscribers at the GSM MGW node. Connection within a GSM MGW (local MIC or MOC) The calling subscriber and the called subscriber are connected to a GSM MGW. The trafc connection is switched through directly, within the GSM MGW, without loading the interface trunk with subscriber trafc. The trafc can be lead to another mobile subscriber (local MIC) or via backdoor trunks to a xed subscriber in the PSTN/ISDN (local MOC).
272
DRAFT
A50016-D1112-V41-2-7618
Information System
2G RAN
Calling subscriber (MS)
RAN
RAN
Called subscriber (MS)
Fixed network (e.g. PSTN/ISDN)
GSM MGW Interface trunks HLR/ AC GSM MSC-S (GMSC)
Backdoor trunks Called subscriber LE
CN, CS domain
Fig. 4.87
Connection within a GSM MGW (local MIC or MOC)
A50016-D1112-V41-2-7618
DRAFT
273
Information System
Connection between GSM MGWs (local MMC or MOC) The calling subscriber and the called subscriber belong to adjacent GSM MGWs that are linked via sidedoor trunks. The trafc connection is switched via sidedoor trunks, without loading the interface trunk with subscriber trafc. The trafc can be lead to another mobile subscriber (local MMC) or via the following backdoor trunks to a xed subscriber in the PSTN/ISDN (local MOC).
2G RAN
RAN
RAN
Called subscriber (MS)
Fixed network (e.g. PSTN/ISDN)
GSM MGW
Sidedoor trunks
GSM MGW Backdoor trunks LE Called subscriber
Interface trunks HLR/ AC GSM MSC-S (GMSC)
CN, CS domain
Fig. 4.88
Connection between GSM MGWs (local MMC or MOC)
Connection via the GSM MSC-S (local MMC or MOC) The calling subscriber and the called subscriber belong to different GSM MGWs of the same GSM MSC-S that are not linked via sidedoor trunks. The trafc connection is switched via the GSM MSC-S over interface trunks. This is also the case if, for example, pooled equipment is allocated in GSM MSC-S. This could be e.g., a conference unit (ATCO), in the case of a multiparty service, or a Specialized Resource Function (SRF), in the case of a IN/CAMEL service. The signaling control is switched via the GSM MSC-S as usual, e.g., in the case of a IN/CAMEL service to the SCP/CSE component. The trafc can be switched to another mobile subscriber (local MMC) via interface trunks or via following backdoor trunks to a xed subscriber in the PSTN/ISDN (local MOC).
274
DRAFT
A50016-D1112-V41-2-7618
Information System
2G RAN
RAN
Called subscriber (MS) RAN Fixed network (e.g. PSTN/ISDN)
GSM MGW
GSM MGW Backdoor trunks LE
CN, CS domain HLR/ AC
Interface trunks GSM MSC-S (GMSC)
Called subscriber
SCP/CSE IN/ CAMEL only signaling signaling and traffic not used trunks
Fig. 4.89
Connection via the GSM MSC-S (local MMC or MOC)
4.11.1.1
Framework for Basic Functions

Framework for basic functions together with local switching made only with pooled equipment in the MSC-S and connection via the MSC-S to further network components are (see also section 4.11.2, GSM MSC-S Functions): Interworking function (IWF) for data services (with pooled equipment, that is, DSU in the GSM MSC-S) IN/CAMEL advanced call processing (with pooled equipment, that is, UI LTG or CPH LTG in the GSM MSC-S) Supplementary service call of multi party (with pooled equipment, that is, ATCO LTG in the GSM MSC-S) Broadcast announcements within a call (with pooled equipment, that is, ATCO LTG in the GSM MSC-S) Lawful interception call (with pooled equipment, that is, ATCO LTG in the GSM MSCS) Echo cancellation The DEC in the MSC protects the mobile subscriber against the echo from the PSTN/ISDN. The speech from the mobile subscriber is reflected from the 2 to 4 wire connection of the analog subscriber of the PSTN/ISDN. This is heard from the mobile subscriber as echo if no DEC is in the connection. The distance (delay) between the DEC and the 2 to 4 wire connection is not changed with the introduction of the GSM
A50016-D1112-V41-2-7618
DRAFT
275
Information System
MGW. The MSC sees the MS-BSC-TRAU connection as echo-free. Echo compensation for the mobile side is done within the MS itself and with the TRAU. Call with ASCII services The supplementary service enhanced multi level precedence and preemption (eMLPP) works in a GSM MGW environment without any modifications.
The ASCII services voice group call (VGC) and voice broadcast call (VBC) are not available in a GSM MGW environment. Support of compression on interface trunks and sidedoor trunks For long trunk lines between remote timeslot interchanges (RTIs) and host timeslot interchanges (HTIs) (interface trunks) and between RTIs, which can be more than 1000 km, the compression of trunk lines saves bandwidth. The compression of trunk lines for voice calls (not for data calls) is supported by a special Q3/MML commander line marker that creates a separate line trunk group. This separate line trunk group routes the voice traffic over a compress tool.
4.11.1.2
Framework for Mobility Functions

2G to 2G handover scenarios in GSM MGW The following 2G to 2G handover scenarios for a GSM mobile subscriber via GSM MGW show, for example: Intra GSM MSC-S handover (within a GSM MGW) Intra GSM MSC-S handover (between two adjacent GSM MGWs belonging to the same GSM MSC-S) Inter GSM MSC-S handover (between two GSM MGWs belonging to different MSCSs) Fig. 4.90 shows different 2G to 2G handover scenarios at GSM MGW (here in case of an MOC).
276
DRAFT
A50016-D1112-V41-2-7618
Information System
Calling subscriber (MS) Case 1a Case 1b
Case 1a/1b: Intra GSM MSC-S handover Case 2: Inter GSM MSC-S handover
Case 2
PLMN
BSC
BSC
BSC
BSC
GSM MGW
Sidedoor trunks
GSM MGW
GSM MGW LE
Called subscriber
Interface trunks GSM MSC-S
Backdoor trunks
Interface trunks
GSM MSC-S HLR/ AC Fixed network (e.g. PSTN/ISDN)
Fig. 4.90
Different 2G to 2G handover scenarios at the GSM MGW (here in case of an MOC)
2G to 3G (or vice versa) handover scenarios in GSM MGW The following 2G to 3G (or vice versa) handover scenarios for a mobile subscriber via GSM MGW show, for example: Intra 2G/3G GSM MSC-S handover (between a 2G GSM MGW with concatenated 2G BSC and a 3G RNC belonging to the same 2G/3G GSM MSC-S) Inter-system inter-GSM MSC-S handover (between two GSM MGWs belonging to different GSM MSC-Ss) Fig. 4.91 shows different 2G to 3G (or vice versa) handover scenarios for a mobile subscriber at GSM MGW (here in the case of an MOC).
A50016-D1112-V41-2-7618
DRAFT
277
Information System
Case 1: Intra MSC-S handover (2G to 3G) Case 2: Inter-system inter MSC-S handover (3G to 2G)
Calling subscriber (MS) PLMN Case 1 Case 2
2G BSC
2G BSC Sidedoor trunk
3G RNC
2G BSC
GSM MGW
GSM MGW
Called subscriber LE
Interface trunk 2G/3G GSM MSC-S
Backdoor trunks
Interface trunk
2G GSM MSC-S HLR/ AC Fixed network (e.g. PSTN/ISDN)
Fig. 4.91
Different 2G to 3G (or vice versa) handover scenarios at the GSM MGW (here in the case of an MOC)
4.11.2
GSM MSC-S Functions

The generic SIEMENS MSC is upgraded to provide GSM MSC-S functionality, which communicates with the GSM MGW via the GSM MGW control interface. Therefore, the MSC acts as a standard GSM MSC and additionally controls GSM MGWs. SS7 signaling is transferred from a GSM MGW to the GSM MSC to be processed in the MSC. A GSM MGW can be controlled by one GSM MSC-S, only. Because the GSM MGW control has to be available at all times, this means that the GSM MGW is unavailable if the link between a GSM MGW and the GSM MSC fails. Therefore, a redundant link configuration of the GSM MGW control link is proposed: Either by physically different paths of the direct link to the controlling MSC or by one direct path and one redundant path via an adjacent GSM MGW to the controlling MSC. Both controlling links have to be served by the same host timeslot interchange (HTI) in the MSC as the basis for automatic link re-configuration after a failure.
278
DRAFT
A50016-D1112-V41-2-7618
Information System
Call control functions towards the GSM MGW The basic functions together with local switching made in the GSM MSC-S are: Call control of a local MOC/EMC, a local MTC, a local MIC/MMC (see also section 4.5.1, 4.5.2, 4.5.3) Call control of optimal routing (see also section 4.5.5) Call control of carrier routing call by call and preselected (see also section 4.5.6) Call control of number portability (see also section 4.5.7) Call control of location services (see also section 4.5.8) Call control of IN/CAMEL services (see also section 4.5.4) Call control of trafc data management/measurement Call control of telecommunication services (see also section 4.5.13) Call control of overload handling (see also section 4.8.13) Call control of lawful interception (see also section 4.10.8) Enhanced functions of call routing, charging and user information together with local switching are: SDDPFC Charging and billing together with local switching are: Charging collection function (see also section 4.6.1) Charging gateway function (see also section 4.6.2) Charging with hot operation (see also section 4.6.3) Special charging features (see also section 4.6.6) Interadministrative procedures for billing/revenue accounting (see also section 4.6.4) Mobility functions together with local switching are: Location update (see also section 4.8.2.1 and 4.8.2.2) Handover (see also section 4.8.5.1) Interrogation and paging in case of an MTC (see also section 4.8.2.3) Cell-oriented routing of service numbers (see also section 4.8.8) and subscriber-related routing of service numbers (see also section 4.8.9) In some cases, traffic connections in the GSM MGW need hardware in the GSM MSCS. Thus, these traffic connections have to be routed from the GSM MGW via the GSM MSC-S to the communication partner. For this reason, the following traffic connection functions are made in the GSM MSC-S: Data services (which need the DSU) IN/CAMEL services (which need UI LTG and CPH LTG) Broadcast announcements (which need the ATCO) Multi party supplementary services (which need the ATCO) Lawful interception (which need the LI LTG)
4.12
Call Handling Functions in the MSC-S Part and CS-MGW Part of MSC - for Trafc over ATM CN
The traffic over ATM CN feature introduces the asynchronous transfer mode (ATM) packet transport to the CN as an alternative to the traditional traffic over TDM CN. This enables the PLMN operator to save bandwidth. Resource allocation takes place on demand, providing bandwidth only when it is requested by the mobile subscriber. The main benefit is action on higher usage links. Each customer can decide whether or not to change the whole PLMN of the current software version to ATM. Fig. 4.92 shows the traffic separation 2G RAN/3G RAN - TDM/ATM based CN.
A50016-D1112-V41-2-7618
DRAFT
279
Information System
TDM 2G Radio Access Network (2G RAN) Core Network (CN) using ISUP
MSC
3G Radio Access Network (3G RAN) ATM
Core Network (CN) using BICC and AAL2
Fig. 4.92
Traffic separation 2G RAN/3G RAN - TDM/ATM based CN
The transport of compressed voice over ATM is achieved by the ATM adaptation layer 2 (AAL2), which provides the necessary means for the real-time delivery of traffic with variable bit rates. ATM/AAL2 packet transport can be introduced to an existing CN without changing the existing synchronous digital hierarchy (SDH) transport infrastructure (point-to-point interconnection with ATM-links between the MSCs), or to a newly built ATM backbone if the existing transport infrastructure is upgraded.
If more than 1000 Erlang are required, a TDM in parallel is necessary. The use of ATM/AAL2 in the CN provides additional opportunities for mobile customers. This feature enables the PLMN operator to route voice traffic in the following ways: Using the new ATM backbone technology and the existing time division multiplex (TDM) environment for overow trafc. Using the existing TDM environment and the introduced ATM backbone for overow trafc. This feature supports ATM backbone access for circuit-switched traffic.
4.12.1
MSC Server (MSC-S) Part and Circuit-Switched Media Gateway (CSMGW) Part
Furthermore the concept described above serves as a basis for the overall circuitswitched system architecture of the future. Then the main tasks are the traffic short cut without the use of the classical MSC (first step towards a separated MSC server concept) and the voice over IP (VoIP) support (first step towards an universal circuitswitched Media Gateway (CS-MGW) or PSTN-MGW concept). In the current software version, the focus is on traffic short cut using ATM traffic connections.
280
DRAFT
Fig. 4.94 shows for the 2G PLMN the 1st step with an internal separation of the MSC server (MSC-S) part and an AAL2 gateway part (circuit-switched Media Gateway, CS-
A50016-D1112-V41-2-7618
Information System
MGW) as is implemented in the current software version for traffic over ATM CN implementation.
MSC BSC A interface (BSSAP) E interface (ISUP) Nc interface (BICC)
GMSC
MSC server part
MSC server part
To ISDN/PSTN (ISUP)
RNC
Iu interface (RANAP)
internal
internal
Iu interface (AAL2/PVC
CSMGW
Nb interface (AAL2/PVC)
CSMGW
ATM traffic TDM traffic
Fig. 4.93
Separation of MSC server (MSC-S) part and circuit-switched Media Gateway (CS-MGW) part for traffic over ATM CN implementation in the 2G PLMN
Fig. 4.94 shows for the 3G PLMN the 1st step with an internal separation of the MSC server (MSC-S) part and an AAL2 gateway part (circuit-switched Media Gateway, CSMGW) as is implemented in the current software version for traffic over ATM CN implementation.
A50016-D1112-V41-2-7618
DRAFT
281
Information System
MSC BSC A interface (BSSAP) E interface (ISUP) Nc interface (BICC)
GMSC
MSC server part
MSC server part
To ISDN/PSTN (ISUP)
RNC
Iu interface (RANAP)
internal CSMGW Nb interface (AAL2/PVC)
internal CSMGW
Iu interface (AAL2/PVC
ATM traffic TDM traffic
Fig. 4.94
Separation of MSC-Server (MSC-S) part and circuit-switched Media Gateway (CS-MGW) part for traffic over ATM CN implementation in the 3G PLMN
CS-MGW part functions For ATM traffic the CS-MGW part provides the transport and switching functionality of an MSC while call control is mainly done by the MSC-S part. The CS-MGW part is connected to the MSC-S part via the proprietary internal H.248 based call & bearer control (CBC) interface. The CS-MGW part is capable of switching voice traffic (in ATM CN, see traffic in ATM CN) between different CS-MGW parts for the following cases: Mobile-to-xed trafc (MOC) and xed to mobile trafc (MTC) Mobile-to-mobile trafc (MMC) As it is necessary to enable compressed mode in the ATM leg on traffic path (coming from 2G RAN and leading to ATM CN) an internal loop between the MSC-S and CSMGW is used. This internal loop contains a TDM to ATM conversion with the help of a TRAU server card, type D (TSCD) whereas the TSCD fulfills the AMR compression used for voice over ATM CN. Beside compressed speech by AMR also uncompressed speech by ITU-T standard G.711 is supported. As it is necessary to enable compressed mode in the ATM leg on traffic path (coming from 3G RAN and leading to ATM CN) either ATM transcoder free operation (TrFo) break functionality in AAL2 break server (A2BS) can be used or a traffic loop via TDMlinks to resources of the MSC-Server part can be used. For TDM-links to resources to the MSC-Server traffic path contains a ATM to TDM conversion with the help of a TRAU server card, type D (TSCD) and following a TDM to ATM reconversion with the help of a TSCD whereas the TSCD fulfills the AMR compression used for voice over ATM CN. Beside compressed speech by AMR also uncompressed speech by ITU-T standard G.711 is supported.
282
DRAFT
A50016-D1112-V41-2-7618
Information System
Calls to pooled TDM-based resources (e.g., ATCO LTG, LI LTG, UI LTG, CPH LTG) are routed to the MSC-S part and from there rerouted to the CS-MGW part in the direction of the communication partner(s) via the ATM domain (see also MSC-S part functions below). This type of equipment is best located at the MSC-S part due to capital expenditure (CAPEX) and operational expenditure (OPEX). MSC-S part functions The generic SIEMENS MSC is upgraded to provide MSC-S part, which communicates with the CS-MGW part via the proprietary internal H.248 based call & bearer control (CBC) interface. Therefore, the MSC acts as a standard MSC and additionally controls CS-MGW. SS7 bearer independent call control (BICC) signaling is transferred from an MSC-S part of one node to an MSC-S part of another node. The MSC-S part fulfills the same functions for switching traffic over ATM CN as for switching traffic over TDM CN. Therefore, all functions for traffic over TDM CN described from section 4.5 to 4.10 are, in general, also valid for traffic over ATM CN. Some additional functions for traffic over ATM CN are described in the following sections. In some cases, traffic connections in the CS-MGW part need additional hardware in the MSC-S part. For this reason, the following traffic connection functions are used in the MSC-S part: Multi-party supplementary services (which need the ATCO) Lawful interception (which need the LI LTG) CSC xed network subscriber access (which needs an LTG or a DLU) IN/CAMEL services (which need UI LTG and CPH LTG) Circuit-switched data services (which need DSU together with an IWF LTG)
4.12.2
Basic Functions of Call Handling for Traffic in ATM CN

For mobile originating calls (MOC) in V-MSC and mobile terminating calls (MTC) in GMSC, the result of traffic routing no longer leads just to TDM CN. Depending on some criteria the traffic could be transferred to an ATM CN. The decision of transport the payload in a compressed or uncompressed form depends on some criteria available for call control. This decision must be transmitted to the integrated circuit-switched Media Gateway (CS-MGW) part. In the following, important aspects during MOC, MTC and MMC are described: MOC: To distinguish between trafc routed over ATM CN or TDM CN only the origin of the trafc (Iu or A interface) is evaluated. 3G mobile subscribers who are attached to a 2G RAN are therefore handled like 2G mobile subscribers. The only distinguishing characteristic is which interface (Iu or A interface) is used for the trafc. MTC: To distinguish between trafc over ATM CN or TDM CN in GMSC, the routing database for mobile station routing number (MSRN)/handover routing number (HON) is used. The VMSC should provide different ranges of roaming number blocks for ATMand TDM-trafc during interrogation procedure according to the same rules (e.g., if the mobile subscriber is reachable via Iu or A interface) as used for routing mobile originating trafc to ATM CN or TDM CN. MMC: For mobile-to-mobile calls (MMC) the decision which Core Network (ATM or TDM) to use is taken both at the originating and the terminating side. In the GMSC, the routing to the VMSC via ATM or TDM is done via a conventional routing database.
A50016-D1112-V41-2-7618
DRAFT
283
Information System
4.12.3 4.12.3.1
Framework for Traffic in ATM CN Framework for Basic Call Handling Functions
For the implementation of the feature traffic over ATM CN the following system functions are necessary: Introduction of bearer independent call control (BICC) used as signaling Provision of the logical separation of bearer transport/control and call control as a rst step towards a physical separation Pooled TDM-based resources in the MSC-S part ATM AAL2 transport for circuit-switched trafc (user data) in the CN coming from RNC (3G RAN) or BSC (2G RAN) Bearer independent call control (BICC) BICC is based on ISUP and defines all necessary changes to guarantee a bearerless call control functionality and signaling, including the establishment of the required bearer necessary for user data transport. In principle, BICC is independent from the used transport method (ATM or IP) but includes bearer specific parameters. One of the important features of the new transport networks (ATM or IP) is the transport of voice in compressed form. But also the transport of voice in uncompressed form is possible. For this, the negotiation of codecs must be supported by BICC. The BICC standards define two functions which work together for handling of calls. Call control function (CCF), responsible for the call control Bearer control function (BCF), responsible for bearer control
The call & bearer control (CBC) interface between both could also be an external one, which means that CCF and BCF could be located on different physical nodes based on H.248. The current software release has a proprietary internal CBC interface. In general, BICC signaling transport can be done via SS7:MTP3B using ATM or via M3UA/SCTP using IP. Furthermore, for voice traffic over ATM CN ITU-T Q.1901 CS2 (Capability Set 2) is valid. Pooled TDM-based resources in the MSC-S part (involved in resulting traffic over ATM CN) Requirements for basic functions -together with traffic short cut in the ATM domainmade only with pooled TDM-based resources in the MSC-S part and from there in the direction of the communication partner via ATM CN are (see also CS-MGW part functions/MSC-S part functions in section 4.12.1 above): Supplementary service call of multi party (with pooled TDM-based resources, that is, ATCO LTG in the MSC-S part) IN/CAMEL advanced call processing (with pooled TDM-based resources, that is, UI LTG or CPH LTG in the MSC-S part) Lawful interception call (with pooled TDM-based resources, that is, LI LTG in the MSC-S part)
284
DRAFT
DTMF tones
DTMF tone generation is done in the TDM-based MSC-part, whereas DTMF tone reception is done in TSCD. that is, for DTMF tone handling the ATM based A2BS TrFO break functionality cannot be used in case of 3G.
A50016-D1112-V41-2-7618
Information System
The AAL2 data stream can either be compressed voice traffic (AMR coded), or uncompressed voice/data traffic (ITU-T G.711 coded). In case of compressed voice traffic all AMR modes are supported. Only if the IN/CAMEL function voice recognition is used, which uses DTMF-tones, only the two highest available modes of the AMR codec (AMR mode 7/AMR EFR (12.2 kbit/s) and AMR-mode 6 (10.2 kbit/s) are used to avoid a loss of quality. It is also possible to inhibit the compression in order to avoid a loss of quality. This could be the case if a multiple transcoding (more than two times) of voice again is to be avoided. Echo control In the following, the two general connection types are discussed: Effect on echo control - MS to/from PSTN For the echo control equipment (echo canceller) the delay between digital echo canceller (DEC) and the hybrid circuit must not exceed 65 msec. Since the DEC is always part of the GMSC (in detail on the PSTN network side), the additional delay caused by the ATM leg handling (transcoding) has no effect on the echo canceller. So, for the usual mobile echo control no new requirements are pending. Effect on echo control - FS to/from FS/PSTN FS to/from FS (intra PLMN) There are currently no requirements for echo control for xed to xed subscriber calls carried out by xed subscribers (FS) in a CSC which are part of the PLMN. This was given by the basis that PLMN internal the delay time doesn't exceed about 25 msec one-way delay. This is standard for common national networks (TDM based and terrestrial congured). With the introduction of the trafc over ATM CN feature (which causes an additional delay time with a minimum of about 50 msec), a xed subscriber to xed subscriber call would need the necessary echo cancellation. It is important that two loops per xed to xed PLMN internal call are necessary because each hybrid circuit needs dedicated echo cancellation equipment. FS to PSTN calls Only one trunk loop is necessary. This trunk loop provides the PLMN internal FS with a dedicated hybrid circuit with the necessary echo cancellation. The echo cancellation function for the PSTN side is situated, (as it is also usual for an MOC), on the trunk side towards the PSTN. AAL2 routing requirements Alternate routing is supported to find a new route to the destination exchange in case of congestion or failure on all AAL2 path's associated with a selected route. In a 2G environment, that is, traffic coming from the A interface and going to the Nb interface the general asynchronous bearer service BS20 (circuit-switched CDA data service) is not supported. The BS20 data service requires the DSU of the CP platform part and corresponding traffic is routed within the TDM CN. In a 3G environment and in the case of a traffic loop coming from the Iu interface and going to the Nb interface the general synchronous bearer service BS30 (transparent 64 kbit/s UDI data service) is also supported, but not the general asynchronous bearer service BS20 (circuit-switched CDA data service). The BS20 data service requires the DSU of the CP platform part and corresponding traffic is routed within the TDM CN.
A50016-D1112-V41-2-7618
DRAFT
285
Information System
4.12.3.2
Framework for Charging and Billing

MCR data records MCR data records can include trunk group ID and circuit identification codes (CIC) for TDM/ISUP-based calls and call instance codes (CICs) for ATM/BICC-based calls. The current implementation of CIC record format including also BICC CICs formats. In addition, introduction of a transmission mode parameter is possible in MCR data records, which includes information like, e.g., transparent/non transparent mode, halfrate/full-rate information which might be enhanced to include use of compressed/uncompressed mode of TSC*. For the threshold reporting features the output record includes CIC information. The layout is supported structured according to the TDM/ISUP-based CIC layout and also the ATM/BICC-based CIC layout.
4.12.3.3
Framework for Mobility Functions

Handover There are many different scenarios for handover and relocation (see also section 4.8.5). In addition to the kinds known for traffic over TDM CN the various variations for traffic over ATM CN (that is, CS-MGW part) are to be handled. The main principle for all handovers is that the decision what to do is done on current parameters available at time of handover. The history of the call and the previous handovers is not be taken into account. The outcome is caused by both the conventional handover decisions (handover/relocation, internal handover/external handover, inter-system handover, etc.) and the generic transcoder free operation (TrFO) check (see also section 4.12.4). For handover/relocation and traffic over ATM CN together with transcoder free operation (TrFO) following requirements are given: Separation of handover to control and transport part. The handover control part is located within the MSC-Server part and has to be independent on the transport plane. The handover transport part is located within CS-MGW part in case of Iu interface (3G) and trafc in ATM CN, if possible. In other cases transport can be located at MSC-Server and CS-MGW part. Support of the H.248 based proprietary protocol for the Mc interface (inclusive topology descriptor). Allocation of the new transport resources for handover within the CS-MGW part, initiated and controlled by the handover control within the MSC-Server. Support of the topology change (bicasting) mechanism for handover in the MSCServer and in the CS-MGW part. For 3G the transcoder free operation break function (that is, A2BS) within the CSMGW part supports handover, e.g., bicasting, initialization Iu user plane, handling of two (old and new side) Iu user planes in parallel. Support of the anchor principle for handover, which means anchor MSC-Server and anchor CS-MGW part (and even anchor transcoder free operation break function for TrFO in case of 3G). Adaptation of inter-system handover to 2G on basis of separation of handover to MSC-Server and CS-MGW part.
286
DRAFT
A50016-D1112-V41-2-7618
Information System
Since the logical separation of control and bearer and the corresponding separation of the MSC-Server (control) and CS-MGW part (bearer) the handover/relocation procedures are affected and described shortly in the following: The proprietary internal Mc interface is used for communication of control, which is located in the BSSAP/RANAP LTG in the MSC-S part and in the bearer control function (BCF), that is, in BCF-MP in CS-MGW part. The terminations for handover are maintained over that interface, and with bearer up/down procedures and topology states, it is decided, where the traffic is connected through. The main kinds of handover are: Intra-MSC handover/relocation For 2G (that is, via A interface) intra-MSC handover is done in the MSC-Server and then leaded into the CS-MGW part in case of trafc in ATM CN. For 3G (that is, via Iu interface) intra-MSC relocation is done in the CS-MGW part if possible. Inter-MSC handover/relocation For 2G (that is, via A interface) and for 3G (that is, via Iu interface) inter-MSC SRNS relocation is done in the MSC-Server part. For the inter-MSC handover/relocation scenario the call processing in the MSC-Server part uses MAP messages between the two concatenated MSCs. In case of 3G and TrFO, TrFO is always broken and the trafc is switched over the MSC-S part. Depending on the connection between MSC A and MSC B the handover leg of the call forms one or two internal trafc loops. During inter-MSC-handover/relocation the decision for selection of TDM CN or ATM CN must be taken. In the corresponding Q3/MML command a new parameter for MS routing number type is introduced. This special handover number (HON) is selected, if the connection between MSC-A and MSC-B in case of inter-MSC-handover/relocation should be routed via the ATM CN. The criteria for selecting this special handover number are the same as for the other routing scenarios.
For a call setup first in an MSC-A with corresponding traffic over ATM CN and then handed over to MSC-B (inter-MSC handover) there are the following possibilities: 1.) The traffic remains in the ATM CN or 2.) Changes to the TDM CN. In the case of inter-MSC handover/relocation the second possibility is preferred. Inter-system handover Inter-system handover 3G to 2G ends the TrFO mode (if active) and inter-system handover 2G to 3G can start TrFO. Again the generic TrFO check is used to decide on the actions to be done. When the TrFO mode ends the bearer up is triggered to support internal trafc loops in the MSC-S with the options to route the trafc nally via ATM CN or TDM CN. Directed retry For 3G (that is, via Iu interface) directed retry is a procedure where the trafc channel in call setup is not assigned but immediately relocated to another RNC. In contrast to 2G (that is, via A interface) the trafc resource (termination) is already seized. Thus the termination is to be released after the relocation. This termination is released with the normal Iu interface release procedure, as used in a normal relocation. As the call is not connected the bicasting sequence is not necessary, but is used in order to apply normal relocation procedure. In a relocation during call setup the call is not yet connected. Interworking with tones and announcements are possible. These functions are implemented by bearer up/down.
A50016-D1112-V41-2-7618
DRAFT
287
Information System
4.12.4
Transcoder Free Operation (TrFO) (3G only)

The transcoder free operation (TrFO) feature is introduced with the current software release. The main advantage of TrFO is that it avoids transcoding whenever possible. This improves voice quality and saves bandwidth. This feature enables end-to-end codec negotiation (Fig. 4.95) for: 3G-mobile-to-public switched telephone network (PSTN) calls The transcoders are shifted to the edge of the public land mobile network (PLMN), that is, the PSTN gateway. Within the 3G PLMN/CN, voice is transmitted in compressed form (that is, adaptive multi rate transcoder (AMR) coded). 3G-mobile-to-3G-mobile calls Common codec types and modes are negotiated between two mobile terminals; no transcoder is involved in the connection. Voice is transmitted in compressed form end-to-end.
CN, CS domain
TrFO for mobileto-mobile call: compressed speech end-toend
3G RAN Iu
3G VMSC
3G VMSC
Iu
3G RAN
AAL2 compressed speech 3G VMSC
TrFO for mobileto-PSTN call: compressed speech until the edge of the PLMN
Transcoder GMSC TDM (64 kbit/s)
PSTN/ISDN/ PLMN
Fig. 4.95
Overview of the transcoder free operation (TrFO) feature
Transcoder free operation in a CN using asynchronous transfer mode (ATM) improves voice quality compared to 3G or 2G via time division multiplex (TDM). Delays are decreased significantly because the common codec types and modes are negotiated; this avoids the need for transcoding.
288
DRAFT
ATM/AAL2, used as the platform for the TrFO, multiplexes different data streams as separate AAL2 connections to a single ATM stream. This enables the network to transport compressed voice data efficiently, which provides more transport capacity and requires fewer physical lines compared to the TDM environment used within 3GPP R99.
A50016-D1112-V41-2-7618
Information System
As a major impact on voice quality, the coding and decoding is avoided. Therefore, with the use of TrFO, 3G mobile subscribers experience improved voice quality compared to voice over TDM used in 2G or 3G 3GPP R99 environments.
4.12.4.1
Framework for TrFO (3G only)

To enable TrFO within a 3G MSC part following framework is implemented: Codec negotiation Common codec types and modes have to be negotiated end-to-end via BICC signaling. Within the MSCs the relevant messages have to be passed through from incoming to outgoing side. Dual tone multi frequency (DTMF) All CN nodes must use the out-band procedure and DTMF reception occurs in the TSCD. ATM interface user protocol version Both on Iu and Nb interface user protocol version 2 has to be used. RNC data within CN MSC has to know which codec types and modes and ATM interface user protocol versions are supported by the RNCs. Short cut connection between two A2BS cards The MSC server part and the transcoding and rate adaptation unit (TRAU) server card are bypassed by a direct ATM AAL2 trafc short cut connection between the two AAL2 break server cards (A2BS) (see Fig. 4.96)
MSC Server (with pooled TDM-based resources)
TSCD
TSCD
A2BS
A2BS Short cut LIC (ATM):Nb ASN to VMSC/GMSC (Nb interface)
LIC(ATM):Iu to 3G RAN (Iu,cs interface)
CS-MGW
A50016-D1112-V41-2-7618
DRAFT
Fig. 4.96 MSC architecture for TrFO
289
Information System
Use of pooled TDM-based resources in the MSC-S part Pooled TDM-based resources in the MSC-S part, e.g., tone generation, announcement generation, conference unit, etc. are still used by the CS-MGW part via TDMlinks (see section 4.12.3.1). Switching of a TDM connection in parallel to the ATM AAL2 trafc short cut by a hot standby trafc loop. A parallel hot standby trafc loop via TDM-based CS-MGW part can be switched on temporary with a synchronized switch off of ATM AAL2 trafc short cut, that is, a temporary interruption of TrFO (see Fig. 4.96). Affected handover/relocation procedures The proprietary internal Mc interface is used for communication of control, which is located in the RANAP LTG and the bearer control function (BCF) in CS-MGW part. The terminations for handover are maintained over that interface, and with bearer up/down procedures and topology states, it is decided, where the trafc is connected through. TrFO is supported for intra-MSC-handover/relocation, when the 3G trafc is switched through the A2BS-short-cut and in parallel the relocation is performed in the MSC-Server part. For every intra-MSC-relocation it is checked, whether the new RNC is capable to support TrFO. As a consequence of that, TrFO can be established also after an MSC-internal inter-system handover from 2G to 3G occurred. An MSC-external handover/relocation is always performed with the trafc through the MSC-Server part, which means that the TrFO (if active) is broken. Depending on the connection between the MSC-A and the MSC-B the trafc is connected via TDM or ATM. Obviously an inter-system handover from 3G to 2G always ends the TrFO.
4.12.5
Transit MSC (ATM/AAL2 Transit Functionality)

Transit Mobile-switching Centers (TMSCs) are used in large and expanding networks to structure PLMNs efficiently and meet PLMN operator needs to minimize the costs of CN equipment and the related maintenance. The use of TMSCs simplifies the CN configuration for the interconnections of the network elements used in mobile CNs (see also section 4.3.3.2, Hierarchical ATM Based CN Scenarios (3G only). The introduction of the transit MSC (ATM/AAL2 transit functionality) feature provides network-wide benefits: Both 3G (and 2G) voice over asynchronous transfer mode (ATM): saving bandwidth by transmitting compressed voice over the CN Transcoder free operation (TrFO) in case of 3G: improving voice quality through endto-end codec negotiation (see also section 4.12.4) These features are available irrespective of which hierarchical levels are introduced to the CN. The ATM/AAL2 transit functionality can be located in a visited MSC (VMSC), a Gateway MSC (GMSC), or in a separate transit MSC (TMSC) and supports the interworking of different types of connections, such as: - ATM/AAL2 <--> ATM/AAL2 transitions - TDM <--> ATM/AAL2 interconnections - TDM <--> TDM transition (with BICC <--> BICC signaling) (with ISUP <--> BICC signaling) (with ISUP <--> ISUP signaling)
290
DRAFT
To improve the call success rate for ATM/AAL2 connections, rerouting mechanisms (crank back) are supported on the control network layer. This feature enables the selec-
A50016-D1112-V41-2-7618
Information System
tion of alternative signaling routes if bearer independent call control (BICC) routing is not accomplished successfully. The introduction of the transit MSC (ATM/AAL2 transit functionality) feature prevents the need for fully meshing MSCs on the transport layer and the control network layer (Fig. 4.97). This helps PLMN operators to reduce operational expenditure (OPEX) due to possible ATM/AAL2 traffic concentration within a TMSC. This reduces transport costs. On the control network layer, this feature allows PLMN operators to structure CNs efficiently. This minimizes the costs of maintenance required during the CN upgrades and extensions. The efficient CN structure combined with precise bandwidth allocation for the transmission of compressed voice data helps operators to reduce costs. The availability of ATM/AAL2 in the CN enables PLMN operators to substitute integrated CS/PS domains for a single ATM network, although different CN hierarchical levels can be used. The ATM/AAL2 <--> ATM/AAL2 transition supports the TrFO feature, which allows PLMN operators to offer their customers improved voice quality and to save bandwidth through end-to-end transmission of compressed voice data.
Fully meshed network
CN with ATM TSMC as the transit layer
TMSC VMSC VMSC VMSC VMSC
VMSC
VMSC
VMSC
VMSC
CN, CS domain
CN, CS domain
AAL2 connection BICC signaling
Fig. 4.97
CN with a separate ATM transit MSC as the transit layer
A50016-D1112-V41-2-7618
DRAFT
Prerequisites: 3G voice over ATM/AAL2 or 2G voice over ATM/AAL2 (see section 4.12.2) are required for the transit MSC (AAL2 transit functionality) feature. To support different types of connections, the Seamless 3GPP R99 and Rel-4 Interworking (3G only) feature (see section 4.12.6) is necessary. Remark: To improve voice quality, the transcoder free operation (TrFO) feature (see section 4.12.4) is recommended.
291
Information System
4.12.6
Seamless 3GPP R99 and Rel-4 Interworking (3G only)

The current software version provides for 3G the logical separation between the control and the transport plane as a first step towards the 3GPP Rel-4 network architecture. Nevertheless, in parallel the 3GPP Release 99 architecture has to be supported using user plane version 1 on the Iu interface to the radio network controller (RNC) and the time division multiplex (TDM) technology in the CN. With the Seamless R99 and Rel-4 Interworking feature, the parallel support of both architectural approaches is supported. This enables the PLMN operator to introduce the Rel-4 environment network node by node without affecting the R99 environment. This feature enables the introduction of the 3G voice over ATM/AAL2 feature (see section 4.12.2) in the CN on a node-by-node basis, according to PLMN operator needs. This minimizes the risk of destabilizing the network when a new network architecture is introduced. PLMN operators can introduce Rel-4 features, 3G voice over ATM and transcoder free operation (TrFO), step by step without affecting the network part still running in an R99 environment. This enables the PLMN operator to save bandwidth and offer improved voice quality for the network part that has been upgraded to the 3G Rel4 architecture. The step-by-step introduction of 3G Rel-4 enables the introduction of the TrFO feature (see section 4.12.4) according to PLMN operator needs. The feature improves voice quality without affecting the network part still running within an R99 environment.
MSC Server LTG: RANAP LTG: ISUP LTG: BICC
R99 TDM environment

to VMSC/GMSC (E interface)
Interworking: 3G R99/Rel-4 3G Rel-4/R99 TSCD TSCD
Traffic Traffic:flow: 3G Rel-4 3G R99
A2BS
A2BS
R99 environment
LIC(ATM):Iu ASN
ATM/AAL2 environment
LIC (ATM):Nb to VMSC/GMSC (Nb interface)
Rel-4 environment
LIC(ATM):Iu to 3G RAN (Iu,cs interface)
292
DRAFT
Fig. 4.98 R99 / Rel-4 traffic flow in a 3G MSC part
A50016-D1112-V41-2-7618
Information System
4.13
Special Operation and Maintenance Functions

These operation and maintenance functions enable the PLMN operator to manage data throughout the network in a simple way and to control functions which influence or control the mobile subscriber traffic. For the most part, the network-wide management and control of the facilities of the mobile subscriber functionality are performed in the circuitswitched domain of CN with the aid of MP:OAM within the ATM MP platform (or CP:BAP/IOP:SCDP within CP platform) of the MSC network element. The CN provides the PLMN operator with various management functions (e.g., subscriber management, routing management, call charge management). The management functions are implemented via Q3 tasks/MML commands or command files generated with them. These commands can be introduced either locally or remotely. Remote introduction is implemented via Switch Commander (SC) or the Operations Support System (OSS). TMN interfaces with corresponding services (e.g., CMIP/FTP and CMISE/FTAM) are available for this (section 4.14.8, Communication Protocols of the Telecommunication Management Network (TMN)). An example of a TMN application is the management of mobile subscriber data in the HLR with the aid of the dialog service CMIP/CMISE. Management functions in the circuit-switched domain of CN The following sections (4.13.1 to 4.13.25) highlight special circuit-switched CN management functions which are relevant for all PLMNs. Functions based on special handling of identities IMSI tracing in the CN - circuit-switched domain Security-relevant AC operator functions Security enhancements in the AC Support of USIM with two 3G security algorithm sets in AC (3G only) Exchange procedure for new mobile subscriber chip cards ((U)SIM)) Roaming restrictions for mobile subscribers Operator-determined barring (ODB) of CN service functions Administrative block Barred directory numbers for call forwarding USSD text management Barring of USSD for roaming mobile subscriber Administration of mobile subscriber proles in the HLR User-specic HLR access Bulk HLR subscriber administration Combined HLR/AC administration Combined MSC/VLR trunk administration (with ATM in CN) Deletion of mobile subscriber data Display of number of mobile subscriber in VLR Enhanced display of mobile subscriber data in VLR Display of allocated data for AAL2 path Display of HLR statistics for mobile subscribers roaming outside HPLMN Purge initiation in VLR. IN/CAMEL: roaming subscriber table in VLR HSCSD administration (2G only)
A50016-D1112-V41-2-7618
DRAFT
293
Information System
4.13.1
Functions Based on Special Handling of Identities

Single numbering and multinumbering There are basically two alternative ways of allocating several telecommunication services to a mobile subscriber: All telecommunication services are allocated to the same mobile subscriber number which the caller of a mobile subscriber has to dial (single numbering). A separate mobile subscriber number is allocated for each telecommunication service which the caller of a mobile subscriber has to dial, e.g., for distinguishing between different teleservices at the mobile subscriber (multinumbering). See also System Description, register Network System Concept, section codes of mobile subscriber. Double mobile subscriber (double IMSI) - TwinCard The double mobile subscriber function allows two different mobile subscriber numbers (MSISDN and IMSI) to be created which are linked administratively in the PLMN to form a double mobile subscriber. This administrative link allows only one of these mobile subscriber numbers to be active in the PLMN at any time. The mobile subscriber is given two physical (U)SIM cards (TwinCard). A typical application would be the possibility for the mobile subscriber to handle charges separately for private and business calls. Improved TwinCard The improved TwinCard feature a link between two different IMSIs to be created, where the second IMSI refers to the same mobile subscriber profile as the first IMSI. This simplifies mobile subscriber administration and saves system resources because all basic and supplementary service records are available only once. Only common data records and mobility data records are available twice. For both IMSIs all existing MSISDNs are in common. The switching between active/passive status of an IMSI is triggered by the location update (LUP) procedure within the HLR when this message is received from the VLR. Only the MSC/VLR address of the partner IMSI is canceled. The SGSN/SLR address is maintained. In a future stage, it is expected to set the active/passive status via mobile-initiated USSD. Mobile terminated transactions, such as MTC, SMS-MT, and network initiated USSD, for example, are always routed to the active TwinCard subscriber. The mobile subscriber is given two physical (U)SIM cards in the same way as for the old TwinCard (Double mobile subscriber (double IMSI)) feature, as described above.
294
DRAFT
There is also an improved TwinCard feature in addition to the basic feature. The basic and the improved TwinCard feature are supported in parallel by the HLR; however, it is not possible to apply both features to one mobile subscriber at the same time. For users of the improved TwinCard feature, two IMSIs are linked to the same basic MSISDN. This MSISDN is displayed for MOCs with calling line identification presentation (CLIP) to the B-Party. For the linked IMSI (slave IMSI), only a mini-profile consisting of a common data record and a mobility data record is allocated. This allows, for example, the call forwarding service settings both IMSIs to be adjusted by modification of the first subscribers profile (master IMSI) only. The allowed command set for the second IMSI is restricted. That is, most subscriber administration commands can be executed for the master MSIN only.
A50016-D1112-V41-2-7618
Information System
Multiple NDC for a PLMN Normally a PLMN is defined by exactly one national destination code (NDC). The structure of the MSISDN with the NDC as an integral part is explained in the System Description, register Network System Concept, section codes of mobile subscriber. The additional NDCs are to be issued by the national telecoms. The multiple NDC function for a PLMN permits the PLMN operator to introduce MSISDN with various NDCs in one or more HLR/AC. Therefore, the PLMN operator has the choice of dividing up the PLMN or of introducing new services in the PLMN and in this way managing different categories of the mobile subscriber, or of simply increasing the range of directory numbers and therefore the total number of mobile subscribers in the PLMN. Dialing without national destination code NDC It is possible to define for a particular project whether any mobile subscriber within the individual PLMN can dial any other mobile subscriber with the same NDC without having to dial the NDC. This is done by the MSC network element putting the traffic discrimination digit(s) and the NDC of the called mobile subscriber in front of the dialed digits and only then performing digit translation and routing.
4.13.2
IMSI Tracing in the CN - Circuit-Switched Domain

The IMSI tracing feature is for collecting trace data from the CN in the MSC/VLR in IMSI trace data records relating to certain mobile subscribers, so as to send them to a selected processing center in the predominant Operations Support System (OSS). There are two types of IMSI trace data records: Normal IMSI trace data records These data records are stored in the local hard disk after collection in the MSC and transmitted, if necessary, as sum data record via FTP service (TCP/IP signaling) to the OSS. Priority IMSI trace data records These data records are transmitted to the OSS after collection in the MSC directly via hot operation service (HOP) or GTP/CGP service (TCP/IP signaling) (see section 4.6.3, under hot operation).
4.13.3
Security-Relevant AC Operator Functions

Additional security procedures are available on the operator side in addition to the security measures for setting up traffic connections (e.g., mobile subscriber authentication, confidentiality of user data on the radio interface). One important measure is used to prevent unauthorized access to security-relevant data in the AC by means of encryption. This security-relevant data in the AC can be accessed locally or remotely via the SC or OSS. An AC key management function using a Q3 task/MML command is available for local access. For remote access, an AC key management function is available using the X.25-based secure application service (SAS) interface or TCP/IP-based SMML-T interface (see section 4.14.8, Communication Protocols of the Telecommunication Management Network (TMN)) with the security procedure described below. The SAS interface employs the X.25 user services FTAM for data transfer and CMISE for dialog purposes.
A50016-D1112-V41-2-7618
DRAFT
295
Information System
There are two different ways of safeguarding data by means of encryption: All data is encrypted using an algorithm (A..) and a parameter (K..) and subsequently decrypted. A signature (electronic signature) that identies the sender of data is generated and transmitted together with the user security data. The user security data itself can be encrypted or decrypted. These two means of managing data in the AC are achieved by the following specific procedures: Security-relevant data is transmitted in encrypted form to and from the AC and/or safeguarded by a signature (electronic signature). All important security data for the mobile subscribers is stored in the AC in encrypted form only. The following algorithms and parameters are managed in conjunction with the abovementioned encryption procedures (for the AC key management). Operator-related: A7, K7p, K7s, A9 (SAS/S-MML-T data transmission) A4, K4, A2, K2 (re-encryption of K). Traffic connection-related (e.g.,): A3, A8, Ki, Kc (2G mobile subscriber authentication) A5, Kc (encryption on 2G radio interface). f1 to f5, K, CK (3G mobile subscriber authentication) f3, CK (encryption on 3G radio interface).
With the introduction of the new IOP:AUC3 supporting more processing power (factor 10) can be achieved. A regular change of K2 and K4 is necessary for a reliable secure network. In former software releases, special chip cards (access control modules ACM) and the appropriate card readers are available to the PLMN operator for using the algorithms/parameters K4 or A7/K7 and A9. In former software releases, the transport key K4 as well as A7/K7 and A9 can be remotely changed using Q3 tasks/MML commands.
4.13.3.1
Use and Administration of the Encryption Functions

A number of encryption algorithms and their associated cipher keys are used in the AC. Some of them can be administered to some extent. In the following the algorithms and keys relevant for administration of the AC are described: A2, A4, A7 and K2, K4, K7. Algorithm A7 and keys K7p, K7s An unsymmetrical encryption method is used to transfer data at the X.25-based SAS interface or TCP/IP-based SMML-T interface and, to some extent, to store security-related information in the AC outside the IOP:AUC. The algorithm A7, the secret key K7s, and the public key K7p are used for this function. The encryption and decryption and the creation and verification of signatures are carried out in the IOP:AUC. The keys K7s and K7p are administrable, the algorithm A7 is not administrable. Basically, an AC can be in contact with one or more Personalization Centers for (U)SIM (PCSs) and Security Management Centers (SMCs). For the exchange of data the following administrable information must therefore be available in the AC: Public K7 of the relevant PCS or SMC: K7p,PCS/SMC Secret K7 of the AC: K7s,AC Public K7 of the AC: K7p,AC
296
DRAFT
A50016-D1112-V41-2-7618
Information System
The K7p and K7s are administered either by loading the parameters of chip cards using a chip card reader connected to an IOP:AUC, or by remotely Q3/MML command access (only possible since IOP:AUC2) or alternatively by direct input. The parameters which are essential for the home AC (K7p and K7s of the AC called master key set) are always loaded initially by direct reading of two chip cards. Already existing keys can be modified and new public keys of communication partners can be added from the SMC by way of the SAS/SMML-T interface or also by direct input. The K7p of communication partners are entered without being encrypted; the K7s of the home AC is encrypted with the old (that is, still valid at the time of input) K7p,AC. In both cases the time at which the new cipher keys are to become valid is also entered. Algorithms A4, A2 and keys K4, K2 When being created, each mobile subscriber is assigned a secret key which is used at the air interface for the purpose of authentication and encryption. Accordingly, this key must be very carefully protected against possible misuse. When a mobile subscriber is created in the AC, the secret key is always entered in encrypted form with the algorithm A4 and the parameter K4. The IOP:AUC decrypts the secret key and encrypts it again using A2 and K2, before it is stored in the database. The combinations A4/K4 and A2/K2 are both symmetrical encryption methods. The key K4 is administrable, the key K2 and the algorithms are not administrable. The choice of K4 depends on the method used to administer the mobile subscribers in the AC. Which of the following methods are allowed depends on the activated features: Session-dependent K4: When the mobile subscribers are created over the SAS/SMML-T interface, a new K4 is used for each session, that is, for each complete data transfer process. This K4 (session key) is generated by the sender of data and sent (encrypted with A7 and K7p,AC and signed with A7 and K7s,sender) together with data to the AC. The IOP:AUC stores the K4 until the end of the session; K4 that are no longer required are deleted. Up to ten K4 can be stored simultaneously, that is, a data transfer for which a K4 is required can take place with up to ten communication partners simultaneously. One default K4: When mobile subscribers are not administered over the SAS/SMML-T interface function, the standard K4 parameter stored in the IOP:AUC (default key) is normally used. Multiple K4: Several K4 can be used even without the SAS/SMML-T interface. The logical name and the version of the K4 used for encrypting the secret key can be entered when the home mobile subscribers are created. The IOP:AUC then uses this K4 for decryption. The operator is responsible for ensuring that the specied K4 was in fact used to encrypt the secret key. Up to 10 different K4 can be used in one AC (in addition to the default K4). Two features are available for multiple K4: Predened K4: The database contains predened K4. If no K4 is specied when the mobile subscriber is created in the AC or the specied K4 does not exist, the system uses the default K4. Administrable K4: The K4 database can be administered either by loading K4 of chip cards using a chip card reader connected to an IOP:AUC, or by remotely MML command access (only possible with the new IOP:AUC2) or alternatively by direct input. If no K4 is specied when the subscriber is created in the AC, the system uses the
A50016-D1112-V41-2-7618
DRAFT
297
Information System
active K4. Any K4 available in the database can be activated by the operator, but only one key can be active at a time. The secret key stored semi permanently with the mobile subscriber data is encrypted with A2 and K2. Since this data is normally stored for a lengthy period, it is advisable to alter the encryption from time to time for security reasons. This decryption and re-encryption of the complete mobile subscriber database (that is, all secret keys) can be initiated either from the SMC (via the SAS/SMML-T interface) or the AC/HLR. An IOP:AUC then generates a new K2 and distributes it to all active IOP:AUCs. Decryption with the old K2 and re-encryption with the new K2 are always carried out by two IOP:AUCs in parallel (secure calculation). The newly encrypted key is only stored if the two results coincide, otherwise the process is repeated. In order to carry on with this dual system even if one of the IOP:AUCs fails, at least 3 IOP:AUCs must be active at the commencement of re-encryption. Re-encryption of the entire database can take several hours. The system ensures that there are no conflicts regarding database access between the administration of the mobile subscriber database and the re-encryption procedure. Normally the administration of the mobile subscriber database is hardly affected by the re-encryption procedure. At the end of reencryption, the old K2 is canceled in all IOP:AUCs. The K2 used in the AC is stored semi permanently. It is encrypted with K7p,AC and signed with K7s,AC. If there is no SAS/SMML-T interface function, the default K7 parameters stored permanently in the system are used. During re-encryption both the old and the new K2 are stored temporarily.
4.13.4
Security Enhancements in the AC

The current software version features two new security enhancements: AC key management security boost Logging of access to AC database AC key management security boost (increased security level of the asymmetric A7 algorithm) The current software version introduces a new security enhancement feature. This feature AC key management security boost provides an increased level of security for the asymmetric A7 algorithm (see also section 4.13.3).
Authentication and encryption in PLMNs is based on the Ki secret-subscriber-authentication key, which is located on the (U)SIM card and in the AC database. To ensure subscriber data security, the Ki key is encrypted for transport to and initial loading in the AC as follows: The Ki key is encrypted using the A4 algorithm and the K4 key, which is called the A4(Ki). Public key cryptography with the asymmetric key K7 is used to guarantee approved entering of the new K4 key. For periodic change of the public/secret K7 keys, the initial loading of the keys is performed by Q3 tasks/MML commands or by the chip card interface.
298
DRAFT
A50016-D1112-V41-2-7618
Information System
Logging of access to AC database The current software version introduces a new security enhancement feature. The logging of access to AC database feature provides the tracing back of actions, which enable access to the A2 encrypted Ki key in the AC database (see also section 4.13.3).
Authentication and encryption in PLMNs is based on the Ki secret-subscriber-authentication key, which is located on the (U)SIM card and in the AC database. To ensure subscriber data security, the Ki key is encrypted for storage in the AC as follows: The Ki key is encrypted using the algorithm A2 and the key K2, which is called the A2(Ki).
4.13.5
Support of USIM with Two 3G Security Algorithm Sets in the AC (3G only)
USIMs can contain two sets of AKA algorithms f1 to f5 and f1* to f5*. That way, it is possible to switch the AKA algorithm used without the need to change the USIM. The second set of algorithms provides a backup, in case the first set exhibits weaknesses. The general scheme is the following. The secret subscriber key Ki is fed through one of two hash algorithms, generating K1 or K2. The intermediate key K1 is input to the first set of algorithms f1 to f5 and f1* to f5*. The intermediate key K2 is input to the second set of algorithms f1 to f5 and f1* to f5*. When generating quintets, the IOP:AUC indicates the used set of algorithms through the least significant bit of RAND. When this bit is 0, algorithm set 1 is used, when it is 1, algorithm set 2 is used. The IOP:AUC selects the algorithm set to be used, based on information in the AC subscriber database. For every mobile subscriber an indication of the algorithm to be used is stored. This indication can have three values: algorithm set 1, algorithm set 2 or default algorithm set. An Q3 task/MML command is available, that allows to administer the default algorithm set (that is, whether it is algorithm set 1 or 2) for every USIM type.
4.13.6
IPsec Encrypted Transmission (IP Security) on O&M Paths of CNcs

This section describes the IP security concept of the IP-based traffic transmission on O&M paths of the circuit-switched domain of Core Network (CNcs). It addresses all important security issues arising from the usage of potentially flawed implementations of IP protocols including IP-based transport protocols, such as UDP and TCP, and IPbased application protocols, such as Telnet, FTP, HTTP or SNMP.
In the circuit-switched domain of the Core Network (CNcs), a similar solution to the solution used in the packet-switched domain of the Core Network (CNps) has been chosen for IP security, that is, CISCO-based VPN gateways (PIX 515E) and Ethernet switches (3550 Catalyst switches). The following types of IP-based traffic are relevant: Charging trafc to OSS network elements Lawful interception trafc to OSS network elements OAM trafc to the SC element manager
A50016-D1112-V41-2-7618
DRAFT
Basic security considerations
In the traditional GSM world, security is associated with radio-access security and user authentication (see also section 4.8.1). The current ETSI/3GPP security architecture fo-
299
Information System
cuses on radio-access security ((U)SIM key agreement and ciphering). Time division multiplex (TDM) based SS7 networks are closed networks with fixed configured routing tables and require no additional mechanism to secure the CN. For the SS7-based MAP protocol, the network domain security architecture is defined by the 3GPP standards. ATM networks are also considered closed networks that do not need additional security features. The introduction of IP packet-based networks for the mobile Core Network has made security considerations necessary for the CNcs. Network security must be provided with confidentiality and authentication functionality at IP layer with IPsec, and all IPbased network elements must provide separate management interfaces. For IP-based traffic (and signaling like GTP-C for the packet-switched domain o CN (CNps) and SIP for the IMS domain), the 3GPP standards recommend the virtual private network (VPN) protocol IPsec for inter-PLMN signaling protection. In all 3GPP documents, IPsec is the recommended protocol for the protection of any IP traffic in the mobile Core Network (CN). Why IPsec? IPsec technology works independently of the transport network and provides the same security as accepted asynchronous transfer modus (ATM) and multiprotocol label switching (MPLS) networks. The IPsec protocol is defined for transport and tunnel mode and can be located in the router, special VPN gateways or in the network elements. IPsec is a tunneling protocol, which allows the interconnection of private IP networks over a public IP infrastructure. In contrast to other tunneling mechanisms, such as generic routing encapsulation (GRE), IPsec includes tunnel authentication, preserves data integrity and security. The special appeal of IPsec lies in its in-built security mechanisms, which make IPsec a state-of-the-art solution for addressing ultimate security requirements. The key to the acceptance of IPsec as the most secure tunneling protocol is its in-built encryption feature. Like the Gateway GPRS Support Node (GGSN) network element in the packet-switched domain of Core Network (CNps), MSCs fully support IPsec tunneling with encryption according to the data encryption standard (DES), which includes the dynamic exchange of encryption keys through internet key exchange (IKE). IPsec requires additional, IPsecspecific hardware to be installed in an MSC. The authentication mechanism of IPsec can even authenticate the network element. The IPsec devices support extranet access. Extranet access is an IPsec connection between gateways with different managed networks. The IPsec devices must support extranet access for VPN connections between an MSC and different communication partners. IPsec encrypted transmission in CNcs The circuit-switched Core Network (CNcs) is subdivided into the following IP networks with different security policies: Billing network Interception network OAM network These networks can be separated with IP virtual private network (VPN) technologies, such as IPsec. These security protocols ensure the same level of security, provided that PLMN operators use these technologies. The following Fig. 4.99 shows the IPsec-encrypted transmission used in the circuitswitched Core Network (CNcs).
300
DRAFT
A50016-D1112-V41-2-7618
Information System
RAN
MSC
Billing VPN
IPsec
ABC
Interception VPN
IPsec
LI-IMS
OAM VPN
IPsec
SC
CS core domain
Fig. 4.99
Circuit-switched CN IPsec encrypted transmission secure configuration
An application separation divide the circuit-switched domain into completely separate networks. Application separation: The Core Network element MSC and the Switch Commander (SC) element manager in the Telecommunication Management Network (TMN). The Core Network element MSC and the Operations support System (OSS) elements centralized Charging Gateway (CG) and/or Administration and Billing Center (ABC) in the Telecommunication Management Network (TMN). The Core Network element MSC and the Operations Support System (OSS) element Lawful Interception - Interception Management System (LI-IMS) in the Telecommunication Management Network (TMN). Access control lists (ACLs) Access control lists (ACLs) can be used in order to control the forwarding of IP packets between IP networks. An ACL can be configured to define specific rules, which determine whether or not an IP packet is allowed to be forwarded to an IP network. If an IP packet violates one of these rules the packet is dropped or redirected. This functionality is called packet filtering. Rules for the definition of packet filtering can be based on the source IP address, the destination IP address or TCP/UDP-ports, which identify the upper layer application protocols, such as HTTP, FTP, or SNMP.
4.13.7
Exchange Procedure for New Mobile Subscriber Chip Cards ((U)SIM)

As mentioned previously, the mobile subscriber's chip card ((U)SIM) carries a data record with the IMSI and Ki values and also algorithms A3 and A8 (for 2G) and algorithms f1 to f5 (for 3G).
A50016-D1112-V41-2-7618
DRAFT
301
Information System
Chip cards can in certain cases have a life of only 3 years. The PLMN operator can, if necessary, replace old chip cards with their data records by chip cards with new data records. To support this requirement, the PLMN has an automatic exchange procedure for new chip cards with the following two variants: The exchange procedure for the (U)SIM data record runs automatically when the mobile subscriber uses the new chip card for the rst time. The operator re-writes the HLR subscriber data record in advance. The exchange procedure is triggered in the HLR by the PLMN operator after a dened time period. This re-writes the HLR subscriber data record. After completion of the exchange procedure, call requests with the old chip card are rejected. The authentication procedure is then performed with the new algorithms A3 and A8 (for 2G) and new algorithms f1 to f5 (for 3G) and the new IMSI.
4.13.8
Roaming Restrictions for Mobile Subscribers

Subscription restriction Subscription restriction in the HLR allows the PLMN operator to determine the PLMN levels in which the mobile subscriber is allowed to roam, that is, to use the telecommunication services. One of the following possibilities (PLMN levels) must first be defined for each mobile subscriber as a subscription restriction: All PLMNs (national and international) The subscribers individual national PLMN and all the other (that is, international) PLMNs; the use of foreign PLMNs within the subscribers own home country is therefore prohibited for this type of mobile subscriber The subscribers individual PLMN (home PLMN) only. Regional area restriction (roaming areas) In the HLR, it is possible to define additional roaming areas which, based on the initially defined subscription restriction, further restrict the use of the services on the basis of entire countries, PLMNs or individual VLR areas. Roaming areas can be defined as permitted or barred areas in the form of a list. This list contains numbers (E.164addresses or parts thereof) in the form of a positive or negative list. These numbers can include: Only a part of the E.164 for a country: country code that is, roaming permitted/not permitted for this country. Part of the E.164 for a country and network: PLMN that is, roaming permitted/not permitted for this PLMN. Additional digits for the PLMN part, which identify a VLR: VLR area that is, roaming permitted/not permitted for this VLR area. This type of roaming area can best be assigned to a mobile subscriber in addition to one of the above-mentioned PLMN levels. The additional assignment of a roaming area to a mobile subscriber produces the following interactions shown below in Tab. 4.9.
302
DRAFT
A50016-D1112-V41-2-7618
Information System
Subscription restriction (PLMN levels) All PLMNs
Positive list (area permitted as roaming area)
Negative list (area prohibited as roaming area)
Roaming is permitted in all ar- Roaming is prohibited in all areas which are included in the eas included in the roaming roaming area area (-> Roaming is prohibited in all (-> Roaming is permitted in all other areas) other areas)
The subscribers individual national PLMN and all the other international PLMNs
Roaming is permitted in the mobile subscribers home PLMN (even if the home PLMN, or parts thereof, are not explicitly included in the roaming area) and in all the areas of other international PLMNs included in the roaming area
Roaming is prohibited in all areas included in the roaming area (if appropriate, also within the home PLMN, if this or parts thereof are included in the roaming area)
(-> Roaming is prohibited in all (-> Roaming is permitted in all other areas (including external other areas (except in external national PLMNs) national PLMNs) The subscribers individual PLMN (HPLMN) only The assignment of this kind of roaming area has no effect. However, if one is assigned, the following behavior can be observed: Roaming is permitted in the entire HPLMN, even if the HPLMN (or parts thereof) is not included in an assigned roaming area Roaming is prohibited in all areas within the HPLMN which are included in the roaming area
(-> Roaming is prohibited in all (-> Roaming is permitted in all external (national and interna- other areas of the HPLMN) tional) PLMNs) Tab. 4.9 PLMN roaming restrictions on the basis of an additionally assigned roaming area
Regional subscription (assignment of zones for regional roaming restrictions Further additional roaming restrictions are now only possible via the regional subscription feature. The subscription restriction (including assignment of roaming areas) forms the basis for the assignment of zones for regional roaming restrictions: the assignment of zones is only relevant if the mobile subscriber is allowed to roam in the corresponding area. With this feature, the mobile subscriber is assigned a zone code list per PLMN in the HLR. This can be composed of up to 10 regional subscription zone identities (RSZIs). Each RSZI identifies a regional subscription zone where the mobile subscriber is either allowed or not allowed to roam, depending on the assignments in the VLR database (where a combination of radio cells or location areas can be defined).
A50016-D1112-V41-2-7618
DRAFT
303
Information System
National roaming agreements When regional roaming agreements apply, the VLR database has to contain the national roaming database. The latter registers those location areas of its own PLMN in which mobile subscribers of other national PLMNs are allowed to roam by agreement. A parameter allows the PLMN operator to specify whether it concerns a global or a local agreement. Flexible roaming This feature allows the PLMN operator to control the roaming of its own as well as foreign national and foreign international mobile subscribers in its PLMN. This PLMN can be a combined PLMN, a 3G PLMN, or a 2G PLMN. It also allows the PLMN operator to select which kind of subscriber (3G or 2G) is allowed to roam in which kind of PLMN 3G or 2G). The roaming permission of a mobile subscriber depends on the following criteria: Home PLMN of the roaming mobile subscriber Type of roaming mobile subscriber (3G/2G) Type of access network which is used during the location update Visited location area of the MSC/VLR The following table shows the roaming restrictions on the basis of a flexible roaming agreement when the visited VLR checks the roaming permission. Flexible roaming agreements 2G subscriber in a 2G PLMN 3G subscriber in a 2G PLMN Tab. 4.10 Flexible roaming agreements 2G subscriber in a 3G PLMN 3G subscriber in a 3G PLMN
In the HLR, one flag is used in each mobile subscriber record to allow 3G access (network access subscription). The flag can be set for each mobile subscriber using a Q3/MML command. The subscription for 3G access includes the subscription for circuitswitched domain/packet-switched domain per the subscription restriction administration possibilities (see above).
4.13.9
Operator-Determined Barring (ODB) of CN Service Functions

The PLMN function operator-determined barring (ODB) permits the PLMN operator to regulate access by mobile subscribers to the CN with its service functions. This works by barring specific call categories initiated by the mobile subscriber. The effect of such an ODB restriction is equal to the effect of an activated call restriction supplementary service on the mobile subscribers point of view. However, it is not possible to activate or deactivate an ODB by SCI. ODB, and call restriction supplementary service can be allocated to the mobile subscriber. The access to the circuit-switched domain can be barred both by ODB and the supplementary service call barring. The access to the packet-switched domain can only be barred by ODB.
304
DRAFT
Barring by means ODB basically applies to all of a mobile subscriber's telecommunication services (teleservices, bearer services). Emergency calls can still be made without
A50016-D1112-V41-2-7618
Information System
restriction. Some barrings are only applicable for access to the circuit-switched domain or to the packet-switched domain. If an operator determined barring is not supported by all entities, the HLR can nevertheless ensure the barring by sending other appropriate messages to the visited network node (VLR or SGSN). This is called replacement handling. ODB groups for the circuit-switched and packet-switched domain The following ODB groups are applicable for access to the circuit-switched domain and the packet-switched domain: Barring of outgoing calls (does not affect the bearer service GPRS): Barring of all outgoing calls Barring of all outgoing international calls Barring of all outgoing international calls except those directed to the mobile subscriber's home PLMN country Barring of all outgoing calls while the mobile subscriber is roaming outside the home PLMN country Barring of incoming calls: Barring of all incoming calls Barring of all incoming calls while the mobile subscriber is roaming outside the home PLMN country Barring of all calls depending on the location: Barring of all calls while the mobile subscriber is roaming outside the home PLMN Barring of all calls while the mobile subscriber is roaming outside the home country Operator-specic barring (OSB): Four different types of barring can be entered, and their effect can be dened on an operator-specic basis. These barred calls apply only to outgoing calls and for all basic telecommunication services.
An additional feature introduces four new intercepts for the four OSB conditions. For each condition an individual announcement can be assigned. An OSB condition for a certain call is fulfilled, if the assigned traffic type in the traffic restriction table is equal to the traffic type of the call. The PLMN operator can play specific announcements to the mobile subscriber to explain the reason for barring the account. This enables the mobile subscriber to react immediately in the necessary way to unbar the subscription. Otherwise he or she would have had to call the customer care center (CCC) first. The number of complaints to the CCC is reduced and subscriber satisfaction is increased as he or she can access the service earlier. If outgoing calls are barred, the MS can also be routed to an operator defined by the PLMN. These operator-determined traffic restrictions (barrings) are effective for a mobile subscriber. When one or more of these barring functions is activated, the mobile subscriber receives relevant user information at the mobile station in the form of tones, announcements or displays. ODB groups for the circuit-switched domain
A50016-D1112-V41-2-7618
DRAFT
The following ODB groups are only applicable for access to the circuit-switched domain: Barring of all connections for premium rate calls (calls with special charge rates); in this case both restrictions can be activated at the same time: barring of all outgoing premium rate calls for information
305
Information System
barring of all outgoing premium rate calls for entertainment Barring of subscriber-controlled inputs (SCIs) for supplementary services (this group contains only one possible restriction)
ODB groups for the packet-switched domain The following ODB groups are only applicable for access to the packet-switched domain: Barring of attach for GPRS/packet-switched service (proprietary SIEMENS solution): Barring of any attach Barring of attach while the mobile subscriber is roaming outside the home PLMN Barring of GPRS/packet-switched services (that is, of access to a GGSN / an access point): Barring of access to a GGSN located in the home PLMN while the mobile subscriber is roaming outside the home PLMN Barring of access to a GGSN located in the visited PLMN while the mobile subscriber is roaming outside the home PLMN Barring of access to any GGSN
4.13.10
Administrative Block
There is no provision for the explicit input of an administrative block. But an administrative block can be entered implicitly by ODB, even if the feature operator-determined barring is not enabled or not active. The following barrings have to be used: for the circuit-switched domain: barring of all outgoing calls and barring of all incoming calls for the packet-switched domain: barring of any attach
4.13.11
Barred Directory Numbers for Call Forwarding

As a rule, the call forwarding supplementary service allows mobile terminating calls (MTC) to be forwarded to any national or international directory number. Q3 tasks/MML commands can be used to define directory numbers or combinations of digits to which calls cannot be forwarded. The HLR contains a number of tables for the definition of such directory numbers: One table contains those directory numbers which are barred for all mobile subscribers. A number of additional (feature-dependent) tables contain directory numbers which are barred as call forwarding numbers only for those mobile subscribers who satisfy a specic additional criterion. The following criteria can be used for defining feature-dependent barred directory numbers for call forwarding: Operator-determined barring (ODB) for premium-rate calls (information, entertainment) (see section 4.13.9) Operator-specic ODB restriction (see section 4.13.9).
306
DRAFT
Feature-dependent barred directory numbers are only barred for call forwarding for those mobile subscribers for which the corresponding restriction is entered or to which the corresponding feature is assigned. All the other mobile subscribers can also forward calls to these directory numbers.
A50016-D1112-V41-2-7618
Information System
4.13.12
USSD Text Management

The procedure known as unstructured supplementary service data (USSD) defined by 3GPP is used in the PLMN to transmit messages transparently in the form of character strings between the mobile station and the network (see System Description, register Network System Concept, section subscriber control of supplementary services). In particular, this procedure is used in conjunction with specific supplementary services for which no corresponding functional signaling messages have been specified by the 3GPP, e.g., call completion to busy subscriber (CCBS), call transfer, automatic routing of not completed calls, etc. At present, these USSD messages can only be transmitted from the mobile station to the PLMN. Generally speaking, the network replies to such messages by transmitting a specific text (USSD text) which, for example, either confirms the entry or displays a fault situation. USSD texts can be managed in the CN (depending on the associated application). As soon as the MSC receives a USSD message from a mobile station, it uses the service code to decide whether the request should be dealt with in the MSC itself or whether the message should be forwarded to the HLR. When the system is delivered, USSD texts are defined in English for all the possible situations. The MSC allows the individual texts to be changed, e.g., converted into the relevant national language. However, adding or deleting USSD texts is not possible.
4.13.13
Barring of USSD for Roaming Mobile Subscriber

The feature barring of USSD for roaming mobile subscriber enables the PLMN operator to activate barring of USSD functionality for subscriber of other PLMN (roaming subscriber). If a roaming MS activates a phase1 or phase 2 USSD request over subscriber controlled input (SCI), this operation can be barred in the MSC and the USSD request is rejected. Mobile subscriber requesting USSD in their own HPLMN are also affected of this barring. The feature can be activated over operator controlled input (OCI) by the PLMN operator due Q3 task/MML command. The barring can be administered with the first part of IMSI (e.g., country) and/or with a dialed feature code.
4.13.14
Administration of Mobile Subscriber Profiles in the HLR

As a rule, the administration of many mobile subscribers means a comprehensive administration (Q3/MML command input) of various service groups. This can be simplified by storing different service profiles (HLR subscriber templates) of virtual mobile subscribers in the HLR, which contain typical records of service functions for specific mobile subscriber groups. These service profiles can be copied in the HLR during setup of a mobile subscriber, so that the number of the necessary Q3/MML command inputs for the PLMN operator can be considerably reduced. The PLMN operator can introduce the steadily increasing number of new mobile subscribers in the PLMN much more quickly into the PLMN.
4.13.15
User-Specific HLR Access

The user-specific HLR access function is for selectively restricting subscriber administration, based on one specific personal ID which is different for each PLMN operator, and which is defined in an authentication class. This specific user ID only permits each operator to input Q3 tasks/MML commands which are necessary for administrating new
A50016-D1112-V41-2-7618
DRAFT
307
Information System
subscribers. Accesses to different HLR IDs can be transferred to the various members of the operator team. A current, physical HLR can consist of different HLR-IDs and can, therefore, consist of different virtual HLRs. Each operator only has access to a virtual HLR which was assigned to him. Only authorized operators have any access at all to this virtual HLR when using this function. An operator can be assigned more than one user ID and therefore more than one HLR-ID. Advantages of this function: Limitations of user rights for each operator within a physical HLR Fraud prevention Possibility for the service provider to dene an access to virtual HLRs, to carry out his individual subscriber administration. In this case user data from other service providers is not visible Use of the virtual HLRs for test purposes. The PLMN operator can charge the service provider who has been granted the userspecific HLR access to administer subscribers in the HLR.
4.13.16
Bulk HLR Subscriber Administration

Group commands for HLR subscriber administration Owing to the dramatically increasing number of mobile network subscribers, a set of mechanisms is required to enhance the performance of subscriber administration tasks. One of the approaches is to provide commands that handle complex tasks with one command, therefore reducing system load on the Q3 task/MML command and command logging interfaces. In this way, this feature helps reducing the costs of subscriber administration. The group command feature is designed to provide a first step in this direction. Specific Q3 task/MML commands (for administration of mobile subscriber supplementary services), which are used to modify HLR and associated VLR records, can be based on MSIN ranges, MSIN lists or combinations of it. Compared to using several single Q3 task/MML commands, group commands syntax is expected to speed up mass data modification by an average factor 4, so new services can be introduced faster. Improved display of subscriber data in HLR With this feature the overall administration of the HLR database is improved. All mobile subscriber data stored in the HLR is displayed on one command. The time needed to extract all the information that is stored on a mobile subscriber in the HLR is reduced to a third, leading to shorter response times for customer care, fault removal and subscriber support processes. Mobile subscriber expiry date and deletion for HLR subscriber administration Owing to the competition in the mobile network market a relatively large percentage of mobile subscribers are used to change over between different network providers. Several network provider reports churn out figures for up to 25% of their customers. This fact causes large administrative effort to keep the mobile subscriber databases (HLR) clean from mobile subscribers which have already finished their contractual relationship with the relevant operator. The feature mobile subscriber expiry date and deletion allows anticipation of this behavior of subscribers by providing a mechanism for automatic deletion of subscribers who have exceeded the valid period of their contracts.
308
DRAFT
A50016-D1112-V41-2-7618
Information System
The HLR subscriber records have been extended by a subscription expiry date field. After expiry, that is, the mobile subscriber did not prolong his contract with the network provider, he is automatically barred for all services. Several simultaneous processes scan the HLR for expired mobile subscribers and erase them from the relevant HLR, VLR and optionally the AC.
4.13.17
Combined HLR/AC Administration

This feature provides enables a new mobile subscriber entry to be created in the database via one single Q3 command instead of two different commands previously required to create first the AC database entry and afterwards the HLR database entry. The same functionality also applies for the deletion of the subscriber-related database records. This feature saves: Coordination effort, which had to be spent by the PLMN operator to combine the two commands externally Runtime due to the reduction of internal signaling trafc
4.13.18
Combined MSC/VLR Trunk Administration (with ATM in CN)

The aim of this feature is to provide aid in user-data trunk configuration (not the interworking SS7 signaling trunk) between MSC's MP and CP platforms. With this functionality the PLMN operator is able to configure those connections in a much less error prone way avoiding inconsistencies in database that usually occur due to human error. Combined trunk administration in the MSC/VLR can be used with 2G MSC node and 2G/3G MSC node with ATM in CN. It is implemented using the new script execution environment (SEE) based on python script language that is available only from current Switch Commander (SC) release onwards. These SEE scripts are to be included in Switch Commander's task database (using specific scenario wrappers also developed by scripts) and available at workbench application as common tasks in the task tree. The combined trunk administration consists of a set of SEE scripts as scenario tasks (available from workbench) that allows the user to configure (create, modify or cancel) the TDM connections between TSC server cards (TSCs) and BSSAP/RANAP LTGs or MG-BICC LTGs in a consistent and less error prone way (the present method of manually executing several MML and Q3 commands is prone to several human errors). It also provides workbench (SEE) scenarios that helps PLMN operators into the dimensioning of the TDM/ATM network connections for a given destination.
4.13.19
Deletion of Mobile Subscriber Data in the VLR

The mobile subscriber data in the old VLR is normally deleted under HLR control following a location update and change of VLR service area. It is possible that this deletion is obstructed by an irregularity, e.g., in the mobile station or owing to the failure of a signaling connection. The CN therefore provides the option of forced deletion through intervention by the PLMN operator. Such intervention is only possible via the HLR because important parts of the mobile subscriber database in the VLR have to agree with the mobile subscriber database in the HLR.
A50016-D1112-V41-2-7618
DRAFT
309
Information System
4.13.20
Display of Number of Mobile Subscribers in VLR

A Q3 task/MML command is available to retrieve information from the VLR about the number of registered mobile subscribers. The registered mobile subscribers can be grouped according to their HPLMN. Therefore, the number of mobile subscribers from a certain VPLMN which are roaming in the MSC area can be retrieved. With this feature, it is possible for the PLMN operator to display the number of roaming mobile subscribers, especially whether mobile subscribers from a certain PLMN are located in a certain VLR. For fault reduction and detection of problems with international signaling link sets, the PLMN operator can determine whether foreign mobile subscribers from a special PLMN still roam in the network.
4.13.21
Enhanced Display of Mobile Subscriber Data in VLR

In the context of error correction, fault analysis and customer care more information needed by the operator can be displayed, for example: Subscriber status Last known service area identity Date and time of last radio access.
4.13.22
Display of HLR Statistics for Subscribers Roaming Outside HPLMN

With a Q3/MML command, this feature supports the PLMN operator with HLR statistics, that is, the display of VLR addresses of foreign PLMNs together with the corresponding number of a PLMN operators own mobile subscribers roaming there. These counters are based on the location update (LUP) or the number of location cancel messages received and counted in the HLR during normal operation, thus providing a snapshot of the complete location information reported to the HLR in a certain period. The PLMN operator can choose the following outputs: A list of all VLR addresses and related counters belonging to all foreign PLMN areas A list of those VLR addresses and related counters belonging to all foreign PLMN areas within a given country code (CC) A list of the VLR addresses and related counters belonging to a given foreign PLMN area specied by CC + national destination code (NDC) Based on the VLR address output (including CC and NDC) thus the PLMN operator is able to statistically evaluate of their roaming partner networks. Possible use of statistical evaluation: Identication of hotspots: In which geographical area a network expansion is protable (MSC granularity) Subscriber behavior evaluation in terms of roaming time frame and roaming duration (regular evaluations needed) Check of roaming partner network availability and coverage
4.13.23
Display of Allocated Data for AAL2 Paths

With the display opportunity provided by this feature on Q3 interface, it is possible to view information about the present usage of AAL2 connection data. This data could be, e.g., the bandwidth usage and availability of an AAL2 path or the number and states of used speech/data channels. This feature is a basic administration function for the MSC,
310
DRAFT
A50016-D1112-V41-2-7618
Information System
that is, expected by every PLMN operator. Also on the field this feature is helpful for network dimensioning or for field diagnosis if there are problems on certain AAL2 paths.
4.13.24
Purge Initiation in VLR

This feature allows the VLR to inform the HLR about purging a subscriber record in the VLR by sending an appropriate message. The subscriber record in the HLR is marked as MS purged in VLR. In the case of a subsequent mobile terminating call (MTC), the HLR rejects the interrogation request. In such a case, an MSRN is not transferred between the HLR and VLR, neither is the searching procedure on the radio interface triggered in such a case. Irrespective of the outcome of the purging dialog between VLR and HLR the subscriber record is deleted by the VLR database. The PLMN operator can save resources in the VLR as unnecessary subscriber records are deleted. Also obsolete signaling between the HLR and the VLR is avoided and resources on the radio interface are saved. Furthermore there is a performance increase, because in case of MTC the HLR restoration-procedure is started immediately to restore the subscriber data.
4.13.25
IN/CAMEL: Roaming Subscriber Table in VLR

The CN feature IN/CAMEL: roaming subscriber table in VLR introduces a PLMNbased roaming agreement check in the VLR during the location update phase. It enhances the location update handling in VLR supporting IN/CAMEL. A roaming subscriber table is introduced in the visited VLR. This table is also known as the MAP entity-specific version negotiation table. It is used to determine whether a roaming agreement exists with another PLMN. For optimal routing it is used to ascertain whether or not an optimal routing agreement exists with another network provider. The table is implemented in the HLR, in the VLR and GMSC for circuit-switched services and furthermore in the SGSN for packet-switched services (where it is called roaming subscription relevant instances of managed object class CAMEL). The CAMEL standard makes it technically possible for IN subscribers to use their CAMEL services even when they are roaming in a foreign PLMN. One of the key elements of IN/CAMEL is using the CAMEL subscription information (CSI). The CSI is used in the visited MSC to control the CAMEL subscribers subscription to a relevant CAMEL service. During location update, the HLR sends the CSI to the visited VLR as one of the items of parameter information. It is used there to identify a mobile subscriber requiring CAMEL support.
The VLR asks the roaming subscriber table prior to the location update message to HLR, so that the supported CAMEL phase is already indicated here (exception might be a CAMEL-phase1-VLR: here the supported CAMEL phase parameter can be absent). The HLR has to act accordingly. In particular, the HLR assumes that a VLR from which no supported CAMEL phase indication has been received, possibly supports CAMEL phase 1 and hence CAMEL phase 1 data is sent. Thus, a VLR which does not provide any CAMEL function responds now that CAMEL is not supported.
A50016-D1112-V41-2-7618
DRAFT
311
Information System
The VLR compares the mobile subscribers mobile country code (MCC) + mobile network code (MNC) with the PLMN entries in the roaming subscriber table and has to find one of the following results: 1. If the relevant PLMN is found in the roaming subscriber table. CAMEL is supported to the mobile subscriber. The VLR stores the CSI and supports the relevant CAMEL service. 2. If the relevant PLMN is not found in the roaming subscriber table, the mobile subscriber doing this location update belongs to any PLMN network for which IN/CAMEL support by the visited PLMN is not permitted. The VLR cannot store the CSI. After this reaction, mobile subscribers HLR can instruct fallback to a mobile call.
4.13.26
HSCSD Administration (2G only)

The provision of higher transmission rates is implemented with HSCSD by combining several traffic channels on the radio interface for the same call.
In the current software version of CNcs two traffic channels can be supported.
Administration of general bearer services (BS2x) The general bearer services are defined within in the scope of high-speed circuitswitched data (HSCSD) to cover all user rates including the existing ones (e.g., BS2x). The general bearer service is a prerequisite for the introduction of HSCSD. By administering the mobile subscriber with general bearer services in the HLR, the mobile subscriber gets access to the higher data rates provided by HSCSD which range up to 56 kbit/s. The general bearer services also cover the existing bearer services which are already implemented via the following mapping: BS20 covers the asynchronous data services BS21 BS26 Administration of A interface circuit pooling In 2G PLMN the pool concept (fully standardized in 3GPP standards) is implemented. This feature allows the classification of A interface trunks to circuit pools that serve certain channel types and speech coding algorithms (e.g., HSCSD, FR, HR, EFR). The different circuit pools are predefined in the 3GPP standards. For each circuit pool one trunk group has to be administered and the desired circuit pool characteristic has to be assigned to that trunk group. One trunk group comprises a range of circuits which can be distributed to different PCM systems. For this purpose the A interface circuits in the MSC/VLR node that can be used for HSCSD, can be administered according to the pool concept.
14.4 kbit/s channel coding:

14.4 kbit/s channel coding (TCH/F14.4) is a 2G feature for the provision of higher transmission rate for circuit-switched data services (that is, application of HSCSD) and a new forward error correction (FEC) method on the air interface. This feature is provided for asynchronous transparent and non-transparent transmission as well as for unrestricted digital and modem interworking to the fixed network.
312
DRAFT
The PLMN operator is able to offer its users the very common user rate of 14.4 kbit/s by administering the improved interworking function (IWF) of the TRAU network element.
A50016-D1112-V41-2-7618
Information System
4.14
4.14.1
Protocol Stacks for Transport and Signaling

Circuit-Switched Domain Interfaces
In respect to the technological state of that time as 2G PLMN (GSM) was introduced the network elements for circuit-switched domain (e.g., the MSC) are time division multiplexed (TDM) based (64-kbit/s channels) and basically plesiochronous digital hierarchy (PDH) switches which handle E1 signals. The possibilities of broadband access technologies like asynchronous transfer mode (ATM) or Internet protocol (IP) for the circuit-switched CN area (direct links as well as backbone related) are available. For the SS7 network connections the high-speed signaling link (HSL) mode is usable for all MP platform based network elements. It is also possible to use ATM and IP based transfer of signaling between MP platform based network elements. ATM based signaling transfer is possible for the Nc interface. The usage of SCTP/IP based signaling exchange depends on the interface configuration of other service domains. So if network elements within the CN or connections from CN to service domains (e.g., Intelligent Network Domain) requests exclusively SCTP/IP based connections, this would be possible. A replacement for existing TDM narrow-band networks seems not to be main purpose. Digital hierarchies for data transmission In the CN the following digital hierarchies for data transmission are possible: PDH The plesiochronous digital hierarchy is an outdated type of wide area network transmission technology for telecommunication purposes. Disadvantages are that no access to sub-signals within the sum signal without de-multiplexing from a higher transmission level is possible (e.g., a E0 bit stream of 64 kbit/s within a E3 of 34368 kbit/s for example). This is caused due to nearly synchronized signals only (= Plesiochronous) and the need of bit stufng therefore. So the consequence is the implementation complexity of cross connecting the aggregated channels, with demultiplexing and re-multiplexing at each cross connect node. Benet of PDH is that the different tributary channels don't have to be clock synchronized between them and with the aggregate channel. A centralized and very stable network clock is unnecessary avoiding the problems of clock stability, recovery and distribution. SDH The synchronous digital hierarchy is the present type of transmission technology used for wide area network within the telecommunication area. In respect to a further harmonization between European and North American standards an integer multiple of 2.048 Mbit/s (PCM30) and 1.544 Mbit/s (PCM24) (plus overhead) was dened as synchronous transport module 1 (STM-1) with a bit rate of 155.510 Mbbit/s. The two key benefits of SDH/SONET against PDH are: Higher transmission and aggregate rates Direct multiplexing and cross connecting without intermediate multiplexing stages, due to its synchronous nature and pointers in multiplex streams that delineate the aggregated sub streams.
A50016-D1112-V41-2-7618
DRAFT
4.14.2 Overview of Protocol Stacks
In PLMN we can distinguish the following two kinds of planes within the protocol stacks: User (data transport) plane
313
Information System
The user plane defines different user data transport protocols for the circuit-switched domain and packet-switched domain. Control (signaling) plane The control plane defines different signaling protocols for control and transport.
The control signaling is used for circuit-switched/packet-switched service management, user management and resource management. The transport signaling is only responsible for the allocation of the ATM based bearer between the RNC and the MSC/VLR (Iu interface) and between the CS-MGW part of the MSC/VLR and the PSTN-MGW part of the GMSC (Nb interface), in the case of the circuit-switched domain. It comprises only the AAL2 layer 3 signaling. Fig. 4.100 gives an overview of all the PLMN points (PLMN interfaces) of the described protocol stacks.
*) In case of IPS, the CSG does not offer Ga interface, but a GTP/TLV interface. MS CG Radio interface BTS; NodeB Abis interface Iub interface Gb, Iu,ps interfaces Ge interface SCP CAP interface A, Iu,cs interfaces A interface MSC/ VLR (CSC) Gs interface Ga interface CN Ga interface (without L-CG) FTP interface (with L-CG)
Data server
SGSN/ SLR
Gn interface Gr interface
GGSN/ IPS *)
Gi interface
PDN
BSC/TRAU; RNC
EIR
HLR/AC
Fixed subscriber
F interface C/D interface E, Nc, Nb interface C interface
GMSC
PSTN/ ISDN
RAN GSM MGW DSS.1 PA PABX E interface Pulse dialing/DTMF BA a/b
DSS.1 PA PABX
Fig. 4.100 Overview of all PLMN points (PLMN interfaces) of the described protocol stacks
314
DRAFT
i
The transport signaling is clearly separated from control signaling, as opposed to 2G BSSAP signaling where transport signaling is mixed within the control signaling.
A50016-D1112-V41-2-7618
Information System
At the Iu interface and Nb/Nc interface ATM is used as the underlying network layer for signaling and transport protocols for circuit-switched connections. The following sections describe the user data transport protocol ATM-based in the Core Network (section 4.14.4); control signaling protocol TDM/ATM/IP-based in the Core Network (section 4.14.5); transport signaling protocol ATM-based in the Core Network (section 4.14.6) and the signaling functions of the Telecommunication Management System (section 4.14.8).
4.14.3
Summary of all the ATM based Protocol Stacks on the Iu,cs Interface (3G only) or Nb/Nc Interface
Fig. 4.101 shows the complete Iu,cs interfaces (3G only) or Nb/Nc interface protocol stack. Two independent Iu interface instances are envisaged, one for circuit-switched and one for packet-switched traffic. These two instances can or cannot be handled on the same SCCP connection for one user.
User data transport (user plane) Transport signaling
Control signaling (control plane)
RANAP (SM, MM, RM, SMS) BICC AAL2L3 signaling Layer3 SCCP-CO
MTP3-B
AAL2 Layer2 ATM Layer1 SDH/PDH
SAAL AAL5
Fig. 4.101 Iu,cs interface (3G only) or Nb/Nc interface protocol stack for circuitswitched instances
A50016-D1112-V41-2-7618
DRAFT
315
Information System
4.14.4
ATM-based User Data Transport Protocols in the Circuit-Switched Domain of Core Network (CNcs)
In the circuit-switched domain of CN (CNcs) for a 2G PLMN the user data transport is implemented in TDM or PCM30 systems based on plesiochronous digital hierarchy (PDH). This section does not deal with these type of TDM interfaces but with ATM interfaces The Fig. 4.102 shows the Iu,cs interface (3G only) and Nb interface protocol stack of an ATMbased user data transport protocol (user plane) in the circuit-switched domain of CN (CNcs).
OSI layer 3 AAL2 2 ATM 1 SDH/PDH
Fig. 4.102 The Iu,cs interface (3G only) and Nb interface protocol stack of ATM-based user data transport protocol (user plane) in the circuit-switched domain of CN (CNcs) SDH/PDH (layer 1) The functions of layer 1 (physical layer) are the sending, receiving and transferring of bits and coding. These functions depend on the transport medium used. World-wide application parts on the physical medium are the synchronous digital hierarchy (SDH) or the plesiochronous digital hierarchy (PDH). PDH describes a multiplex system (e.g., PCM30) for copper double wire or coaxial wire for higher bit rates. Older networks work with PDH. SDH is used for synchronous optical networks. For the MP platform there are different kinds of LICs, for example: LIC(ATM)-E1 (2.048 Mbit/s) for PDH and LIC(ATM)STM-1 (155.52 Mbit/s) for SDH. ATM (layer 2) Asynchronous transfer mode (ATM) describes a variable bit rate service. The functions of ATM are cell structure and encoding, cell multiplexing and relaying, cell header generation/extraction, generic flow control, traffic control and congestion control. AAL2 The ATM adaptation layer 2 (AAL2) is defined by ITU-T and provides bandwidth-efficient transmission of low-rate, short and variable length packets for delay sensitive applications. AAL2 uses an ATM connection called AAL2 path into which up to 248 individual AAL2 connections for users are multiplexed. On the ATM platform at Iu,cs/Nb interface the AAL2 path is always setup as a virtual channel contained within a virtual path. As specified by 3GPP, AAL2 is used for the transport (user plane) of circuit-switched user data at the Iur interface (between two RNCs) and Iu,cs/Nb interface.
316
DRAFT
A50016-D1112-V41-2-7618
Information System
4.14.5
TDM/ATM/IP-based Control Signaling Protocols in the CircuitSwitched Domain of Core Network (CNcs) Control Signaling Protocol SS7
In a PLMN, the SS7 signaling protocol is used in the following PLMN interfaces: A interface (BSC - MSC/VLR) (2G only) Iu,cs interface (RNC - MSC/VLR) (3G only) C/D interface (MSC/VLR - HLR/AC) F interface (MSC/VLR - EIR) C interface (GMSC - HLR/AC) E interface (MSC/VLR - GMSC) Nc interface (MSC/VLR - MSC/VLR or GMSC) Gs interface (MSC/VLR - SGSN/SLR) CAP interface (MSC/VLR/SSP - SCP/CSE) Interface (HLR/AC - SCP/CSE). The A interface is always based on non-ATM PCM30 systems using the classic SS7 signaling system for control signaling. The C, D, E, F and Gs interfaces are often based on non-ATM PCM30 systems using the classic SS7 signaling system for control signaling. An SS7 signaling connection with the user part CAMEL application part (CAP) must be available in an IN/CAMEL connection between an MSC/VLR/SSP network element with IN/CAMEL function SS7 and an SCP/CSE. Iu,cs/Nc SS7 signaling in CN can be considered as a control plane. The Iu,cs/Nc interface is based on an asynchronous transfer mode (ATM) system on which the SS7 signaling system is set up. Between the CN network elements and the additional project-dependent network elements (service centers), there can be additional signaling connections. Such service centers can be: Service center for subscriber-related routing of service numbers SMS Interworking MSC (SMS-IWMSC)/SMS Gateway MSC (SMS-GMSC) (as link to an SMS Center (SMSC)) Voice Mail Service Center (VMSC). An SS7 signaling connection with the user part IN application part (INAP)/CAMEL application part (CAP) must be available in an IN/CAMEL connection between an M-SSP (MSC/VLR with IN/CAMEL function) and an SCP/CSE. Fig. 4.103 shows signaling connections between the CN (including M-SSP) network elements and various additional service centers (inclusive IN/CAMEL network element SCP/CSE) which can be present as additional network elements depending on the project involved. The SS7:MAPv3 interface between the SCP/CSE and the HLR is not shown in Fig. 4.103.
4.14.5.1
For the connection between MSC/VLR and SGSN (Gs interface), the SS7:BSSAP+ is supported.
A50016-D1112-V41-2-7618
DRAFT
317
Information System
Service center for subscriber-related routing of service numbers
SMS-IWMSC/ SMS-GMSC
Center for VMS SS7 (ISUP)
SCP/CSE (IN/CAMEL)
SS7 (MAP) SS7 (MAP) SS7 (ISUP)
SS7 (MAP)
SS7 (CAP/INAP) MSC/ VLR (M-SSP) GSM MGW HLR/AC GMSC to fixed network
to 2G RAN
Fig. 4.103 Signaling routes between CN network elements and additional service centers Structure of the TDM/PCM30-based SS7 Signaling System The SS7 signaling (based on PCM30 systems) system can be divided into: Message transfer part (MTP3) Signaling connection control part (SCCP) User parts (UP, e.g., SCCP, ISUP/TUP, BICC) Application parts (AP, e.g., TCAP, MAP, BSSAP, CAP). The Fig. 4.104 shows the protocol stack of a TDM/PCM30-based SS7 signaling protocol. The user parts TCAP, MAP and BSSAP support both 2G GSM phase 1 and GSM phase 2/2+ features. The TCAP, MAP and BSSAP is implemented in accordance with the ITUT White Book and Blue Book. The user parts TCAP and MAP support 3G UMTS phases where the TCAP and MAP is needed in accordance with the ITU-T White Book.
318
DRAFT
A50016-D1112-V41-2-7618
Information System
OSI layer 7 BSSAP MAP/ CAP ISUP/ BICC
SS7 levels
TCAP
46 SCCP
3 2 1
Network MTP3 layer Link layer Physical layer
3 2 1
Fig. 4.104 Protocol stack of a TDM/PCM30-based SS7 signaling protocol Tab. 4.11 shows the signaling routes for SS7 in the PLMN with the SS7 signaling components used. Signaling link Signaling components
GMSC ISDN/PSTN (/PSDN) SS7: MTP3, ISUP/TUP or CAS (e.g., MFC:R2) GMSC HLR/AC GMSC MSC/VLR (or 2G GSM MGW) MSC/VLR EIR MSC/VLR HLR/AC MSC/VLR IW-MSC(SMS) MSC/VLR Center of subscriber related routing of service number MSC/VLR VMS-center SS7: MTP3, SCCP, TCAP, MAP SS7: MTP3, ISUP/TUP, BICC SS7: MTP3, SCCP, TCAP, MAP SS7: MTP3, SCCP, TCAP, MAP SS7: MTP3, SCCP, TCAP, MAP SS7: MTP3, SCCP, TCAP, MAP MTP3, ISUP/TUP SS7: MTP3, ISUP/TUP
A50016-D1112-V41-2-7618
DRAFT
Tab. 4.11 SS7 components on the signaling routes
319
Information System
Signaling link MSC/VLR MSC/VLR
Signaling components SS7: MTP3, SCCP, TCAP, MAP MTP3, ISUP/TUP, BICC SS7: MTP3, SCCP, TCAP, CAP/INAP SS7: MTP3, SCCP, TCAP, MAP v3 SS7: MTP3, SCCP, TCAP, MAP SS7: MTP3, SCCP, BSSAP SS7: MTP3, SCCP, BSSAP+
M-SSP SCP/CSE
HLR SCP/CSE MSC/VLR GMLC MSC/VLR (or 2G GSM MGW) 2G RAN MSC/VLR SGSN/SLR (Gs interface) Tab. 4.11
SS7 components on the signaling routes
In the SS7 signaling system, the components message transfer part 3 (MTP3) and signaling connection control part (SCCP) are responsible for signaling routing and routing of messages. Message transfer part 3 (MTP3) The MTP3 defines the protocols for the reliable transmission of messages between the PLMN signaling nodes, e.g., between MSC/VLR network elements and HLR/AC network elements. The MTP3 is structured in three SS7 levels. Level 1 (physical layer) denes the signaling transfer link as an SS7 transmission path (bearer) for signaling between two signaling points which include a duplex channel with the same data rate in both directions. In a 3G PLMN only 64 kbit/s lines are used and these are implemented by PCM30 systems or individual 64 kbit/s lines (by means of multiplexing/demultiplexing). Level 2 (link layer) denes the functions and procedures for the secure transfer of signaling messages (protocols) on the signaling transfer link. These functions include, for instance, signal delimitation and synchronization, error detection, correction, and supervision, and ow control. Level 3 (network layer) deals with the routing of signaling messages to the correct signaling link or to the signal routing functions of higher levels (SCCP). In addition, it provides network management functions.
320
DRAFT
If SS7 is not TDM/PCM30-based, the MTP3 is substituted by other protocol parts. For broadband ATM-based SS7 signaling it is the MTP3-B protocol layer (see 4.14.5.3). For broadband IP-based SS7 signaling it is the M3UA protocol layer (see 4.14.5.4)
A50016-D1112-V41-2-7618
Information System
Signaling connection control part (SCCP) The SCCP has no reference to the traffic channel and makes additional functions available to the MTP3 (or MTP3-B or M3UA). For this purpose it provides two types of message transfer: connection-oriented, that is, with a virtual signaling connection and connectionless, that is, without a virtual signaling connection. The connection-oriented transfer type uses a method which includes procedures for call setup, message transfer or message checks and connection cleardown for the signaling messages. The BSSAP and RANAP (which is described in section 4.14.5.2) uses this mode. The connectionless transfer type is a method of signaling message transfer in which no signaling connection is set up. The TCAP uses this type of transfer. In the circuit-switched domain only subscriber-related communication (location update, MOC, MTC, handover) between MSC/VLR network elements and BSC/RNC is connection-oriented. Communication between MSC, VLR, HLR and GMSC in the case of location update and interrogation of the file contents is connectionless. The SCCP transport capabilities are based on the basic message handling features of the MTP3. Together with the MTP3, the SCCP represents the network service part for signaling routing and message routing. The SCCP is able to address network elements outside its individual signaling network. Because the level 3 addresses or destination point codes (DPC) are only unambiguous within one signaling network, the SCCP must use other internal signaling addresses for international applications. These unambiguous international addresses are called global titles (GT). A GT can, for example, be an IMSI or an MSISDN. The necessary translation to the level 3 address (DPC) is called global title translation (GTT). An outgoing SCCP message is given an SCCP subsystem number which identifies the SCCP application for which it is intended (e.g., MAP-HLR). ISDN user part (ISUP) The ISUP provides the signaling functions which are required for the switched telecommunication services for speech and data applications at the interface of the PLMN to the ISDN. An echo canceller must be activated for speech transmission and deactivated in the case of data transmissions (bearer services and data teleservices). The ISUP is likewise used on the trunks between the circuit-switched MSC network elements. In this application the ISUP is required, for example, during a handover process after handover from one MSC to the next MSC network element. Bearer independent call control (BICC) BICC is based on ISUP and defines all necessary changes to guarantee a bearerless call control functionality and signaling including the establishment of the required bearer necessary for user data transport. In principle, BICC is independent from the used transport method (ATM or IP) but includes bearer specific parameters. One of the important features of the new transport networks (ATM or IP) is the transport of voice in compressed form. For this, the negotiation of codecs must be supported by BICC. The BICC standards define two functions which work together to handle calls. The first is the call control function (CCF), responsible for the call control, and the second is the bearer control function (BCF), responsible
A50016-D1112-V41-2-7618
DRAFT
321
Information System
for bearer control. The CBC-interface between both could be an external one, that means CCF and BCF could be located on different physical nodes based on H.248. In the current software version it is an internal one. BICC signaling transport can be done via ATM-based protocol stack (with MTP3B) or via IP-based protocol stack (with M3UA/SCTP). Telephone user part (TUP) The TUP can be used as an alternative to the ISUP although it only supports data telecommunication services, to a limited extent. The TUP provides the signaling functions needed for the switched traffic channel connections (voice telecommunication services) at the interface of the PLMN to the PSTN (ISDN). Transaction capabilities application part (TCAP) Transaction capabilities (TC) are functions for controlling the transmission of non-trafficchannel related information between two or more signaling nodes over a signaling network. The TCAP always uses the connectionless type of message transfer of the SCCP. The mobile application part (MAP) is based on TCAP functions.
The TCAP is available in accordance with the ITU-T white book. The TCAP in accordance with the ITU-T white book provides the "version negotiation" function which allows phase switching. Mobile application part (MAP) The MAP regulates communication between the network elements in the PLMN to control network access of the mobile stations. For this purpose, the MAP provides signaling procedures which perform self-contained control tasks. The MAP functions are principally concerned with the information transfer relating to the roaming of a mobile station, e.g., the automatic cell change of mobile stations. The MAP meets the requirements with regard to features, user equipment and mobile network capabilities for the provision of roaming and telecommunication services at a national and international level. The MAP uses TCAP, SCCP and MTP3 functions which are provided for information transfer between the network nodes in the PLMN. The following functions are provided: Authentication Location registration (location update and location cancellation) Retrieval of mobile subscriber parameters for call setup Requesting location information (interrogation) Updating HLR and VLR mobile subscriber parameters. CAMEL application part (CAP) The CAP provides signaling functions needed for the exchange of messages between the IN/CAMEL network elements M-SSP (MSC/VLR network elements with IN/CAMEL functionality) and the SCP (Service Control Point) / CSE (CAMEL Service Environment). The ETSI CAP protocol is used. The CAMEL user part CAP uses TCAP, SCCP and MTP functions which are available for transferring information between the network nodes in the PLMN.
322
DRAFT
A50016-D1112-V41-2-7618
Information System
National IN application part (INAP) Several national INAP protocols are also supported, e.g., SIEMENS IN application parts (SINAP5M or SINAP7M+). Similar to CAP the SINAP protocol versions are distinguished by application contexts. Furthermore, different SCCP subsystem numbers are used for the CAP and SINAP protocol families. The national INAP provides signaling functions needed for the exchange of messages between the IN network elements M-SSP (MSC/VLR with IN functionality) and the SCP (Service Control Point). The ETSI core INAP protocol is used. The IN user part INAP uses TCAP, SCCP and MTP functions which are available for transferring information between the network nodes in the 2G PLMN. Base station system application part (BSSAP) (2G only) The BSSAP defines the procedures required on the BSC interface to the MSC (A interface). The BSSAP uses the MTP and the SCCP to support communication between the MSC and the 2G RAN. The BSSAP is subdivided into two sub user parts, the base station system management application part (BSSMAP) and the direct transfer application part of the BSSAP (DTAP).
Two variants are available, BSSAP I for phase 1 signaling and BSSAP II for phase 2/2+ signaling. Base station system management application part (BSSMAP) The BSSMAP supports the procedures for resource management between 2G RAN and MSC. The following functions (in the MSC) are provided: Allocation of a trafc channel (TCH) Barring of a trafc channel (TCH) Resource indication Reset Handover required indication Handover resource allocation Handover execution Release Paging Radio cell identity Flow control Classmark update Encryption update. Direct transfer application part (DTAP) of the BSSAP The direct transfer application part is used for the transfer of connection management (CM) and mobility management (MM) messages between the MSC and the MS. The DTAP information in these messages is not evaluated by the 2G RAN. The majority of the messages from the radio interface are transferred transparently by the DTAP over the 2G RAN/MSC interface.
If a PLMN circuit-switched and packet-switched domain are combined and interconnected via a Gs interface (between MSC/VLR and SGSN/SLR) there is an advanced BSSAP (BSSAP+).
A50016-D1112-V41-2-7618
DRAFT
323
Information System
4.14.5.2
ATM-based Control Signaling Protocol on the Iu,cs Interface (3G only)

In 3G for each domain (circuit-switched and packet-switched) there are individual independent Iu signal connections and RANAP instances. The Fig. 4.105 shows the Iu,cs interface protocol stack terminated in the MSC/VLR network element or RNC of an ATM-based control signaling protocol (control plane).
OSI layer
PMM/SM/RM/SMS
RANAP SCCP-CO 3 MTP3-B SAAL AAL5 2 ATM 1 SDH/PDH
Fig. 4.105 Iu,cs interface protocol stack of an ATM-based control signaling protocol SDH/PDH (layer 1) The functions of layer 1 (physical layer) are the sending, receiving and transferring of bits and coding. These functions depend on the transport medium used. World-wide application parts on the physical medium are the synchronous digital hierarchy (SDH) or the plesiochronous digital hierarchy (PDH). PDH describes a multiplex system (e.g., PCM30) for copper double wire or coaxial wire for higher bit rates. Older networks work with PDH. SDH is used for synchronous optical networks. For the MP platform there are different kinds of LICs, for example: LIC(ATM)-E1 (2.048 Mbit/s) for PDH and LIC(ATM)STM-1 (155.52 Mbit/s) for SDH. ATM (layer 2) Asynchronous transfer mode (ATM) describes a variable bit rate service. The functions of ATM are cell structure and encoding, cell multiplexing and relaying, cell header generation/extraction, generic flow control, traffic control and congestion control. AAL5 (layer 2) The ATM adaptation layer 5 (AAL5) is very useful for transporting data packages. Because the signaling of information is also a kind of data transport, the AAL5 can be used for data services and the (control) signaling part. SAAL (layer 2)
324
DRAFT
A50016-D1112-V41-2-7618
Information System
The signaling ATM adaptation layer (SAAL) was defined, because the AAL is not sufficient for the (control) signaling stack and additional functions are necessary. The SAAL in combination with AAL5 performs the reliability functions of the (control) signaling protocol. The SAAL consists of a common part (SSCOP) and the user-specific part (SSCF). For 3G, the SSCF with a network node interface (NNI) specific adaptation is used. MTP3-B (layer 3) The message transfer part 3 - B (MTP3-B) defines the protocols for the reliable transmission of messages between the broad band PLMN control signaling nodes. The most important difference of the narrow band MTP3 is the maximum amount of user data supported for signaling links. SCCP-CO (layer 3) The signaling connection control part (SCCP) is an ITU-T standardized signaling system no. 7 (SS7) signaling protocol and covers the layer 3 functions of the OSI model as described in the previous section. Within SCCP there are two different modes: the connectionless data transfer mode which works together with the TCAP and the connection-oriented data transfer mode which demands a logical connection. The last variant connection-oriented is used in the Iu,cs interface protocol stack. Radio access network application part (RANAP) The RANAP defines the procedures required on the RNC interface to the MSC/VLR network elements (Iu,cs interface). The RANAP uses the MTP and the SCCP to support communication between the MSC/VLR network elements and the 3G RAN. The RANAP is subdivided into two sub-user parts, the Radio Network Controller management application part (RNCMAP) and the direct message transfer application part of the RANAP (DMTAP). Radio Network Controller management application part (RNCMAP) The RNCMAP supports the procedures for resource management between 3G RAN and the MSC/VLR network elements. The following functions (in the MSC/VLR network elements) are provided: Allocation of a trafc channel (TCH) Barring of a trafc channel (TCH) Resource indication Reset Handover required indication Handover resource allocation Handover execution Release Paging Radio cell identity Flow control Classmark update Encryption update. Direct message transfer application part (DMTAP) of the RANAP The direct message transfer application part is used for the transfer of conguration management (CM)/session management (SM) and mobility management (MM) messages between the MSC/VLR network elements and the MS. The DMTAP information in these messages is not evaluated by the 3G RAN. The majority of the mes-
A50016-D1112-V41-2-7618
DRAFT
325
Information System
sages from the radio interface are transferred transparently by the DMTAP over the Iu,cs interface.
The current software version implements RANAP Rel-5 according to the 3GPP standards. This release ensures multivendor capability and enables inter operability with RNCs of other vendors.
4.14.5.3
ATM-based Control Signaling Protocol on the SS7 Interface

Broadband SS7 links (SS7 over ATM) This type is based on protocol stack message transfer part level 3B (MTP-3B)/signaling ATM adaptation layer (SAAL)/ATM adaptation layer 5 (AAL5) and allows SS7 access over an ATM network. This type enables the setup of signaling links within ATM backbones or on ATM links configured directly between CN nodes. Quality of service (QoS), which means loss less transport of signaling messages within defined time appropriate for SS7 signaling, is guaranteed by the QoS principles offered by ATM. The scalability of the signaling link bandwidth per AAL5 depends on the ability of each involved network node element. All MP platform (SSNC) based network nodes (e.g., MSC, SGSN) are able to in/de-crease the bandwidth within single 64kbit/s steps (e.g., 128 kbit/s, 192 kbit/s, 256 kbit/s, ).
For traffic over ATM CN the ATM-based SS7 call control plane signaling (Nc interface) supported by the LTG:BICC and MP:RANAP/BCF in the MSC/VLR or GMSC can be transferred over the ATM domain. It can also be transferred over the IP domain, that is, over MP:SLT (UDP-IP). The Fig. 4.107 shows the ATM based Nc interface protocol stack terminated in the MSC/VLR or GMSC network element of an ATM-based control signaling protocol (control plane).
OSI layer
BICC
MTP3-B SAAL AAL5
2 ATM 1 SDH/PDH
326
DRAFT
Fig. 4.106 Nc interface protocol stack of an ATM-based control signaling protocol
A50016-D1112-V41-2-7618
Information System
SDH/PDH (layer 1), ATM (layer 2), AAL5 (layer 2), SAAL (layer 2), MTP3-B (layer 3) See descriptions in section 4.14.5.2, ATM-based Control Signaling Protocol on the Iu,cs Interface (3G only) above. BICC (layer 3) See descriptions in section 4.14.5.1, Control Signaling Protocol SS7.
4.14.5.4
IP-based Control Signaling on SS7 Interfaces

Broadband SS7 links (SS7 over IP) This type is based on protocol stack MTP-3 user adaptation layer (M3UA)/stream control transmission protocol (SCTP)/Internet protocol (IP) and allows SS7 access to servers (e.g., SCP/CSE, SMSC or VMSC) over an IP network. The conversion between the traditional SS7 addressing mechanism and the IP-related addressing principles is an integrated part of the SSNC. This SS7 mode, based on the M3UA/SCTP/IP stack, is available at network level in general.
IP-based SS7 call control plane signaling is supported by MP:SLT(UDP-IP) in the CN nodes (e.g., MSC/VLR), which can be transferred over the IP domain. The Fig. 4.107 shows the IP-based SS7 interface protocol stack terminated in the 3G MSC/VLR network element.
OSI layer
M3UA
SCTP 3 IP Ethernet (100BaseT)
Fig. 4.107 SS7 interface protocol stack of an IP-based control signaling protocol Ethernet (100BaseT) Layer 1 is the physical layer and is based in case of Ethernet on the 10/100 BaseT. Layer 2 in case of Ethernet the media access control (MAC) protocol is used which works with CSMA/CD methods. Beyond the Internet layer (layer 3) is a great void. The IP reference model does not really say much about what happens here, except to point out that the host has to connect
A50016-D1112-V41-2-7618
DRAFT
327
Information System
to the network using some protocol so it can send IP packets over it. This protocol is not defined and varies from host to host and network to network. Internet protocol (IP) The Internet layer defines an official packet format and protocol called IP (Internet protocol). The job of the Internet layer is to deliver IP packets where they are supposed to go. Packet routing is clearly the major issue here. For these reasons, it is reasonable to say that the IP Internet layer is very similar in functionality to the OSI network layer. Stream control transmission protocol (SCTP) In the case of IP-based signaling networks the corresponding functionality for reliable and in-sequence delivery of SS7 messages is provided by the stream control transmission protocol which is described in RFC2960. SCTP resides on top of the Internet protocol (IP) layer (RFC 791) like the well-known transmission control protocol (TCP) and user datagram protocol (UDP). It was specifically developed by the Internet Engineering Task Force (IETF) to meet the requirements for transporting signaling information over an IP-based network. MTP3 user adaptation layer (M3UA) The MTP3 user adaptation layer defines a protocol for supporting the transport of any SS7 message transfer part (MTP) level 3 user signaling (e.g., ISUP and SCCP messages) over IP using SCTP services.
4.14.6
ATM-based Transport Signaling Protocols in the Circuit-Switched Domain of Core Network (CNcs)
Transport signaling deals with the allocation of the bearer on Iu,cs interface and on Nb interface (between two CS-MGW parts of neighbor MSC nodes or between the CSMGW parts of a visited MSC node and the GMSC). This signaling is clearly separated from control signaling (as opposed to 2G BSSAP signaling where transport signaling is mixed in the control signaling). Fig. 4.108 shows the Iu,cs/Nb interface protocol stack of an ATM-based transport signaling protocol (transport plane). Transport signaling is only necessary in the circuitswitched domain of Core Network (CNcs).
328
DRAFT
A50016-D1112-V41-2-7618
Information System
OSI layer AAL2L3 signaling 3 MTP3-B SAAL AAL5 2 ATM 1 SDH/PDH
Fig. 4.108 Iu,cs interface and Nb interface protocol stack of an ATM-based transport signaling protocol (transport plane) SDH/PDH (layer 1) The functions of layer 1 (physical layer) are the sending, receiving and transferring of bits and coding. These functions depend on the transport medium used. World-wide application parts on the physical medium are the synchronous digital hierarchy (SDH) or the plesiochronous digital hierarchy (PDH). PDH describes a multiplex system (e.g., PCM30) for copper double wire or coaxial wire for higher bit rates. Older networks work with PDH. SDH is used for synchronous optical networks. For the MP platform different kinds of LICs exist, for example: LIC(ATM/TDM)-E1 (2.048 Mbit/s) for PDH and LIC(ATM)-STM-1 (155.52 Mbit/s) for SDH. ATM (layer 2) Asynchronous transfer mode (ATM) describes a variable bit rate service. The functions of ATM are cell structure and encoding, cell multiplexing and relaying, cell header generation/extraction, generic flow control, traffic control and congestion control. AAL5 (layer 2) The ATM adaptation layer 5 (AAL5) is very useful for transporting data packages. As the signaling information is also a kind of data transport, the AAL5 can be used for data services and the (control) signaling part. SAAL (layer 2) The signaling ATM adaptation layer (SAAL) was defined, because the AAL is not sufficient for the (control) signaling stack and additional functions are necessary. The SAAL in combination with AAL5 performs the reliability functions of the (control) signaling protocol. The SAAL consists of a common part (SSCOP) and the user-specific part (SSCF). For CN the SSCF with a network node interface (NNI) specific adaptation is used.
A50016-D1112-V41-2-7618
DRAFT
MTP3-B (layer 3)
The message transfer part 3 - B (MTP3-B) defines the protocols for the reliable transmission of messages between the broad band PLMN control signaling nodes. The
329
Information System
most important difference of the narrow band MTP3 is the maximum amount of user data supported for signaling links. AAL2L3 signaling (Q.2630) For the AAL2, bearers of different calls are multiplexed in one ATM connection. For the call handling (setup, modify, release) of each AAL2 connection, the AAL2L3 (Q.2630.1, Q.2630.2) is used. This implies that, the signaling protocol for AAL2 connections is AAL2L3. The Capability Set 2 is restricted to the bearer modification feature. Additional included features (path selection, rerouting) are not supported in the current software version. The signaling protocol Q.2630 basically defines the procedures to set up and release AAL2 connections. It is strictly a bearer control protocol, that is, deals with the bearer capabilities of the transport only. All call control issues must be taken care of by other protocols, e.g., RANAP or BICC, that appear as the users of the AAL2 connections. In the reference model of Q.2630 these users are denoted in a generic way as served user for which a specified interface is defined. Because AAL2 is applicable to a variety of different environments, the transport of peer-to-peer AAL2 messages is kept generic too. To this end, a generic signaling transport is defined. Adaptations to a specific transport are made by means of a signaling transport converter (STC). Currently STCs are defined that allow operation via an ATM NNI (MTP3-B) or entirely self-contained, that is, the signaling is conveyed in the associated AAL2 path. The AAL2 STC performs adaptations to a specific transport and is specified in Q.2150.1.
330
DRAFT
A50016-D1112-V41-2-7618
Information System
4.14.7
Structure of the DSS.1 Signaling System

The DSS.1 signaling system is used at the Combined Switching Center (CSC) for connecting wired ISDN subscribers via a primary rate access (PA) to ISDN-PABXs or via an ISDN basic access (BA). In the case of using a 2G GSM MGW, wired ISDN subscribers via a primary rate access (PA) to ISDN-PABXs can also be connected with DSS.1 signaling system.
WLL subscribers (with SS7:BSSAP) can also be connected to the CSC. Fig. 4.109 shows the structure of the DSS.1 signaling system of ISDN subscribers with stationary connection to the CSC or 2G GSM MGW.
Interworking unit SS7 levels ISUP, TUP 7 4 46 L3 3 3 2 1 MTP L2 L1 2 1 OSI layers
SS7
DSS.1
Fig. 4.109 Structure of the DSS.1 signaling system The DSS.1 signaling system (ISDN-D-channel protocol) can be subdivided into 3 OSI layers: Layer 3 (network layer) Implements the current ISDN subscriber signaling. All signaling information for call setup and cleardown and for implementing supplementary services run in layer 3 of the D channel protocol. Layer 2 (data link layer) Implements the error security protocol LAPD, a variant of HDLC. Layer 1 (physical layer)
A50016-D1112-V41-2-7618
DRAFT
Provides the physical layer (bit transmission layer) according to the ITU-T recommendation I.430/I.431. This is the D channel bit rate of 64 kbit/s (primary rate access PA) for
331
Information System
the PABX connection and the D channel bit rate of 16 kbit/s (basic access BA) for the BA connection.
4.14.8
Communication Protocols of the Telecommunication Management Network (TMN)

Communication protocols for O&M connections The TCP/IP communication protocol from Core Network (CN) nodes to Switch Commander (SC) and/or to the Operations Support System (OSS) components The TCP/IP communication protocol with the OSI layer structure is used between the circuit-switched CN nodes and SC and/or OSS in the Telecommunication Management Network (TMN). Fig. 4.110 shows an overview of the communication protocols for the O&M connections in the PLMN between TMN components and the telecommunication network elements indicating the communication protocol (TCP/IP via WAN/LAN) and the user services (CMIP, FTP). The X.25 communication protocol from CN nodes to OSS components The X.25 communication protocol with OSI layer structure is used for communication between some CN nodes and OSS components in the TMN. Fig. 4.110 shows an overview of the communication protocols for the O&M connections in the PLMN between TMN components and the telecommunication network elements indicating the communication protocol (X.25 via WAN) and the user service (CMISE).
LI-IMS
ABC
NMC, DPPS
PCS, SMC
OSS
Q3: TCP/IP (FTP, CMIP) X.25 (TMN interface with CMISE) Q3: TCP/IP (FTP, CMIP)
Q3: TCP/IP (FTP, CMIP)
X.25 (SAS/TMN interface, with CMISE)
SC TMN
Q3:TCP/IP (FTP, CMIP)
CN
GSM MGW
MSC/VLR
EIR
HLR/AC
Fig. 4.110 Communication protocols for the O&M connections of the PLMN with CN nodes
332
DRAFT
A50016-D1112-V41-2-7618
Information System
4.14.8.1
Structure of the TCP/IP or UDP/IP Communication Protocol

Fig. 4.111 shows the structure of the transport control protocol (TCP) or user datagram protocol (UDP)/Internet protocol (IP), implemented e.g., at the Switch Commander (SC) local area network (LAN).
OSI layer Application 7
56 TCP/ UDP
3 2 1
IP Host-tonetwork
Fig. 4.111 Structure of the TCP/IP communication protocol Layer 7 (application layer) Above the transport layer is the application layer. It contains all the higher-level protocols. The early ones include the file transfer protocol (FTP), TELecommunication NETwork (TELNET), simple mail transfer protocol (SMTP) and simple network management protocol (SNMP). The FTP provides a way to move data efficiently from one machine to another. The TELNET provides a remote login or virtual terminal. The SMTP provides the transmission of electronic mail. The SNMP provides the transfer of management informations between network elements and management systems. Layers 6, 5 (presentation and session) These layers are not present in the IP reference model. Layer 4 (transport layer) The layer above the Internet layer in the IP model is usually called the transport layer. It is designed to allow peer entities on the source and destination hosts to carry on a conversation, the same as in the OSI transport layer. There are two possible protocols: User datagram protocol (UDP) - carries PDUs for protocols that do not need a reliable data link (e.g., IP). UDP provides protection against corrupted PDUs. Transport control protocol (TCP) - carries PDUs for protocols that need a reliable data link. TCP provides ow control and protection against lost and corrupted PDUs. Layer 3 (network layer)
A50016-D1112-V41-2-7618
DRAFT
The Internet layer defines an official packet format and protocol called IP (Internet protocol). The job of the Internet layer is to deliver IP packets where they are supposed to
333
Information System
go. Packet routing is clearly the major issue here. For these reasons, it is reasonable to say that the IP Internet layer is very similar in functionality to the OSI network layer. Layer 2 (data link layer) and layer 1 (physical layer) Beyond the Internet layer (layer 3) is a great void. The IP reference model does not really say much about what happens here, except to point out that the host has to connect to the network using some protocol so it can send IP packets over it. This protocol is not defined and varies from host to host and network to network.
4.14.8.2
Structure of the X.25 Communication Protocol

Fig. 4.112 shows the structure of the communication protocol of the O&M interface between the RC and the RAN network elements or the OSS or the CN network elements and some OSS components or SC. The O&M communication protocol is a packetswitched signaling method structured according to the OSI stack and based on the ITUT interface definition X.25.
OSI layers
46 L3 3
L2 L1
2 1
Fig. 4.112 Structure of the X.25 communication protocol Layer 7 (application layer) The following services are available in this layer: File transfer access and management (FTAM) is a le transfer service, e.g., for transfer of call charge les Common management information service element (CMISE) is a dialog service, e.g., for alarm signaling dialog Remote operations service element (ROSE) is a background protocol for opening and maintaining processes running remotely: it is used, e.g., in conjunction with CMISE. Association control service element (ACSE) is a session setup/cleardown protocol and is used e.g., together with FTAM.
334
DRAFT
A50016-D1112-V41-2-7618
Information System
Two servers are also available specially at the Core Network (CN) node to Operations Support System (OSS) interfaces: The TMN interface (in all CN network nodes) controls TMN applications, such as call charge le transfer and hot operations from MSC/VLR to ABC in the OSS, alarm message transfer from Core Network (CN) nodes to the Telecommunication Management Network (TMN) or OSS. The SAS interface (in all HLR/AC network nodes) controls security-relevant data exchange between the personalization center for (U)SIM PCS and the Security Management Center (SMC) in the OSS and the AC , such as exchange of cryptographic keys, security les. Layers 6, 5, 4 (presentation, session and transport layer) Layer 3 (network layer) Complies with the ITU-T interface definition X.25 and transmits the O&M signaling information. Layer 2 (data link layer) Implements the fault protection protocol for X.25, LAPB (or ISO 7776). Layer 1 (physical layer) Complies with the ITU-T interface definition X.21/X.21. Layers 3 to 1 are defined for the transmission of an O&M communication protocol with the packet-switched data network (PSDN).
A50016-D1112-V41-2-7618
DRAFT
335
Information System
5
(U)SIM 3GPP A2BS AAL1 AAL2 AAL5 ABC ACL ACM ACSE AKA AMA AMP AMR AMR AMUX AoC AP APS ARQ ASCI ASN.1 ATCO ATI ATM ATM ATSI BAP BC BCF BCIE BCSM BDG BICC BNE BSSAP
Abbreviations
(UMTS) Subscriber Identity Module Third Generation Partnership Project AAL2 Break Server ATM Adaptation Layer 1 ATM Adaptation Layer 2 ATM Adaptation Layer 5 Accounting and Billing Center (for charging/accounting management) Access Control List Access Control Module Association Control Service Element Authentication and Key Agreement Automatic Message Accounting ATM Bridge Processor Adaptive Multi Rate Adaptive Multi-Rate (transcoder) Access Multiplexer Advice of Charge Application Part Application Program System Automatic Repeat Request Advanced Speech Call Item Abstract Syntax Notation Number One Automatic Test and Conference Unit for LTG Any Time Interrogation Any Time Modification Asynchronous Transfer Modus Any Time Subscription Interrogation Base Processor Bearer Capability Bearer Control Function Bearer Capability Information Element Basic Call State Model Bus Distributor module Bearer Independent Call Control Backbone Network Element Base Station System Application Part Base Station System Management Application Part
BSSMAP
336
DRAFT
A50016-D1112-V41-2-7618
Information System
CAC CAMEL CAP CAP CB CBC CBCH CBR CC CCBS CCC CCF CCG CDR CF CFNRc CFU CGI CGP CITA CLIP CM CM CMIP CMISE CMM CMY CNcs CNps COLP CP113 CPH CPT CR CRN CS CS CSE
Carrier Access Code Customized Application for Mobile Network Enhanced Logic Call Processor CAMEL Application Part Cell Broadcasting Call Bearer Control Cell Broadcasting Channel Constant Bit Rate Country Code Call Completion to Busy Subscriber Customer Care Center Call Contol Function Central Clock Generator Call Detail Record Call Forwarding Call Forwarding on mobile subscriber Not Reachable Call Forwarding Unconditional Global Cell Identifier Charging Gateway Protocol Cell Identification Timing Advance Calling Line Identification Presentation Configuration Management Connection Management Common Management Information Protocol Common Management Information Service Element Channel Mode Modify Common Memory Circuit-Switched Domain of Core Network Packet-Switched Domain of Core Network Connected Line Presentation Identification Coordination Processor 113 Call Party Handling Code Point Core Router Call Reference Number Capability Set
A50016-D1112-V41-2-7618
DRAFT
Circuit-Switched CAMEL Service Environment
337
Information System
CSI CS-MGW CT CTL CUG DAOC DAS DCME DEC DES DiffServ DIU240 DLU DLUC DMTAP DPC DPPS DSS.1 DSU DTAP DTM DTMF E1 E-CITA EFR EM EM eMLPP eMLPP E-OTD ER EWSD FAC FNUR FS FTAM FTN
CAMEL Subscription Information Circuit-Switched Media Gateway Call Transfer Craft Terminal Local Closed User Group Direct Access Originating Call Digital Announcement System Digital Circuit Multiplication Equipment Digital Echo Compensator Data Encryption Standard Differentiated Services Digital Interface Unit (for connection of 240 trunks) Digital Line Unit Control for DLU System (in DSU/DLU) Direct Message Transfer Application Part Destination Point Code Data Post-Processing System (for performance management) Digital Subscriber Signaling System No. 1 Digital Service Unit Direct Transfer Application Part Dual Transfer Mode Dual Tone Multi Frequency European Digital Hierarchy Number One (format for digital data transmission) Enhanced Cell Identification Timing Advance Enhanced Full-Rate Element Manager External Memory Enhanced Multi Level Precedence and Preemption Enhanced Multilevel Precedence and Preemption Enhanced Observed Time Difference Edge Router Electronic Switching System Digital Final Assembly Code Fixed Network User Rates Fixed Subscriber File Transfer and Access Management Forwarded-to Number
338
DRAFT
A50016-D1112-V41-2-7618
Information System
FTNO FTP GDC GGSN GMLC GMSC GMT GPN GPRS GPS GPS GRE GSM MGW GSM GT GTP-C GTT HLRc HLRi HOP HOTOP HPLMN HSCSD HSL HTI HTTP IACAMA IACHASTA IACMET IARA ICP IKE IMS IMSI IN INA INAP INI
Forwarded-To-Number File Transfer Protocol General Data Collector Gateway GPRS Support Node Gateway Mobile Location Center Gateway MSC Greenwich Mean Time Group Processor N General Packet Radio Service Global System Positioning Group Processor for STMI Generic Routing Encapsulation GSM Media Gateway Global System for Mobile communication Global Title GPRS Tunnel Protocol - User Plane Global Title Translation HLR/AC classic HLR/AC innovation Hot Operation Protocol Hot Operation charging record Home PLMN High-Speed Circuit-Switched Data High-Speed Signaling Link Host Timeslot Interchange Hypertext Transfer Protocol Interadministration Charging and Statistics with AMA Tickets Interadministration Charging and Statistics Interadministration Charging and Statistics with Meters Interadministration Revenue Accounting Integrated Common Processor card Internet Key Exchange IP Multimedia Subsystem International Mobile Subscriber Identity Intelligent Network Intelligent Network Accounting charging record (for IN subscribers) IN Application Part Intelligent Network Interface card
GSM MSC-S GSM MSC Server
A50016-D1112-V41-2-7618
DRAFT
339
Information System
IOC IOM IOP IP IPLMN IPSC IPsec ISDN ISUP ITR ITU-T IWE:HS KC Ki LA LACOD LAI LAPB LCS LDICC LE LEA
Input/Output Control IO Mux card Input Output Processor Internet Protocol Interrogating PLMN IP Service Card IP Secure (an IETF protocol framework for securing IP transport) Integrated Services Digital Network ISDN User Part IMSI Tracing Record charging record (for hot operation IMSI tracing) International Telecommunication Union, Sector Telecommunication Standardization Interworking Equipment:High Speed Cipher Key (in 3G PLMN) Authentication key Location Area Location Area Code Location Area Identity Link Access Protocol B Location Service Long Distance InComing Call answer rate Local Exchange Law Enforcement Agency
LIC(ATM):Iu Line Interface Card (Asynchronous Transfer Mode):Iu Interface LIC(ATM):Nb Line Interface Card (Asynchronous Transfer Mode):Nb Interface LI-IMS LMN LMSI LMU LRN LTG LTG:BICC Lawful Interception - Interception Management System Location Mark Number Local Mobile Subscriber Identity Location Measurement Unit Location Routing Number Line/Trunk Group LTG for Bearer Independent Call Control
LTG:BSSAP/RANAPLTG for Base Station System Application Part/Radio Access Network Application Part LTG:CAP LTG:ISUP LTG:MAP LTG for CAMEL Application Part LTG for ISDN User Part LTG for Mobile Application Part
340
DRAFT
A50016-D1112-V41-2-7618
Information System
LTGN LTGP LTU:S LTZ LUP M3UA MAP MB MC MCR MCRI M-CSI MDD MH MIC MM MMC MMC MML MNC MOC MOD MO-LR MP:AAL2 MP:OAM MP:OAMD
Line/Trunk Group N Line/Trunk Group P Line/Trunk Unit:Supplementary Local Time Zone Location Area Update MTP-3 User Adaptation Layer Mobile Application Part Message Buffer Monitoring Center Mobile Call Record Mobile Call Record Imidiate Printout charging record Mobility Management Notification - CAMEL Subscription Information Magnetic Disk Device Message Handler Mobile Intern Call (mobile-to-mobile call, intra MSC) Mobility Management Mobile Country Code Mobile to Mobile Call (inter MSC) Man-Machine Language Mobile Network Code Mobile Originated Call Magneto-optical Disk Mobile Originating Location Request Main Processor:ATM Adaptation Layer 2 Main Processor:Operation, Administration and Maintenance Main Processor:Accounting Output processing
MP:RANAP/BCFMain Processor:RANAP/Bearer Control Function MP-EN MP-IO MPLS MPLS MP-SA MP-SA MSC MSC-S MSISDN Main Processor - Ethernet (board type) Main Processor - Input Output processing (board type) Multi Protcol Label Switching Multi Protocol Label Switching Main Processor - Stand Alone Main Processor - Stand Alone (board type)
A50016-D1112-V41-2-7618
DRAFT
MSC Server Mobile Subscriber ISDN Number
Mobile-services Switching Center
341
Information System
MSP MSRN MTC MT-LR MTP MTP3 MTP3-B MUST MUX NDC NEM NITZ NMC NNI NP O-CSI ODB OPC ORECF ORLCF ORMMC OSB OTDOA OTDOA PABX PCR PCS PCS PDH PIC PLMN PNR PPS PPSC PRCID PRN PS PSTN PTT PVC
Multiple Subscriber Profile Mobile Station Roaming Number Mobile Terminated Call Mobile Terminating Location Request Message Transfer Part Message Transfer Part Level 3 Message Transfer Part 3 - B Multiple Short Message Transactions Multiplex National Destination Code Network Element Manager Network Identity and Time Zone Network Management Center (e.g., for fault management) Network Node Interface Number Portability Originating - CAMEL Subscription Information Operator Determined Barring Origination Point Code Optimal Routing of Early Call Forwarding Optimal Routing of Late Call Forwarding Optimal Routing of Mobile-to-Mobile Call Operator Specific Barring Observed Time Difference Of Arrival Pbserved Time Difference of Arrival Private Automatic Branch Exchange Peak Cell Rate Personalization Center for (U)SIM Policy Control Server Plesiochronous Digital Hierarchy Preselected Interexchange Carrier Public Land Mobile Network Ported Number Range PrePaid Service PrePaid Service Center Partial Record Correlation Identity Provide Roaming Number Packet-Switched Public Switched Telephone Network Press-to-Talk Permanent Virtual Channel
342
DRAFT
A50016-D1112-V41-2-7618
Information System
PVC PVP QoD QoHR QoR QoS RA RAA RANAP RAND RCF RCH RLC RNCMAP ROSE RSUC RSZI RTI RTP SAAL SAI SAS SCCP SCI SCP SCUDIF SDCCH SDDPFC SDH SDL SEE SGSN SI SINAP SIP SLMD SLPP SLR SMC SMLC
Permanent Virtual Connection Permanent Virtual Path Query on Digit analysis Query on HLR Release Query on ISUP Release Quality of Service Rate Adaptation Rate Adaptation, using the A-TRAU format Radio Access Network Application Part Random Number Reason for Call Faliure Resume Call Handling Release Message Radio Network Controller Management Application Part Remote Operations Service Element Remote Switching Unit Controller Regional Subscription Zone Identity Remote Timeslot Interchange Real Time Protocol Signaling ATM Adaptation Layer Service Area Identifier Secure Application Service Signaling Connection Control Part Subscriber Controlled Input Service Control Point Service Change and UDI Fallback Stand-alone Dedicated Control Channel Subscriber Dependent Digit Processing and Feature Control Synchronous Digital Hierarchy Specification and Description Language Script Execution Environment Serving GPRS Support Node Service Indicator SIEMENS Application Part Session Initiation Protocol Subscriber Line Module Digital Subscriber Location Privacy Profile
A50016-D1112-V41-2-7618
DRAFT
SGSN Location Register Security Management Center Serving Mobile Location Center
343
Information System
SMP SMS MT SMS SMSC
Service Management Point Short Message Service Mobile Terminated Short Message Service Short Message Service Center
SMS-GMSC Short Message Service Gateway MSC SMS-IWMSC Short Message Service Interworking MSC SMTP SN SN SNMP SPC SPR SPVP SRES SRF SRI SS SS7 SSCF SSCOP SSNC SSP STC STM-1 STM1I STMI STP SVC SVP TAC TAF T-BCSM TBF TC TCAP TCH TCP T-CSI TDM Simple Mail Transfer Protocol Subscriber Number Switching Network Simple Network Management Protocol Signaling Point Code Signaling Processing Routing Soft Permanent Virtual Path Signed Response Specialized Resource Function Send Routing Information Supplementary Service Signaling System No. 7 Service Specific Convergence Sublayer Service Specific Connection Oriented Protocol Signaling System Network Control Service Switching Point Signaling Transport Converter Synchronous Transport Module Level 1 (155.520 Mbit/s) STM-1 Interface STM-1 Interface Integrated Signaling Transfer Point Switched Virtual Connection Switched Virtual Path Type Approval Code Terminal Adapter Function Terminating - Basic Call State Model Temporary Block Flow Transaction Capabilities Transaction Capabilities Application Part Traffic Channel Transport Control Protocol Terminating CAMEL Subscripton Information Time Division Multiplex
344
DRAFT
A50016-D1112-V41-2-7618
Information System
TDP TELNET TFO TIF-CSI TIF-CSI TLLI TMSC TRAU TrFO TSC TSCD TSI TSIM TSLA TTTP TUP UCB UDP UI UID UMTS UP USIM USSD USSD-CSI UUS VCC VLR VMS VMSC VMSC VNO VoIP VPLMN VPN VT-CSI WAP WLL
Trigger Detection Point TELecommunication NETwork Tandem Free Operation Translation Indicator Flag - CSI Translation Info Flag - CAMEL Subscription Information Temporary Logical Link Identity Transit MSC Transcoding and Rate Adaptation Unit Transcoder Free Operation TRAU Server Card TRAU Server Card, Type D Timeslot Interchange Timeslot Interchange Module Time Slots on the A-Interface Transfer to Third Party Telephone User Part USSD Call Back User Datagram Protocol User Interaction User-Interactive Dialog Universal Mobile Telecommunication System User Part User Services Identity Module Unstructured Supplementary Service Data Unstructured Supplementary Service Data CSI User-to-User Signaling Virtual Channel Connection Visitor Location Register Voice Mail Service Visited MSC Voice Mail Service Center Virtual Network Operation Voice over Internet Protocol Visited PLMN Virtual Private Network VMSC Terminating - CAMEL Subscription Information Wireless Application Protocol Wireless Local Loop
A50016-D1112-V41-2-7618
DRAFT
345
Information System
XY
Service Number
346
DRAFT
A50016-D1112-V41-2-7618

V 041

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

V 041

Загружено:

Авторское право:

Доступные форматы

Information

System System Description CN GSM/UMTScs

System Description CN GSM/UMTScs

Important Notice on Product Safety

Copyright (C) Siemens AG 2005.

System Description CN GSM/UMTScs

System Description CN GSM/UMTScs

System Description CN GSM/UMTScs

System Description CN GSM/UMTScs

System Description CN GSM/UMTScs

System Description CN GSM/UMTScs

System Description CN GSM/UMTScs

Fig. Fig. Fig. Fig. Fig.

2.2 2.3 2.4 2.5 2.6

System Description CN GSM/UMTScs

System Description CN GSM/UMTScs

Fig. 4.45 Fig. 4.46

System Description CN GSM/UMTScs

Fig. Fig. Fig. Fig.

4.75 4.76 4.77 4.78

Fig. 4.91 Fig. 4.92 Fig. 4.93

Fig. Fig. Fig. Fig. Fig.

4.95 4.96 4.97 4.98 4.99

Fig. 4.100 Fig. 4.101 Fig. 4.102

System Description CN GSM/UMTScs

System Description CN GSM/UMTScs

Tab. 4.10 Tab. 4.11

System Description CN GSM/UMTScs

1 Overview of System Description

Use of the individual system description documents

System Description CN GSM/UMTScs

System Description CN GSM/UMTScs

Scope of the CN GSM/UMTScs Description

System Description CN GSM/UMTScs

2 System Architecture of the Circuit-Switched Domain of the Core Network (CNcs)

Element managers (EMs) within Telecommunication Management Network (TMN) RC SC

Core Network (CN) Circuit-switched domain TMSC GMSC

Packet-switched domain CG Ga GGSN/IPS Go PCS SCP Gq Gi to ABC

2G Radio Access Network (2G RAN)

System Description CN GSM/UMTScs

Combination of Network Elements of the Core Network (CN) Nodes

Integrated Circuit-Switched CN Nodes

System Description CN GSM/UMTScs

Stand-Alone Circuit-Switched CN Nodes

Hardware Architecture of an MSC/VLR Node

System Description CN GSM/UMTScs

System Description CN GSM/UMTScs

LTG (ATCO) LTG LTG LTG

to VMSC/GMSC (E, Nc interface) LTG:ISUP/BICC, MAP

to GSM MGW (Interface trunks) * *)

MP platform TSCD TSCD

A2BS to VMSC/GMSC (Nb interface)

MP:AAL2 to 3G RAN (Iu,cs interface) ***) LIC(ATM):Iu

MP:ACC MP-SA MP:STATS

***) Only used for 3G part of the node.

Switch Commander (SC) to ABC or hot operation

Block diagram of an integrated MSC/VLR node

System Description CN GSM/UMTScs

System Description CN GSM/UMTScs

SNOPT optical output to SND

Line/trunk group P (LTGP)

GPS STM1I interfaces 16x PCM30 (4 x GPP)