Documente Academic
Documente Profesional
Documente Cultură
DRAFT
Information System
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.
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. 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.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. 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.94
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
14
DRAFT
A50016-D1112-V41-2-7618
Information System
Tab. 1.1
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
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
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
HLR
AC
BTS
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
2.1.1
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.
2.2
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
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
A2BS
MP:RANAP/BCF
ASN
LIC (ATM):Nb
MP:SLT
MP:OAM
TCP / IP
MP:SM
MP:OAMD TCP / IP
Fig. 2.2
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
16x PCM30
SDC to SNB
LTU:S
Fig. 2.3
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.
STM-1
SDC to SNB
LTU:S
Fig. 2.4
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
Fig. 2.5
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
TSI
RSUC
MH
DIU240
DIU240
DIU240
DIU240
DIU240
DIU240
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
signal distribution
Fig. 2.7
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
signal distribution
Fig. 2.8
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
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
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.
IOP 0
IOP
IOP 15 0
IOP
IOP
IOP 15 SSNC
BAP0
BAP1
CAP0
CAPn
IOC0
IOC1
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
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
2 Mbit/s TDM
ASN
LIC
MP:SLT
MP:SLT
MP:SM
to ABC
MP:ACC
MP:OAMD
SC
MP:OAM/STATS
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
digital trunks to optional fixed subscribers connected to GSM MGW (ISDN PA/PABX)
LTG
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
36
DRAFT
Fig. 2.13 shows the interfaces of a GSM MGW and a GSM MSC-S.
A50016-D1112-V41-2-7618
Information System
to fixed subscribers BSC to GSM mobile subscribers to fixed subscribers BSC GSM MGW GSM MGW GSM MGW control interface MSC with GSMMSC-S
BSC
Fig. 2.13
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
TSI
RSUC
MH
DIU240
DIU240
DIU240
DIU240
DIU240
DIU240
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
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)
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
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
40
DRAFT
A50016-D1112-V41-2-7618
Information System
2.5
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.
LTG
LTG to SMSC (Gd interface) LTG to SLMC (Lh interface) LTG CCG SN
MB
CP 113
CP platform
SSNC MP platform
TCP / IP
Fig. 2.16
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
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.
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
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
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.
A50016-D1112-V41-2-7618
DRAFT
45
Information System
Hardware
Operating system
User software
Fig. 2.20
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
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
2.7.2.3
2.7.2.4
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.1.1
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
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
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
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
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
i
3.1.4
In this software version, the GMSC for a 3G case corresponds to an ordinary 2G GMSC.
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.
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
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
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
Wired ISDN subscribers The CN allows wired ISDN subscribers to be connected to a Combined Switching Center (CSC) (Fig. 3.1).
EIR
Fig. 3.1
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
BA
BA/P A
PA
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
BA
BA/P A
PA
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
67
Information System
BA
BA/P A x x x x x x
PA
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
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
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.
3.3.1
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
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
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
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
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
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
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
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
Fig. 3.4
3.3.5.2
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
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
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
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
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
i 4.1
The network functions in the packet-switched domain are described in the System Description, register GPRS/UMTSps.
4.1.1
A50016-D1112-V41-2-7618
DRAFT
89
Information System
A/Iu interface (separate signaling connections, that is, in 3G case RANAP instances per service domain)
MS
Fig. 4.1
4.2
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
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
A50016-D1112-V41-2-7618
DRAFT
93
Information System
RAN
PSTN/ISDN/ PLMN
TMSC
AAL2
BICC
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
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
TDM
Other PLMN
2G RAN
Fig. 4.5
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
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.
MSC II (MSC-S)
2G RAN
Fig. 4.6
4.3.2.2
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
Fig. 4.7
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
2G RAN
PSTN/ISDN/ PLMN
BNE
BNE
BNE
Legend: BNE = Backbone Network Element (SDH switch) Physical connections TDM PCM 30 Physical connections TDM STM-1 Logical connections
Fig. 4.8
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
A50016-D1112-V41-2-7618
DRAFT
101
Information System
3G RAN
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
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
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
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
104
DRAFT
A50016-D1112-V41-2-7618
Information System
T/G 3G MSC
AAL2 connections
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
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
ATM node
ATM node
3G MSC
3G MSC or RNC
ATM node
ATM backbone CN
Fig. 4.12
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.
ATM node
ATM node
3G MSC
3G MSC or RNC
ATM node
ATM backbone CN
Fig. 4.13
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.
ER CR
ER
ER
IP backbone CN
Fig. 4.14
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
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
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
TDM
Partner PLMN
TFO *)
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
3G RAN
PSTN/ISDN
2G RAN
Fig. 4.16
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.
ATM
3GVMSC
3G RAN
Partner PLMN
Transcoding
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
#) Partner PLMN
PSTN/ISDN
2G RAN
Fig. 4.17
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
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, ...
4.4.1
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 n
Operator X
SS7 Network 32
Fig. 4.18
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
MTP
Fig. 4.19
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
A50016-D1112-V41-2-7618
DRAFT
117
Information System
4.5.1
RAN elements
RAN CN
Called subscriber 3 LE
VLR
MSC (GMSC)
118
DRAFT
Fig. 4.20
A50016-D1112-V41-2-7618
Information System
4.5.2
A50016-D1112-V41-2-7618
DRAFT
119
Information System
PLMN
RAN elements
7 RAN CN
6 VLR MSC
4 HLR
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
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.
RAN elements
RAN elements
10
VLR2
MSC2
4 3 HLR 5
PLMN
Fig. 4.22
A50016-D1112-V41-2-7618
DRAFT
121
Information System
4.5.4
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
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
VPLMN-A/IPLMN (VMSC-A/GMSC-A)
VPLMN-B (VMSC-B/VLR-B)
Fig. 4.25
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).
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.
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
Fig. 4.26
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
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.
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
Country Y
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
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
VMSC/VLR-B
6; 7 Country Y 4
HLR-B
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
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
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
Fig. 4.31
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
Recipient network
Fig. 4.32
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.
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
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
MSC/VLR
GMLC
LCS client
Um interface
Abis interface
A interface
Lg interface
Le interface
Fig. 4.35
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
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
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
BTS 5 5
LCS client
Fig. 4.37
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
2 9 GMLC 1
LCS client
Fig. 4.38
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
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
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
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
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
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
4.5.11
154
DRAFT
Tab. 4.4 Circuit pool types
A50016-D1112-V41-2-7618
Information System
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)
Tab. 4.4
4.5.12
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
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
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
Modem RA (Codec)
Network node
Modem
R interface
Radio interface
A interface
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
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
Network node
RA
R interface
Radio interface
A interface
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
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
A interface
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
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
A interface
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.
MS Data terminal MT
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
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
TRAC
IWF
Radio interface
Abis interface
Asub interface
A interface
Fig. 4.47
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
2G RAN
MSC
Fig. 4.48
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
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
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
MSC (with IWF) (in the CN) Fax G3 (with modem) PSTN/ISDN (Fixed network)
Fax G3
MT
User protocol
FA
R interface
Radio interface
A interface
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
MT
Network node
R interface
Radio interface
Iu interface
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
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
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
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
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
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
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
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
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):
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
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
180
DRAFT
A50016-D1112-V41-2-7618
Information System
4.6.5
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
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
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
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
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
MSC/VLR
RAN
Fig. 4.56
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
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
Fig. 4.57
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
4.7.6
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
MSC/VLR
RAN
special mobile subscriber: Calls to special services free of charge (not charge generation)
Fig. 4.58
4.7.7
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
4.7.10
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
4 10 M-SSP 1
2, 3 5
SCP
PLMN
Fig. 4.59
4.7.11
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
4 5 M-SSP 1
SCP
3 4 PLMN 5
Fig. 4.60
4.7.12
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
A50016-D1112-V41-2-7618
DRAFT
205
Information System
4.8
4.8.1
206
DRAFT
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
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
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
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
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
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
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
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
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
4.8.2
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
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
1 RAN RAN
1 Radio interface
MS
Fig. 4.66
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
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
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
Location update accept sent Gs associated Location update accept received Gs LA update
Paging sent
Fig. 4.67
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
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
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
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.
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
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
Fig. 4.69
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
BSC (Manuf. A)
BTS 900 MHz MSC Intra-MSC Multiband Handover BTS 1800 MHz
BSC (Manuf. A)
MSC
BSC (Manuf. B)
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
230
DRAFT
A50016-D1112-V41-2-7618
Information System
4.8.5.3
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
DRNC
MSC
SRNC
Fig. 4.71
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
MSC-A
SRNC
Fig. 4.72
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
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
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
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.
serving BSC
2G/3G MSC
target SRNC
Fig. 4.75
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
target BSC
3G/2G MSC
serving RNC
Fig. 4.76
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
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)
serving BSC
Fig. 4.78
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
2G(/3G) MSC-B
target BSC
(MAPv3) E interface
2G(/3G) MSC-A
serving BSC
Fig. 4.79
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
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
serving RNC
Fig. 4.81
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)
(MAPv3) E interface
3G(/2G) MSC-A
serving RNC
Fig. 4.82
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
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
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
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
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
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
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
4.8.6.3
A50016-D1112-V41-2-7618
DRAFT
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
CN affected
no ---
yes Equivalent PLMN list National/flexible roaming 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
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
Fig. 4.85
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
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
4.8.9
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
4.8.11
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
258
DRAFT
A50016-D1112-V41-2-7618
Information System
4.8.13
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
4.9.1
4.9.2
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
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
4.10.5
4.10.6
4.10.7
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
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)
(2)
SS7
(2) ISDN/PSTN
PLMN RAN
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
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
RAN
RAN
CN, CS domain
Fig. 4.87
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
GSM MGW
Sidedoor trunks
CN, CS domain
Fig. 4.88
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
GSM MGW
Called subscriber
SCP/CSE IN/ CAMEL only signaling signaling and traffic not used trunks
Fig. 4.89
4.11.1.1
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
276
DRAFT
A50016-D1112-V41-2-7618
Information System
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
Backdoor trunks
Interface trunks
Fig. 4.90
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)
2G BSC
3G RNC
2G BSC
GSM MGW
GSM MGW
Called subscriber LE
Backdoor trunks
Interface trunk
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
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
Fig. 4.92
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.
GMSC
To ISDN/PSTN (ISUP)
RNC
Iu interface (RANAP)
internal
internal
Iu interface (AAL2/PVC
CSMGW
Nb interface (AAL2/PVC)
CSMGW
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
GMSC
To ISDN/PSTN (ISUP)
RNC
Iu interface (RANAP)
internal CSMGW
Iu interface (AAL2/PVC
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
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
4.12.3.3
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
CN, CS domain
3G RAN Iu
3G VMSC
3G VMSC
Iu
3G RAN
TrFO for mobileto-PSTN call: compressed speech until the edge of the PLMN
PSTN/ISDN/ PLMN
Fig. 4.95
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
TSCD
TSCD
A2BS
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
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.
VMSC
VMSC
VMSC
VMSC
CN, CS domain
CN, CS domain
Fig. 4.97
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
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
A50016-D1112-V41-2-7618
DRAFT
293
Information System
4.13.1
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
4.13.3
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
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
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
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
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
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
302
DRAFT
A50016-D1112-V41-2-7618
Information System
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
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
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
4.13.13
4.13.14
4.13.15
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
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
4.13.18
4.13.19
A50016-D1112-V41-2-7618
DRAFT
309
Information System
4.13.20
4.13.21
4.13.22
4.13.23
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
4.13.25
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
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.
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
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
GMSC
PSTN/ ISDN
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.
RANAP (SM, MM, RM, SMS) BICC AAL2L3 signaling Layer3 SCCP-CO
MTP3-B
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
SMS-IWMSC/ SMS-GMSC
SCP/CSE (IN/CAMEL)
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
SS7 levels
TCAP
46 SCCP
3 2 1
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 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
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
PMM/SM/RM/SMS
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
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
2 ATM 1 SDH/PDH
326
DRAFT
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 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
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
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
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
LI-IMS
ABC
NMC, DPPS
PCS, SMC
OSS
Q3: TCP/IP (FTP, CMIP) X.25 (TMN interface with CMISE) Q3: TCP/IP (FTP, CMIP)
SC TMN
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
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
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
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
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
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