MSC - HLR Service Guild

411-2231-827
GSM
MSC/HLR
Services Guide
GSMR02 Standard 02.05 September 2001
GSM
MSC/HLR
Services Guide
Document number: 411-2231-827 Product release: GSMR02 Document version: Standard 02.05 Date: September 2001
Copyright Country of printing Confidentiality Legal statements Trademarks
Copyright 19992001 Nortel Networks, All Rights Reserved Printed in the United States of America NORTEL NETWORKS CONFIDENTIAL
The information contained herein is the property of Nortel Networks and is strictly confidential. Except as expressly authorized in writing by Nortel Networks, the holder shall keep all information contained herein confidential, shall disclose it only to its employees with a need to know, and shall protect it, in whole or in part, from disclosure and dissemination to third parties with the same degree of care it uses to protect its own confidential information, but with no less than reasonable care. Except as expressly authorized in writing by Nortel Networks, the holder is granted no rights to use the information contained herein. Information is subject to change without notice. Nortel Networks reserves the right to make changes in design or components as progress in engineering and manufacturing may warrant. This equipment has been tested and found to comply with the limits for a Class A digital devl of the FCC Rules, and the radio interference regulations of the Canadian Department of Communications. These limits are designed to provide reasonable protection comply with the limits for a Class A digital devl of the FCC Rules, and the radio interference regulations of the Canadian Department of Communications. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses and can radiate radio frequency energy. If not installed and used in accordance with the instruction manual, this equipment may cause harmful interference to radio communications. Operations of this equipment in a residential area is likely to cause harmful interference in which case, the user will be required to correct the interference at his own expense.
ii
Nortel Networks Confidential
* Nortel Networks, the Nortel Networks logo, the Globemark HOW the WORLD SHARES IDEAS, and Unified Networks are trademarks of Nortel Networks. DMS, DMS-MSC, DMS-HLR, DMS-100, and NORTEL are trademarks of Nortel Networks. GSM is a trademark of France Telecom. Trademarks are acknowledged with an asterisk (*) at their first appearance in the document.
411-2231-827
Standard
02.05
September 2001
iii
Publication history
September 2001 Version 02.05, Standard. This standard release documents the GSM-R functionalities supported by the GSM-R Phase 02 network. This release also contains the corrections made because of comments received during two technical reviews of the document. November 2000 Version 02.04, Preliminary. This preliminary release contains corrections made during a technical review of the document. October 2000 Version 02.03, Preliminary. This preliminary release contains corrections made during a technical review of the document. October 2000 Version 02.02, Preliminary. This preliminary release documents the GSM-R functionalities supported by GSM-R Phase 02 network. This release also adds appendices on the following topics: GSM11 features used by GSM-R02 August 2000 Version 02.01, Draft. This draft release documents the GSM-R functionalities supported by the GSM-R Phase 02 network. The GSMR02 functionalities include enhanced GSMR01 functionalities plus the following additional functionalities: HLR one-night process Data tables used to set up GSM-R features OPARMS used by GSM-R features Log reports used by GSM-R features OMs used by the GSM-R features
GSM
MSC/HLR Services Guide GSMR02
iv
Publication history
September 1999
Access Matrix Call Forwarding to Functionally Structured Numbers Integrated Acknowledgement Center (IAC) Fast Call Setup
Version 01.01, Draft. This draft release documents the GSM-R functionalities supported by the GSM-R Phase 01 network. These functionalities include GSM-R numbering plan Voice Broadcast Service (VBS) Voice Group Call Services (VGCS) enhanced Multi-level Precedence and Pre-emption (eMLPP)
411-2231-827
Standard
02.05
September 2001
Contents
About this document
Audience for this document xi Organization of this document xi Software release applicability xii Related documents xii Software release applicability xiii
1
xi
Delta information
xxxv
GSM11 functionality information xv DMS-HLR support for phase 2 MS-initiated and network-initiated USSD xv IN VLR logic migration xviii MSC changes for end-to-end subaddress support xix GSMR01 to GSMR02 delta information xx Mated Pair Disaster Standby for GSM-R xxi HLR Call Forwarding to Functionally Structured Number xxii USSD Enhancement for HLR xxiii enhanced Multi-level Precedence and Preemption Service for Mobile Subscribers Phase 2 xxiv Access Matrix for GSM-R xxv enhanced Multi-Level Precedence/Preemption Fast Call Setup and Immediate Setup xxvi Integrated Acknowledgment Center on DMS-MSC xxvii Voice Group Call Service (VGCS) and Voice Broadcast Service (VBS) Relay Enhancements xxviii VGCS Dispatcher Talk Control and Mute/Unmute Service xxx VBS/VGCS Inter-MSC Handover xxx Voice Group Call Service (VGCS) Emergency Call xxxi Dispatcher Disconnect xxxii Five Dispatchers in a VGCS and VBS xxxiii Connect Indication Enhancement xxxiii MAP Enhancements for Inter-MSC Group Calls xxxiv Delta tables xxxv
Overview of the GSMR network

Purpose of the GSM-R network 1-1 History 1-1 The European Commission and MORANE The EIRENE specification 1-2 GSM 1-1
1-1
vi
Contents Capabilities of the GSM-R network 1-2 Benefits of the GSM-R network 1-3 Frequency band of the GSM-R network 1-3
Network and switching components

Mobile services switching center (DMS-MSC) 2-1 DMS-MSC functions 2-1 Visitor location register (VLR) 2-4 VLR functions 2-5 Home location register (DMS-HLR) 2-5 DMS-HLR functions 2-6 Types of data stored in the DMS-HLR 2-7
2-1
GSM-R functionalities
GSM-R functionality 3-1 GSM-R numbering plan 3-2 Access Matrix 3-3 Functional Addressing 3-7 Location Dependent Addressing 3-18 Call Forwarding to Functionally Structured Numbers 3-21 Voice Broadcast Service (VBS) 3-27 Voice Group Call Service (VGCS) 3-62 Integrated Acknowledgement Center (IAC) 3-105 enhanced Multi-level Precedence and Pre-emption (eMLPP) 3-112 Fast Call Setup 3-127 Nature of Address (NOA) Format Customization 3-136
3-1
Appendix A: Supported GSM11 features

The GSM10 load A-1 GSM11 functionalities used by GSMR02 A-1 Supported GSM11 functionalities A-1 Unsupported GSM11 functionalities A-3
A-1
Appendix B: DMS-HLR GSMR02 One Night Process

The TABXFR process B-1 ONP data transfers B-1 The EDM method B-1 The PDM method B-2 ONP tables B-2 GSM10 to GSMR02 dump and restore B-2 GSMR01 to GSMR02 dump and restore B-3 GSMR02 to GSMR02 dump and restore B-3 Interactions B-4 Restrictions and limitations B-4
B-1
Appendix C: Data tables used by GSM-R features

411-2231-827 Standard 02.05 September 2001
C-1
Nortel Networks Confidential Table ACSMTRX C-3 Table BSSC2TMR C-6 Table DNROUTE C-9 Table GCAREA C-13 Table GCR C-15 Table GHLRBCA C-19 Table GHLRCUG C-29 Table GHLRBSVC C-34 Table GHLRFAID C-39 Table GHLRFANC C-42 Table GHLRNDSC C-45 Table GHLRPARM C-81 Table GHLRSCF C-82 Table GHLRSSOP C-86 Table GHLRUSSD C-106 Table GHLRVBCA C-109 Table GHLRVGCA C-111 Table GHLRVGS C-113 Table GHLRVLR C-118 Table GHLRXTND C-129 Table LACGID C-132 Table PETSERVS C-134 Table PETSIG C-141 Table SERVCNFG C-150 Table XLAENTRY C-152 Table xxCODE C-156 Table xxHEAD C-166
Contents
vii
Appendix D: Oparms used by GSM-R features

Table GSMVAR D-2 CF_MS_CPC D-2 GSMEIR_NUMBER D-2 GSM_PAGE_RETRY D-3 IAA_GEN_FREQUENCY D-3 MS_CPC D-4 MSCLOC D-4 REPLACE_INTL_ROAM_CLID D-5 REPLACE_MS_CC_DIGITS D-5 USE_HANDOVER_DETECT_NTWK_CONN D-5 Table OFCENG D-6 CRS_SUBRU_POOL4_SIZE D-6 GID_DIGITS_LENGTH D-8 MAX_VGS_SUBS_IN_VLR D-8 NCCBS D-9 NO_OF_HIS_CONTROL_BLKS D-10 NO_OF_HIS_DATA_BLKS D-10 NUMBER_OF_BSC_CLSTR_CELL_TIDS D-10 NUMBER_OF_CPIPP_ADDR_PAIR_BLOCKS D-11 NUMBER_OF_DMS_SYSTEM_TIDS D-11
D-1
GSM
viii
Contents
Nortel Networks Confidential NUMBER_OF_FPF_HUGE_AUX_BLOCKS D-11 NUMBER_OF_FPF_LARGE_AUX_BLOCKS D-11 NUMBER_OF_FPF_MEDIUM_AUX_BLOCKS D-11 NUMBER_OF_FPF_SMALL_AUX_BLOCKS D-12 NUMBER_OF_FPF_XLARGE_AUX_BLOCKS D-12 NUMBER_OF_MDM_CONTROL_BLOCKS D-12 NUMBER_OF_MM_TIDS D-12 NUMBER_OF_MOBILE_CLUSTER_TIDS D-13 NUMBER_OF_MS_TIDS D-13 NUMBER_OF_PI_CLIENT_TIDS D-13 NUMBER_OF_PI_OBC_TIDS D-13 NUMBER_OF_RELAY_LOGICAL_TIDS D-14 NUMBER_OF_TLK_HO_MAP_TTIDS D-14 NUMBER_OF_TTID_SERVER_TIDS D-14 Table OFCVAR D-15 DISP_DISC_SEQ D-15 EMLPP_DEFAULT_PRECEDENCE D-15 GSM_VGCS_VBS_ORIG_XLAENTRY D-16 GSM_VGCS_VBS_TERM_XLAENTRY D-16 GSMR_FUNCTIONAL_ADDRESS_ENABLED D-16 HIGH_PRIORITY_CALL D-17 MLPP_PBX_FULL_SUPPORT D-17 MLPP_SERVICE_DOMAIN D-17 PREFERRED_NOA D-17 RAILWAY_ACCESS_CODE D-17 VGCS_DISPATCHER_TALK_CONTROL D-18
Appendix E: Log reports generated by GSM-R features

HLR log reports E-1 GHLR401 E-1 GVLR300 E-9 MSC log reports E-9 GBCS300 E-10 GC6000 E-10 GGCN300 E-11 GMSC301 E-11 GMSC302 E-12 GMSC609 E-13 GMSC612 E-16
E-1
Appendix F: OMs generated by GSM-R features

Group eMLPPSS F-1 Registers F-2 OMSHOW example F-3 Group EVGCS F-3 Registers F-3 OMSHOW F-4 Group GHLRADM3 F-4 411-2231-827 Standard 02.05 September 2001
F-1
Nortel Networks Confidential Registers F-4 OMSHOW F-7 Group GHLRBS F-7 Registers F-7 OMSHOW example F-10 Group GMAPCH2 F-10 Registers F-10 OMSHOW F-11 Group HLRFA F-12 Registers F-12 OMSHOW F-14 OM logic flow or pseudo code F-14 Group MCLUSTER F-22 Registers F-23 OMSHOW example F-25 OM logic flow or pseudocode F-25 Group MSCGCS F-26 Registers F-27 OMSHOW example F-28 Group MSUPLNK F-28 Registers F-28 OMSHOW example F-29 OM Logic Flow or Pseudocode F-29
Contents
ix
Appendix G: Glossary
G-1
GSM
Contents
411-2231-827
Standard
02.05
September 2001
xi
About this document
This publication describes the DMS-mobile switching center (DMS-MSC) and DMS-home location register (DMS-HLR) services provided through the GSM-Railways (GSM-R) Phase 02 network. This document is in a draft state and is subject to changes.
Audience for this document

This publication is applicable for any person involved in the planning, engineering, administration, or maintenance of the GSM-R network.
Organization of this document
This publication consists of the following chapters: Delta information describes the delta information regarding GSM11 functionalities used by GSMR02, lists the functionality changes that occurred from GSMR01 to GSMR02, and provides delta tables that summarize the additions and changes made to data tables, log reports, and operational measurements (OMs). Overview of the GSM-R network introduces the GSM-R network. Network and switching subsystem components discusses the functions and configuration of the DMS-MSC, VLR, and DMS-HLR. GSM-R functionalities describes the GSMR02 functionalities. This chapter also describes how the GSM DMS-MSC and DMS-HLR support these functionalities. Appendix A: Supported GSM11 features discusses the load and GSM11 features used by GSMR02. Appendix B: DMS-HLR GSMR02 One Night Process discusses the necessary DMS-HLR one night process (ONP) support for GSMR02. Appendix C: Data tables used by GSM-R features discusses the data tables used to set up the GSM-R features. Appendix D: OPARMS used by GSM-R features discusses the office parameters (OPARMs) used to set up GSM-R features.
GSM
xii
About this document
Appendix E: Log reports used by GSM-R features discusses the HLR and MSC log reports that provide information specific to GSM-R functionalities. Appendix F: Operational measurements generated by GSM-R features describes the OM groups that provide information specific to the GSM-R functionalities. Appendix G: Glossary defines acronyms and terms associated with the GSM-R products.
Software release applicability

This publication is applicable to the GSMR02 software release. Unless this publication is revised, it also applies to offices that have software releases greater than GSMR02.
The Nortel Networks product development process allows for development subsequent to the initial release of a product. Changes to the MSC subsequent to this release will be described either by altering this Product Specification, or by accepting Feature Specification Documents from Nortel Networks.
Related documents
The following documents are recommended as references: PB-GSMR02-DOC GSMR02 DMS-MSC and DMS-HLR Documentation Anomalies PB-GSMR02-MRA GSMR02 DMS-MSC MRA Documentation GSM10 DMS-MSC GSM Mobile Switching Services Center Product Specification Nortel Networks GSM Software Engineering Guide Nortel Networks GSM Hardware Engineering Guide SB003138 GSM-Rail Follow-Me SSD 411-2231-001 DMS-MSC/HLR Product Documentation Directory 411-2231-010 DMS-MSC Product Guide 411-2231-100 MSC Network and Switching Subsystem Description 411-2231-195 MSC Software Delta for Planners 411-2231-310 CCS7 Application Guide 411-2231-455 MSC Office Parameters Reference Manual 411-2231-495 MSC Customer Data Schema Reference Manual 411-2231-515 MSC Output Reports (Logs) Reference Manual 411-2231-809 MSC Maintenance Administration Position Commands
411-2231-827
Standard
02.05
September 2001
About this document
xiii
411-2231-815 MSC Operational Measurements Reference Manual 411-2831-151 DMS-HLR Customer Data Schema Reference Manual 411-2831-809 DMS-HLR MAP Commands and Procedures Reference Manual
Software release applicability

This publication is applicable to the GSMR02 software release. Unless this publication is revised, it also applies to offices that have software releases greater than GSMR02.
The Nortel Networks product development process allows for development subsequent to the initial release of a product. Changes to the MSC subsequent to this release will be described either by altering this Product Specification, or by accepting Feature Specification Documents from Nortel Networks.
GSM
xiv
About this document
411-2231-827
Standard
02.05
September 2001
xv
Delta information
This chapter briefly describes the delta information regarding the following GSM11 functionalities used by GSMR02
lists the functionality changes that occurred from GSMR01 to GSMR02 provides delta tables that summarize the additions and changes made to data tables, log reports, and operational measurements (OMs)
GSM11 functionality information

GSMR02 requires the following functionalities from the GSM11 load: DMS-HLR Support for Phase 2 MS-initiated and Network-initiated USSD IN VLR Logic Migration MSC Changes for End-to-End Subaddress Support
DMS-HLR support for phase 2 MS-initiated and network-initiated USSD This functionality enhances the DMS-HLR to support the following operations associated with Unstructured Supplementary Service Data (USSD): Process_Unstructured_SS_Request (PUSSR) Unstructured_SS_Request (USSR) Unstructured_SS_Notify (USSN)
The above operations provide support for mobile station-initiated and network-initiated USSD. Through the above operations the mobile station and the network can communicate with the HLR using USSD GSM MAP Phase 2 signalling. Data schema This functionality adds two new tables (table GHLRUSSD and table GHLRXTND). This functionality also modifies tables GHLRSCF, GHLRVLR, GSMTIMRS, and GHLRPARM.
GSM
xvi
Delta information
Table GHLRUSSD determines how to process the USSD string received in a PUSSR. Table GHLRUSSD has the following fields: USSD_STR contains a USSD string that is mapped to a supplementary service or an operation supported by the HLR. When the HLR receives a USSD string in a PUSSR request, the HLR tries to match the string to one of the strings datafilled in the USSD_STR field of each tuple. Once a match is found, the remaining tuples fields determine the outcome. SSCODE contains a symbolic name for a supplementary service supported on the HLR through USSD. SSOPER contains a valid supplementary service (SS) operation. PROCSSAT is an optional field that consists of two subfields NODE_SEL and NODEADDR.
Tables GHLRSCF and GHLRXTND must be datafilled before table GHLRUSSD. Table GHLRXTND associates a symbolic name with the actual E.164 network address of an external node. It also records the highest common version supported by the HLR and external node for the network unstructured (NUS) application context. This information is used when the HLR initiates a service request to the external node to determine which version of the AC to use when establishing the dialogue. Table GHLRXTND has the following fields: XTND_NAME holds the symbolic names of various external node addresses. XTND_NUMBER contains the corresponding E164 address of the external node whose symbolic name is contained in the XTND_NAME field. NUS_AC contains the version of NUS AC used by the HLR for this external node. EVAL_NUS contains the evaluate NUS AC flag. This flag is used to indicate if the NUS AC version is required to be updated to the latest common highest version supported by both HLR and the external node. This field is reset periodically by the AC audit to Y. AC_AUDIT specifies if the AC version audit is allowed to set the value of NUS_AC to hlr_max and the evaluate AC flags (that is, EVAL_NUS) to Y for this entry. This is to provide system administrator the option to turn off the AC audit for an individual external node.
A symbolic address for an external node must be datafilled in GHLRXTND before that symbolic address can be used in GHLRUSSD.
411-2231-827
Standard
02.05
September 2001
Delta information
xvii
Table GHLRSCF associates a symbolic name with the actual E.164 network address of the gsmSCF. This feature does not change any existing function of this table but adds additional fields to record the highest common version supported by the HLR and gsmSCF for the NUS application context. The added fields include NUS_AC contains the version of NUS AC used by the HLR for this gsmSCF. EVAL_NUS contains the evaluate NUS AC flag. This flag is used to indicate if the NUS AC version is required to be updated to the latest common highest version supported by both HLR and gsmSCF. AC_AUDIT specifies if the AC version audit is allowed to set the value of NUS_AC to hlr_max and the evaluate AC flags (that is, EVAL_NUS) to Y for this entry. This is to provide system administrator the option to turn off the AC audit for an individual gsmSCF.
A symbolic address must be datafilled in table GHLRSCF before that address can be used in tables GHLRCAML or GHLRUSSD. Table GHLRVLR contains information about the VLRs within the same PLMN or a different PLMN, or another PLMN considered as a single entity with which the DMS-HLR communicates. This feature does not change any of the existing functionality of this table but adds the NUS_AC and EVAL_NUS fields to store the highest AC version currently supported by the the HLR and VLR. Table GSMTIMRS contains field HLR. This field is extended to cover timing information for new messages. The following timers are added to field HLR: T_PUR (Process-UnstructuredSS-Request) T_USR (UnstructuredSS-Request) T_USN (UnstructuredSS-Notify)
Table GHLRPARM is an office parameter table. Within this table, one parameter (AC_MAX_V) is changed and one parameter (MISCSSN) is added. Parameter AC_MAX_V specifies the maximum version for each application context. This parameter now includes an entry for the Network Unstructured SS AC (NUS_AC). This entry specifies the maximum version supported by the HLR for the NUS Application Context. Parameter MISCSSN enables the datafill of the subsystem numbers (SSN) required for CCS7-SCCP requester message routing to the SGSN, gsmSCF and External Node (XTND). Log reports This functionality modifies the following existing logs: GHLR401
GSM MSC/HLR Services Guide GSMR02
xviii
Delta information
GHLR600 GHLR601 GHLR612 GHLR664
GHLR401 logs hourly traffic. This log report was updated to include the operations Process-USS-Request, USS-Request, and USS-Notify and an indication of the USSD acceptance ratio. GHLR664 is a generic log used to indicate a problem with the USSD Resource Monitoring tool. The other log reports were updated to include errors Unknown Alphabet and Call Barred operations PUSSR, USSR and USSN support the NUS application context
Operational measurements This functionality creates OM group HLRUSSDT. The registers in the HLRUSSDT group measure USSD traffic between the HLR and VLR and between the HLR and gsmSCF/external node. Man-machine interface This functionality modified the QVLR command located in the HLRADMIN directory. This command is updated to display the networkUnstructuredSS AC at version 2. Billing This functionality does not make any additions or changes to the billing. IN VLR logic migration This functionality provides the following service interaction enhancements with IN DP2: Removes the restriction of blocking regular call hold or multi-party hold on an active call from an originating mobile to an Intelligent Peripheral (IP). Removes the restriction of blocking multi-party bridging into an active call from a mobile to an IP. Call waiting now is permitted on a mobile actively engaged in a call to an IP.
411-2231-827
Standard
02.05
September 2001
Delta information
xix
This functionality shifts the dependency of IN from Class Of Service (COS) translations to VLR translations for Type II Emergency checking. Finally, this functionality enables the customer to provision numbers (normally classified as Emergency Type II) through VLR translations. Data schema This functionality does not introduce any data schema changes. Log reports This functionality does not add or change any log reports. Operational measurements This functionality does not add or change any OMs. Man-machine interface This functionality does not make any additions or changes to the manmachine interface. Billing This functionality does not make any additions or changes to the GSM-R billing. MSC changes for end-to-end subaddress support This functionality enhances the processing of the subaddressing information elements within the DTAP messaging used between the network GSM MSC BSS
These DTAP messages are used when dealing with mobile-originated and mobile-terminated calls. This functionality is as is described in Mobile Radio Interface, Layer 3 Specification (GSM 04.08 version 5.8.0) and Q.931. The enhancements are made so that end-to-end teleservices receive the routing information required to terminate calls and display status information. The network transparently passes the subaddress information elements in order to enable user defined functionality. The relevant information elements include: Called Party Subaddress Calling Party Subaddress Connected Party Subaddress
GSM
xx
Delta information
Data schema This functionality does not introduce any data schema changes. Log reports This functionality does not add or change any log reports. Operational measurements This functionality does not add or change any OMs. Man-machine interface This functionality does not make any additions or changes to the manmachine interface. Billing This functionality does not make any additions or changes to the GSM-R billing.
GSMR01 to GSMR02 delta information

This section lists the functionality changes that occurred from GSMR01 to GSMR02. GMR02 adds the following functionalities: Mated Pair Disaster Standby for GSM-R
411-2231-827
HLR Call Forwarding to Functionally Structured Number Change in No Activity Timer USSD Enhancement for HLR Enhanced Multi-level Precedence and Preemption Service for Mobile Subscribers Phase 2 Access Matrix for GSM-R Enhanced Multi-level Precedence/Preemption Fast call Setup and Immediate Setup Integrated Acknowledgement Center on DMS-MSC Voice Group Call Service (VGCS) and Voice Broadcast Service (VBS) Relay Enhancements VGCS Dispatcher Talk Control and Mute/Unmute Service VBS/VGCS Inter-MSC Handover VGCS Emergency Call Dispatcher Disconnect Five Dispatchers in a VGCS and VBS Connect Indication Enhancement MAP Enhancements for Inter-MSC Group Calls
02.05 September 2001
Standard
Delta information
xxi
Increased the number of supported cells per group from 20 to 25 VGCS warning Tone
The following paragraphs describe the data schema, log reports, and OM changes made by these functionalities. For a more in depth description of these functionalities, refer to the chapter entitled, GSM-R functionalities. Because some of these functionalities build on existing GSM-R functionalities, the description of the functionalities may be embedded within the description of another functionality. Mated Pair Disaster Standby for GSM-R This functionality provides Mated Pair functionality for DMS-HLR nodes in a GSM-R network. Mated Pair functionality allows the network to cope if a disaster occurs in one HLR. For this functionality, two HLRs are connected as a mated pair. Each HLR acts as a real-time backup for the other HLR. If a disaster occurs, the surviving HLR has the subscriber data required to take over with minimal loss of service to the network. With Mated Pair functionality, the HLR handles two kinds of subscribers: acting subscribers - these are the subscribers to whom the HLR normally provides service standby subscribers - these are the subscribers for whom the HLR acts as a backup
In the event of a disaster, the surviving HLR treats all its subscribers as acting subscribers. Data schema This functionality adds error and warning messages to the existing set of messages for table GHLRVGS. Log reports This functionality does not add or change any log reports. Operational measurements OM group GHLRADM3 pegs the number of subscribers provisioned in table GHLRSSOP. In GSMR01, the following registers were added to the existing GHLRADM3 OM group: EMLPPPR UUS1PR FAPR
xxii Delta information
This functionality updates the above HLR database related OMs if the subscriber has an ASTATUS of acting and the HLR is not in standby out-of-service mode, or the HLR is in a standby stand-alone mode, or the standby functionality is turned off
OM group GHLRBSG pegs the number of subscribers provisioned with VBS and VGCS basic services. In GSMR01, the following registers were added to the existing GHLRBSG OM group: VGS VGCS
This functionality updates the above HLR database related OMs if the subscriber has an ASTATUS of acting and the HLR is not in standby out-of-service mode, or the HLR is in a standby stand-alone mode, or the standby functionality is turned off
Man-machine interface This functionality modifies the DBOMCALC tool. This tool recalculates the database OM groups and countable types. The tool is modified to recognize and support the changes made to the GHLRBSG and GHLRADM3 OM groups. Billing This functionality does not make any additions or changes to the GSM-R billing. HLR Call Forwarding to Functionally Structured Number This functionality allows subscribers to route their calls to chosen Functionally Structured Numbers* (FSN). The FSNs are seen as standard MSISDN numbers by the network, but are seen as functional numbers by calling parties. Data schema This functionality does not add or change any data tables. Log reports This functionality does not add or change any log reports. Operational measurements This functionality does not add or change any OMs.
411-2231-827
Standard
02.05
September 2001
Delta information
xxiii
Man-machine interface This functionality does not make any additions or changes to the manmachine interface. Billing This functionality does not make any additions or changes to the GSM-R billing. USSD Enhancement for HLR This functionality enhances the existing USSD application to add the MSISDN as a new field into the Phase 2 USSD message at the MAP layer. Data schema This functionality does not add or change any data tables. Log reports This functionality does not add or change any log reports. Operational measurements This functionality does not add or change any OMs. Man-machine interface This functionality enhances the HLRTRACE tool to display the new MSISDN field. Figure 2-1 shows a sample display of the modified tool. As a result of its optionality, the field is displayed only if it exists in the message under consideration.
Figure 2-1 Example of the modified HLRTRACE display Ind Inv Process Unstructur IMSI ..................: 456231234567890 ProcessUnstructuredSSRequest ---------------------------USSD Coding Scheme: 0F USSD String Info (7-bit HEX): AA116D04 (8-bit HEX): 2A233423 (ASCII): *#4# ... USSD MSISDN : 6112300001 MSG 10:10:21.860 710
...
Billing This functionality does not make any additions or changes to the GSM-R billing.
xxiv Delta information
enhanced Multi-level Precedence and Preemption Service for Mobile Subscribers Phase 2 This functionality implements the eMLPP supplementary service that provides prioritized call handling service. This enhancement primarily adds preemption capabilities and MLPP interworking. Data schema This functionality modifies table SERVCHFG to enable the network operator to allocate the following for each priority level call on the MSC: call setup class resource preemption capability information
A Txx timer used for VBS and VGCS calls also is added to this table. Refer to the Connection Indication enhancements section. The SERVCHNG tuples cannot be added or deleted. The tuples can only be changed. This functionality also modifies table OFCVAR. The following office parameters are added to this table: HIGH_PRIORITY_CALL MLPP_PBX_FULL_SUPPORT MLPP_SERVICE_DOMAIN NUMBER_OF_PREEMPTION_TIDS
Log reports This functionality does not add or change any log reports. Operational measurements This functionality also adds OM group MLPP. This group contains registers that measure how often pre-emption occurs due to the MLPP service. The following resources can be pre-empted: PSTN trunks TTID trunks
Man-machine interface This functionality does not make any additions or changes to the manmachine interface.
411-2231-827
Standard
02.05
September 2001
Delta information
xxv
Billing When pre-emption occurs, the SS module code is generated and appended to the pre-empted calls billing record. The SS module code captures both the preempting and pre-empted calls precedence level. The pre-empteds billing record may be any of the following records: mobile originated mobile terminated incoming intra-plmn incoming gateway outgoing intra-plmn outgoing gateway
Access Matrix for GSM-R This functionality allows or disallows a call depending on the functions the originator and terminator have within a GSM-R network. The screening is based on the dialed digits and the calling/called parties functional numbers. This functionality is controlled by SOC. Data schema This functionality changes tables PETSERVS and OFCENG adds table ACSMTRX
In table PETSERVS, this functionality adds the option AMSCRN. The AMSCRN option allows the Access Matrix feature to be activated on a per PET trunk basis. If the AM option is datafilled, the Access Matrix check is applied to the specific PET trunk. Table ACSMTRX specifies the Access Matrix used for the Access Matrix feature. Table ACSMTRX uses a two-part key (Call Type (CT) and Function Code (FC)) to access the data tuples. The data tuple contains a boolean value ALLOWED and a list of Call Type and Function Code combinations. The Function Code must be entered as a range (FROMFC and TOFC). The table is initialized with five tuples specifying default permission patterns for each Call Type. These default tuples can be changed but not deleted by the user. Call permission patterns that differ from the ones given by the default tuples are to be added as additional tuples to the table. In table OFCENG, this functionality adds parameter RAILWAY_ACCESS_ CODE. This parameter specifies the railway access code (RAC) of the local
GSM
xxvi Delta information
GSM-R network. This information is necessary for the Access Matrix feature to decide if the Access Matrix check must be performed. Log reports This functionality does not add or change any log reports. Operational measurements This functionality does not add or change any OMs. Man-machine interface This functionality does not make any additions or changes to the manmachine interface. Billing This functionality does not make any additions or changes to the GSM-R billing. enhanced Multi-Level Precedence/Preemption Fast Call Setup and Immediate Setup This feature provides enhancements to the DMS-MSC software to support the following: Fast call setup based on the eMLPP precedence selected or assigned to mobile origination that includes the mobile service, Voice Broadcast Service, and Voice Group Call Service origination. This enhancement is controlled by datafill in table SERVCHNG. Fast call setup based on eMLPP precedence selected by mobile originating party or the ISDN MLPP precedence received in the incoming IAM message that includes only the mobile service termination. This enhancement is controlled by datafill in table SERVCHNG. Fast call setup based on the reception of VBS/VGCS Immediate Setup message. This enhancement is controlled from the mobile originators terminal.
Data schema This functionality does not add or change data schema. Log reports This functionality does not add or change log reports. Operational measurements This functionality adds the following registers to OM group MSCGCS: VGCSIMST - This register pegs every time a Voice Group Call is initiated by a GCC Immediate Setup message VBSIMST - This register pegs every time a Voice Group Call is initiated by BCC Immediate Setup message
411-2231-827
Standard
Delta information
xxvii
Man-machine interface This functionality does not make any additions or changes to the manmachine interface. Integrated Acknowledgment Center on DMS-MSC This optional functionality is responsible for collecting and storing information about high priority calls. This feature is triggered by calls from mobile terminals to a specific number. The captured information is provided by the terminals in the call setup signaling. Data schema This functionality changes the following universal translations tables: AMCODE PXCODE CTCODE FACODE OFCCODE FTCODE ACCODE NSCCODE Note: The changes to these tables are identical. These tables are modified by adding an option to the existing Database Query (DBQ) selector to identify Acknowledgment Calls. The DBQ option is AC. When translations (UXLA) on the called number hits the AC option, the call is identified as an Acknowledgment Call. Then the call is released immediately. Log reports This functionality does not add or change any log reports. Operational measurements This functionality does not add or change any operational measurements. Man-machine interface This functionality does not make any additions or changes to the manmachine interface. Billing This functionality enhances the GSM billing records to capture data about high priority VGCS and VBS calls through the Integrated Acknowledgment Center. The information is stored in an acknowledgment record. An
xxviii
Delta information
acknowledgment record is generated for each Setup message of the Acknowledgement Call received by the Integrated Acknowledgment Center that resides on the DMS-MSC. The acknowledgment records are written to the GHOT billing stream. Figure 2-2 shows an example of an acknowledgement record.
Figure 2-2 Example of an acknowledgement record HEX ID = AA CALL CODE = 016C STUDY IND = 0C CALLING NUM = 2C01000CFFFFFFFFFFFFFFFFF61411000231001C CALLED NUM = 2C01000CFFFFFFF61411000231001C MSCID= 01000CFFFFFFFFF614180700000C GROUP REF = 000001612C FUNCT NUM = 00003026178911101C CALL DURATION = 001200600C PRIORITY CALL CAUSE = 000C RECORD TIME = 921115044730700C REL = 00214755300C PRIORITY LEVEL = 006C HOTBILL = 1C RECORD NUMBER= 0000254C STRUCT CODE = 00020C
Voice Group Call Service (VGCS) and Voice Broadcast Service (VBS) Relay Enhancements This functionality completes the VBS/VGCS functionality in GSMR01 by adding the Relay MSC functionality to the MSC. A group call area may be configured to include cells from up to four MSCs, one being a designated Anchor MSC and the others being Relay MSCs. A user may originate and terminate calls from a Remote MSC. Data schema This functionality changes the following tables: DNROUTE GCR OFCENG
Table DNROUTE is used to datafill temporary DN numbers used for MSRNs and HONs. This functionality adds feature selector GSMGCN. This feature selector is used to process the IAM message sent from the AMSC to the RMSC with the GCN as the address.
411-2231-827
Standard
02.05
September 2001
Delta information
xxix
Table GCR serves as the primary database for the Voice Group Call Service and Voice Broadcast Service. It stores the call attributes per group call references in the MSC. Two fields are added to table GCR: ANCHOR_MSC and RELAY_MSC_LIST. If the MSC is a relay MSC, table GCR shows field ANCHOR_MSC. This field stores the anchor MSCs country code and NDC digits. If the MSC is an anchor MSC, table GCR shows field RELAY_MSC_LIST. This field lists the relay MSCs for the GID. This field is a vector of vectors up to 15 (0 to 9)s. The maximum number of relay MSCs is 3. Table OFCENG has one new office parameter, NUMBER_OF_RELAY_ LOGICAL_TIDS. This office parameter specifies the number of the logical TIDs required on the DMS-MSC for the relay feature software. One TID is required for each relay feature. Since an anchor-MSC supports setting up a group call for three relay-MSCs, therefore, three TIDs are required for each group call. Log reports This functionality adds log report GGCN300. This log report is generated when a group call number cannot be allocated. Operational measurements This functionality changes OM group MSCGCS. OM group MSCGCS captures the usage information of VGCS and VBS services, in particular, the number of times that the service is invoked (successfully and unsuccessfully), and how it is invoked (service subscriber origination, dispatcher origination, or network-initiated group call origination). This functionality adds the following registers to the group: VGCSINVR - This register counts the number of VGCS invocations from the remote MSC. VBSINVR - This register counts the number of VBS invocation from the remote MSC. GCNFAIL - This register counts the number of GCN allocation failures.
These registers were added to distinguish between the anchor MSC and remote MSC. Man-machine interface This functionality does not make any additions or changes to the manmachine interface.
GSM
xxx
Delta information
Billing This functionality does not make any additions or changes to the GSM-R billing. VGCS Dispatcher Talk Control and Mute/Unmute Service This optional functionality designs and implements the dispatcher talk control and mute/unmute service functionality of VGCS for anchor and relay MSCs. This functionality uses the same DTMF receivers (NTX62EA) as the dispatcher disconnect functionality. Data schema This functionality adds tuple DISPATCHER_TALK_CONTROL to table OFCVAR. This tuple has the following fields: ENABLED which defines a function control option. START_TALKING which defines the DTMF tone sequence used by the dispatcher to request talk. END_TALKING which defines the DTMF tone sequence used by the dispatcher to release the talk. GRANT_TONE which defines a warning tone used to notify the dispatcher that the talk request was granted. REJECT_TONE which defines a warning tone used to notify the dispatcher that the talk request was rejected.
Log reports This functionality does not add or change any log reports. Operational measurements This functionality does not add or change any OMs. Man-machine interface This functionality does not make any additions or changes to the manmachine interface. Billing This functionality does not make any additions or changes to the GSM-R billing. VBS/VGCS Inter-MSC Handover This functionality provides group call inter-MSC handover capabilities for VBS and VGCS. VBS supports inter-MSC handover functionality using circuit connections. This functionality includes the following: inter-MSC handover (MSC-A to MSC-B) subsequent handover (MSC-B to MSC-B)
411-2231-827
Standard
02.05
September 2001
Delta information
xxxi
inter-MSC handback (MSC-B to MSC-A)
VGCS supports inter-MSC handovers over either a circuit connection or a signaling connection. If the VGCS talker is on dedicated channel, the interMSC handover is performed over a circuit connection. If the VGCS call is on a group channel, the inter-MSC handover is performed over a signaling connection. Data schema This functionality uses the following OPARM in table OFCENG: NUMBER_OF_TLK_HO_MAP_TIDS Log reports This functionality does not add or change any log reports. Operational measurements This functionality does not add or change any OMs. Man-machine interface This functionality does not make any additions or changes to the manmachine interface. Billing This functionality does not make any additions or changes to the GSM-R billing. Voice Group Call Service (VGCS) Emergency Call This functionality encompasses the functionalities of VGCS emergency call takedown and VGCS emergency call talker restrictions. The call is taken down when one of the following occurs: authorized dispatcher uses DTMF kill sequence originating dispatcher releases the call (hangs up) originating service subscriber sends the termination request while having uplink (hangs up) the service subscriber originator sends in the uplink release Note: The No Activity Timer does not apply to VGCS emergency calls. Data schema This functionality does not add or change data schema. Log reports This functionality does not add or change any log reports.
GSM
xxxii
Delta information
Operational measurements This functionality adds a new operational measurement group EVGCS. This OM group contains registers that count the number of Emergency VGCS calls. The registers are EVGCSSS records the number of Emergency VGCS calls originated by a service subscriber. EVGCSDI records the number of Emergency VGCS calls originated by a dispatcher.
Man-machine interface This functionality does not make any additions or changes to the manmachine interface. Billing This functionality does not make any additions or changes to the GSM-R billing. Dispatcher Disconnect This feature provides the following functionalities on the MSC: Tone detection on the dispatcher lines to detect dispatcher dialed DTMF tone sequences for call take down. Logic to identify the authorized dispatchers allowed to terminate an ongoing group call. Ability to detect the incoming dispatcher_disconnect DTMF tone sequence and compare it to the predetermined sequence in datafill.
Data schema This functionality adds office parameter DISP_DISC_SEQ to table OFCVAR. This parameter allows the network operator to datafill the desired dispatcher disconnect sequence for group call terminations by authorized dispatchers. These sequence digits are matched with the incoming DTMF tone sequences from authorized dispatchers while they attempt to tear down an on-going group call. An interdigit timer is used to reset digit collection on partial input sequences. Log reports This functionality adds log report GMSC600 and modifies log report GMSC301. A GMSC600 log is generated when a NT6X62EA Specialized Tone Receiver (STR) card cannot be allocated within a PDTC serving a trunk connecting a dispatcher. The STR card is required for inband DTMF tone monitoring. Log report GMSC301 is generated for the following cases: when the hardware is not appropriately installed or
411-2231-827
Standard
02.05
September 2001
Delta information
xxxiii
when datafill is not correct
Operational measurements This functionality does not add or change any OMs. Man-machine interface This functionality does not make any additions or changes to the manmachine interface. Billing This functionality does not make any additions or changes to the GSM-R billing. Five Dispatchers in a VGCS and VBS This feature enhances the VGCS/VBS to support up to five dispatchers in one VGCS/VBS call. Data schema This functionality changes the range of the dispatcher and relay MSCs lists in table GCR. The range for the dispatcher list is changed from four to five. The range for the MSC list is changed from five to three. Log reports This functionality does not add or change any log reports. Operational measurements This functionality does not add or change any operational measurements. Man-machine interface This functionality does not make any additions or changes to the manmachine interface. Billing This functionality does not make any additions or changes to the GSM-R billing. Connect Indication Enhancement This feature enhances DMS-MSC VGCS and VBS by implementing a Connect Indication algorithm. The Connect Indication message is sent when either the Full Condition is satisfied or both the Timer and Limited Conditions are satisfied. The Full Condition is satisfied when VBS/VGCS is established in all cells before the timer expires. The Timer Condition is satisfied when the timer Txx elapses. The Limited Condition is satisfied when
xxxiv
Delta information
an origination cell is established (in the case of a service subscriber originated call) or any cell is established (in the case of a dispatcher originated call) Data schema This functionality adds a new subfield to table SERVCHFG. The subfield is Txx. This subfield assigns a timer value of 1 to 10 seconds. Log reports This functionality does not add or change any log reports. Operational measurements This functionality does not add or change any operational measurements. Man-machine interface This functionality does not make any additions or changes to the manmachine interface. Billing This functionality does not make any additions or changes to the GSM-R billing. MAP Enhancements for Inter-MSC Group Calls This functionality enhances the DMS-MSC Mobile Application Part (MAP) software by providing support for new signaling messages. These messages are sent between an anchor MSC and a relay MSC in a VBS or VGCS call. Data schema This functionality does not add or change any data schema tables. Log reports This functionality does not add or change any log reports. Operational measurements This functionality does change OM group GMAPCH2. This group measures the number of requests and responses received for each Prepare Group Call operation, the number of Forward Group Call, and the number of Process Group Call Operations that are implemented in the MAP layer. This functionality adds the following registers: PGCREQ - pegs the number of Prepare Group Call Requests PGCRQ2 - pegs the number of extension registers for Prepare Group Call Request PGCRES - pegs the number of Prepare Group Call Results
411-2231-827
Standard
02.05
September 2001
Delta information
xxxv
PGCRS2 - pegs the number of extension registers for Prepare Group Call Result FGCREQ - pegs the number of Forward Group Call Requests FGCRQ2 - pegs the number of extension registers for Forward Group Call Requests PRGCREQ - pegs the number of Process Group Call Requests PRGCRQ2 - pegs the number of extension registers for Process Group Call Request
Man-machine interface This functionality does not make any additions or changes to the manmachine interface. Billing This functionality does not make any additions or changes to the GSM-R billing.
Delta tables
2
This section provides tables that summarize the additions or changes made by the three GSM11 features used by GSMR02 as well as the GSMR02 functionalities. Table 2-1 summarizes the additions and changes made to data schema tables. The data tables are listed in alphabetical order.
Table 2-1 Summary of data schema changes made by GSM11 and GSMR02 features Table name ACSMTRX DNROUTE GCR New/ modified new modified modified Description of changes This new table specifies the Access Matrix used for the Access Matrix feature. Adds feature selector GSMGCN. Two fields are added to table GCR: ANCHOR_MSC and RELAY_MSC_LIST. Also, the range for the dispatcher list is changed from four to five. The range for the MSC list is changed from five to three. Parameter AC_MAX_V is changed to include the NUS_AC entry. Also, parameter MISCSSN is added.
sheet 1 of 3
GHLRPARM
modified
GSM
xxxvi
Delta information
Table 2-1 Summary of data schema changes made by GSM11 and GSMR02 features Table name GHLRSCF GHLRVGS GHLRVLR GHLRUSSD New/ modified modified modified modified new Description of changes Adds fields NUS_AC, EVAL_NUS, and AC_AUDIT. Adds error and warning messages to the existing set of messages Adds fields NUS_AC and EVAL_NUS. This new table determines how to process the USSD string received in a PUSSR. This table associates a symbolic name with the actual E.164 network address of an external node. It also records the highest common version supported by the HLR and the external node for the NUS application context. Field HLR is extended to cover timing information for new messages. Also, the following timers are added to field HLR: T_PUR, T_USR, T_USN. The following parameters are added to this table: RAILWAY_ACCESS_CODE, NUMBER_OF_RELAY_LOGICAL_TIDS, and NUMBER_OF_DMS_TIMER_TIDS. Parameter RAILWAY_ACCESS_ CODE specifies the railway access code (RAC) of the local GSM-R network. Parameter NUMBER_OF_RELAY_LOGICAL_TIDS
GHLRXTND
new
GSMTIMRS
modified
OFCENG
modified
specifies the number of the logical TIDs required on the DMS-MSC for the relay feature software.
OFCVAR modified The following office parameters are added to this table: EMLPP_HIGH_ PRECEDENCE, MLPP_PBX_FULL_ SUPPORT, MLPP_SERVICE_DOMAIN and DISP_DISC_SEQ. Also, tuple DISPATCHER_TALK_ CONTROL is added to table OFCVAR.
sheet 2 of 3
411-2231-827
Standard
02.05
September 2001
Delta information
xxxvii
Table 2-1 Summary of data schema changes made by GSM11 and GSMR02 features Table name PETSERVS New/ modified modified Description of changes Option AMSCRN is added to this table. The AMSCRN option allows the Access Matrix feature to be activated on a per PET trunk basis. Table SERVCHNG is modified to enable the network operator to allocate the following for each priority level call on the MSC: call setup class, emergency group call indication, and resource preemption capability information. Also, subfield Txx is added. This subfield assigns a timer value of 1 to 10 seconds. Universal tables (AMCODE, PXCODE, CTCODE, FACODE, OFCCODE, PTCODE, ACCODE, NSCCODE) modified These tables are modified by adding an option to the existing Data Base Query (DBQ) selector to identify Acknowledgment Calls. The DBQ option is AC.
SERVCHFG
modified
sheet 3 of 3
Table 2-2 summarizes the additions and changes made to log reports. The log reports are listed in alphanumeric order.
Table 2-2 Summary of log report changes made by GSM11 and GSMR02 features Log report name GGCN300 GHLR401 New/ modified new modified Description of changes This new log report generates when a group call number cannot be allocated. This log report was updated to include the operations Process-USS-Request, USSRequest, and USS-Notify and an indication of the USSD acceptance ratio.
sheet 1 of 2
GSM
xxxviii
Delta information
Table 2-2 Summary of log report changes made by GSM11 and GSMR02 features Log report name GHLR600 New/ modified modified Description of changes This log report was updated to include errors Unknown Alphabet and Called Barred and operations PUSSR, USSR, and USSN. This log report also was updated to support the NUS application context. This log report was updated to include errors Unknown Alphabet and Called Barred and operations PUSSR, USSR, and USSN. This log report also was updated to support the NUS application context. This log report was updated to include errors Unknown Alphabet and Called Barred and operations PUSSR, USSR, and USSN. This log report also was updated to support the NUS application context. GHLR664 is a generic log used to indicate a problem with the USSD Resource Monitoring too. This new log report generates when there is an issue with allocating the STR card.
sheet 2 of 2
GHLR601
modified
GHLR612
modified
GHLR664
modified
GMSC600
new
411-2231-827
Standard
02.05
September 2001
Delta information
xxxix
Table 2-3 summarizes the additions and changes made to OMs. The OMs are listed by OM group. The OM groups are listed in alphanumeric order.
Table 2-3 Summary of OM changes made by GSM11 and GSMR02 features OM group EVGCS New/ modified new Description of changes This OM group contains registers that count the number of Emergency VGCS calls. GSMR02 updates the above HLR database related OMs if the subscriber has an ASTATUS of acting and the HLR is not in standby out-of-service mode, or the HLR is in a standby stand-alone mode, or the standby functionality is turned off. GSMR02 updates the above HLR database related OMs if the subscriber has an ASTATUS of acting and the HLR is not in standby out-of-service mode, or the HLR is in a standby stand-alone mode, or the standby functionality is turned off. The following registers are added to this OM group: PGCREQ, PGCRQ2, PGCRES, PGCRS2, FGCREQ, FGCRQ2, PRGCREQ, and PRGCRQ2. The registers in the HLRUSSDT group measure USSD traffic between the HLR and VLR and between the HLR and gsmSCF/external node. This group contains registers that measure how often pre-emption occurs due to the MLPP service. The following registers are added to this OM group: VGCSIMST, VBSIMST, VGCSINVR, VBSINVR, and GCNFAIL.
GHLRADM3
modified
GHLRBSG
modified
GMAPCH2
modified
HLRUSSDT
new
MLPP
new
MSCGCS
modified
GSM
xl
Delta information
Table 2-4 summarizes the changes made to the man-machine interface (MMI). The MMI changes are listed in alphabetical order.
Table 2-4 Summary of MMI changes made by GSM11 and GSMR02 features MMI command DBOMCALC New/ modified modified Description of changes The tool is modified to recognize and support the changes made to the GHLRBSG and GHLRADM3 OM groups. Changed the QVLR command located in the HLRADMIN directory. Updated the command to display the networkUnstructuredSS AC at version 2. The HLRTRACE tool is enhanced to display the new MSISDN field. The field is displayed only if it exists in the message under consideration.
HLRADMIN
modified
HLRTRACE
modified
Table 2-5 summarizes the additions or changes made to billing. The billing additions and changes are listed in alphabetical order.
Table 2-5 Summary of billing changes made by GSM11 and GSMR02 features Billing Acknowledgement record New/ modified new Description of changes Captures data about high priority VGCS and VBS calls through the Integrated Acknowledgment Center. An acknowledgment record is generated for each Setup message of the Acknowledgement Call received by the Integrated Acknowledgment Center that resides on the DMS-MSC. The SS module code is enhanced to capture both the pre-empting and preempted calls precedence level.
SS module code
modified
411-2231-827
Standard
02.05
September 2001
1-1
This chapter introduces the GSM-R network. This chapter also provides background information about why the GSM-R network was created. Finally, this chapter discusses the capabilities and benefits of the GSM-R network.
Purpose of the GSM-R network
GSM-Railways (better known as GSM-R) is a pan-European radio system that provides digital communications for multiple railway operations. The goal of GSM-R is to provide the following functions through one system: shunting operations trackside team communications automatic train control driver-to-zone controller communications local communications within railway stations passenger communications
History
1
Today, European railway telecommunications networks often use different types of systems to provide various functions. For example, many European railway telecommunications networks employ tunnel radio systems, paging systems, shunting radio systems, track-to-track radio systems, as well as other types of systems. Using multiple types of systems has the following drawbacks: It increases operations and maintenance costs. It limits the interoperability between the railway networks. It inefficiently uses radio frequencies.
The European Commission and MORANE The European Commission (EC) is a group responsible for proposing and implementing the European Unions legislation. The EC wanted to overcome
GSM
1-2
the drawbacks and improve the current the interoperability of European railway networks. The EC funded a project called MORANE (MObile RAdio for Railways Networks in Europe). The objective of MORANE is to specify, develop, test, and validate prototypes of a new radio system that would meet the global requirements of railways. The EC created the MORANE consortium to oversee the MORANE project. This consortium is comprised of railways operators, manufacturers, vendors, and research organizations. The EIRENE specification In conjunction with the Union Internationale des Chemins de Fer (UIC) and the European Telecommunications Standards Institute (ETSI), the MORANE Consortium developed the EIRENE (European Integrated Railway Radio Enhanced Network) specification. This specification defines the requirements for the GSM-R network.
Capabilities of the GSM-R network

The GSM-R network uses state-of-the-art technology to meet the mobile communications needs of the European railways. Through one telecommunications network system, the GSM-R provides ground-train voice and data communications
ground-based mobile communications for track-side workers, station, and depot staff ground-based mobile communications for railway managerial and personnel staff
The GSM-R also facilitates international interoperability between national railways. Figure 1-1 illustrates the GSM-R network.
411-2231-827
Standard
02.05
September 2001
Nortel Networks Confidential Figure 1-1 Diagram of the GSM-R network
1-3
Railway fixed network
National EIRENE network
Other EIRENE network(s)
Shunting communications
Voice and data communications, eg: - driver - ERTMS/ETCS - other on train users - passenger information
International trains
Wide area communications Train communications
Benefits of the GSM-R network

Following are some of the benefits of the GSM-R network: reduced operations and maintenance costs for radio infrastructure improved bandwidth frequency efficiency improved emergency and safety procedures
Frequency band of the GSM-R network

The GSM-R system operates primarily in a frequency band of 4 MHz bandwidth, where: 876-880 MHz is used for the uplink 921-925 is used for the downlink
Refer to Figure 1-2.
GSM
1-4
Figure 1-2 The frequency band for the GSM-R system
R- E-GSM
P-GSM
R- E-GSM
P-GSM
870
880
890
900
910
920
930
940
950
960
970
f/MHz
Uplink
Downlink
Up to now, the Extended GSM (E-GSM) band was reserved for military applications. Now, the E-GSM is available to private operators in Europe. The E-GSM is a 10 MHz band just above the R-GSM band and below the 35 MHz GSM900 (P-GSM) band: 880-890 MHz is used for the uplink 925-935 MHz is used for the downlink
In private and hybrid networks, the network operator can enable the GSM-R network to operate in the E-GSM and P-GSM bandwidths, as well as the RGSM bandwidth.
411-2231-827
Standard
02.05
September 2001
2-1
The network and switching subsystem (NSS) performs the main switching functions in a public land mobile network. The NSS manages communication among GSM-R mobile subscribers and communications between GSM-R mobile subscribers and users in other networks. The GSM-R NSS consists of the following components: GSM Mobile Services Switching Center (DMS-MSC) Visitor Location Register (VLR) Home Location Register (DMS-HLR)
This chapter discusses the functions and configuration of the DMS-MSC, VLR, and DMS-HLR.
Mobile services switching center (DMS-MSC)
The DMS-MSC is a SuperNode-based switching architecture packaged to support the switching functions required for mobile subscribers located in an associated geographical area. DMS-MSC functions The DMS-MSC performs all of the call processing, switching, and interface functions needed for the mobile subscribers located in a particular NSS. The DMS-MSC performs the following functions: establish, re-establish, and route subscriber calls translate dialed digits control calls and provide signaling handle data calls manage call facilities and procedures locate and contact subscribers for call termination handover calls from one cell to another support roaming to other public land mobile networks (PLMNs)
GSM
2-2
control echo capture and format billing data support supplementary services
Establish, re-establish, and route subscriber calls The DMS-MSC manages mobile subscriber calls and handles call establishment and routing. The call establishment process includes querying the VLR for information about the subscriber involved in the call establishing a network connection to join the voice paths between two subscribers establishing the mobility environment for call traffic providing the logical group call register GCR for VBS and VGCS teleservices providing part of the logical acknowledgement center function for GSMR
Call re-establishment enables communication to continue between two subscribers. Call re-establishment occurs after a sudden connection loss is caused by interference from bridges, tunnels, or buildings. Translate dialed digits The DMS-MSC supports customer-definable dialing plans and universal translations. The DMS-MSC uses dialed digits, in addition to other data, to determine the call path of a PSTN-terminated call. Source directed routing (SDR) is used in translation instances where the location of the call origination is combined with the dialed digits to influence a call path. The DMS-MSC includes uniform and non-uniform plans that require dialing information or does not rely on the present location of the subscriber or its home service area. Dialed digits translations uses customer group (CUSTGRP) ID tags for user communities. These CUSTGRP ID tags logically relate and uniquely identify every member of the group. The CUSTGRP ID tags also provide every group member with uniform and group-specific services. If any deviations exist within a community, the deviations are groups by assigning a unique network class of service (NCOS) value or ID tag. Control calls and provide signaling The DMS-MSC performs call control functions that are responsible for establishing, maintaining, and releasing calls. The DMS-MSC handles signaling connections between itself and other GSM-R public land mobile network (PLMN) nodes.
2-3
Handle data calls The DMS-MSC support mobile-originated and mobile-terminated data calls. Manage call facilities and procedures The DMS-MSC manages the facilities for calls and handles non-call-related activities pertaining to the subscriber. The DMS-MSC also performs the following mobility management procedures: requests the subscriber provide its international mobile subscriber identity (IMSI) to the PLMN registers a subscriber in a new VLR and identifies itself by the temporary mobile subscriber identity (TMSI) in which the previous VLR was allocated updates a subscribers current location area in the VLR enables a subscriber to indicate it is entering an inactive state and cannot receive incoming calls enables a subscriber to indicate it is entering the active state and can receive incoming calls
Locate and contact subscribers for call termination For mobile-terminated calls, the DMS-MSC locates the mobile station and establishes radio contact with it. Handover calls from one cell to another The DMS-MSC supports handover, the process of transferring a mobile station involved in a call to another cell in the PLMN. The DMS-MSC supports the following types of handover: intra-MSC handover basic inter-MSC handover (from MSC A to MSC B) subsequent inter-MSC handover (from MSC B to MSC C) subsequent handback (from MSC B back to MSC A)
The DMS-MSC also performs connection updating during the cleanup stage of the handover process. The cleanup stage occurs after the mobile station returns to the new radio resource on the new base station subsystem (BSS). Support roaming to other PLMNs The DMS-MSC supports subscribers in roaming to other PLMNs, both within and outside the subscribers home country. Control echo Echo is generated by signal reflection at the far-end of the exchange. Echo becomes intrusive when talkers hear a repeat of their own speech after a
GSM
2-4
momentary delay. The D S-MSC supports echo control that is performed by external echo canceller modules linked to the DMS-MSC. Capture and format billing data The DMS-MSC captures and formats billing data for mobile-originated and mobile-terminated calls. The billing data is stored on a billing server and is transferred to a downstream processor. The DMS-MSC provides partial billing capabilities for long-duration calls. By recording data on the call at pre-determined intervals, the DMS-MSC limits the maximum billable time lost to the established interval. For calls that span different networks and service provider areas, the DMSMSC performs inter-administration accounting. This functionality measures bulk conversation time and number of answered calls that occur over interconnect routes between service providers. Support supplementary services A supplementary service modifies or supplements basic telecommunication services. A supplementary service cannot be offered to a subscriber as a stand-alone product The DMS-MSC supports the following supplementary services: number identification call offering call completion multi-party calling charging call restriction call independent supplementary services proprietary services
Visitor location register (VLR)
The VLR is integrated within the DMS-MSC and resides entirely in the DMS-core memory. Although the DMS-MSC contains the integrated VLR, the DMS-MSC and VLR are two separate functional entities within the GSMR network. The coverage area of the GSM-R is divided into subsections called location areas. These location areas contain cells. A VLR may serve one or more location areas.
411-2231-827
Standard
02.05
September 2001
2-5
VLR functions The VLR performs the following functions: maintains information about subscribers that have roamed into the area supports call establishment assigns temporary mobile subscriber identity allocates mobile station roaming number supports supplementary services and Short Message Service
Maintains information about subscribers A VLR database maintains the information about subscribers that have roamed into the location area or areas served by that VLR. The VLR contains temporary details of subscribers active within its area. The VLR obtains the subscriber details from the DMS-HLR. The VLR provides the subscriber data to the DMS-MSC so the DMS-MSC can perform its call handling functions. Supports call establishment When a subscriber tries to establish a call, the DMS-MSC queries the VLR to request and validate information pertaining to the subscriber involved in the call. The VLR then returns the information to the DMS-MSC. Assigns temporary mobile subscriber identity Upon demand from the DMS-HLR, the VLR assigns a mobile station roaming number (MSRN) to a subscriber. The DMS-HLR uses the MSRN to route calls to the DMS-MSC that is serving the subscriber at any given time. Supports supplementary services and Short Message Service The VLR communicates with the DMS-MSC and DMS-HLR to support callrelated messages required for supplementary services for both speech and data calls. The VLR also communicates with the DMS-HLR to support Short Message Service.
Home location register (DMS-HLR)
The DMS-HLR is the master database of all GSM-R subscriber data. The DMS-HLR contains information such as subscriber provisioning and service information. The DMS-HLR also contains dynamic information from the VLR. Every GSM-R subscriber is associated with a DMS-HLR. Unlike the VLR that contains information pertaining to subscribers currently visiting the VLR area, the DMS-HLR maintains a permanent list of GSM-R subscribers associated with it, regardless of where those subscribers are currently located. Therefore, the DMS-HLR is queried for information about a subscriber, regardless of the subscribers current geographical location.
GSM
2-6
Each GSM-R NSS is configured with a mated pair of HLR. The DMS-HLRs normally run in active mode but can be configured to provide disaster mode. Subscriber creation can occur on both HLRs in parallel. Updates to subscriber provisioning occur on the active node and are propagated to the standby node. Network-side updates are transported to the mate HLR through a dedicated update connection or through the SS7 network. The mated pair of HLRs support up to 400,000 busy hour USSD requests and 400,000 busy hour completed attempts (BHCA). DMS-HLR functions The DMS-HLR is the hub of the network. The DMS-HLR performs the following functions: supports call routing controls supplementary services supports Short Message Service maintains network consistency
Supports call routing The DMS-HLR supports call routing to GSM-R subscribers by providing the DMS-MSC with information about the location of subscribers. In order to do this, the DMS-HLR interacts frequently with the different VLRs where the subscriber is currently located. Controls supplementary services The DMS-HLR provisions, controls, and manages supplementary services information. The DMS-HLR stores a subscribers supplementary services information, determines its applicability to calls, and manages interaction among the different supplementary services. The DMS-HLR allows supplementary services to be provisioned against individual subscribers and basic service groups. Supports Short Message Service Short Message Service (SMS) is a service that allows messages of a limited size to be sent to and from GSM-R subscribers. Maintains network consistency The DMS-HLR maintains network consistency by downloading subscriber data to the VLR that a subscriber is currently visiting. The DMS-HLR also propagates data changes to the VLR. By communicating regularly with the VLRs, the DMS-HLR retrieves and stores information about the current location of its subscribers.
411-2231-827
Standard
02.05
September 2001
2-7
Types of data stored in the DMS-HLR The DMS-HLR stores two main types of data: permanent data and temporary data. Refer to Figure 2-1.
Figure 2-1 DMS-HLR data types
Transient data Includes information such as current location of a subscriber. Updated in real-time by the GSM-R network. Temporary data Non-transient data Includes information such as a subscribers forwarded-to number. Updated in real-time by the GSM-R network or the service provider. Operational data Includes individual subscriber IDs, subscriber ISDN number, and authentication key. Changed manually by the service provider. Permanent data Subscriber data Includes the basic services available to the GSM-R subscriber, options related to those services, and supplementary services. Changed manually by the service provider.
Temporary data Temporary data is updated by the network in real-time. When a subscriber roams within the GSM-R network, the VLR associated with the subscriber informs the DMS-HLR of the subscribers location. There are two types of temporary data: transient data and non-transient data. Transient data is updated frequently and in real-time by the network. An example of transient data is the current location of a subscriber. Non-transient data is updated less frequently than transient temporary data. Non-transient data is updated either by the network or by the service provider. An example of non-transient temporary data is supplementary service registration data. Non-transient temporary data is changed as a result of user control or by the service provider.
GSM
2-8
Permanent data Permanent data does not change unless the service provider manually changes the information in the database. Permanent data includes operational and subscription information about the subscriber.
411-2231-827
Standard
02.05
September 2001
3-1
GSM-R functionality
3
3
GSM-R functionalities will be provided in various phases. This product guide discusses the functionalities provided in Phase 1 and Phase 2. These functionalities are GSM-R numbering plan Access Matrix Functional Addressing Location Dependent Addressing Call Forwarding to Functionally Structured Numbers Voice Broadcast Service (VBS) Voice Group Call Services (VGCS) Integrated Acknowledgement Center (IAC) enhanced Multi-level Precedence and Preemption (eMLPP) Fast Call Setup Nature of Address (NOA) Format Customization
The following sections describe the GSMR02 functionalities. This chapter also describes how the GSM Mobile Services Switching Center (DMS-MSC) and Home Location Register (DMS-HLR) support these functionalities.
GSM
3-2
GSM-R numbering plan

The Nortel GSM-R numbering plan was developed as an interim numbering plan that was mutually agreed upon between Nortel and ARCOR. This numbering plan provided a base for design and test teams and ARCOR acceptance teams during a time when the EIRENE numbering plan was incomplete and changing. Most of the numbering plan change requests that were submitted to EIRENE have now been accepted. Therefore, the EIRENE numbering plan is used as the GSMR02 numbering plan. Note: For further information on the EIRENE numbering plan, refer to the EIRENE SRS, version 12.0.
411-2231-827
Standard
02.05
September 2001
3-3
Access Matrix
Purpose of Access Matrix 3
The subscribers in a GSM-R network are classified by either their function (for example, leading driver, primary controller, shunting leader) or location (for example, shunting teams, maintenance teams, and train controllers)
The information stored in table ACSMTRX (Access Matrix) determines the combinations of subscribers that are allowed to call each other. For subscribers that are classified by their function, the Access Matrix functionality determines the functions of the originator and the terminator of a call based on the Calling Party Number (CGN) and the Called Party Number (CDN) determines if a connection between the two parties is allowed based on their functions
For subscribers that are classified by their location, the Access Matrix functionality determines the location of the originator and the terminator of the call allows the call if the two parties are in the same location disallows the call if the two parties are not in the same location
How the Access Matrix works
Access Matrix Supports User-to-User Information Elements (UUI IEs) with and without alphanumeric Functional Numbers (FN), however only the numerical Functional Number is for the Access Matrix check. Includes location checking within call type 6. This checking occurs from call type 6 to 7 and vice versa. Checking is done at call setup. Access Matrix checking for national GSM-R calls only. Access Matrix does not support checking for public networks access (national and international) other EIRENE networks (break out code 900) other private networks (break out code 901)
GSM
3-4
Access Matrix checking applies to point-to-point calls (voice and data). Access Matrix checking is not performed on group calls emergency calls
Screens calls originating from GSM-R mobile subscribers, PRI link, or EIRENE international ISUP trunks Screens incoming calls with Functional Numbers or Functionally Structured Numbers from foreign EIRENE networks at the gateway MSC according to the national rules. Identifies the called/calling party can be derived unambiguously from the CT/FC of the FN, FSN. Does not support train checking. Is not dependent on bearer or teleservices. Does not apply to Call Forwarding (CF). There is no Access Matrix checking at the time of the Call Forwarding activation. In the case of a forwarded call, the screening applies to the originally dialed digits only. Checks the validity of the dialed number according to the Eirene numbering plan.
GSM-R number types According to the EIRENE specification document, the following types of numbers can be dialed within a GSM-R network: National EIRENE Number (NEN) International EIRENE Number (IEN) MSISDN number Short Dialling Code (SDC)
The NEN and IEN reflect the function of a subscriber within the GSM-R network and are subject of the Access Matrix check. Therefore, a call applies to the Access Matrix check if the calling party is of call type 2, 3, 4, 6, 7, 8 or 95-99 and the called party is of call type 2, 3, 4, 6, or 7
Activating the Access Matrix functionality The activation of the Access Matrix feature is split into two parts. The activation and deactivation by Software Optionality Control (SOC). The provisioning of the Access Matrix check on a specific Protocol Enhanced Trunk (PET trunk).
411-2231-827
Standard
02.05
September 2001
3-5
Feature activation by Software Optionality Control (SOC) The activation of the Access Matrix functionality is controlled by Software Optionality Control (SOC). Therefore, a password is required to activate and deactivate the Access Matrix functionality. Once Access Matrix is active, the Access Matrix check is applied to all mobile originated calls within a GSM-R network and to all PET trunks that have the AMSCRN option in table PETSERVS provisioned. If Access Matrix is inactive, no call applies to the Access Matrix check. AM check provisioning for PET trunks Access Matrix is provisionable on a per trunk basis by option AMSCRN in table PETSERVS. If the AMSCRN option is set for a specific trunk and Access Matrix is active (SOC is turned on), the trunk applies to Access Matrix screening. If Access Matrix is not set, no Access Matrix check is performed on the trunk even if the feature is active. Note: In order to screen all calls originating from mobile GSM-R subscribers and PRI links, the AMSCRN option has to be datafilled for all PRI incoming trunks. On gateway MSCs, the AMSCRN option has to be datafilled additionally on the private inter GSM-R trunks in order to apply the Access Matrix functionality to international EIRENE calls.
How the DMS-MSC supports Access Matrix
The DMS-MSC within a GSM-R network receives the following termination numbers: From inside the GSM-R network over direct PRI links or from mobiles: national functional numbers (FNs) and functional structured numbers (FSNs) E.164 numbers From other GSM-R networks (international EIRENE calls) over a private trunk FNs and FSNs with 900+RAC prepended to it E.164 numbers with CC and NDC of the destination GSM-R network and originating from a GSM-R network From the public PSTNs E.164 numbers
Datafill required for Access Matrix

The following tables must be datafilled for the Access Matrix functionality:
GSM
3-6
table OFCVAR table PETSERVS table ACSMTRX
Table OFCVAR Office parameter RAILWAY_ACCESS_CODE specifies the RAC of the local GSM-R network. This information is necessary for the Access Matrix feature to decide if the Access Matrix check has to be performed (in case the called party belongs to the local GSM-R network) or not. Table PETSERVS In table PETSERVS, option AMSCRN assigns an Access Matrix check to an incoming PET trunk. If the AMSCRN option is datafilled on a trunk, the Access Matrix functionality is applied to it. The check is based on the Access Matrix that is datafilled in table ACSMTRX. The check determines if a call between two parties, identified by their Functional Number, is allowed or not. Table ACSMTRX Table ACSMTRX specifies the Access Matrix that is used for the Access Matrix functionality. The table uses a two-part key. The key is made up of the call type (CT) and the function code (FC). The data tuple contains a boolean value ALLOWED and a list of call type and function code combinations. The function code is entered as a range (FROMFC and TOFC). The table is initialized with five tuples specifying default permission patterns for each call type. These default tuples can only be changed but not deleted by the user. Call permission patterns that differ from the ones given by the default tuples are to be added as additional tuples to the table.
Log reports associated with Access Matrix

There are no log reports associated with Access Matrix.
3 3 3
Operational measurements associated with Access Matrix

There are no operational measurements associated with Access Matrix.
Billing
The Access Matrix functionality does not affect billing.
411-2231-827
Standard
02.05
September 2001
3-7
Functional Addressing
Purpose of Functional Addressing (FA)
Functional Addressing (FA) sets up a call based on the function of the call originator and call terminator, instead of the mobile subscriber ISDN (MSISDN) currently being used. Logically, Functional Addressing has two phases: the FA registration, deregistration, and interrogation phase the call processing phase
FA registration, deregistration, and interrogation
To use Functional Addressing, a user must subscribe to the FA Supplementary Service (SS). FA SS performs the following functions: registers a functional number to an MSISDN interrogates the status of a functional number deregisters a functional number from the MSISDN
The FA user must also register a functional number against the mobile station. Once a user has a functional number, a caller can reach the user through either the users MSISDN or registered functional number. If a call originator uses a functional number to call a user, the MSISDN address of the functional number is presented to the caller. The MSISDN is presented through the Calling Line Identification Presentation (CLIP) and Connected Line Identification Presentation (COLP) supplementary services. Class of registration (CoR) The class of registration (CoR) defines a mobiles specific subscription capabilities. The following CoRs are available: A = engine/train cab-radio basic function B = maintenance service user C = operation support user D = customer support user Note: A mobile station can subscribe to one or more CoR. A user who registers, deregisters, or interrogates against a functional number (FN) must use a mobile with a CoR that enables FA SS. FA SS decides if the user has the capability to register and deregister.
GSM
3-8
How the FA registration, deregistration, and interrogation phase works The FA registration, deregistration, and interrogation responsibility is divided into two logical parts: Home Location Register-mobile (HLRm) Home Location Register-functional (HLRf)
The HLRm The HLRm stores all the subscriber-based data. When a mobile makes a registration-related request, the DMS-MSC and VLR send the request to the HLRm. The DMS-MSC and VLR send the request through USSD messaging. The HLRm verifies the request based on the subscribers subscription data. The HLRf If the HLRm encounters no error, the HLRm passes the request with the MSISDN to the HLRf for processing. The HLRf provides registration, deregistration, or interrogation capabilities based on the request type. The HLRf then sends the result back to the mobile through the HLRm and the DMS-MSC and VLR. The HLRf also processes requests from the DMS-MSC and VLR for FA call setup information. The HLRf provides the DMS-MSC and VLR with the MSISDN that corresponds to the functional number (FN). Note: The HLRm is not involved in FA call setup. Functional steps of a successful transaction Figure 3-1 illustrates the FA architecture.
411-2231-827
Standard
02.05
September 2001
Nortel Networks Confidential Figure 3-1 FA architecture
3-9
HLRm MMI Provisioning and CI tool query 1 Database IMSI MSISDN FN MSISDN Provisioning for: - FA service with details - Mapping to gsmSCF/ external node - System requirements
3 Processing 2 PUSSR indication (with string-1) 6 PUSSR response (with string-4) 4 PUSSR request includ. MSISDN (with string-2) 5 PUSSR confirm. (with string-3)
Database
MS
Subscription and functional checking
FFN
Forwarding
Note: The DMS-MSC/VLR are not shown because they are passing the information in a transparent way.
Following are the functional steps that occur for a successful transaction. The number of the step corresponds with the numbers that appear in Figure 3-1. 1. The needed provisioning is provided for FA. 2. A mobile station sends a FA request. The request is sent to the HLRm with a process unstructured supplementary service request (PUSSR) indication message. 3. The HLRm performs subscription and functional checking based on the mobile attributes and the FA provisioning. 4. The HLRm sends a PUSSR request message to the related Follow-Me Function Node (FFN).
3-10
5. The HLR receives a PUSSR confirmation message. 6. A PUSSR response message is sent to the mobile station. The response message is sent in the same string with the USSD confirmation message.
FA call processing
Figure 3-2 Call processing an FA call
Figure 3-2 illustrates the steps that occur during call processing of an FA call.
2) InitDP(FN) Mobile 1) DTAP Setup Station FN, UUI MSC/ SSP 3) Connect (MSISDN, FN) SCP
4) IAM ODD UUI MSISDN
5) Send routing info (SRI) (MSISDN) HLR
Gateway MSC 9) IAM MSRN UUI ODD Mobile 10) Setup Station MSRN,SA,BC,UUI Visiting MSC
8) Routing Info Ack (SRI-Ack) (MSRN) 7) PRN response # (MSRN) 6) Provide roaming # (MSISDN) VLR
Following are the steps that occur when an FA call is processed: 1. The call originator dials the functional number. The mobile station sends this number to the DMS-MSC in a DTAP SETUP message. A UUI may be included in the DTAP SETUP message. 2. The functional number is subscribed to Detection Point 3 (DP3) at the service switching point (SSP). Using an InitDP message, the DMS-MSC queries the service control point (SCP) for the functional number. 3. The SCP returns the MSISDN and functional number to the SSP. The SCP returns this information in a Connect message.
411-2231-827
Standard
02.05
September 2001
3-11
4. The DMS-MSC routes the MSISDN as the called party number (CDPN). The MSISDN is sent in the ITU-T ISUP IAM message. The functional number is mapped to the original dialed digits (ODD). This information is propagated in the IAM using the original called number (OCN). The UUI also is transported in the IAM using the user-to-user information (UUI) parameter. 5. At the gateway DMS-MSC, a query requesting routing information is sent to the HLR. 6. The HLR provides the roaming number to the VLR. 7. The VLR then sends a PRN response to the HLR. 8. The HLR sends an acknowledgement message to the gateway DMSMSC. This message contains the routing information. 9. The gateway DMS-MSC routes the message to the visited DMS-MSC. The original dialed digits and UUI are tandemed. 10. The visiting DMS-MSC determines the subaddress and bearer capability of the mobile using the original dialed digits. This information is sent to the mobile station using the DTAP SETUP message. The UUI is mapped from the ITU-T ISUP IAM and sent in the DTAP SETUP message.
How the DMS-MSC supports FA
The DMS-MSC supports FA service by performing the following functions: passes the USSD messaging between the mobile station and the DMSHLR. Refer to Figure 3-3. obtains MSISDN and routes the MSISDN as the called party number.
GSM
3-12
Figure 3-3 Call flow showing the DMS-MSC passing USSD messaging between the MS and the HLRm Mobile station MSC VLR HLRm SCP
USSD string 1
USSD string 2
USSD string 3
USSD string 4
User-to-user Supplementary Service 1 (USS1) presents the calling functional number to the users. UUS1 transfers the information transparently across the network. The mobile terminal is responsible for inserting the functional number into the User-to-user Information Element (UUIE) and into the DTAP SETUP message. A mobile subport may provide the on-train function. Therefore, it is mandatory that the function related subaddress (SA) be sent to the mobile. The SA derived from the calling original dialed digits is used for mobile users with subports. In the case of a non-ISDN, the DMS-MSC determines the service that is offered to the mobile. The DMS-MSC performs this function by checking the relationship between the SA, function code, and basic service. Note: Only one DMS-MSC can be involved in a call at one time.
How the DMS-HLR supports FA

The DMS-HLR supports FA service by performing the following functions: stores all subscriber-based data receives all registration-related requests initiated by a mobile
411-2231-827
Standard
02.05
September 2001
3-13
verifies registration-related requests based on the subscribers subscription data provides registration, deregistration, and interrogation functions based on the request type sends the result back to the mobile
Feature interactions
Since the original called number stores the original dialed digits, there are interactions with the Call Forwarding Supplementary service, as follows: A GSM-R subscriber can not forward a call to a functional number, except as described for Functionally Structured Numbers in the section entitled, Call Forwarding to Functionally Structured Numbers.
If the called party of an FA call has call forwarding activated, call forwarding parameters such as originally called number remain present. However, the call forwarding parameters contain the original called number of the FA call. Therefore, devices that use the call forwarding parameters (for example, voice mail boxes) might not work properly. The content of the User-to-User information for presentation of Functional Number remains unchanged. For example, Party A (MSISDNa, FNa) calls Party B (MSISDNb, FAb) using Functional Addressing. Party B has Call Forwarding on Busy (CFB) to Party C (ISDNc). Party C actually is a voice mail system. When the call is presented to Party C, the Originally Called Number contains FAb, as opposed to MSISDNb. The content of the User-to-User information for presentation of Functional Number remains FNa. The visiting DMS-MSC can not distinguish the original called number of a normal call forwarding call from the original call forwarding number of an FA call. No checking is performed to determine if the original called number is from an FA call or a call forwarding call. This interacts with normal GSM calls because a subaddress could be sent to mobiles not expecting it.
Datafill required for FA

The following tables must be datafilled for FA service: table OFCVAR table GHLRBCA table GHLRFAID table GHLRFANC table GHLRSSOP table GHLRUSSD table GHLRSCF
GSM
3-14
table GHLRXTND
The following paragraphs provide a brief description of these tables. Note: For more detailed information, refer to NTP 411-2231-455, GSM DMS-MSC Office Parameters Reference Manual, and NTP 411-2831-151, GSM DMS-HLR Customer Data Schema. Table OFCVAR datafill Datafill office parameter GSMR_FUNCTIONAL_ADDRESS_ENABLED. This office parameter prevents breaking GSM calls when the GSMR02 stream is merged back into the GSMXX stream determines the presence of the GSM-R network where users may make Functional Address calls overwrites the bearer capability AFE-OCN with the OCN received from the Connect message sends the appropriate bearer capability in the outgoing DTAP SETUP message
The values that can be entered in this office parameter are Y and N. The default value is N. A value of N means there is only a GSM network. A value of Y means there is a hybrid network - GSM and GSM-R. Table GHLRBCA datafill Table GHLRBCA stores BC information that may be used when none is available (for example, with a mobile terminated data call from the PSTN). Specifically, table GHLRBCA stores BC information against a bearer capability Key. This bearer capability key can then be stored against an MSISDN (a mobile subscribers phone number) in other DMS-MSC/HLR tables. Thus, when a data call is destined for an MSISDN but no BC information is available, the DMS-MSC/HLR provides this information by having BC information stored against that MSISDN. Table GHLRFAID datafill This table determines the implied CoR and basic service (BS) information from a functional number. This table uses a key derived from the functional number according to digit-collection rules. The digit collection is based on the functional number type. The rules are as follows: For functional number types 2, 3, and 4: collect the functional number type digits plus the functional code (the last two digits of the functional number).
411-2231-827
Standard
02.05
September 2001
3-15
For functional number type 6: collect the functional number type digits plus the team type (the fourth from the last digit of the functional number).
Other assumptions include: A key can have a minimum of one and a maximum of six basic services. The HLRm is not required to check the validity of the functional number.
Normally, Nortel Networks recommends the appropriate values for this table and this table is locked by the HLRDEFAULTS command. Table GHLRFANC datafill Table GHLRFANC routes the functional address network code (FANC) to relevant HLRf. The FANC contains the GSM HLRm FANC number that is mapped to the HLRf. In this table, enter the FANC that is mapped to the node address select the existing table used to find the node. For GSMSCF, it is table GHLRSCF. For XTND, it is table GHLRXTND.
Either table GHLRSCR of GHLRXTND must be datafilled before this table is datafilled. Table GHLRSSOP datafill This table contains option data for provisioning, registering, and activating supplementary services associated with a subscriber or basic service group. This table contains one tuple per supplementary service provisioned against the IMSI. The tuples are identified with a three-part key consisting of the IMSI MNC, the IMSI MSIN, and the supplementary service. Enter the CoR information into this table. The CoR enables the FA service to decide whether the user has a capability for registration and deregistration. Note: To datafill a subscriber with a supplementary service option in table GHLRSSOP, first datafill the subscriber in tables GHLRAUTH and GHLRDATA and ensure the subscriber has an ISTATUS of D, A, or N. Table GHLRSCF datafill This table assigns symbolic names and network addresses to each actual GSM Service Control Function (gsmSCF) on the network. An entry in this table consists of a symbolic name for the gsmSCF and its corresponding actual network address. These symbolic names are referenced in table GHLRCAML and GHLRUSSD, instead of a network address.
GSM
3-16
A symbolic address must be datafilled in table GHLRSCF before symbolic address can be used in table GHLRCAML or GHLRSSD. Table GHLRXTND datafill This table associates a symbolic name with the actual E164 network address of an external node. It also implements additional fields to record the highest common version supported by the HLR and the external node for the network unstructured (NUS) application context. This information determines which version of the application context to use when establishing a dialogue when the HLR initiates a service request to the external node. A symbolic address for an external node must be datafilled in table GHLRXTND before it is used in table GHLRUSSD. Table GHLRUSSD datafill This table determines how the unstructured supplementary service data (USSD) string received in a process unstructured supplementary service request (PUSSR) should be processed. This table invokes FA string processing. Datafill the SSCODE field with the FA value. Datafill tables GHLRSCF and GHLRXTND before datafilling table GHLRUSSD.
Log reports associated with FA service
Field USSD Indication & Request of log report GHLR401 supports the FA service. This field indicates USSD message traffic. Note: For more detailed information on this log report, refer to NTP 4112831-510, GSM DMS-HLR Log Reference Manual.
Operational measurements associated with FA service

The following operational measurement (OM) groups contain information regarding FA service: GHLRADM3 HLRFA
The following paragraphs briefly describe these OM groups. Note: For detailed information on these OM groups, refer to NTP 4112831-814, GSM DMS-HLR Operational Measurements Reference Manual.
411-2231-827
Standard
02.05
September 2001
3-17
Group GHLRADM3 This group maintains statistics related to the DMS-HLR supplementary services. Register FAPR pegs the number of subscribers provisioned in table GHLRSSOP with FA supplementary service. FAPR2 is an extension register of register FAPR. Group HLRFA This group measures data related with FA such as number of FA registration requests number of errors sent to the mobile after the HLRm processed the FA registration request number of FA registration request errors that occurred because the HLRf did not respond number of FA registration errors sent from the HLRf number of FA deregistration requests number of errors sent to the mobile after the HLRm processed the FA deregistration request number of FA deregistration request errors that occurred because the HLRf did not respond number of FA deregistration errors sent from the HLRf number of all FA interrogation requests number of errors sent to the mobile after the HLRm processed the FA interrogation request number of FA interrogation request errors that occurred because the HLRf did not respond number of FA interrogation errors sent from the HLRf
Billing
FA service does not have an impact on billing information.
GSM
3-18
Location Dependent Addressing

Purpose of Location Dependent Addressing
This functionality allows a call to be routed to different destinations depending of where a mobile call originator is located.
How Location Dependent Addressing works

Location Dependent Addressing (LDA) is accomplished either through Cell of Origin (COO) routing in the MSC or LDA Intelligent Network (IN) service
Both methods provide one cell location granularity. The LDA IN service enables expansion if a more granular LDA service is requested. LDA IN service The LDA IN service is implemented especially for GSM-R networks and is, therefore, briefly described in this document. The LDA IN service is a subset of the Functional Addressing service. Complete description of this service can be found in SB003138. A mobile call originator dials a special short code number defined in the numbering plan. The DMS-MSC analyzes the dialed digits and triggers a IN service on a DP3 trigger point. An IN query is made to the IN node (Nortel Networks ServiceBuilder SCP) in an InitDP message. The IN node maps the dialed short code to a destination routing address. The IN node bases its mapping on the cell the call originated from. The IN node sends the destination routing address in a Connect message to the DMS-MSC. The DMS-MSC continues call setup to the destination routing address.
411-2231-827
Standard
02.05
September 2001
Nortel Networks Confidential Figure 3-4 Example of a short code LDA delivery MS Setup DP3 InitDP (SrvKey, LocNum, CgPN, CdPN) MSC/SSP
3-19
SCP
SCP executes FA service, retrieves MSISDN
SCP analyzes the location and short code
P Connect (DestRtgAddr) SCP ends service execution ER
Key: D Disk table read
P OM pegged ER Event record generated
To comply with the special needs of railroads, the Nortel DMS-MSC supports a special type of network-initiated group calls as a result of LDA invocation. These calls will connect a mobile originator to 2 or more train or supply controllers. Note: Note: Nortel DMS-MSC supports network initiated group calls only for this specific scenario. Network- initiated group calls by-passes some of the functionality that normally would be part of a group call. Particularly, network-initiated group calls do not have an associated group call area and no service subscribers. The call originator is treated as a dispatcher authorized to originate the group call. For more information on network-initiated group calls, please see VBS and VGCS chapters.
GSM
3-20
How the DMS-MSC supports LDA
The DMS-MSC supports LDA services by performing the following functions: Provide short code and cell of origin information to the IN node. Receives a Destination Routing Address from the IN node. If the Destination Routing Address is a MSISDN or ISDN number, the DMS-MSC routes the call accordingly. If the Destination Routing Address is a Functional Number, the DMSMSC continues handling the call according to Functional Addressing service. If the Destination Routing Address is a network initiated group call number, the DMS-MSC continues the network-initiated Group call setup according to VBS or VGCS service, respectively.
For further information on LDA, please see FA.
Location dependent addressing Location dependent addressing can be used to initiate a VGCS call. Location dependent addressing routes calls for a given function to a destination address that is dependent upon the users location. Location dependent addressing is invoked when a user dials a short code. The location provided to the network is based on the cell from which the call originated.
411-2231-827
Standard
02.05
September 2001
3-21
Call Forwarding to Functionally Structured Numbers

Purpose of Call Forwarding to FSNs 3
This functionality allows subscribers to route their calls to chosen Functionally Structured Numbers (FSNs). The network sees FSNs as standard MSISDN numbers. However, calling parties see FSNs as functional numbers.
How Call Forwarding to FSNs work

The DMS-HLR uses two translations schemes: PSTN translations and LCO translations. The two schemes are distinguished by their datafill in table XLAENTRY. The Call Forwarding to FSNs functionality uses the LCO translation scheme.
When a call is forwarded to an FSN, the FSN is translated into a Forward-To Number (FTN). The DMS-HLR stores the FTNs in data tables. The FTNs must be saved in the International E.164 (CC+NDC+SN) format. An FTN is obtained in two ways: by an operator datafilling the FTN in table GHLRSSOP or a mobile making a Call Forwarding Activation request.
FSN formats The following FSN formats can register as an FTN: 00 + CC + NDC + 8 + <other SN digits> 00 + CC + NDC + 95 + <other SN digits> 00 + CC + NDC + 96 + <other SN digits> 00 + CC + NDC + 97 + <other SN digits> 00 + CC + NDC + 98 + <other SN digits> 00 + CC + NDC + 99 + <other SN digits> 0 + NDC + 8 + <other SN digits> 0 + NDC + 95 + <other SN digits> 0 + NDC + 96 + <other SN digits> 0 + NDC + 97 + <other SN digits> 0 + NDC + 98 + <other SN digits> 0 + NDC + 99 + <other SN digits> 8 + <other SN digits> 95 + <other SN digits> 96 + <other SN digits>
3-22
97 + <other SN digits> 98 + <other SN digits> 99 + <other SN digits>
The plus key (+) also can be used to register the FSN formats described below: (+) + CC + NDC + 8 + <other SN digits> (+) + CC + NDC + 95 + <other SN digits> (+) + CC + NDC + 96 + <other SN digits> (+) + CC + NDC + 97 + <other SN digits> (+) + CC + NDC + 98 + <other SN digits> (+) + CC + NDC + 99 + <other SN digits>
Additionally, the mobile station can register an FTN in EIRENE numbering plan format where the railway access code (RAC) is that of the home GSM-R network: 900 + RAC + 8 + <other FN digits> 900 + RAC + 95+ <other FN digits> 900 + RAC + 96+ <other FN digits> 900 + RAC + 97+ <other FN digits> 900 + RAC + 98+ <other FN digits> 900 + RAC + 99+ <other FN digits>
How the DMS-HLR supports Call Forwarding to FSNs

The DMS-HLR supports the Call Forwarding to FSN functionality by storing the FTNs in data tables normalizing FTNs that are not in the International E.164 format processing FTNs from Call Forwarding Activation requests
Normalizing FTNs The DMS-HLR stores the FTNs in data tables. As previously stated, the FTNs must be saved in the International E.164 (CC+NDC+SN) format. If the FTN in the activation request is not in the International E.164 format, the DMSHLR normalizes the FTN into International E.164 format. The DMS-HLR uses universal translations to perform the normalization process. Following are the steps performed in the translations process. 1. If the FTNs first digit is an 8 or the first two digits are 95-99, the number is normalized with the CC and NDC of the railway operators network.
411-2231-827
Standard
02.05
September 2001
3-23
2. If the FTN is registered as 0 + NDC + 8 or 0 + NDC + 95-99, the 0 is stripped off the number. If the NDC is the railway operators network NDC: the number is normalized and stored if the first digits of the station number are 8 or 95-99 the number is rejected if the first digits of the station are not 8 or 95-99
lIf the NDC is not the railway operators network NDC, the request is rejected 3. If the FTN is registered as 00 + CC + NDC + 8 or 00 + CC + NDC + 9599, the 00 is stripped off. If the CC and NDC is the railway operators network CC and NDC the number is normalized and stored if the first digits of the station number are 8 or 95-99 the number is rejected if the first digits of the station number are not 8 or 95-99 If the CC is not the railway operators network CC, the request is rejected. If the CC is the railway operators network CC but the NDC is not the railway operators network NDC, the request is rejected. Processing FTNs The DMS-HLR processes the FTNs received when a mobile sends a Call Forwarding Activation request. Figure 3-5 illustrates this process.
GSM
3-24
Figure 3-5 Processing FTNs H LR CF Activation Request M essage contains FTN step-1 step-8 N Call Forwarding provisioned?
Y SS ERROR
Number is in international
step-2
form at?
N Step-10 Step-9
System Based Approach

Table X LA E N TRY Translations PX tables OFC tables CT tables
step-4 Successful translation
step-5 Translation failed
SS - ACK
step-7
Save the Inlt. E.164 format FTN in the database ( GHLRSSOP )
A bort M e ssag e
step-6
Necessary info. not found up to FTN
411-2231-827
Standard
02.05
September 2001
3-25
Following are the steps performed to process the FTN. 1. The mobile station sends a Call Forwarding Activation message to the DMS-HLR. The DMS-HLR checks whether the subscriber has Call Forwarding Supplementary Service (CF SS). If the subscriber does not have CF SS provisioned, the DMS-HLR goes to Step 8. If the subscriber has CF SS provisioned, the DMS-HLR goes to Step 2. 2. The FTN enters into System-Based Translations. 3. The DMS-HLR performs the normalization process. If the process is successful, the DMS-HLR goes to Step 4. If the process fails, the DMSHLR goes to Step 5. 4. The DMS-HLR saves the normalized FTN in table GHRLSSOP and then goes to Step-7. 5. The translation process (and normalization process) failed because the FTN is not CT8 or CT95-99. The DMS-HLR moves to Step-6. 6. The DMS-HLR sends an Abort Message back to the mobile station. 7. The DMS-HLR sends an SS-ACK to indicate the CF-Activation Request was successfully processed. 8. The DMS-HLR sends an SS-Error since Call Forward SS is not provisioned. 9. The DMS-HLR moves into the system-based normalization translation flow. 10. The DMS-HLR saves the FTN as it is in the CF message.
Feature interactions Datafill required for Call Forwarding to FSNs

The following tables are used to perform Call Forwarding to FSNs: GHLRSSOP XLAENTRY PXHEAD PXCODE OFCHEAD OFCCODE CTHEAD
3 3
This functionality does not change the current Call Forwarding functionality.
GSM
3-26
CTCODE
The following paragraphs provide a brief description of these tables. Note: For more detailed information, refer to NTP 411-2831-151, GSM DMS-HLR Customer Data Schema. Table GHLRSSOP This table contains option data for provisioning, registering, and activating supplementary services associated with a subscriber or basic service group. This table contains one tuple per supplementary service provisioned against the IMSI. The tuples are identified with a three-part key consisting of the IMSI MNC, the IMSI MSIN, and the supplementary service. Enter the Call Forwarding Service information in this table. To datafill a subscriber with a supplementary service option in table GHLRSSOP, first datafill the subscriber in tables GHLRAUTH and GHLRDATA and ensure the subscriber has an ISTATUS of D, A, or N. Table XLAENTRY This table is used to initiate System-Based translations. Table PXHEAD, OFCHEAD, and CTHEAD These tables are used to datafill default values for Universal Translations. Table PXCODE, OFCCODE, and CTCODE These tables contain the necessary information used in Universal Translations.
Log reports associated with Call Forwarding to FSNs

There are no log reports associated with Call Forwarding to FSNs.
Operational measurements associated with Call Forwarding to FSNs

There are no operational measurement (OM) groups associated with Call Forwarding to FSNs.
Billing
Call Forwarding to FSNs does not have an impact on billing information.
411-2231-827
Standard
02.05
September 2001
3-27
Voice Broadcast Service (VBS)

Purpose of Voice Broadcast Service (VBS)
VBS enables a VBS subscriber to broadcast a unidirectional speech call simultaneously to a predefined group of destination subscribers located in a particular geographical area and entitled dispatchers. Figure 3-6 illustrates VBS.
Figure 3-6 Voice Broadcast Service
VBS Originating Subscriber
Copyright 1996 Northern Telecom
Co
py
rig
ht
19
96
No
rth
ern
Te
lec
om
GSM Access
PSTN/ ISDN
Dispatcher
Dispatcher
VBS is an ASCI teleservice that is available only for speech calls. Multiple VBS calls may exist simultaneously. These calls may be placed to different groups of destination subscribers located in the same group call area (GCA). Also, parallel VBS calls may be placed to the same group of destination subscribers in different, possibly overlapping GCAs.
How VBS works
With VBS, a standard full duplex channel is provided to the calling subscriber and dispatchers during call setup. However, if the dispatcher is not the originator, the dispatcher is not allowed to speak.
GSM
3-28
Simplex down-link channels are allocated to all destination service subscribers, with one common down-link per cell of the VBS broadcast area. (A destination service subscriber is the party to which a VBS call is directed.) Establishing a VBS call A VBS call can be established by a VBS service subscriber dispatcher network operator
A VBS call is established to all the dispatchers identified in the group call register (GCR) a list of up to 25 cells identified in the group call area (GCA) Note: Group call areas are predefined in the network. The DMS-MSC notifies destination subscribers of the incoming VBS call. The service subscribers receive the notification over the notification channel. Subscribers are notified as a group through the group ID. Dispatchers are called individually by their ISDN or MSISDN numbers. A service subscriber that leaves the GCA during an ongoing VBS call ceases to be a destination subscriber. Likewise, a service subscriber that enters the GCA during an ongoing VBS call becomes a destination subscriber. When the service subscriber enters the GCA, the subscriber receives a notification message about the VBS call. The subscriber receives the notification message over the notification channel. Subscriber-initiated calls To originate a VBS call, the service subscriber uses the MMI functions on the mobile equipment to select VBS as the call type. The requested type of service is sent to the DMS-MSC in a CM_Service_Request message. After the subscriber sets the types of service, the subscriber dials the group ID. The group ID digits are sent to the DMS-MSC in a BCC DTAP Setup message. The visitor location register (VLR) determines if the service subscriber is entitled to originate a VBS call. If the subscription check is successful, the call proceeds forward. If the subscription check fails, the origination is denied and a cause value is sent to the originator. The DMS-MSC uses the information received in the CM_Service_Request message to determine if the call is a VBS or VGCS call. The DMS-MSC then uses the group ID and the subscribers cell of origin (COO) to determine the group call reference (GCRef).
411-2231-827
Standard
02.05
September 2001
3-29
Once all checks pass, the system provides a one-way broadcast connection for the VBS call. The network notifies the calling subscriber when the VBS call is successfully established. The notification indicates the calling subscriber can start to speak. All destination subscribers participate in the call as listening subscribers. The calling subscriber is the only subscriber allowed to speak on this connection. The calling subscriber placing the VBS call must remain within the broadcast area during the call. The call is taken down if the calling subscriber leaves the broadcast area. Dispatcher-initiated calls A dispatcher is a railway employee. A dispatcher is connected to the network through standard radio links or ISDN. Dispatchers using the GSM-R network can be located outside the group call area. To place a VBS call, a dispatcher dials <country code> + <national destination code> + 5 + 1 + GCRef Dispatchers do not have to subscribe to VBS. Therefore, no subscription checking is performed at the VLR. The system does perform origination entitlement checking. To verify the dispatcher is entitled to originate a VBS call, the system ensures the dispatchers calling party address is present in the group call register (GCR). If the check fails, the origination is denied and a cause value is sent to the originator. Once the dispatcher passes the origination entitlement checking, the system provides the one-way broadcast connection. While the system performs checking, the dispatcher hears ring-back tone. The ring-back tone stops when the connection is made. Network-initiated calls To place a network-initiated VBS call, the network operator must provision DMS-MSC translations to derive the following called number: <country code> + <national destination code> + 5 + 6 + GCRef The DMS-MSC does not perform entitlement checking on network-initiated calls. Note: A call initiated as a point-to-point location dependent address can result in a network-initiated VBS or VGCS call.
GSM
3-30
Joining an ongoing VBS call If a dispatcher is entitled to originate a group call, the dispatcher can join an ongoing VBS call. To join the call, the dispatcher dials the GCRef of the ongoing call. Only dispatchers who are entitled to originate a VBS call are allowed to join an ongoing VBS call. A service subscriber cannot originate a call to an ongoing VBS call. A network operator can join an ongoing VBS call only if the calling party is a dispatcher provisioned in the entitled originating dispatcher list in the GCR. Terminating a VBS call The calling subscriber or a calling dispatcher can terminate a VBS call. Other dispatchers can terminate a VBS call if they are entitled. Other service subscribers cannot terminate a VBS call. The VBS call is terminated if the calling subscriber releases the call the calling subscriber leaves the geographical call area (GCA) the calling dispatcher releases the call an authorized dispatcher involved in the group call dials the predetermined DTMF dispatcher_disconnect sequence
Land line dispatchers A fixed line trunk-based dispatcher (ISUP/PRI) that is involved in a group call and wants to tear down the call should signal a disaptcher_disconnect request. This dispatcher_disconnect request is sent using the predetermined DTMF tone sequences from the dispatchers terminal or through external equipment connected to the dispatchers terminals. Mobile dispatchers A mobile dispatcher that is involved in a group call and wants to tear down the call should send a dispatcher_disconnect request from their terminal input the predetermined dispatcher_disconnect DTMF tone sequence on their terminal
The dispatchers mobile terminal sends a DTAP message to the DMS-MSC to initiate call take down. Mobile dispatchers do not transmit DTMF tones inband. Instead, the mobile sends a GSM_START_DTMF signal with an information element identifying
411-2231-827
Standard
02.05
September 2001
3-31
the requested digits. The DTMF tone is used as a conditional trigger to force down the group call. The predefined group of destination subscribers A group ID identifies the predefined group of destination subscribers. A destination subscriber can be either a fixed line or mobile subscriber. Fixed line and mobile subscribers identified as dispatchers can be located anywhere during a broadcast. Mobile destination subscribers not identified as dispatchers must be located within the broadcast area in order to receive the broadcast. When a mobile destination subscriber leaves the broadcast area, their association with the broadcast call is dropped. The association is resumed when the subscriber re-enters the broadcast area and chooses to rejoin the call. GSM-R networks with multiple DMS-MSC serving areas Figure 3-7 depicts the distribution of group calls in GSM-R networks consisting of multiple MSC serving areas.
GSM
3-32
Figure 3-7 Distribution of group calls in GSM-R networks with multiple DMS-MSC serving areas HLR SCP
MAP
INAP ISUP
D D F
R-MSC VLR
terrestrial trunk
R-MSC
GCR
MAP-E
PRI
A-MSC
ISUP
VLR
GCR
VLR
GCR
ISUP
BTS not shown BSC2 GC area

CC-DTAP
BSC1
BSC3
X
BCC-DTAP GCC-DTAP
CC-DTAP
X X
Cell
Cell X X X X
Key: D F G ----- VGCS/VBS dispatcher (mobile or fixed (ISUP or PRI)) ----- call over fixed network ----- VGCS talker B X ----- VBS originator ----- VGCS/VBS service subscriber
Within a network, each defined group is assigned one anchor DMS-MSC (AMSC). The other DMS-MSCs in the network are configured as relay DMSMSCs (R-MSCs) for the defined group. The R-MSC controls the group call area cells that are not controlled by the A-MSC.
411-2231-827
Standard
02.05
September 2001
3-33
This functionality supports Establishing a broadcast call from a R-MSC to a group call area that includes an A-MSC and up to two additional R-MSCs Establishing a broadcast call from an A-MSC to a group call area that includes an A-MSC and up to three R-MSCs Broadcast call takedown Enhancements to group call register (GCR) Implementing the group call number (GCN) database and its functionality Switching subsequent VBS talker speech through a secondary R-MSC conference port
Messaging The DMS-MSC Mobile Application Part (MAP) software supports messages for signaling between the anchor MSC and relay MSC in a VBS call. The MAP messages for the VBS call between the anchor and relay switches are Prepare Group Call Prepare Group Call Ack Send Group Call End Signal Send Group Call End Signal Ack
In each MSC, the Mobile Application Part (MAP) interacts with the Advanced Speech Call Items (ASCI) handling process in order to provide the necessary functionality required to perform the Group Call procedures. Prepare Group Call The A-MSC invokes MAP_PREPARE_GROUP_CALL service to inform the R-MSC about a group call setup. This is a confirmed service which means, in response to the MAP_PREPARE_GROUP_CALL message the receiving entity returns a MAP_PREPARE_GROUP_CALL confirmation. Prepare Group Call Ack The R-MSC sends a Prepare Group Call Ack message to the A-MSC in response to the Prepare Group Call message. Send Group Call End Signal The MAP_SEND_GROUP_CALL_END_SIGNAL service is used between the R-MSC and the A-MSC. This message indicates the VBS/VGCS channels are established in the R-MSC area. This service requires response from the AMSC which anchor MSC uses to inform relay MSC that all resources for the call can be released in the relay MSC because the call has been released in the anchor MSC.
GSM
3-34
Send Group Call End Signal Ack The A-MSC sends the Send Group Call End Signal Ack message to the RMSC. This message tells the R-MSC that all resources for the group call can be released in the R-MSC because the call has been released in the A-MSC. Connect Indication message The A-MSC sends a Connect Indication message to the originator once it receives the expected ASSIGNMENT RESULTs from all the BSCs and the SEND_GROUP_CALL_END_ SIGNALs from all the R-MSCs. The Connect Indication message indicates the call has been established. The Connect Indication message may be a DTAP Connect, PRI Connect, or ISUP IAM message, depending on the protocol used towards the call originator. Connect Indication timer A DMS-MSC implemented timer is started before the group call is established towards the BSSs, R-MSCs, and dispatchers. The A-MSC must receive the BSS assignment results and the SEND_GROUP_CALL_END_SIGNAL before the timer expires. If the timer expires before all the expected answers are received, the A-MSC considers the VBS/VGCS established only if in a subscriber originated group call, the originating cell is established or in a dispatcher originated group call, the group call channel in at least one cell is established
If the Txx timer expires and one of these two criteria is fulfilled, the A-MSC sends the Connect Indication message to the call originator immediately after the Txx timer expires. Note: The value of the Txx timer is correlated to the call's priority value and is defined on a per-DMS-MSC basis in the SERVCNFG table. Group call procedure This section discusses the basic message flow for a normal inter-MSC group call procedure. In this section, the anchor MSC is referred to as A-MSC and the relay MSC is referred to as R-MSC. When the A-MSC receives an indication that a group call must be established, the A-MSC sends a MAP Prepare Group Call request to the R-MSC. In response, the R-MSC sends a MAP Prepare Group Call Ack message to the A-MSC. The A-MSC checks the contents of the acknowledgement message. If the group call number is available, the A-MSC sends a MAP Prepare Group Call Ack with the group call number to the ASCI handling process. The A-MSC waits for the R-MSC to send a connect indication in a MAP Send Group Call
3-35
End Signal message. Once the R-MSC sends the connect indication, the AMSC sends a Connect Indication message to the group call originator. If the group call number is missing, the A-MSC sends a MAP Prepare Group Call Negative Response to the ASCI handling process and an ABORT package with a MAP-U-ABORT request to the R-MSC. Once VBS channels are established in the R-MSC area, the R-MSC sends a MAP Send Group Call End Signal A-MSC. The R-MSC then waits for further uplink management signals. For a VBS call, the A-MSC sends a MAP Send Group Call End Signal Ack to the R-MSC in a TCAP END package. Figure 3-8 shows the normal dialogue for a normal VBS call.
GSM
3-36
Figure 3-8 Example of a normal VBS messaging dialogue

Anchor MSC MAP_PREPARE_GROUP_CALL BEGIN (AARQ: groupCallControlContext-v3 (INVOKE, (Invoke ID = i, Operation = PrepareGroupCall, Parameters =Teleservice, ASCI Call Reference, Ciphering Algorithm, Group Key Number, Group Key, Priority, CODEC-Information, Uplink Free Indicator))) MAP_PREPARE_GROUP_CALL_ACK CONTINUE (AARE: groupCallControlContext-v3 (RESULT-L, (InvokeID = i, Operation = PrepareGroupCall, Parameters= GroupCallNumber))) MAP_SEND_GROUP_CALL_END_SIGNAL CONTINUE ((INVOKE (Invoke ID = k, Operation=sendGroupCallEndSignal, Parameters = IMSI))) Relay MSC
MAP_FORWARD_GROUP_CALL_SIGNALLING ** CONTINUE ((INVOKE, (Invoke ID = l, Operation = forwardGroupCallSignalling Parameters = IMSI, Uplink Request Acknowledgement Uplink Release Indication Uplink Reject Command, Uplink Seized Comman, Uplink Release Command))) Continued on next page .....
411-2231-827
Standard
02.05
September 2001
3-37
Anchor MSC MAP_PROCESS_GROUP_CALL_SIGNALLING ** CONTINUE ((INVOKE, (Invoke ID = m, Operation = processGroupCallSignalling Parameters = Uplink Request, Uplink Release Indication, Release Group Call)))
Relay MSC
MAP_SEND_GROUP_CALL_END_SIGNAL_ACK END ((RESULT (Invoke ID = k, Operation = sendGroupCallEndSignal, Parameters = none)))
** These messages are relevant for VGCS calls only.
Periodic group call channel retry Sometimes a group call channel fails to establish during a call setup or is lost because of cell congestion, pre-emption, or other reasons. When this occurs, the AMSC and all the RMSCs involved in the call periodically retry to establish the channel. By doing this, the AMSC and RMSCs increase the probability of having all VBS/VGCS group call channels remain established from set up to release. This periodic group call channel retry procedure is performed for every cell in the group call area that does not have its group call channel assigned. This periodic retry procedure is performed in two stages: 1AF and 1CC. Figure 3-9 illustrates the two stages of the periodic retry procedure.
GSM
3-38
Figure 3-9 Two-stages of periodic retry procedure

Assignment Failure with unacceptable cause value received on single immediate retry
Group call channel not assigned at call setup (No response or Assignment Failure with acceptable cause value) Group call channel assigned after single immediate retry
Stage 1AF
Group call channel not assigned after single immediate retry (No response or Assign. Failure with acceptable cause value) Group call channel assigned after periodic retry Periodic Retry (Assign. Failure with acceptable cause value)
IDLE
Stage 2
Assign. Failure with unacceptable cause value received during periodic retry
ABORT
Group call channel not assigned after single delayed retry Group call channel (No response or Assign. lost during on-going Failure with acceptcall (Clear Request or Clear able cause value) Command with acceptable cause value or no response to Clear Command) Group call channel assigned after single delayed retry
Assign. Failure with unacceptable cause value received on single delayed retry
Stage 1CC
Group call channel not assigned at call setup or lost during on-going call (Assignment Failure, Clear Request or Clear Command with unacceptable cause value)
Stage 1AF (Assignment Failure): Single immediate retry stage after an Assignment Failure with an acceptable cause value is received or the TNT2 timer expires waiting for the response. Stage 1CC (Clear Complete): Single delayed retry stage after a Clear Request with an acceptable cause value is received or a Clear Command with an acceptable cause value is generated and the subsequent Clear Complete is received or the TNT3 timer expires waiting for the response. (Delay = 15 seconds) Stage 2: Periodic retry stage after the group call channel fails to get assigned in Stage1AF or Stage1CC. IDLE: The two-stage periodic retry procedure is not active and the VBS/VGCS group call channel is assigned. ABORT: The two-stage periodic retry procedure has been aborted for the remainder of the call and the VBS/VGCS group call channel is not assigned.
411-2231-827
Standard
02.05
September 2001
3-39
Stage 1AF Stage 1AF is performed when the MSC receives a VBS/VGCS Assignment Failure, Clear Request, or Clear Command message with an acceptable cause value at call setup. If the received message contains an unacceptable cause value, the periodic retry procedure aborts. Following is a list of the acceptable cause values for the VBS/VGCS Assignment Failure message: no radio resource available equipment failure O & M intervention terrestrial resource already allocated switch circuit pool requested terrestrial resource unavailable Note: The VBS/VGCS call non-existent cause value is an exception to the rule. Although it is considered an unacceptable cause value for the VBS/VGCS group call channel periodic retry procedure, a single reattempt is made when this cause value is received. This re-attempt is performed after the initial VBS/VGCS Setup procedure is aborted and a new one is started. Following is a list of the acceptable cause values for the Clear Request message: radio interface message failure equipment failure O & M intervention pre-emption
Following is a list of the acceptable cause values for the Clear Command message: equipment failure O & M intervention pre-emption
During stage 1AF, the MSC performs a single immediate retry to establish the VBS/VGCS group call channel. If this immediate retry fails to establish the group call channel and generates a failure message with an acceptable value, the MSC performs periodic retries. If any retry generates a failure message with an unacceptable cause value, the periodic retry procedure aborts. If no response is received on a retry, the procedure continues.
GSM
3-40
For a given cell, it is possible that the periodic retry procedure is never triggered during the call. This possibility occurs when the first received Assignment Failure or Clear Request message, or the first Clear Command message generated by the MSC for the group call channel in that cell contains an unacceptable cause value. Also, if the MSC fails to send a VGCS/VBS Assignment Request message due to any internal MSC error or due to a lack of channels, no further retries are made and the periodic retry procedure ends at that time for that cell. Therefore, after a group call channel is pre-empted by a higher priority call, retries are performed to establish that group call channel, as long as the MSC can find a channel to perform the first retry. If there is still no channel available at the time the MSC tries to perform the first retry, the VGCS/VBS Assignment Request message cannot be sent out and the periodic retry procedure ends at that point for that particular cell. Stage ICC A group call channel reaches stage 1CC when one of the following occurs during an ongoing VBS/VGCS call: the BSC sends a Clear Request message with an acceptable cause value to the MSC, the MSC sends a Clear Command message to the BSC, and the MSC receives the subsequent Clear Complete message the MSC receives a Clear Request message with an acceptable cause value and the TNT3 timer expires waiting for a response to the second Clear Command message sent to the BSC the MSC generates and sends a Clear Command message with an acceptable cause value to the BSC and the MSC receives the subsequent Clear Complete message the MSC generates and sends a Clear Command message with an acceptable cause value to the BSC and the TNT3 timer expires waiting for the response to the second Clear Command message sent to the BSC
During stage 1CC, a single delayed retry is performed to establish the VBS/ VGCS group call channel. The delay period is set to 15 seconds. If this stage fails to establish the group call channel and the cause value in the failure message is an acceptable value, the MSC performs periodic retries. If the failure message received on any retry contains an unacceptable cause value, the periodic retry procedure aborts. If no response is received on a retry, the procedure continues. For a given cell, it is possible that the periodic retry procedure is never triggered during the call. This possibility occurs when the first received Assignment Failure or Clear Request message, or the first Clear Command message generated by the MSC for the group call channel in that cell contains an unacceptable cause value.
3-41
Also, if the MSC fails to send a VGCS/VBS Assignment Request message due to any internal MSC error or due to a lack of channels, no further retries are made and the periodic retry procedure ends at that time for that cell. Therefore, after a group call channel is pre-empted by a higher priority call, retries are performed to establish that group call channel, as long as the MSC can find a channel to perform the first retry. If there is still no channel available at the time the MSC tries to perform the first retry, the VGCS/VBS Assignment Request message cannot be sent out and the periodic retry procedure ends at that point for that particular cell. Period between retries The period between retries is set to the Table BSSC2TMR TNT2 timer + the Group Call Channel Retry (TGCHR) timer. The TGCHR timer is given a default value of 1 minute and is implemented in the BSSC2TMR table in the related MSCs. The TGCHR timer can be selected within the 1 minute to 10 minute range. For example, if VBS/VGCS group calls are known to be up for long periods of time, the TGCHR timer value can be increased to avoid overloading the A-interface unnecessarily and improving the system time. The period may be less than TNT2 timer + TGCHR timer if an Assignment Failure message (with an acceptable cause value) is received by the MSC before the TNT2 timer expires. In this case, the period is the response time plus the TGCHR timer. Inter-MSC handovers VBS supports inter-MSC handover functionality using circuit connections. This functionality includes the following: inter-MSC handover (MSC-A to MSC-B) subsequent handover (MSC-B to MSC-B) inter-MSC handback (MSC-B to MSC-A)
The following figures show the message flows for each type of VBS interMSC handover. An intermachine trunk (IMT) is used to set up the speech path between two MSCs. This type of handover uses the existing handover functionality implemented on MSC switch.
GSM
3-42
Figure 3-10 Inter-MSC handover (MSC-A to MSC-B) with call terminating request by the originating talker
BSSold
HO Required
MSC-A
[HO Request Prepare HO Tgt_Cell_ID]
MSC-B
BSSnew
MS
HO Request HO Request Ack [HO Request Ack Prepare HO Ack HON]
IAM [HON] ACM HO Command HO Detect PAS [HO Detect] HO Complete SES [HO Complete]
Clear Cmd/Cmp SCCP RLSD/RLC
ANM
Termination Request PAS [Termination Req.] Termination FAS [Termination] Release SES Ack Clear Cmd/Cmp SCCP RLSD/RLC
411-2231-827
Standard
02.05
September 2001
Nortel Networks Confidential Figure 3-11 Subsequent handover (MSC-B to MSC-B) BSSold
HO Required Prepare Subsequent HO [HO Request Tgt_Cell_ID Tgt_MSC_Num] Prepare HO Ack [HO Request Ack HON]
3-43
MSC-B
MSC-A
MSC-B'
BSSnew
[HO Request Prepare HO Tgt_Cell_ID] HO Request
HO Request Ack
IAM [HON]
ACM Prepare Subsequent HO Ack [HO Request Ack] HO Command HO Detect PAS [HO Detect] HO Complete SES [HO Complete] ANM Clear Cmd/Cmp SCCP RLSD/RLC Release SES Ack
Note: After a subsequent handover, MSC-B becomes MSC-B. So the call termination signaling is the same as Figure 3-11.
GSM
3-44
Figure 3-12 Inter-MSC handback (MSC-B to MSC-A) BSSnew MSC-A MSC-B BSSold
Prepare Subsequent HO [HO Request Tgt_Cell_ID Tgt_MSC_Num]
HO Required
HO Request
HO Req Ack Prepare Subsequent HO Ack [HO Request Ack] HO Command HO Detect
HO Complete SES Ack Clear Cmd/Cmp SCCP RLSD/RLC Release
Handover failures When an inter-MSC handover occurs to a target MSC outside the talkers group area, the MSC-A verifies the MSC-B against the group area and the verification fails. The MSC-A rejects the handover and sends an HO Required Reject. When an inter-MSC handover occurs to a target cell outside the talkers group area, the MSC-A sends a MAP Prepare HO request to the MSC-B. The target cell is verified against the group area and the verification fails. The MSC-B rejects the handover by sending a Prepare HO Ack [HO Failure] message with a cause value of Invalid Cell. Abnormal responses from the MSC-B When the MSC-B responds with a Reject, Error, or Abort, the transaction is terminated at MSC-A. A Handover Required Reject is sent back to the serving BSS reflecting the failure cause associated with this cell. The call is maintained on the old channel.
411-2231-827
Standard
02.05
September 2001
3-45
Handover failure on the MSC-B side If the traffic channel allocation is not possible, the HO Failure is received by BSS on MSC-B. This failure is reported to the MSC-A in a Prepare HO Ack message. The HO Number is not included. The call is maintained on the old channel. Talker disconnects before receiving a Prepare HO Ack When the VBS talker disconnects at the beginning of the handover before the MSC-B responds with a Prepare Handover Ack, the MSC-A sends no notification to MSC-B. When the MSC-A receives a response to the original Prepare Handover message, it responds with an Abort which informs MSC-B to terminate its transaction. HO failure on the MSC-A side If the HO Failure is received in response to an HO command, the inter-MSC handover attempt is terminated and an Abort is sent to the MSC-B to clean resources. The call is maintained on the old channel. No HO Complete on the MSC-B side If the HO Complete is not received from the BSS on the MSC-B side during a specified time, the MSC-B sends an Abort to the MC-A. The resources on the MSC-B are freed. The entire VBS call is maintained on the old channel. Errors and abnormal conditions Following are the types of errors and abnormal conditions that affect the behavior of group call: datafill errors authorization errors resource failures unexpected behavior protocol errors race conditions
Datafill errors Datafill errors usually are caused by inconsistent datafill existing in DMS-MSC tables or incorrect datafill resulting in call establishment failure
Authorization errors Authorization errors occur when an unauthorized subscriber or dispatcher attempts to originate a group call or join an ongoing group call.
GSM
3-46
Resource failures A VBS resource failure occurs when the DMS-MSC attempts to assign a terrestrial circuit and the DMS-MSC receives a VGC/VBS call non-existent message. Unexpected behavior The following unexpected behavior failures can occur during or after a VBS call is established: the IMSI Detach from the VBS originator takes the VBS call down a radio failure on the VBS originators dedicated link a radio failure on a broadcast channel the group call register (GCR) access fails
Protocol errors The following protocol errors can affect VBS calls: syntactic errors receipt of unexpected messages receipt of unexpected information elements receipt of unexpected transaction ID mismatch in teleservice type
Race conditions A race condition occurs if a dispatcher attempts to join an ongoing call that is terminating. If this race condition occurs, the joining dispatcher is released with a cause value of temporary failure.
How the DMS-MSC supports VBS
The DMS-MSC supports VBS service by performing the following functions: stores subscription information sent from the DMS-HLR performs subscription checks at the VLR implements the GCR and its functionality establishes a call to multiple cells establishes a call to multiple dispatchers terminates and releases VBS calls performs handovers for mobiles in VBS calls
How the DMS-HLR supports VBS
The DMS-HLR supports VBS service by performing the following functions: stores VBS subscription information on a per user basis
3-47
stores data required by the service applications associated with VBS sends VBS subscription information to the DMS-MSC and VLR for the following reasons: in response to an update location (UL) MAP request in response to a restore data (RD) MAP request because subscriber data changed at the DMS-HLR
screens home PLMN roaming data to determine if VBS data should be sent to the VLR or if roaming should be denied sends only the roaming specific data to the DMS-MSC and VLR when a mobile roaming outside of its home PLMN
This section discusses how VBS interacts with the following features: group call reference presentation supplementary services eMLPP operator determined barring intelligent feature usage dispatcher talk token
Group call reference presentation Destination dispatchers and calling service subscribers If the destination dispatchers subscribe to calling line identification presentation (CLIP), the group call reference (GCRef) is presented to the destination dispatchers. The calling party number is not presented to the destination dispatchers. The destination service subscribers always display the group ID regardless of their subscription status to CLIP. Calling dispatchers and calling service subscribers If a calling dispatcher subscribes to connected line identification presentation (COLP), the GCRef is presented to the calling dispatcher. The GCRef always is presented to the calling service subscriber through the connect message sent to the mobile station. It is up to the mobile station to display the GCRef as the connected number. No destination subscriber or dispatcher identities ar presented to the calling party. The DMS-MSC always overrides any presentation restrictions (calling line identification restriction [CLIR] and connect line identification restriction
3-48
[COLR]). The DMS-MSC always includes the GCRef as the presented number. Supplementary services Supplementary services are applied on a per basic service group (BSG) basis. Service subscriber originated VBS calls always have the BSG of VBS. Therefore, only the supplementary services that can be provisioned for a VBS service subscriber apply to the service subscribers in the call. VBS dispatchers have the teleservice of telephony. Therefore, supplementary services provisionable for Telephony apply to the dispatcher. A VBS service subscriber can use only a particular subset of supplementary services. Table 3-1 indicates if a specific supplementary service can be used by a VBS subscriber.
Table 3-1 Supplementary services applicable to a VBS service subscriber Supplementary service Enhanced Multi-level Priority Preemption (eMLPP) Functional Addressing (FA) Calling Line Identification Presentation (CLIP) Calling Line Identification Restriction (CLIR) Connected Line Identification Presentation (COLP) Connected Line Identification Restriction (COLR) Call Forwarding Unconditional (CFU) Call Forwarding Busy (CFB) Call Forwarding on No Reply (CFNRy) Call Forwarding on Mobile Subscriber Not Reached (CFNRc) Call Waiting (CW) Hold Multi-party Service (MPTY) Closed User Group (CUG)
sheet 1 of 2
Applicable to VBS subscriber? Yes No Yes Yes Yes Yes No No No No No No No No
411-2231-827
Standard
02.05
September 2001
3-49
Table 3-1 Supplementary services applicable to a VBS service subscriber Supplementary service Advise of Charge (Information) (AoCI) Advise of Charge (Charging) (AoCC) User-to-user Signaling 1 (UUS1) Barring of All Outgoing Calls (BAOC) Barring of Outgoing International Calls (BAIC) Barring of Outgoing International Calls except those directed to the Home PLMN country (BOIC-exHC) Barring of All Incoming Calls (BAIC) Barring of Incoming Calls when Roaming outside the Home PLMN country (BIC-Roam) Explicit Call Transfer (ECT) Local Calls Only (LCO) Class of Service (COS) Hotbill Account Code (AC) Calling Name Display (CNAM) Malicious Call Trace (MCT) Extension Service (EXT) Anonymous Call Rejection (ACRJ)
sheet 2 of 2
Applicable to VBS subscriber? No No No Yes No No No No No No No No No No No No No
Dispatchers in VBS calls have the teleservice of telephony. Therefore, telephony-related supplementary services apply to the dispatcher-originated VBS call. Following are the exception or special cases: CLIP is supported for dispatcher in that the GCRef number (calling party number for PRI) is available for presentation to the destination dispatchers.
GSM
3-50
eMLPP
The network always overrides CLIP in such a way that the GCRef number (calling party number for PRI) is available for presentation to the destination dispatchers. COLP is supported for dispatchers and originating service subscribers in that the GCRef number (calling party number for PRI) is available for presentation to the calling party, regardless of whether or not the subscriber has COLP subscription. The network always overrides CLOR in such a way that the GCRef number is available to the calling dispatchers. BAOC is applicable, if subscribed to, with the possible exception of high priority calls. CFB is applicable for dispatchers if the group call does not have a higher priority than the present call. CUG is not applicable. Being a member of a CUG has no impact on receiving and establishing voice group calls.
The eMLPP provides different levels of precedence for call setup for VBS. Precedence is defined as the call priority in a call. There are seven priority levels defined for eMLPP. The eMLPP also provides for called party pre-emption which allows an active mobile station involved in a VBS call to answer an incoming call if it has a higher priority level than the ongoing call. Priority levels for group calls are datafilled in GCR and only can be changed through provisioning. Precedence Following are the messages that contain the precedence of the call: CM-SERV_REQ. A priority level is included within each set of VBS call attributes stored in the group call register (GCR) if eMLPP is applied. The priority level is provided by the GCR to the DMS-MSC with the call attributes. For VBS establishment, the calling mobile station may indicate a priority level in the service request message. This priority level can be applied to the dedicated link of the calling mobile station as long as the GCR does not provide a different level. If the priority level provided by the GCR is different from the incoming priority level, the priority level of the GCR is applied to the dedicated link of the calling mobile station. Connect. The group or broadcast call reference includes the priority level applied to the group or broadcast call in the network. This priority level can be different from the one indicated in the service request message.
411-2231-827
Standard
02.05
September 2001
3-51
NOTIF_REQ. The priority level is indicated with the related notification request messages for the called mobile stations.
Called party pre-emption If a mobile station currently involved in a VBS call receives a subsequent notification that another VBS call is attempting to reach the mobile station, the called party pre-emption occurs as follows: The notification includes the related priority level of the call. If the new call has a higher priority level, the mobile station may automatically leave the ongoing VBS call and respond to the new call.
Similarly, if a paging request message for a point-to-point call is attempted towards the mobile station involved in a VBS call, the called party pre-emption occurs as follows: The paging request includes the related priority level of the call. If the priority level in the paging request is higher than the priority level of the ongoing call, the mobile station may automatically leave the ongoing VBS call and respond to the page.
Operator determined barring The facts that apply to the subscriber controlled barring determine if operator determined barring (ODB) can be used with a VBS subscriber. Table 3-2 indicates if operator determined barring is applicable for a VBS subscriber.
Table 3-2 When ODB is applicable to a VBS subscriber ODB ODB outgoing ODB incoming ODBMISC ODBECT Applicable to VBS subscriber? Yes for Barring for All Outgoing Calls No No No
Intelligent network feature usage The DMS-MSC contains an integrated SSP used to support intelligent networking applications. The following paragraphs detail IN support for group and broadcast calls for both dispatchers and service subscribers. Dispatcher originated group calls Since dispatcher originated group calls are treated as normal mobile or fixed trunk network originations, intelligent networking functionality is fully supported for this type of call. Support includes the originating triggers
GSM
3-52
detection point 2 (DP2), detection point 2-trunk (DP2-T), and detection point 3 (DP3). An example of an IN service on a dispatcher originated group call is short code dialing. For this application, a dispatcher dials a short code that triggers DP3 through the appropriate translations datafill. Upon triggering DP3, the SSP sends an InitialDP to the SCP. The SCP sends a Connect message with the GCRef as the new called number. By retranslating on this new number, the call is identified as a group call. The remaining call flow is identical to a dispatcher dialing a GCRef explicitly. Subscriber-originated group calls Partial intelligent networking feature functionality is supported for subscriber-initiated group calls. Particularly, a group call subscriber also may subscribe to originated IN service DP2. Similar to group and broadcast call basic teleservices and their associated group IDs, IN subscription information is stored in the DMS-HLR and VLR. When a group call is initiated by a service subscriber, the VLR performs group call screening and screens for subscription to originating IN DP2. If subscription to IN DP2 exists, the VLR triggers the DP2. Upon triggering DP2, a query is sent to the SCP in the form of an InitialDP message. The SCP modifies the behavior of the call by sending response messages. The SCP response messages can be used for the purpose of rejecting the call continuing the call modifying information regarding the call billing
An example of IN services applied to a subscriber-initiated group call is a time of day rejection. In this application, an operator may wish to allow only a subscriber to initiate a group call during a particular time window. If the time of the origination does not fall within the range of the window, the SCP responds to the InitialDP message with a Release Call message. Call intercept Call intercept is not supported. However, this feature does not introduce software to block dispatchers from being specified as a CI target. Therefore, partial event records may generate. No new CI functionality is provided for service subscriber originations or for mobiles in cluster call termination.
411-2231-827
Standard
02.05
September 2001
3-53
Dispatcher Talk Token Interaction occurs between the Dispatcher Disconnect feature and the Dispatcher Talk Token feature since both features use DTMF signaling. Dispatcher Talk Token uses two office parameters START_TO_TALK_REQUEST and END_TO_TALK_REQUEST to store the same number and type of digits, namely the # and the * as used by this feature for the office parameter DISP_DISC_SEQ. A warning message is displayed to the operator trying to datafill OPARM DISP_DISC_SEQ with the same datafill as START_TO_TALK_REQUEST or END_TO_TALK_REQUEST. The datafill request is rejected. The warning message indicates that the requested datafill change matches with an existing datafill in one of the other office parameters. These office parameter datafills will never hold the same sequences at one time.
Datafill required for VBS service

The following tables must be datafilled for VBS service: table OFCENG table OFCVAR table BSSC2TMR table DNROUTE table GCR table GCAREA table LACGID table XXCODE and XXHEAD table GHLRVGS table GHLRVBCA table GHLRBSVC table GHLRSSOP table GHLRNDSC table SERVCNFG
The following paragraphs briefly describe these tables. Note: For detailed information on these tables, refer to NTP 411-2231455, GSM DMS-MSC Office Parameters Reference Manual, NTP 4112231-495, GSM DMS-MSC Customer Data Schema, and NTP 411-2831151, GSM DMS-HLR Customer Data Schema.
GSM
3-54
Table OFCENG datafill In this table, datafill parameters GID_LENGTH MAX_GROUP_CALL_SUBS_IN_VLR
GID_LENGTH Office parameter GID_LENGTH determines the length of group ID (GID) portion within group call reference (GCREF). The possible range of values are 0 to 6. The default value is 3. MAX_GROUP_CALL_SUBS_IN_VLR Office parameter MAX_GROUP_CALL_SUBS_IN_VLR allows the operating company to provision the number of subscribers that may have group call data in the VLR. The value of MAX_CALL_SUBS_IN_VLR cannot exceed the current value of MAX_SUBSCRIBERS_IN_VLR. Each increment of MAX_GROUP_CALL_SUBS_IN_VLR translates to 1024 (1K) entries in the table. For example, if the parameter value is 3, that means 3K entries are allocated for the table. Through the MAX_GROUP_CALL_SUBS_IN_VLR parameter, the operating company can control the amount of memory used to store group call data. The range of values for MAX_GROUP_CALL_SUBS_IN_VLR is 0 to 50 (represented in thousands). The default value is 0. Table OFCVAR datafill In this table, datafill parameters GSM_VGCS_VBS_ORIG_XLAENTRY GSM_VGCS_VBS_TERM_XLAENTRY DISP_DISC_SEQ NUMBER_OF_DMS_SYSTEM_TIDS
GSM_VGCS_VBS_ORIG_XLAENTRY This parameter determines the entry point into XLAENTRY table only if table XLAENTRY has an index that is equal to the GSM_VGCS_VBS_ ORIG_XLAENTRY number. Provision this matching XLAENTRY index for VBS and VGCS service subscriber originated calls. When provisioning this parameter, follow the derivation of the group call reference (GCRef) from the dialed GID, LAC, and Cell ID. The GCRef enters translations indicated by this parameter.
411-2231-827
Standard
02.05
September 2001
3-55
If the GSM_VGCS_VBS_ORIG_XLAENTRY number does not match the XLAENTRY index, the default index (which is 0) is used to enter into the XLAENTRY table. The range of values for this parameter is 0 to 1023. The default value is 0. GSM_VGCS_VBS_TERM_XLAENTRY This parameter determines the entry point into XLAENTRY table only if table XLAENTRY has an index that is equal to the GSM_VGCS_VBS_ TERM_XLAENTRY number. Provision this matching XLAENTRY index for VBS and VGCS calls that require translations toward dispatchers and relay MSCs. If the GSM_VGCS_VBS_ORIG_XLAENTRY number does not match the XLAENTRY index, the default index (which is 0) is used to enter into the XLAENTRY table. The range of values for this parameter is 0 to 1023. The default value is 0. DISP_DISC_SEQ Office parameter DISP_DISC_SEQ stores the predetermined dispatcher disconnect sequence digits. These digits are matched with the incoming DTMF tone sequences from authorized dispatchers while they attempt to tear down an on-going group call. NUMBER_OF_DMS_SYSTEM_TIDS This parameter controls the size of a logical terminal identifier pool required by active group call feature control software for internal messaging purposes. The range of values for this parameter is 0 to 32767. The default setting for this office parameter is (NCCBS) * (0.04). This default value is an estimated required number assuming 5% of all MSC calls are group calls. Table BSSC2TMR datafill Table BSSC2TMR contains BMAP class two engineerable timers that can be associated with a particular location area of a DMS-MSC. In particular, this table contains information regarding the Group Call Channel Retry timer. This timer is controlled by field TGCHR. The range of values for field TGCHR is 60 seconds to 600 seconds. The default value is 60 seconds. Table DNROUTE datafill This table allocates group call numbers (GCNs). GCNs are temporary routing numbers used to establish calls for R-MSC at group call setup time. When processing a Prepare Group Call message from the A-MSC, the R-MSC MAP
GSM
3-56
service allocates a GCN. This allocated GCN is sent back to the A-MSC embedded in the Prepare Group Call Ack message. This temporary GCN number is later released by the R-MSC when the call is routed back to the RMSC. Table GCR datafill Table GCR serves as the primary database for the VGCS and VBS. It stores the call attributes per group call references in the MSC. The key that is used for indexing into table GCR is GCREF (Group Call REFerence). Table GCAREA datafill Table GCAREA is indexed by GCA ID digits in order to retrieve the list of cells that are present in a group call area. In Phase 1, a maximum of 20 cells can be datafilled in a GCA. Table LACGID datafill Table LACGID is indexed by the multi-part key combination of LAC+CELL ID+GID. This table retrieves the GCA digits datafilled against a LAC+CELL ID+GID combination. Table XXCODE and XXHEAD datafill XXCODE and XXHEAD stands for all the following universal translations tables: AMHEAD and AMCODE PXHEAD and PXCODE CTHEAD and CTCODE FAHEAD and FACODE OFCHEAD and OFCCODE FTHEAD and FTCODE ACHEAD and ACCODE NSCHEAD and NSCCODE
These tables add a new option to the existing database query (DBQ) selector to identify group/broadcast calls and the need to perform GCR query screening. The DBQ option is: GCQ (Group Call Query). When translations (UXLA) on the called number hits the GCQ option, it is identified as a group or broadcast call. At this point, the system performs GCR screening on the group call reference (GCRef).
411-2231-827
Standard
02.05
September 2001
3-57
To handle the possibility that retranslation on the same GCRef could occur, the following existing option can be used in conjunction with the GCQ option: DBQCONT. Retranslations on the GCRef results in a loop. The DBQCONT option can be used in these cases if deemed necessary. This option specifies a new translation system (XLASYS) and translation name (XLANAME) to use when re-entering UXLA. Specifying a new XLASYS and XLANAME keeps looping from occurring. Table GHLRVGS datafill Table GHLRVGS stores subscriber VBS and VGCS provisioning details. The tables key consists of a subscribers IMSI and the VBS or VGCS service with which the subscriber is provisioned. If a subscriber is provisioned with both VBS and VGCS, two tuples exist for the subscriber (one tuple for each service). Each tuple stores the group IDs the subscriber is allowed to call. Each subscriber can be datafilled with up to 50 group IDs for each service. The group IDs consist of between 1 and 3 BCD digits. For VBS only, a boolean (Y/N) is collocated with each group ID. This boolean indicates if the subscriber is allowed to initiate a call to that particular group. Another boolean (Y/N) indicates if the subscriber can use the VBS or VGCS service when roaming out of the home PLMN. Subscriber information must be datafilled in table GHLRBSVC before a tuple can be created for a subscriber in table GHLRVGS. The subscriber must be assigned the VBS or VGCS in table GHLRBSVC before the subscriber can be detailed in table GHLRVGS. Note: A large subscriber database may slow access to table GHLRVGS. Table GHLRVBCA datafill Table GHLRVBCA stores the supra-PLMN group IDs. These supra-PLMN group IDs allow a VBS subscriber to place a VBS call even when the subscriber outside the home PLMN. A group ID that is not included in table GHLRVBCA can be datafilled in table GHLRVGS against an IMSI. In this case, the group ID is assumed to be usable only within the home PLMN.
GSM
3-58
Table GHLRBSVC datafill Table GHLRBSVC contains the GSM HLR basic service data for a subscriber. Table GHLRBSVC allows basic services to be added against an IMSI along with an MSISDN. Each basic service and associated data for a subscriber is represented by a separate tuple in table GHLRBSVC. A subscriber may have separate MSISDNs for all or some basic services with the following exceptions: Short Message Service Mobile Terminating (SMMT), Short Message Service Mobile Originating (SMMO), and Telephone (TPHNY) must have the same MSISDN. Alternate Speech and Data Circuit Duplex Asynchronous (ALTSPCDA) and Alternate Speech and Data Circuit Duplex Synchronous (ALTSPCDS) must have the same MSISDN. Speech followed by Circuit Duplex Asynchronous (SPCHCDA) or speech followed by Circuit Duplex Synchronous (SPCHCDS) must have the same MSISDN.
Table GHLRAUTH must be datafilled before table GHLRBSVC. Table GHLRSSOP datafill This table contains option data for provisioning, registering, and activating supplementary services associated with a subscriber or basic service group. This table contains one tuple per supplementary service provisioned against the IMSI. The tuples are identified with a three-part key consisting of the IMSI MNC, the IMSI MSIN, and the supplementary service. Note: To datafill a subscriber with a supplementary service option in table GHLRSSOP, first datafill the subscriber in tables GHLRAUTH and GHLRDATA and ensure the subscriber has an ISTATUS of D, A, or N. Table GHLRNDSC datafill This table contains data associated with VLR screening classes. The DMSHLR uses the contents of table GHLRNDSC to determine which services must be sent to a particular VLR (considering its class and version) in certain special cases, which encoding method must be used (phase 1, 2, or 2+) for the propagation of the services how the HLR must react in the event a service is not supported
Table GHLRNDSC also includes screening options for VBS and VGCS. The class name must be datafilled in table GHLRSCMP before it is datafilled in table GHLRNDSC.
411-2231-827
Standard
02.05
September 2001
3-59
Table SERVCNFG datafill Subfield Txx in this table contains the Connect Indication Timer (Txx) values in seconds.
Log reports associated with VBS service

The following log reports contain information regarding VBS service: GVLR300 GMCS302 GBCS300 GGCN300
The following paragraphs briefly describe these log reports. Note: For more detailed information on these log reports, refer to NTP 411-2231-515, GSM DMS-MSC Log Reference Manual. The GVLR300 log report This log report generates when the VLR has no memory to store VBS data at subscription time. This report informs the craft person of VLR memory exhaustion and possible action to take. The GMCS302 log report This log report indicates illogical triggering of the GCR query occurred in the R-MSC due to datafill errors. The GBCS300 log report This log report indicates failures in attempting to establish a group call in the base station subsystem (BSS). The GGCN300 log report This log is generated when a GC number can not be allocated.
Operational measurements associated with VBS service

The following operational measurement (OM) groups contain information regarding VBS service: MSCGCS MCLUSTER GHLRBS GMAPCH2
The following paragraphs briefly describe these OM groups.
GSM
3-60
Note: For detailed information on these OM groups, refer to NTP 4112231-815, GSM DMS-MSC Operational Measurements Reference Manual, and NTP 411-2831-814, GSM DMS-HLR Operational Measurements Reference Manual. Group MSCGCS This OM group captures the usage information of VGCS and VBS services. In particular, this group records the number of times the service is invoked (successfully and unsuccessfully) how it is invoked (service subscriber versus dispatcher versus Network Initiated group call origination)
Group MCLUSTER The MCLUSTER OM group records the events that take place in a mobile cluster call (VBS or VGCS) terminating to a list of cells in the service area. Group GHLRBS This OM group maintains statistics related to the DMS-HLR basic services. In particular, registers in this group peg the number of subscribers provisioned with the VBS or VGCS basic service. Group GMAPCH2 This OM group measures the number of requests and responses received for each Prepare Group Call operation, the number of Forward Group Call, and the number of Process Group Call Operations that are implemented in the MAP layer.
Billing
3
The existing Teleservice Module captures the usage of VBS call services. The code for VBS is 92. Figure 3-13 is an example of a VBS call billing record.
411-2231-827
Standard
02.05
September 2001
Nortel Networks Confidential Figure 3-13 VBS call billing record MSCD GCDR600 JAN04 23:27:15 3751 INFO Billing Record Data
3-61
Location: GSMMSC Software Call Recording HEX ID=AA STRUCT CODE=10002C CALL CODE=001C STUDY IND=0C CALL FORWARDING IND=0C CALLING PARTY=1CFFFFFCFFFFFF505021120311003C CALLING NUM=2C01000CFFFFFFFF0411002131001C CALLED NUM=0C01000CFFFFFFF61601112C CALLING EQUIP=FFFFFFFFFFFFFFFFFFFFFC ADDITIONAL INFO=FFFC CALLTS: CH ALLOC=FFFFFFFFFFFFFFFC ANSWER=706104232711400C DISC=760104232714200C REL=760104232714200C OFF-AIR-CALL-SET-UP=0C HALF-RATE-IN-USE=0C CAUSE FOR TERM=000C CALL REFERENCE=03475C MS CLASSMARK=FFF0FFFC CLASSMARK TS=FFFFFFFFFFFFFFFC DIALED DIGITS=6CFFFFFFFFFFFFFFFFFFC OG TRUNK GROUP=00719C OG TRUNK MEMBER=00001C OG ROUTE GROUP=086C TRK SEIZ TIME=760104232711000C CALLING SUBSCR CTGY=000C CALL INDICATOR=0000000C CALL DURATION=0000003C DIAGNOSTIC=00016C MSCID=01101CFFFFFFFFF614180400000C RECORD NUMBER=0000290C MC=006C TELESERV=092C TIME=760104232711000C MC=000C NOTE #1: Dialed Digits=GID NOTE #2: Called Num=GCRef
GSM
3-62
Voice Group Call Service (VGCS)

Purpose of Voice Group Call Service (VGCS)
VGCS enables a pre-defined set of destination subscribers in a pre-defined geographical area and entitled dispatchers to hold speech conversations. Figure illustrates VGCS.
Figure 3-14 Voice Group Call Service
Shunting Leader Shunting Team Members
Driver
Shunting Group Call
Dispatcher
VGCS is an ASCI teleservice that is available only for speech calls. The functional difference between VBS and VGCS is that VGCS allows subscribers other than the call initiator to use VGCS-specific uplink request signaling to speak to the group. Multiple VGCS calls may exist simultaneously. These calls may be placed to different groups of destination subscribers located in the same group call area (GCA). Also, parallel VGCS calls may be placed to the same group of destination subscribers in different, possibly overlapping GCAs.
How VGCS works
With VGCS, a standard full-duplex channel is provided to the calling subscriber and dispatchers during call setup. Simplex down-link channels are allocated to all destination service subscribers, with one common down-link per cell of the VGCS broadcast area. (A destination service subscriber is the party to which a VGCS call is directed.)
3-63
Establishing a VGCS call A VGCS call can be established by either a VGCS service subscriber or dispatcher
A VGCS call is established to all the dispatchers identified in the group call register (GCR) a list of up to 25 cells identified in the group call area (GCA) Note: Group call areas are predefined in the network. The DMS-MSC notifies destination subscribers of the incoming VGCS call. The subscribers receive the notification over the notification channel. Subscribers are notified as a group through the group ID. Dispatchers are called individually by their ISDN or MSISDN numbers. A service subscriber that leaves the GCA during an ongoing VGCS call ceases to be a destination subscriber. Likewise, a service subscriber that enters the GCA during an ongoing VGCS call becomes a destination subscriber. When the service subscriber enters the GCA, the subscriber receives a notification message about the VGCS call. The subscriber receives the notification message over the notification channel. Subscriber-initiated calls To originate a VGCS call, the service subscriber uses the MMI functions on the mobile equipment to select VGCS as the call type. The requested type of service is sent to the DMS-MSC in a CM_Service_Request message. After the subscriber sets the type of service, the subscriber dials the group ID. The group ID digits are sent to the DMS-MSC in a DTAP Setup message. The visitor location register (VLR) determines if the service subscriber is entitled to originate a VGCS call. If the subscription check is successful, the call proceeds forward. If the subscription check fails, the origination is denied and a cause value is sent to the originator. The DMS-MSC uses the information received in the CM_Service_Request message to determine if the call is a VBS or VGCS call. The DMS-MSC then uses the group ID and the subscribers cell of origin (COO) to determine the group call reference (GCRef). Once all checks are passes, the system provides a connection for the VGCS call. The network notifies the calling subscriber when the VGCS call is successfully established. The notification indicates the calling subscriber can start to speak.
GSM
3-64
VGCS allows only one talking service subscriber at any moment. Additionally, up to four dispatchers can talk simultaneously at one time. The right to be a talking subscriber is allocated on a first-come first-served basis without queuing. A service subscriber must send an uplink request message to indicate when they wish to talk. The message is sent to the network. The subscriber becomes a talking subscriber when there is no other talking subscriber. A talking subscriber sends an uplink release message to indicate they want to become a listening subscriber. Dispatchers can talk at any moment without any need to signal the wish to talk. The calling subscriber always has the uplink at call origination. The calling subscriber maintains the uplink until he releases the uplink. A separate full duplex channel is not allocated on an uplink grant. Instead, to preserve radio resources, the common group channel uplink is used to carry the talker speech to the rest of the group. The calling subscriber placing the VGCS call must remain within the broadcast area during the call. The call is taken down if the calling subscriber leaves the broadcast area. Dispatcher-initiated calls A dispatcher is a railways employee. A dispatcher is connected to the network through standard radio links or ISDN. Dispatchers using the GSM-R network can be located outside the group call area. To place a VGCS call, a dispatcher dials <country code> + <national destination code> + 5 + 0 + GCRef Dispatchers do not have to subscribe to VGCS. Therefore, no subscription checking is performed at the VLR. The system does perform origination entitlement checking. To verify the dispatcher is entitled to originate a VGCS call, the system ensures the dispatchers calling party address is present in the group call register (GCR). If the check fails, the origination is denied and a cause value is sent to the originator. Once the dispatcher passes the origination entitlement checking, the system provides the one-way broadcast connection. While the system performs checking, the dispatcher hears ring-back tone. The ring-back tone stops once the connection is made.
411-2231-827
Standard
02.05
September 2001
3-65
Network-initiated calls To place a network-initiated VGCS call, the network operator must provision DMS-MSC translations to derive the following called number: <country code> + <national destination code> + 5 + 7 + GCRef The DMS-MSC does not perform entitlement checking on network-initiated calls. Joining an ongoing VGCS call If a dispatcher is entitled to originate a group call, the dispatcher can join an ongoing VGCS call. To join the call, the dispatcher dials the GCRef of the ongoing call. Only dispatchers who are entitled to originate a VGCS call are allowed to join an ongoing VGCS call. A service subscriber cannot originate a call to an ongoing VGCS call. A network operator can join an ongoing VGCS call only if the calling party is a dispatcher provisioned in the entitled originating dispatcher list in the GCR. Terminating a VGCS call The VGCS call is terminated if the calling subscriber has access to the uplink and releases the call the call has exceeded a pre-defined period of time during which no uplink activity has occurred and no service subscriber has attempted to retrieve the uplink within three seconds after a call takedown warning tone has been issued all the parties in an all-dispatcher VGCS call has released authorized dispatcher involved in the group call dials the predetermined DTMF dispatcher_disconnect sequence
Land line dispatchers A fixed line trunk-based dispatcher (ISUP/PRI) that is involved in a group call and wants to tear down the call should signal a disaptcher_disconnect request. This dispatcher_disconnect request is sent using the predetermined DTMF tone sequences from the dispatchers terminal or through external equipment connected to the dispatchers terminals. Mobile dispatchers A mobile dispatcher that is involved in a group call and wants to tear down the call should send a dispatcher_disconnect request from their terminal
GSM
3-66
input the predetermined dispatcher_disconnect DTMF tone sequence on their terminal
The dispatchers mobile terminal sends a DTAP message to the DMS-MSC to initiate call take down. Mobile dispatchers do not transmit DTMF tones inband. Instead, the mobile sends a GSM_START_DTMF signal with an information element identifying the requested digits. The DTMF tone is used as a conditional trigger to force down the group call. The predefined group of destination subscribers A group ID identifies the predefined group of destination subscribers. A destination subscriber can be either a fixed line or mobile subscriber. Fixed line and mobile subscribers identified as dispatchers can be located anywhere during a broadcast. Mobile destination subscribers not identified as dispatchers must be located within the broadcast area in order to receive the broadcast. When a mobile destination subscriber leaves the broadcast area, their association with the broadcast call is dropped. The association is resumed when the subscriber re-enters the broadcast area and chooses to rejoin the call. Subsequent talkers The system verifies the group ID of all subsequent talkers on the group call. When a subsequent talker begins talking, the system checks the talkers group ID against the link the subscriber is on. GSM-R networks with multiple DMS-MSC serving areas Figure 3-15 depicts the distribution of group calls in GSM-R networks consisting of multiple MSC serving areas.
411-2231-827
Standard
02.05
September 2001
3-67
Figure 3-15 Distribution of group calls in GSM-R networks with multiple DMS-MSC serving areas HLR SCP
MAP
INAP ISUP
D D F
R-MSC VLR
terrestrial trunk
R-MSC
GCR
MAP-E
PRI
A-MSC
ISUP
VLR
GCR
VLR
GCR
ISUP
BTS not shown BSC2 GC area

CC-DTAP
BSC1
BSC3
X
BCC-DTAP GCC-DTAP
CC-DTAP
X X
Cell
Cell X X X X
Key: D F G ----- VGCS/VBS dispatcher (mobile or fixed (ISUP or PRI)) ----- call over fixed network ----- VGCS talker B X ----- VBS originator ----- VGCS/VBS service subscriber
Within a network, each defined group is assigned one anchor DMS-MSC (AMSC). The other DMS-MSCs in the network are configured as relay DMSMSCs (R-MSCs) for the defined group. The R-MSC controls the group call area cells that are not controlled by the A-MSC.
GSM
3-68
This functionality supports Establishing a group call from a R-MSC to a group call area that includes an A-MSC and up to 2 additional R-MSCs Establishing a group call from an A-MSC to a group call area that includes an A-MSC and up to 3 R-MSCs Uplink management between the MSCs through MAP-E for VGCS calls only Group call takedown Enhancements to group call register (GCR) Implementing the group call number (GCN) database and its functionality Switching subsequent VGCS talker (on group channel) speech through a R-MSC conference port
Messaging The DMS-MSC Mobile Application Part (MAP) software supports messages for signalling between the anchor MSC and relay MSC in a VGCS call. The MAP messages for the VGCS call between the anchor and relay switches are Prepare Group Call Prepare Group Call Ack Process Group Call Signaling Forward Group Call Signaling Send Group Call End Signal Send Group Call End Signal Ack
In each MSC, the Mobile Application Part (MAP) interacts with the Advanced Speech Call Items (ASCI) handling process in order to provide the necessary functionality required to perform the Group Call procedures. Prepare Group Call The anchor MSC invokes MAP_PREPARE_GROUP_CALL service to inform the relay MSC about a group call setup. This is a confirmed service which means, in response to the MAP_PREPARE_GROUP_CALL message the receiving entity will return a MAP_PREPARE_GROUP_CALL confirmation. Prepare Group Call Ack The R-MSC sends a Prepare Group Call Ack message to the A-MSC in response to the Prepare Group Call message.
411-2231-827
Standard
02.05
September 2001
3-69
Process Group Call Signaling The relay MSC invokes the MAP_PROCESS_GROUP_CALL_ SIGNALLING service to indicate to the anchor MSC that the uplink is requested by the subscriber roaming in the relay MSC area. This service does not require confirmation from the other MSC involved. This service is relevant to VGCS only. Forward Group Call Signaling The anchor MSC invokes the MAP_FORWARD_GROUP_CALL_ SIGNALLING service to indicate the uplink status to relay MSC. This service also does not require any confirmation from the other MSC involved. This service is relevant to VGCS only. Send Group Call End Signal The MAP_SEND_GROUP_CALL_END_SIGNAL service is used between the R-MSC and the A-MSC. This message indicates the VBS/VGCS channels are established in the R-MSC area. This service requires response from the AMSC which anchor MSC uses to inform relay MSC that all resources for the call can be released in the relay MSC because the call has been released in the anchor MSC. Send Group Call End Signal Ack The A-MSC sends the Send Group Call End Signal Ack message to the RMSC. This message tells the R-MSC that all resources for the group call can be released in the R-MSC because the call has been released in the A-MSC. Connect Indication message The A-MSC sends a Connect Indication message to the originator once it receives the expected ASSIGNMENT RESULTs from all the BSCs and the SEND_GROUP_CALL_END_ SIGNALs from all the R-MSCs. The Connect Indication message indicates the call has been established. The Connect Indication message may be an DTAP Connect, PRI Connect or ISUP ANM message, depending on what protocol is used towards the call originator. Connect Indication timer The Connect Indication timer is an DMS-MSC implemented timer. The Connect Indication timer is started before the group call is established towards the BSSs, R-MSCs, and dispatchers. The A-MSC must receive the BSS assignment results and the SEND_GROUP_CALL_END_SIGNAL before the timer expires. If the timer expires before all the expected answers are received, the A-MSC considers the VBS/VGCS established only if in a subscriber originated group call, the originating cell is established or in a dispatcher originated group call, the group call channel in at least one cell is established
3-70
If the Txx timer expires and one of these two criteria is fulfilled, the A-MSC sends the Connect Indication message to the call originator immediately after the Txx timer expires. The value of the Txx timer is correlated to the call's priority value and is defined on a per-DMS-MSC basis in the SERVCNFG table. Uplink timers Two uplink timers are associated with group calls. These timers are the Uplink Duration timer and the Uplink No Activity timer. The Uplink Duration timer The Uplink Duration timer runs while a VGCS talker is on the group call channel. Note: A dispatcher is not considered to be a talker. The Uplink Duration timer stops when the talker releases the call. Once the Uplink Duration timer stops, the network releases the uplink, and the Uplink No Activity timer starts. The Uplink No Activity timer The Uplink No Activity timer runs when there is no VGCS talker in the call. This timer starts when the talker releases the uplink (this includes when a service subscriber originator releases the uplink of the dedicated channel) at the beginning of a dispatcher-originated VGCS call Note: The Uplink No Activity timer is not started for a dispatcheroriginated VGCS emergency call. However, it is started for all other dispatcher-originated VGCS calls. The Uplink No Activity timer stops when a listener is granted an uplink. Once the Uplink No Activity timer expires, a warning tone plays to all the listeners and a three-second warning tone timer starts. If a listener requests the uplink within the three seconds, the call continues and the Uplink Duration timer starts. If no listeners request the uplink within the three seconds, the VGCS call is taken down, regardless of whether or not there is a dispatcher on the call. Note: The Uplink Duration and Uplink No Activity timers do not apply to Emergency VGCS calls. Group call procedure This section discusses the basic message flow for a normal inter-MSC group call procedure. In this section, the anchor MSC is referred to as A-MSC and the relay MSC is referred to as R-MSC.
3-71
When the A-MSC receives an indication that a group call must be established, the A-MSC sends a MAP Prepare Group Call request to the R-MSC. In response, the R-MSC sends a MAP Prepare Group Call Ack message to the A-MSC. The A-MSC checks the contents of the acknowledgement message. If the group call number is available, the A-MSC sends a MAP Prepare Group Call Ack with the group call number to the ASCI handling process. The A-MSC waits for the R-MSC to send a connect indication in a MAP Send Group Call End Signal message. Once the R-MSC sends the connect indication, the AMSC sends a Connect Indication message to the group call originator. If the group call number is missing, the A-MSC sends a MAP Prepare Group Call Negative Response to the ASCI handling process and an ABORT package with a MAP-U-ABORT request to the R-MSC. Once VGCS channels are established in the R-MSC area, the R-MSC sends a MAP Send Group Call End Signal to the A-MSC. The R-MSC then waits for further uplink management signals. For a VGCS call, the following messages are used for uplink management: Forward Group Call Signaling Process Group Call Signaling
These messages are sent in TCAP CONTINUE packages, prior to sending/ receiving the Map Send Group Call End Signal Ack in an END package. When the A-MSC wants to convey the uplink status to the R-MSC, the AMSC sends a MAP Forward Group Call Signaling request to the R-MSC. If the R-MSC wants to tell the A-MSC that the uplink is free or the uplink is requested by a subscriber roaming in the R-MSC area, the R-MSC sends a Map Process Group Call Signalling request with the information received in the request to the A-MSC. Figure 3-16 shows the normal dialogue for a normal VGCS call.
GSM
3-72
Figure 3-16 Example of a normal VGCS messaging dialogue

Anchor MSC MAP_PREPARE_GROUP_CALL BEGIN (AARQ: groupCallControlContext-v3 (INVOKE, (Invoke ID = i, Operation = PrepareGroupCall, Parameters =Teleservice, ASCI Call Reference, Ciphering Algorithm, Group Key Number, Group Key, Priority, CODEC-Information, Uplink Free Indicator))) MAP_PREPARE_GROUP_CALL_ACK CONTINUE (AARE: groupCallControlContext-v3 (RESULT-L, (InvokeID = i, Operation = PrepareGroupCall, Parameters= GroupCallNumber))) MAP_SEND_GROUP_CALL_END_SIGNAL CONTINUE ((INVOKE (Invoke ID = k, Operation = sendGroupCallEndSignal, Parameters = IMSI))) M A P _ F O R W A R D _ G R O U P _C A L L_ S IG N A LL IN G ** CONTINUE ((INVOKE, (Invoke ID = l, Operation = forwardGroupCallSignalling Parameters = IMSI, Uplink Request Acknowledgement Uplink Release Indication Uplink Reject Command, Uplink Seized Comman, Uplink Release Command))) Continued on next page ..... Relay MSC
411-2231-827
Standard
02.05
September 2001
3-73
Anchor MSC MAP_PROCESS_GROUP_CALL_SIGNALLING ** CONTINUE ((INVOKE, (Invoke ID = m, Operation = processGroupCallSignalling Parameters = Uplink Request, Uplink Release Indication, Release Group Call)))
Relay MSC
MAP_SEND_GROUP_CALL_END_SIGNAL_ACK END ((RESULT (Invoke ID = k, Operation = sendGroupCallEndSignal, Parameters = none)))
** These messages are relevant for VGCS calls only.
Periodic group call channel retry Sometimes a group call channel fails to establish during a call setup or is lost because of cell congestion, pre-emption, or other reasons. When this occurs, the AMSC and all the RMSCs involved in the call periodically retry to establish the channel. By doing this, the AMSC and RMSCs increase the probability of having all VBS/VGCS group call channels remain established from set up to release. This periodic group call channel retry procedure is performed for every cell in the group call area that does not have its group call channel assigned. This periodic retry procedure is performed in two stages: 1AF and 1CC. Figure 317 illustrates the two stages of the periodic retry procedure.
GSM
3-74
Figure 3-17 Two-stages of periodic retry procedure

Assignment Failure with unacceptable cause value received on single immediate retry
Group call channel not assigned at call setup (No response or Assignment Failure with acceptable cause value) Group call channel assigned after single immediate retry
Stage 1AF
Group call channel not assigned after single immediate retry (No response or Assign. Failure with acceptable cause value) Group call channel assigned after periodic retry Periodic Retry (Assign. Failure with acceptable cause value)
IDLE
Stage 2
Assign. Failure with unacceptable cause value received during periodic retry
ABORT
Group call channel not assigned after single delayed retry Group call channel (No response or Assign. lost during on-going Failure with acceptcall (Clear Request or Clear able cause value) Command with acceptable cause value or no response to Clear Command) Group call channel assigned after single delayed retry
Assign. Failure with unacceptable cause value received on single delayed retry
Stage 1CC
Group call channel not assigned at call setup or lost during on-going call (Assignment Failure, Clear Request or Clear Command with unacceptable cause value)
Stage 1AF (Assignment Failure): Single immediate retry stage after an Assignment Failure with an acceptable cause value is received or the TNT2 timer expires waiting for the response. Stage 1CC (Clear Complete): Single delayed retry stage after a Clear Request with an acceptable cause value is received or a Clear Command with an acceptable cause value is generated and the subsequent Clear Complete is received or the TNT3 timer expires waiting for the response. (Delay = 15 seconds) Stage 2: Periodic retry stage after the group call channel fails to get assigned in Stage1AF or Stage1CC. IDLE: The two-stage periodic retry procedure is not active and the VBS/VGCS group call channel is assigned. ABORT: The two-stage periodic retry procedure has been aborted for the remainder of the call and the VBS/VGCS group call channel is not assigned.
411-2231-827
Standard
02.05
September 2001
3-75
Stage 1AF Stage 1AF is performed when the MSC receives a VBS/VGCS Assignment Failure, Clear Request, or Clear Command message with an acceptable cause value at call setup. If the received message contains an unacceptable cause value, the periodic retry procedure aborts. Following is a list of the acceptable cause values for the VBS/VGCS Assignment Failure message: no radio resource available equipment failure O & M intervention terrestrial resource already allocated switch circuit pool requested terrestrial resource unavailable Note: The VBS/VGCS call non-existent cause value is an exception to the rule. Although it is considered an unacceptable cause value for the VBS/VGCS group call channel periodic retry procedure, a single reattempt is made when this cause value is received. This re-attempt is performed after the initial VBS/VGCS Setup procedure is aborted and a new one is started. Following is a list of the acceptable cause values for the Clear Request message: radio interface message failure equipment failure O & M intervention pre-emption
Following is a list of the acceptable cause values for the Clear Command message: equipment failure O & M intervention pre-emption
During stage 1AF, the MSC performs a single immediate retry to establish the VBS/VGCS group call channel. If this immediate retry fails to establish the group call channel and generates a failure message with an acceptable value, the MSC performs periodic retries. If any retry generates a failure message with an unacceptable cause value, the periodic retry procedure aborts. If no response is received on a retry, the procedure continues.
GSM
3-76
Note: For a given cell, it is possible that the periodic retry procedure is never triggered during the call. This possibility occurs when the first received Assignment Failure or Clear Request message, or the first Clear Command message generated by the MSC for the group call channel in that cell contains an unacceptable cause value. Also, if the MSC fails to send a VGCS/VBS Assignment Request message due to any internal MSC error or due to a lack of channels, no further retries are made and the periodic retry procedure ends at that time for that cell. Therefore, after a group call channel is pre-empted by a higher priority call, retries are performed to establish that group call channel, as long as the MSC can find a channel to perform the first retry. If there is still no channel available at the time the MSC tries to perform the first retry, the VGCS/VBS Assignment Request message cannot be sent out and the periodic retry procedure ends at that point for that particular cell. Stage ICC A group call channel reaches stage 1CC when one of the following occurs during an ongoing VBS/VGCS call: the BSC sends a Clear Request message with an acceptable cause value to the MSC, the MSC sends a Clear Command message to the BSC, and the MSC receives the subsequent Clear Complete message the MSC receives a Clear Request message with an acceptable cause value and the TNT3 timer expires waiting for a response to the second Clear Command message sent to the BSC the MSC generates and sends a Clear Command message with an acceptable cause value to the BSC and the MSC receives the subsequent Clear Complete message the MSC generates and sends a Clear Command message with an acceptable cause value to the BSC and the TNT3 timer expires waiting for the response to the second Clear Command message sent to the BSC
During stage 1CC, a single delayed retry is performed to establish the VBS/ VGCS group call channel. The delay period is set to 15 seconds. If this stage fails to establish the group call channel and the cause value in the failure message is an acceptable value, the MSC performs periodic retries. If the failure message received on any retry contains an unacceptable cause value, the periodic retry procedure aborts. If no response is received on a retry, the procedure continues. Note: For a given cell, it is possible that the periodic retry procedure is never triggered during the call. This possibility occurs when the first received Assignment Failure or Clear Request message, or the first Clear Command message generated by the MSC for the group call channel in
3-77
that cell contains an unacceptable cause value. Also, if the MSC fails to send a VGCS/VBS Assignment Request message due to any internal MSC error or due to a lack of channels, no further retries are made and the periodic retry procedure ends at that time for that cell. Therefore, after a group call channel is pre-empted by a higher priority call, retries are performed to establish that group call channel, as long as the MSC can find a channel to perform the first retry. If there is still no channel available at the time the MSC tries to perform the first retry, the VGCS/VBS Assignment Request message cannot be sent out and the periodic retry procedure ends at that point for that particular cell. Period between retries The period between retries is set to the Table BSSC2TMR TNT2 timer + the Group Call Channel Retry (TGCHR) timer. The TGCHR timer is given a default value of 1 minute and is implemented in the BSSC2TMR table in the related MSCs. The TGCHR timer can be selected within the 1 minute to 10 minute range. For example, if VBS/VGCS group calls are known to be up for long periods of time, the TGCHR timer value can be increased to avoid overloading the A-interface unnecessarily and improving the system time. The period may be less than TNT2 timer + TGCHR timer if an Assignment Failure message (with an acceptable cause value) is received by the MSC before the TNT2 timer expires. In this case, the period is the response time plus the TGCHR timer. Inter-MSC handovers VGCS supports two types of inter-MSC handovers: handovers using circuit connections signaling-only handovers
Handovers using circuit connections Inter-MSC handover functionality using circuit connections is a handover that occurs while the talker is on a dedicated channel. Circuit connection handover functionality includes the following: inter-MSC handover (MSC-A to MSC-B) subsequent handover (MSC-B to MSC-B) inter-MSC handback (MSC-B to MSC-A)
The following figures show the message flows for each type of VGCS interMSC handover. An IMT is used to set up the speech path between two MSCs. This type of handover uses the existing handover functionality implemented on MSC switch.
GSM
3-78
Figure 3-18 Inter-MSC handover (MSC-A to MSC-B) with call terminating request by the originating talker
BSSold
HO Required
MSC-A
MSC-B
BSSnew
MS
ANM
Termination Request PAS [Termination Req.] Termination FAS [Termination] Release SES Ack Clear Cmd/Cmp SCCP RLSD/RLC
411-2231-827
Standard
02.05
September 2001
Nortel Networks Confidential Figure 3-19 Inter-MSC handover from MSC-A to MSC-B with an uplink release BSSold
HO Required
3-79
MSC-A
MSC-B
BSSnew
ANM
Uplink Release Ind.

Clear Request Uplink Release Cmd. Release SES Ack Clear Cmd/Cmp SCCP RLSD/RLC Clear Command
Note: When the uplink is released, an SES Ack message is sent due to the signaling on the group call control connection.
GSM
3-80
Figure 3-20 Subsequent handover (MSC-B to MSC-B) BSSold

HO Required Prepare Subsequent HO [HO Request Tgt_Cell_ID Tgt_MSC_Num] Prepare HO Ack [HO Request Ack HON]
MSC-B
MSC-A
MSC-B'
BSSnew
[HO Request Prepare HO Tgt_Cell_ID] HO Request
HO Request Ack
IAM [HON]
ACM Prepare Subsequent HO Ack [HO Request Ack] HO Command HO Detect PAS [HO Detect] HO Complete SES [HO Complete] ANM Clear Cmd/Cmp SCCP RLSD/RLC Release SES Ack
Note: After a subsequent handover, MSC-B becomes MSC-B. So the call termination signaling and uplink release is the same as Figure 3-18 and Figure 3-19.
411-2231-827
Standard
02.05
September 2001
Nortel Networks Confidential Figure 3-21 Inter-MSC handback (MSC-B to MSC-A) BSSnew MSC-A MSC-B
3-81
BSSold
Prepare Subsequent HO [HO Request Tgt_Cell_ID Tgt_MSC_Num]
HO Required
HO Request
HO Complete SES Ack Clear Cmd/Cmp SCCP RLSD/RLC Release
When a VGCS inter-MSC handover occurs to a target cell outside the group call area, the MSC-B sends a Handover Failure with a cause value of invalid cell id. Signaling-only handovers A signaling-only handover occurs while the talker is on a group channel. Signaling-only inter-MSC handovers occur only on VGCS calls. The primary differences between a signaling-only handover and a circuit connection handover follow: A private tag (GCRef) is present in the handover MAP Prepare Handover message. This tag is not present in circuit connection handovers. Signaling-only handovers do not use ISUP (IMT) trunks. Circuit connection handovers use IMT trunks. After a signaling-only handover is complete, the old MSC sends an HO Succeeded message to the old BSS. A circuit connection handover sends a Clear Cmd/Cmp and SCCP RLSD/RSC message instead. For signaling-only handovers, the talker speech connection is changed locally at the target MSC.
GSM
3-82
Handover Number Not Required information element is required in the MAP Prepared Handover message.
The following figures show the message flows for each type of VGCS signaling-only inter-MSC handover.
Figure 3-22 Signaling-only handover from MSC-A to MSC-B with a call termination request by the originating talker BSSold MSC-A MSC-B BSSnew MS
HO Required Prepare HO [HO Request Tgt_Cell_ID, HON_Not_Required Private Tag(GCRef)]
HO Request
HO Request Ack Prepare HO Ack [HO Request Ack]
HO Command HO Detect PAS [HO Detect] HO Complete SES [HO Complete] HO Succeeded
Termination Request PAS [Termination Req.]
FAS [Termination]
Termination
SES Ack Clear Cmd/Cmp SCCP RLSD/RLC
411-2231-827
Standard
02.05
September 2001
3-83
Figure 3-23 Signaling-only handover from MSC-A to MSC-B with an uplink release BSSold MSC-A MSC-B BSSnew
HO Required Prepare HO [HO Request Tgt_Cell_ID, HON_Not_Required Private Tag(GCRef)]
HO Request
HO Request Ack Prepare HO Ack [HO Request Ack]
HO Command HO Detect PAS [HO Detect] HO Complete SES [HO Complete] HO Succeeded
Uplink Release Ind.
Uplink Release Cmd. SES Ack
Note: When the uplink is released, an SES Ack message is sent due to the signaling on the group call control connection.
GSM
3-84
Figure 3-24 Signaling-only subsequent handover from MSC-B to MSC-B BSSold

HO Required Prepare Subsequent HO [HO Request Tgt_Cell_ID, Tgt_MSC_Num] Prepare HO [HO Request Tgt_Cell_ID, HON_Not_Required Private Tag (GCRef)]
MSC-B
MSC-A
MSC-B'
BSSnew
HO Request
Prepare HO Ack [HO Request Ack]
HO Request Ack
Prepare Subsequent HO Ack [HO Request Ack] HO Command HO Detect PAS [HO Detect] HO Complete SES [HO Complete]
HO Succeeded
SES Ack
Note: After a subsequent handover, MSC-B becomes MSC-B. So the call termination and uplink release signaling are the same as shown in Figure 3-22 and Figure 3-23.
411-2231-827
Standard
02.05
September 2001
Nortel Networks Confidential Figure 3-25 Signaling-only subsequent handback from MSC-B back to MSC-A BSSnew MSC-A
3-85
MSC-B
BSSold
HO Required Prepare Subsequent HO HO Request [HO Request Tgt_Cell_ID, Tgt_MSC_Num]
HO Complete SES Ack
Handover failures When an inter-MSC handover occurs to a target MSC outside the talkers group area, the MSC-A verifies the MSC-B against the group area and the verification fails. The MSC-A rejects the handover and sends an HO Required Reject message. Abnormal responses from the MSC-B When the MSC-B responds with a Reject, Error, or Abort, the transaction is terminated at MSC-A. A Handover Required Reject is sent back to the serving BSS reflecting the failure cause associated with this cell. The call is maintained on the old channel but the uplink is released. Handover failure on the MSC-B side If the traffic channel allocation is not possible, the HO Failure is received by BSS on MSC-B. This failure is reported to the MSC-A in a Prepare HO Ack message. The HO Number is not included. The call is maintained on the old channel but the uplink is released.
GSM
3-86
When an inter-MSC handover occurs to a target cell outside the talkers group area, the MSC-A sends a MAP Prepare HO request to the MSC-B. The target cell is verified against the group area and the verification fails. The MSC-B rejects the handover and sends a Prepare HO Ack [HO Failure] message with a cause value of Invalid Cell. Talker disconnects before receiving a Prepare HO Ack When the VGCS talker disconnects at the beginning of the handover before the MSC-B responds with a Prepare Handover Ack, the MSC-A sends no notification to MSC-B. When the MSC-A receives a response to the original Prepare Handover message, it responds with an Abort which informs MSC-B to terminate its transaction. The call is maintained on the old channel but the uplink is released. HO failure on the MSC-A side If the HO Failure is received in response to an HO command, the inter-MSC handover attempt is terminated and an Abort is sent to the MSC-B to clean resources. The call is maintained on the old channel but the uplink is released. No HO Complete on the MSC-B side If the HO Complete is not received from the BSS on the MSC-B side during a specified time, the MSC-B sends an Abort to the MC-A. The resources on the MSC-B are freed. In the VGCS call, the call is maintained on the old channel but the uplink is released. Talker release uplink before receiving HO Command The handover procedure is abandoned when the VGCS talker releases the uplink at the beginning of the handover and before receiving the HO Command. After the MSC-A receives a Prepare Handover Ack from the MSC-B, the MSC-A sends an Abort to the MSC-B. The Abort tells the MSCB to terminate its transaction. Talker release uplink after receiving HO Complete The handover completes when the VGCS talker releases the uplink after the MSC-B receives an HO Complete. This case is a normal uplink release. Note: After a VGCS signaling-only handover fails, no handover retry is made with a circuit connection. Emergency VGCS calls A VGCS call is identified as an emergency VGCS call when the calls priority is datafilled as Class1 in table SERVCNFG. In other words, if table SERVCNFG datafills priority 0 as Class1, all priority 0 VGCS calls are identified as emergency VGCS calls.
411-2231-827
Standard
02.05
September 2001
3-87
A VGCS emergency call is released when any of the following actions occur: the originator (service subscriber or dispatcher) hangs up any authorized dispatcher sends in the DTMF Kill sequence the service subscriber originator sends in the uplink release
VGCS emergency call talker restrictions If a dispatcher initiates the VGCS emergency call, the dispatcher can talk automatically, without having to send in the start-to-talk request. The dispatcher cannot be interrupted by any other dispatcher and service subscribers are not granted an uplink. The start-to-talk and the end-of-talk sequences from dispatchers are ignored. These start-to-talk DTMF requests sent in by the dispatchers do not have any Reject tones in response. Dispatcher-kill sequences from authorized dispatchers are not ignored and therefore, takes down the call. The call also can be taken down by the originating dispatcher hanging up. No Uplink Requests from service subscribers are granted. Note: VGCS emergency call takedown is an optional functionality that is implemented through SOC. If a service subscriber initiates the VGCS emergency call, the subscriber can talk automatically, without having to send in the Uplink Request. No dispatcher is allowed to interrupt the originating service subscriber and no other service subscriber is granted the uplink. The start-to-talk and the endof-talk sequences from dispatchers are ignored. The start-to-talk DTMF requests sent in by the dispatchers do not have any Reject tones in response. Again, the dispatcher-kill sequences from authorized dispatchers are not ignored and may take down the call. The call also can be taken down by the originating service subscriber hanging up the originating service subscriber sending in the Uplink Release message Note: VGCS emergency call takedown is an optional functionality that is implemented through SOC. No Uplink Requests from service subscribers are granted (Uplink Reject messages are sent in response to these Uplink Requests). Errors and abnormal conditions Following are the types of errors and abnormal conditions that affect the behavior of group calls: datafill errors authorization errors resource failures
3-88
unexpected behavior protocol errors race conditions
Datafill errors Datafill errors usually are caused by inconsistent datafill existing in DMS-MSC tables or
1
incorrect datafill resulting in call establishment failure
Authorization errors Authorization errors occur when an unauthorized subscriber or dispatcher attempts to originate a group call or join an ongoing group call. Resource failures A VGCS resource failure occurs when the DMS-MSC attempts to assign a terrestrial circuit and the DMS-MSC receives a VGC/VBS call non-existent message a VGCS call fails to allocate a conference bridge a VGCS conference bridge does not have enough ports maintenance personnel force-releases a conference circuit used by an ongoing VGCS call
Unexpected behavior The following unexpected behavior failures can occur during or after a VGCS call is established: the IMSI Detach from the VGCS originator takes the VGCS call down an IMSI Detach from a subsequent talker using the uplink of a group call channel results in the release of the uplink a radio failure on the VGCS originators dedicated link a radio failure on a group call channel the group call register (GCR) access fails the BSC returns an unexpected cell identification in an uplink request confirmation message
Protocol errors The following protocol errors can affect VGCS calls: syntactic errors receipt of unexpected messages receipt of unexpected information elements
411-2231-827
Standard
02.05
September 2001
3-89
receipt of unexpected transaction ID mismatch in teleservice type
Race conditions A race condition occurs if a dispatcher attempts to join an ongoing call that is terminating. If this race condition occurs, the joining dispatcher is released with a cause value of temporary failure.
How the DMS-MSC supports VGCS
The DMS-MSC supports VGCS service by performing the following functions: stores subscription information sent from the DMS-HLR performs subscription checks at the VLR implements the GCR and its functionality establishes a call to multiple cells establishes a call to multiple dispatchers manages uplinks terminates and releases VGCS calls performs handovers for mobiles in VGCS calls
How the DMS-HLR supports VGCS
The DMS-HLR supports VGCS service by performing the following functions: stores VGCS subscription information on a per user basis stores data required by the service applications associated with VGCS sends VGCS subscription information to the DMS-MSC and VLR for the following reasons: in response to an update location (UL) MAP request in response to a restore data (RD) MAP request because subscriber data changed at the DMS-HLR screens home PLMN roaming data to determine if VGCS data should be sent to the VLR or if roaming should be denied sends only the roaming specific data to the DMS-MSC and VLR when a mobile roaming outside of its home PLMN
This section discusses how VGCS interacts with the following features: group call reference presentation supplementary services
GSM
3-90
eMLPP operator determined barring intelligent feature usage dispatcher talk token
Group call reference presentation Destination dispatchers and calling service subscribers If the destination dispatchers subscribe to calling line identification presentation (CLIP), the group call reference (GCRef) is presented to the destination dispatchers. The calling party number is not presented to the destination dispatchers. The destination service subscribers always display the group ID regardless of their subscription status to CLIP. Calling dispatchers and calling service subscribers If the calling dispatcher subscribes to connected line identification presentation (COLP), the GCRef is presented to the calling dispatcher. The GCRef always is presented to the calling service subscriber through the connect message sent to the mobile station. It is up to the mobile station to display the GCRef as the connected number. No destination subscriber or dispatcher identities ar presented to the calling party. The DMS-MSC always overrides any presentation restrictions (calling line identification restriction [CLIR] and connect line identification restriction [COLR]). The DMS-MSC always includes the GCRef as the presented number. Supplementary services Supplementary services are applied on a per basic service group (BSG) basis. Service subscriber originated VGCS calls always have the BSG of VGCS. Therefore, only the supplementary services that can be provisioned for a VGCS service subscriber apply to the service subscribers in the call. VGCS dispatchers have the teleservice of telephony. Therefore, supplementary services provisionable for Telephony apply to the dispatcher.
411-2231-827
Standard
02.05
September 2001
3-91
A VGCS service subscriber can use only a particular subset of supplementary services. Table 3-3 indicates if a specific supplementary service can be used by a VGCS subscriber.
Table 3-3 Supplementary services applicable to a VGCS subscriber Supplementary service Enhanced Multi-level Priority Preemption (eMLPP) Functional Addressing (FA) Calling Line Identification Presentation (CLIP) Calling Line Identification Restriction (CLIR) Connected Line Identification Presentation (COLP) Connected Line Identification Restriction (COLR) Call Forwarding Unconditional (CFU) Call Forwarding Busy (CFB) Call Forwarding on No Reply (CFNRy) Call Forwarding on Mobile Subscriber Not Reached (CFNRc) Call Waiting (CW) Hold Multi-party Service (MPTY) Closed User Group (CUG) Advise of Charge (Information) (AoCI) Advise of Charge (Charging) (AoCC) User-to-user Signaling 1 (UUS1) Barring of All Outgoing Calls (BAOC) Barring of Outgoing International Calls (BAIC) Barring of Outgoing International Calls except those directed to the Home PLMN country (BOIC-exHC)
sheet 1 of 2
Applicable to VGCS subscriber? Yes No Yes Yes Yes Yes No No No No No No No No No No No Yes No No
GSM
3-92
Table 3-3 Supplementary services applicable to a VGCS subscriber Supplementary service Barring of All Incoming Calls (BAIC) Barring of Incoming Calls when Roaming outside the Home PLMN country (BIC-Roam) Explicit Call Transfer (ECT) Local Calls Only (LCO) Class of Service (COS) Hotbill Account Code (AC) Calling Name Display (CNAM) Malicious Call Trace (MCT) Extension Service (EXT) Anonymous Call Rejection (ACRJ)
sheet 2 of 2
Applicable to VGCS subscriber? No No No No No No No No No No No
Dispatchers in VGCS calls have the teleservice of telephony. Therefore, telephony-related supplementary services apply to the dispatcher originated VGCS call. Following are the exception or special cases: CLIP is supported for dispatcher in that the GCRef number (calling party number for PRI) is available for presentation to the destination dispatchers. The network always overrides CLIR in such a way that the GCRef number (calling party number for PRI) is available for presentation to the destination dispatchers. COLP is supported for dispatchers and originating service subscribers in that the GCRef number (calling party number for PRI) is available for presentation to the calling party, regardless of whether or not the subscriber has COLP subscription. The network always overrides CLOR in such a way that the GCRef number is available to the calling dispatchers. The network always overrides CLOR in such a way that the GCRef number is available to the calling dispatchers.
411-2231-827
Standard
02.05
September 2001
3-93
eMLPP
BAOC is applicable, if subscribed to, with the exception of high priority calls. CFB is applicable for dispatchers if the group call does not have a higher priority than the present call. CUG is not applicable. Being a member of a CUG has no impact on receiving and establishing voice group calls.
The eMLPP provides different levels of precedence for call setup for VGCS. Precedence is defined as the call priority in a call. There are seven priority levels defined for eMLPP. The eMLPP also provides for called party pre-emption which allows an active mobile station involved in a VGCS call to answer an incoming call if it has a higher priority level than the ongoing call. Priority levels for group calls are datafilled in GCR and only can be changed through provisioning. Precedence Following are the messages that contain the precedence of the call: CM-SERV_REQ. A priority level is included within each set of VGCS call attributes stored in the group call register (GCR) if eMLPP is applied. The priority level is provided by the GCR to the DMS-MSC with the call attributes. For VGCS establishment, the calling mobile station may indicate a priority level in the service request message. This priority level can be applied to the dedicated link of the calling mobile station as long as the GCR does not provide a different level. If the priority level provided by the GCR is different from the incoming priority level, the priority level of the GCR is applied to the dedicated link of the calling mobile station. Connect. The group or broadcast call reference includes the priority level applied to the group or broadcast call in the network. This priority level can be different from the one indicated in the service request message. NOTIF_REQ. The priority level is indicated with the related notification request messages for the called mobile stations.
Called party pre-emption If a mobile station currently involved in a VGCS call receives a subsequent notification that another VGCS call is attempting to reach the mobile station, the called party pre-emption occurs as follows: The notification includes the related priority level of the call. If the new call has a higher priority level, the mobile station may automatically leave the ongoing VGCS call and respond to the new call.
GSM
3-94
Similarly, if a paging request message for a point-to-point call is attempted towards the mobile station involved in a VGCS call, the called party pre-emption occurs as follows: The paging request includes the related priority level of the call. If the priority level in the paging request is higher than the priority level of the ongoing call, the mobile station may automatically leave the ongoing VGCS call and respond to the page.
Operator determined barring The facts that apply to the subscriber controlled barring determine if operator determined barring (ODB) can be used with a VGCS subscriber. Table 3-4 indicates if operator determined barring is applicable for a VGCS subscriber.
Table 3-4 When ODB is applicable to a VGCS subscriber ODB ODB outgoing ODB incoming ODBMISC ODBECT Applicable to VGCS subscriber? Yes for Barring for All Outgoing Calls No No No
Intelligent network feature usage The DMS-MSC contains an integrated SSP used to support intelligent networking applications. The following paragraphs detail IN support for group and broadcast calls for both dispatchers and service subscribers. Dispatcher originated group calls Since dispatcher originated group calls are treated as normal mobile or fixed trunk network originations, intelligent networking functionality is fully supported for this type of call. Support includes the originating triggers detection point 2 (DP2), detection point 2-trunk (DP2-T), and detection point 3 (DP3). An example of an IN service on a dispatcher originated group call is short code dialing. For this application, a dispatcher dials a short code that triggers DP3 through the appropriate translations datafill. Upon triggering DP3, the SSP sends an InitialDP to the SCP. The SCP sends a Connect message with the GCRef as the new called number. By retranslating on this new number, the call is identified as a group call. The remaining call flow is identical to a dispatcher dialing a GCRef explicitly.
411-2231-827
Standard
02.05
September 2001
3-95
Subscriber-originated group calls Partial intelligent networking feature functionality is supported for subscriber-initiated group calls. Particularly, a group call subscriber also may subscribe to originated IN service DP2. Similar to group and broadcast call basic teleservices and their associated group IDs, IN subscription information is stored in the DMS-HLR and VLR. When a group call is initiated by a service subscriber, the VLR performs group call screening and screens for subscription to originating IN DP2. If subscription to IN DP2 exists, the VLR triggers the DP2. Upon triggering DP2, a query is sent to the SCP in the form of an InitialDP message. The SCP modifies the behavior of the call by sending response messages. The SCP response messages can be used for the purpose of rejecting the call continuing the call modifying information regarding the call billing
An example of IN services applied to a subscriber-initiated group call is a time of day rejection. In this application, an operator may wish to allow only a subscriber to initiate a group call during a particular time window. If the time of the origination does not fall within the range of the window, the SCP responds to the InitialDP message with a Release Call message. Call intercept Call intercept is not supported. However, this feature does not introduce software to block dispatchers from being specified as a CI target. Therefore, partial event records may generate. No new CI functionality is provided for service subscriber originations or for mobiles in cluster call termination. Dispatcher Talk Token Interaction occurs with the Dispatcher Talk Token feature since both features use DTMF signaling. Dispatcher Talk Token uses two office parameters START_TO_TALK_REQUEST and END_TO_TALK_REQUEST to store the same number and type of digits, namely the # and the * as used by this feature for the office parameter DISP_DISC_SEQ. A warning message is displayed to the operator trying to datafill OPARM DISP_DISC_SEQ with the same datafill as START_TO_TALK_REQUEST or END_TO_TALK_REQUEST. The datafill request is rejected. The warning message indicates that the requested datafill change matches with an existing
GSM
3-96
datafill in one of the other office parameters. These office parameter datafills will never hold the same sequences at one time.
Datafill required for VGCS service

The following tables must be datafilled for VGCS service: table OFCENG table OFCVAR table BSSC2TMR table DNROUTE table GCR table GCAREA table LACGID table XXCODE and XXHEAD table GHLRVGS table GHLRVGCA table GHLRBSVC table GHLRSSOP table GHLRNDSC table SERVCNFG
The following paragraphs briefly describe these tables. Note: For detailed information on these tables, refer to NTP 411-2231455, GSM DMS-MSC Office Parameters Reference Manual, NTP 4112231-495, GSM DMS-MSC Customer Data Schema, and NTP 411-2831151, GSM DMS-HLR Customer Data Schema. Table OFCENG datafill In this table, datafill parameters GID_LENGTH MAX_GROUP_CALL_SUBS_IN_VLR NUMBER_OF_DMS_SYSTEM_TIDS
GID_LENGTH Office parameter GID_LENGTH determines the length of group ID (GID) portion within group call reference (GCREF). The possible range of values are 0 to 6. The default value is 3.
411-2231-827
Standard
02.05
September 2001
3-97
MAX_GROUP_CALL_SUBS_IN_VLR Office parameter MAX_GROUP_CALL_SUBS_IN_VLR allows the operating company to provision the number of subscribers that may have group call data in the VLR. The value of MAX_CALL_SUBS_IN_VLR cannot exceed the current value of MAX_SUBSCRIBERS_IN_VLR. Each increment of MAX_GROUP_CALL_SUBS_IN_VLR translates to 1024 (1K) entries in the table. For example, if the parameter value is 3, that means 3K entries are allocated for the table. Through the MAX_GROUP_CALL_SUBS_IN_VLR parameter, the operating company can control the amount of memory used to store group call data. The range of values for MAX_GROUP_CALL_SUBS_IN_VLR is 0 to 50 (represented in thousands). The default value is 0. NUMBER_OF_DMS_SYSTEM_TIDS This parameter controls the size of a logical terminal identifier pool required by active group call feature control software for internal messaging purposes. The range of values for this parameter is 0 to 32767. The default setting for this office parameter is (NCCBS) * (0.04). This default value is an estimated required number assuming 5% of all MSC calls are group calls. Table OFCVAR datafill In this table, datafill parameters GSM_VGCS_VBS_ORIG_XLAENTRY GSM_VGCS_VBS_TERM_XLAENTRY DISP_DISC_SEQ VGCS_Dispatcher_TALK_CONTROL
GSM_VGCS_VBS_ORIG_XLAENTRY This parameter determines the entry point into XLAENTRY table only if table XLAENTRY has an index that is equal to the GSM_VGCS_VBS_ ORIG_XLAENTRY number. Provision this matching XLAENTRY index for VBS and VGCS service subscriber originated calls. When provisioning this parameter, follow the derivation of the group call reference (GCRef) from the dialed GID, LAC, and Cell ID. The GCRef enters translations indicated by this parameter.
GSM
3-98
If the GSM_VGCS_VBS_ORIG_XLAENTRY number does not match the XLAENTRY index, the default index (which is 0) is used to enter into the XLAENTRY table. The range of values for this parameter is 0 to 1023. The default value is 0. GSM_VGCS_VBS_TERM_XLAENTRY This parameter determines the entry point into XLAENTRY table only if table XLAENTRY has an index that is equal to the GSM_VGCS_VBS_ TERM_XLAENTRY number. Provision this matching XLAENTRY index for VBS and VGCS calls that require translations toward dispatchers and relay MSCs. If the GSM_VGCS_VBS_ORIG_XLAENTRY number does not match the XLAENTRY index, the default index (which is 0) is used to enter into the XLAENTRY table. The range of values for this parameter is 0 to 1023. The default value is 0. DISP_DISC_SEQ Office parameter DISP_DISC_SEQ stores the predetermined dispatcher disconnect sequence digits. These digits are matched with the incoming DTMF tone sequences from authorized dispatchers while they attempt to tear down an on-going group call. VGCS_DISPATCHER_TALK_CONTROL This parameter determines the function control option in a VGCS call. This parameter also defines the tone sequences used by a dispatcher to request talk or release talk in a VGCS call and the tones used to grant or deny a dispatchers request. Table BSSC2TMR datafill Table BSSC2TMR contains BMAP class two engineerable timers that can be associated with a particular location area of a DMS-MSC. In particular, this table contains information regarding the Group Call Channel Retry timer. This timer is controlled by field TGCHR. The range of values for field TGCHR is 60 seconds to 600 seconds. The default value is 60 seconds. Table DNROUTE datafill Allocates group call numbers (GCNs). GCNs are temporary routing numbers used to set up A-MSC to R-MSC connections. When processing a Prepare Group Call message from the A-MSC, the R-MSC MAP service allocates a GCN. This allocated GCN is sent back to the A-MSC embedded in the Prepare Group Call Ack message. This temporary GCN number is later released by the R-MSC when the call is routed back to the R-MSC.
411-2231-827
Standard
02.05
September 2001
3-99
Table GCR datafill Table GCR serves as the primary database for the VGCS and VBS. It stores the call attributes per group call references in the MSC. The key that is used for indexing into table GCR is GCREF (Group Call REFerence). Table GCAREA datafill Table GCAREA is indexed by GCA ID digits in order to retrieve the list of cells that are present in a group call area. In Phase 1, a maximum of 20 cells can be datafilled in a GCA. Table LACGID datafill Table LACGID is indexed by the multi-part key combination of LAC+CELL ID+GID. This table retrieves the GCA digits datafilled against a LAC+CELL ID+GID combination. Table XXCODE and XXHEAD datafill XXCODE and XXHEAD stands for all the following universal translations tables: AMHEAD and AMCODE PXHEAD and PXCODE CTHEAD and CTCODE FAHEAD and FACODE OFCHEAD and OFCCODE FTHEAD and FTCODE ACHEAD and ACCODE NSCHEAD and NSCCODE
These tables add a new option to the existing database query (DBQ) selector to identify group/broadcast calls and the need to perform GCR query screening. The DBQ option is: GCQ (Group Call Query). When translations (UXLA) on the called number hits the GCQ option, it is identified as a group or broadcast call. At this point, the system performs GCR screening on the group call reference (GCRef). To handle the possibility that retranslation on the same GCRef could occur, the following existing option can be used in conjunction with the GCQ option: DBQCONT. Retranslations on the GCRef results in a loop. The DBQCONT option can be used in these cases if deemed necessary. This option specifies a new translation system (XLASYS) and translation name (XLANAME) to use when re-entering UXLA. Specifying a new XLASYS and XLANAME keeps looping from occurring.
3-100
Table GHLRVGS datafill Table GHLRVGS stores subscriber VBS and VGCS provisioning details. The tables key consists of a subscribers IMSI and the VBS or VGCS service with which the subscriber is provisioned. If a subscriber is provisioned with both VBS and VGCS, two tuples exist for the subscriber (one tuple for each service). Each tuple stores the group IDs the subscriber is allowed to call. Each subscriber can be datafilled with up to 50 group IDs for each service. The group IDs consist of between 1 and 3 BCD digits. A boolean (Y/N) indicates if the subscriber can use the VBS or VGCS service when roaming out of the home PLMN. Subscriber information must be datafilled in table GHLRBSVC before a tuple can be created for a subscriber in table GHLRVGS. The subscriber must be assigned the VBS or VGCS in table GHLRBSVC before the subscriber can be detailed in table GHLRVGS. Note: A large subscriber database may slow access to table GHLRVGS. Table GHLRVGCA datafill Table GHLRVBCA stores the supra-PLMN group IDs. These supra-PLMN group IDs allow a VGCS subscriber to place a VGCS call even when the subscriber outside the home PLMN. A group ID that is not included in table GHLRVGCA can be datafilled in table GHLRVGS against an IMSI. In this case, the group ID is assumed to be usable only within the home PLMN. Table GHLRBSVC datafill Table GHLRBSVC contains the GSM HLR basic service data for a subscriber. Table GHLRBSVC allows basic services to be added against an IMSI along with an MSISDN. Each basic service and associated data for a subscriber is represented by a separate tuple in table GHLRBSVC. A subscriber may have separate MSISDNs for all or some basic services with the following exceptions: Short Message Service Mobile Terminating (SMMT), Short Message Service Mobile Originating (SMMO), and Telephone (TPHNY) must have the same MSISDN. Alternate Speech and Data Circuit Duplex Asynchronous (ALTSPCDA) and Alternate Speech and Data Circuit Duplex Synchronous (ALTSPCDS) must have the same MSISDN. Speech followed by Circuit Duplex Asynchronous (SPCHCDA) or speech followed by Circuit Duplex Synchronous (SPCHCDS) must have the same MSISDN.
411-2231-827
Standard
GSM-R functionalities 3-101
Table GHLRAUTH must be datafilled before table GHLRBSVC. Table GHLRSSOP datafill This table contains option data for provisioning, registering, and activating supplementary services associated with a subscriber or basic service group. This table contains one tuple per supplementary service provisioned against the IMSI. The tuples are identified with a three-part key consisting of the IMSI MNC, the IMSI MSIN, and the supplementary service. To datafill a subscriber with a supplementary service option in table GHLRSSOP, first datafill the subscriber in tables GHLRAUTH and GHLRDATA and ensure the subscriber has an ISTATUS of D, A, or N. Table GHLRNDSC datafill This table contains data associated with VLR screening classes. The DMSHLR uses the contents of table GHLRNDSC to determine which services must be sent to a particular VLR (considering its class and version) in certain special cases, which encoding method must be used (phase 1, 2, or 2+) for the propagation of the services how the HLR must react in the event a service is not supported
Table GHLRNDSC also includes screening options for VBS and VGCS. The class name must be datafilled in table GHLRSCMP before it is datafilled in table GHLRNDSC. Table SERVCNFG datafill Subfield Txx in this table contains the Connect Indication Timer (Txx) values in seconds.
Log reports associated with VGCS service

The following log reports contain information regarding VGCS service: GVLR300 GMSC301 GMCS302 GBCS300 GGCN300
The following paragraphs briefly describe these log reports.
GSM
3-102
Note: For more detailed information on these log reports, refer to NTP 411-2231-515, GSM DMS-MSC Log Reference Manual. The GVLR300 log report This log report generates when the VLR has no memory to store VGCS data at subscription time. This report informs the craft person of VLR memory exhaustion and possible action to take. The GMSC301 log report This log report generates when hardware is not properly installed or datafill is incorrect. The GMCS302 log report This log report indicates illogical triggering of the GCR query occurred in the R-MSC due to datafill errors. The GBCS300 log report This log report indicates failures in attempting to establish a group call in the base station subsystem (BSS). The GGCN300 log report This log is generated when a GC number can not be allocated.
Operational measurements associated with VGCS service

The following operational measurement (OM) groups contain information regarding VGCS service: EVGCS GHLRBS GMAPCH2 MCLUSTER MSCGCS MSCUPLNK
The following paragraphs briefly describe these OM groups. Note: For detailed information on these OM groups, refer to NTP 4112231-815, GSM DMS-MSC Operational Measurements Reference Manual, and NTP 411-2831-814, GSM DMS-HLR Operational Measurements Reference Manual. Group EVGCS EVGCS contains registers that count the number of Emergency VGCS calls.
411-2231-827
Standard
02.05
September 2001
Group GHLRBS This OM group maintains statistics related to the DMS-HLR basic services. In particular, registers in this group peg the number of subscribers provisioned with the VBS or VGCS basic service. Group GMAPCH2 This OM group measures the number of requests and responses received for each Prepare Group Call operation, the number of Forward Group Call, and the number of Process Group Call Operations that are implemented in the MAP layer. Group MCLUSTER The MCLUSTER OM group records the events that take place in a mobile cluster call (VBS or VGCS) terminating to a list of cells in the service area. Group MSCGCS This OM group captures the usage information of VGCS and VBS services. In particular, this group records the number of times the service is invoked (successfully and unsuccessfully) how it is invoked (service subscriber versus dispatcher versus Network Initiated group call origination)
Group MSCUPLNK This group provides information about uplink channel control for a GSM VGCS group call terminating to a list of cells.
Billing
The existing Teleservice Module captures the usage of VGCS call services. The code for VGCS is 91. Figure 3-26 is an example of a VGCS call billing record.
GSM
3-104
Figure 3-268 VGCS call billing record MSCD GCDR600 JAN04 23:27:15 3751 INFO Billing Record Data Location: GSMMSC Software Call Recording HEX ID=AA STRUCT CODE=10002C CALL CODE=001C STUDY IND=0C CALL FORWARDING IND=0C CALLING PARTY=1CFFFFFCFFFFFF505021120311003C CALLING NUM=2C01000CFFFFFFFF0411002131001C CALLED NUM=0C01000CFFFFFFF61601112C CALLING EQUIP=FFFFFFFFFFFFFFFFFFFFFC ADDITIONAL INFO=FFFC CALLTS: CH ALLOC=FFFFFFFFFFFFFFFC ANSWER=706104232711400C DISC=760104232714200C REL=760104232714200C OFF-AIR-CALL-SET-UP=0C HALF-RATE-IN-USE=0C CAUSE FOR TERM=000C CALL REFERENCE=03475C MS CLASSMARK=FFF0FFFC CLASSMARK TS=FFFFFFFFFFFFFFFC DIALED DIGITS=6CFFFFFFFFFFFFFFFFFF112C OG TRUNK GROUP=00719C OG TRUNK MEMBER=00001C OG ROUTE GROUP=086C TRK SEIZ TIME=760104232711000C CALLING SUBSCR CTGY=000C CALL INDICATOR=0000000C CALL DURATION=0000003C DIAGNOSTIC=00016C MSCID=01101CFFFFFFFFF614180400000C RECORD NUMBER=0000290C MC=006C TELESERV=091C TIME=760104232711000C MC=000C NOTE #1: Dialed Digits=GID NOTE #2: Called Num=GCRef
411-2231-827
Standard
02.05
September 2001
Integrated Acknowledgement Center (IAC)

Purpose of the IAC
IAC is an optional function. The optionality is built into the mobile. IAC collects and stores information about high priority calls for VBS and VGCS calls. The IAC functionality is located on the DMS-MSC.
How the IAC works

After a high priority VBS or VGCS call is released, the mobiles involved in the call set up a subsequent call known as an acknowledgment call. The acknowledgement call is sent to the IAC.
The setup portion of the acknowledgement call contains data about the high priority call. This information is included in a user-to-user signaling information element (UUS1). The IAC extracts the data from the UUS1 and captures it in a new call detail billing record known as an acknowledgement record. The acknowledgment record is generated and stored on the billing server. The Network Operator can, in near-real time or at any later occasion, query the data through operations on the GSM Billing Mediation Device (GBMD) for post-incident analysis. Once the data is stored in an acknowledgment record, the DMS-MSC releases the acknowledgment call. It releases the call by sending a RELEASE COMPLETE message with an acknowledgment indication in the UUS1. Figure 3-27 illustrates the message flow of an acknowledgement call.
GSM
3-106
Figure 3-27 Message flow of an acknowledgement call

IAC feature
BSS
HLR
Channel Request Immediate Assign (CM-Service Request)
MSC/VLR
EIR
MSC/VLR
Complete Layer 3 Info
Authenticate Request Authentication Response
BSSMAP Cipher Mode Command BSSMAP Cipher Mode Complete
Cipher Mode Command
Cipher Mode Complete
SETUP message (UUIE)
The information from the UUIE is captured into an Acknowledgment record.
RELEASE COMPLETE (UUIE-acknowledge)
* Note: IAC resides on the MSC
Normal operation with successful outcome The UUS1 is transferred in the signaling messages towards the DMS-MSC. If an external network is used, the external network must support the transfer of user-to-user information.
The DMS-MSC must clear the call and acknowledge the received UUS1 using the user-user information element in the release complete message. The mobile equipment controls the procedure even though DMS-MSC associated with the IAC always clears the call. The mobile equipment considers the confirmation procedure to be successful once the mobile equipment receives a positive acknowledgment in the RELEASE COMPLETE message. Exceptional procedures or unsuccessful outcome It is possible for a call to be cleared without an acknowledgement message being sent to the mobile equipment. (This can occur due to network congestion or radio link failure.) When this happens, the mobile equipment repeats the procedure by setting up another call using an updated confirmation message. There are two types of negative acknowledgement messages that can be sent to the mobile equipment. Negative acknowledgment #1 (NACK1) indicates a reparable error. When the mobile receives a NACK1, the mobile is requested to repeat the confirmation (as long as the maximum repetition value is not reached) using an updated confirmation message. Negative acknowledgment #2 (NACK2) indicates a fatal error. When the mobile receives a NACK2, the mobile does not repeat. Instead, the mobile equipment stores an error locally on an event recorder.
If the confirmation call signaling cannot complete (for example, the call is interrupted by a call with a higher priority), the mobile equipment repeats the procedure by setting up a call using an updated confirmation message. The mobile equipment repeats the procedure after the preceding signaling relationship is terminated. When more than one confirmation is pending, the earliest call is confirmed first.
How the DMS-MSC supports the IAC
The IAC functionality is integrated into the DMS-MSC and fully supported by the DMS-MSC. The DMS-MSC supports the IAC by performing the IAC functions for capturing the data. The captured records can be viewed through a GSM Billing Mediation Device (GBMD).
This section discusses how the IAC interacts with the following features: hot billing UUS1 Barring of All Outgoing Calls (BAOC)
GSM
3-108
Hot billing The IAC uses the same billing stream that hot billing uses. However, the acknowledgment records use a different record type than the hot billing records. The acknowledgement records are intermixed with the hot billing records if both services are provisioned at the same time. UUS1 The IAC supports UUS1 subscription verification. Barring of all outgoing calls (BAOC) If the operator does not want BAOC to block acknowledgment calls, the operator can datafill "VLRXLA" translations to return a "CLASS = EMRG" for the acknowledgment calls called number.
Datafill required for the IAC functionality

The following tables should be datafilled for the IAC functionality: XXCODE tables table VLRXLA
The following paragraphs provide a brief description of these tables. Note: For more detailed information, refer to NTP 411-2231-455, GSM DMS-MSC Office Parameters Reference Manual, and NTP 411-2231-495, GSM DMS-MSC Customer Data Schema. XXCODE tables The OSEL field in the following XXCODE (universal translations) tables needs to be datafilled: AMCODE PXCODE, CTCODE, FACODE, OFCCODE, FTCODE, ACCODE, NSCCODE
This field contains an AC selector. This selector identifies calls as acknowledgement calls. When translations on the called number hits the AC option in the XXCODE tables, the call is identified as an Acknowledgment Call.
The XXHEAD tables should be datafilled before the XXCODE tables. Table VLRXLA The operator should datafill VLRXLA translations if the operator does not want BAOC to block acknowledgment calls. The VLRXLA translations should be datafilled to return a "CLASS = EMRG" for the acknowledgment calls called number.
Log reports associated with IAC

There are no log reports associated with the IAC.
3 3 3
Operational measurements associated with IAC

There are no operational measurements associated with the IAC.
Billing
IAC enhances the GSM billing records to capture data about high priority calls for VGCS and VBS. The information is stored in the new acknowledgment record. The acknowledgment records are written to the GHOT billing stream. Only when table CRSMAP is not datafilled with the GHOT stream is the acknowledgment record written to the GCDR stream. Acknowledgement record The following table describes the contents of the acknowledgement record. The table contains the name of the field, a key indicating how the field is supported, and a description of the contents. The key field has the following meaning: M: this field is mandatory and always populated. Any exceptions to this rule are explicitly described. C: this field is only populated under certain conditions. The conditions under which the field is populated are individually described.
GSM
3-110
Figure 3-28 Acknowledgement record fields Field GSM Record Header M/C/NS M M M GSM Structure Code - Defines the set of ordered data fields to associate with this structure. GSM Call Type Code - Type of call or event. (Acknowledgment Call) Study Indicator Calling Number Called Number M C M Indicates nature of the call/event record. For mobile originated calls this number will be the MSISDN. The address of the called party as seen by the MSC. This is the number employed by the MSC to identify that a call setup message contains the acknowledgement information. This number is the number of the called party if available at this node. The id number of the MSC. Absolute time of when record is captured. Time between end of high priority call and confirmation call Priority of broadcast/group call Group call reference number of high priority call Functional number of the confirming mobile The duration of the high priority call. The reason for the release of the connection of the high priority call. Indicate whether or not the record is output to the GHOT stream. The number assigned to the record generated. Description Hexidecimal ID - Identifies record to be good or data errors occurred.
MSC Number Record Time Priority Release Time Priority Level Group Reference Functional Number Priority Call Duration Priority Call Cause HotBill Record Number
M M C C C C C C M M
The billing system supports the generation of billing records in two different billing streams: the normal billing stream and the hot billing stream. The format of the records in both streams are the same, but the hot billing stream provides near real-time access to the records. The acknowledgment record is output in the hot billing stream.
411-2231-827
Standard
02.05
September 2001
Figure 3-29 shows an example of an acknowledgement record.

Figure 3-29 Example of an acknowledgement record HEX ID=AA CALL CODE=016C STUDY IND=0C CALLING NUMB=2C01000CFFFFFFFFFFFFFFFFF61411000231001C CALLED NUM=2C01000CFFFFFFF61411000231001C MSCID=01000CFFFFFFFFF614180700000C GROUP REF=000001612C FUNCT NUM=00003026178911101C CALL DURATION=001200600C PRIORITY CALL CAUSE=000C RECORD TIME=921115044730700C REL=00214755300C PRIORITY LEVEL=006C HOTBILL=1C RECORD NUMBER=0000254C STRUCT CODE=00020C
GSM
3-112
enhanced Multi-level Precedence and Pre-emption (eMLPP)

Purpose of eMLPP 3
MLPP provides subscribers various priority levels (also called precedence levels). The system uses the priority levels to provide precedence to network resources during call setup and call handover. The system also uses priority levels to pre-empt ongoing calls and applications. Also, the priority value is used so that high priority calls may pre-empt ongoing calls of a lower priority. The priority value is presented to the called party during call setup. There are two versions of MLPP service: GSM enhanced multi-level precedence and pre-emption (eMLPP) ISDN MLPP
MLPP/eMLPP can be used in the following call scenarios: mobile-originated calls mobile-terminated calls including interworking with ISDN eMLPP service mobile-to-mobile calls in case of roaming mobile-to-mobile calls in the same network Voice Broadcast Service (VBS) calls Voice Group Call Service (VGCS) calls Note: eMLPP pre-empts ETSI ISUP and PRI. It does not pre-empt ANSI ISUP and PRI.
How MLPP/eMLPP works

When a user subscribes for service, the service provider sets the default and maximum priority levels for the subscriber. The service provider determines the priority levels based on the subscribers needs.
eMLPP priority levels There are seven priority levels (also called precedence levels) associated with eMLPP service (A, B, 0, 1, 2, 3, and 4). Mobile users may subscribe to all priority levels A, B, 0, 1, 2, 3, or 4. Priority levels A and B are used locally, in the domain of one MSC. For interworking purposes, eMLPP levels A and B map to MLPP level 0. This
411-2231-827
Standard
02.05
September 2001
mapping occurs because ISUP and PRI protocols do not support the precedence levels A and B. ISDN MLPP priority levels There are five ISDN MLPP priority levels: 0, 1, 2, 3 and 4. 0 is the highest level and 4 is the lowest priority level. ISDN users may subscribe to any of the ISDN MLPP priority levels. Originating a call When an eMLPP subscriber originates a call, the subscriber selects (either explicitly or by default) a priority value for the call. To explicitly select a priority level, the eMLPP subscriber includes the priority level in a CM_SERVICE_REQUEST message to the DMS-MSC. The DMS-MSC compares the level against the subscriber information stored in the VLR. Since the DMS-HLR stores the subscriber information, the DMS-HLR downloads the required subscriber information to the VLR. The VLR then compares the requested priority level with the subscribers maximum priority level. If the requested priority level is equal to or less than the subscribers maximum priority level, the DMS-MSC assigns the requested priority level to the call. If the requested priority level is greater than the subscribers maximum priority level, the DMS-MSC assigns the subscribers maximum priority level to the call. The DMS-MSC then notifies the subscriber of the assigned priority level. If the eMLPP subscriber does not request a particular priority level, the DMSMSC retrieves the subscribers default priority level from the VLR. The DMS-MSC then assigns the subscribers default priority level to the call. If the subscriber placing the call is not an eMLPP subscriber, the DMS-MSC assigns the network default priority level to the call. The network default priority level is specific to the DMS-MSC. ISDN/PSTN originations In ISUP or PRI originating calls, an MLPP precedence level may or may not appear in the message. If an MLPP precedence level does not appear in the message, the default precedence level is sent to the terminator. Pre-empting calls When there are not enough idle resources, a call can pre-empt another call in progress. The call being pre-empted must have a lower precedence level than
GSM
3-114
the call attempting the pre-emption. Pre-emption seizes resources that are in use by a call of a lower precedence. A call may be pre-empted any time after the precedence level of a call has been established and before call clearing has begun. There are two types of pre-emption: resource pre-emption called party pre-emption
Resource pre-emption Resource pre-emption terminates a lower precedence call so that resources are made available for a higher precedence call. Resource pre-emption supports pre-empting ETSI ISUP and terrestrial trunks. Contention in gaining terrestrial resources (such as terrestrial trunk, ISUP, and PRI) during initial setup or handover of a precedence call results in resource pre-emption at the DMS-MSC. If at the receipt of a call request, the network can not find a suitable idle circuit to terminate the call, then a search may be conducted to find a suitable preemptable circuit for preemption. The decision to do the search is based on the information contained in the Service Configuration Table. When a network receives a call request, it establishes the precedence level for the call. If a suitable idle circuit is not successful, the value of the calls precedence level determines the action taken. If the calling party has the lowest precedence level of the network (level 4), then the calling party is released. If the calling partys precedence level is higher than level 4 and Table SERVCNFG allows calls with that particular precedence level to pre-empt, the network searches for the lowest precedence circuit. The network searches for a circuit to pre-empt, starting from the lowest precedence level circuits (level 4). If the search is successful, the network pre-empts the targeted circuit, making the circuit available to the call. If the search is unsuccessful, the calling party is released. Table SERVCNFG does not allow calls with that particular precedence level to pre-empt, the network releases the call. No circuit search is performed. Called party pre-emption Called party pre-emption allows an active mobile station to answer an incoming call when the incoming calls priority is greater than the ongoing
411-2231-827
Standard
02.05
September 2001
calls priority level. Therefore, the called party decides whether an ongoing call is pre-empted. Called party pre-emption occurs only when the following two conditions are met: the called party has call waiting service the called party has the auto-answer functionality turned on
Called party pre-emption cannot be invoked if a high priority subscriber tries to reach an active party that does not subscribe to call waiting service. The attempted call setup is abandoned with the cause precedence call blocked. An example of a called party pre-emption scenario follows. Parties A and B are on an active call that has a priority level of 4. Party C originates a call to party A. The originated call has a priority 3. Party A decides to pre-empt the call and accept the call from party C. What happens to party B depends upon whether party A subscribes to the hold service. When called parties subscribe to hold service When a called party with hold service decides to pre-empt an ongoing call to answer an incoming call, the ongoing call is placed on hold and the waiting call is accepted.
If the called party decides to not pre-empt the call, the call waiting service functions as usual, allowing the called party the chance to accept the waiting call. When called parties do not subscribe to hold service When a called party who does not subscribe to hold service decides to pre-empt an ongoing call to answer an incoming call, the ongoing call is released and the waiting call is accepted.
If the called party decides to not pre-empt the call, the call waiting service functions as usual, allowing the called party the chance to accept the waiting call. Call precedence for PRI The DMS-MSC sends the appropriate MLPP information in outgoing messages to the originating or terminating PBX. If the PBX does not support MLPP, the PBX ignores the MLPP information.
GSM
3-116
PRI-originated calls Office parameter MLPP_PBX_FULL_SUPPORT indicates whether all of the PBXs in the network support MLPP service. The office parameter is set to Y when all the PBXs in the network support the MLPP service. When at least one PBX in the network does not support the MLPP service, the office parameter is set to N. Regardless of the value of the office parameter, the DMS-MSC always sends the appropriate MLPP information in the outgoing messages to the originating or terminating PBX. When MLPP_PBX_FULL_SUPPORT is set to N If the Setup message received at the DMS-MSC contains the MLPP information, the MLPP information is used to set the priority level for the call and the caller is assumed to be an MLPP user. If the Setup message received at the DMS-MSC does not contain the MLPP information, the DMS-MSC sets the priority level for the call and the caller is assumed to be an MLPP user. If the call is a voice call, the DMS-MSC hardcodes the priority value 3 and if the call is a data call, the MSC hardcodes the priority value 1. The DMS-MSC always sends MLPP information in an Alerting message to the originating PBX. When MLPP_PBX_FULL_SUPPORT is set to Y If the Setup message received at the DMS-MSC contains the MLPP information, the MLPP information is used to set the priority for the call and the caller is assumed to be an MLPP user. If the Setup message received at the DMS-MSC does not contain the MLPP information, the caller is assumed to be a non-MLPP user. If the Setup message contains the MLPP information, the DMS-MSC sends the MLPP information in an Alerting message to the originating PBX. If the Setup message does not contain the MLPP information, the DMS-MSC sends an Alerting message with NO MLPP information to the originating PBX. Call precedence for PRI-originated calls Figure 3-30 illustrates the MLPP calls originated at a PBX.
411-2231-827
Standard
02.05
September 2001
Nortel Networks Confidential Figure 3-30 MLPP calls originated at a PBX Originating PBX MSC
Invoke: MLPP Call Request Setup Call Proceeding MLPP Precedence IAM R e turn R esu lt: MLPP Call Request Alerting Connect MLPPUser Status ACM1 ANM N E T W O R K
Note 1: The ACM only contains the MLPP User Status for ETSI ISUP. The ACM for ANSI ISUP does not contain the MLPP User Status.
When the DMS-MSC receives a Setup Indication with a Facility Information IE containing an MLPP Call Request Operation, the DMS-MSC sets the call precedence level. The DMS-MSC sets the level based on the precedence value received in the Setup message (except for emergency calls). For emergency calls, the DMS-MSC sets the precedence level for the call through the table OFCVAR HIGH_PRIORITY_CALL OPARM (2 for point-to-point emergency calls, including Type 1 and Type 2). The DMS-MSC then sends the call precedence to the subsequent network in an ISUP IAM message. When the DMS-MSC receives an ACM with an MLPP user indicator, the DMS-MSC builds and sends a Return Result component to the originating PBX. PRI-terminated calls As previously stated, office parameter MLPP_PBX_FULL_SUPPORT indicates whether all of the PBXs in the network support MLPP service.
GSM
3-118
When MLPP_PBX_FULL_SUPPORT is set to N The DMS-MSC always sends MLPP information in a Setup message to the terminating PBX. The DMS-MSC does not expect the Alerting message (sent by the terminating PBX) to contain the MLPP information. The DMS-MSC handles the message even when the message does not contain MLPP information. A log report is not generated when the Alerting message does not contain the MLPP information. When MLPP_PBX_FULL_SUPPORT is set to Y The DMS-MSC always sends MLPP information in a Setup message to the terminating PBX. The DMS-MSC expects the Setup and Alerting messages to contain MLPP information. A log report is generated when the Setup and Alerting messages do not contain the MLPP information. The log report flags the protocol violation. Call precedence for PRI-terminated calls Figure 3-31 illustrates MLPP calls terminating on a PBX.
Figure 3-31 MLPP calls terminating on a PBX Terminating PBX MSC
Invo ke MLPP Call Request Setup Call Proceeding Return Result MLPP Call Request Alerting Connect
MLPP Precedence IAM N E T W MLPPUser Status ACM1 ANM O R K
Note 1: The ACM only contains the MLPP User Status for ETSI ISUP. The ACM does not contain the MLPP User Status for ANSI ISUP.
411-2231-827
Standard
02.05
September 2001
The precedence level of a call terminating to a PBX depends on the precedence assigned to the call on origination. If a precedence level is received in an IAM message, then it is used as the precedence level for the PRI-terminated call (except for emergency calls). For emergency calls, the DMS-MSC determines and sets the precedence level for the call through the table OFCVAR HIGH_PRIORITY_CALL OPARM (2 for point-to-point emergency calls, including Type 1 and Type 2). A precedence call is indicated to a terminating PBX by the presence of a Facility Information IE with an Invoke component of MLPP call Request operation. The terminating PBX sends a Return Result component of the MLPP Call Request operation in an Alerting message. The Return Result acknowledges the precedence received in Setup message. Upon receipt of a Return Result component in Alerting message, an MLPP user status indication is sent in Backward Call Info in an ACM toward the originating network. Call precedence on inter-MSC handover In the event of a handover, the call precedence is propagated to the target BSS in a Handover Request message. It is propagated so that it can arbitrate over radio resources. The call precedence is sent in the MAP-E Prepare HO message to the target DMS-MSC so that it could be propagated to the target BSS in the Handover Request message. Figure 3-32 illustrates precedence on inter-MSC handover.
GSM
3-120
GSM-R functionalities Figure 3-32 Precedence on inter-MSC handover Serving BSS Serving MSC MLPP Precedence
Prepare HO [HO Request]
Target MSC
Target BSS
Handover Required
eMLPP Precedence
Handover Request
Handover Request Ack Prepare HO Ack [HO Request Ack]
MLPP Precedence
IAM ACM Handover Command PAS [HO Detect] Handover Complete SES [HO Complete] Handover Detect
ANM Clear Command
Clear Complete
Call precedence and catastrophe screening Catastrophe screening allows calls with precedence values equal to or greater than the table OFCVAR OPARM HIGH_PRIORITY_CALL go through during a catastrophe situation. Calls with precedence values of less than the HIGH_PRIORITY_CALL OPARM are not allowed to go through when the DMS-MSC is in catastrophe mode. Providing precedence in handovers When a call is being handed over, the DMS-MSC sends the calls priority level to the base station subsystem (BSS). The DMS-MSC sends the priority level in a Handover Request message. The BSS uses the priority level to provide precedence to network resources during call handover.
411-2231-827
Standard
02.05
September 2001
How the DMS-MSC supports eMLPP

The DMS-MSC supports eMLPP service by performing the following functions: determines the precedence levels of mobile-originated or mobileterminated calls performs called party pre-emption
How the DMS-HLR supports eMLPP

The DMS-HLR supports eMLPP service by performing the following functions: stores the subscriber information propagates eMLPP provisioning information to the VLR updates subscriber data when necessary
screens table GHLRNDSC to determine which services are supported by a given DMS-MSC and VLR allows an operator to decide whether or not a subscriber is denied or restricted from roaming to a DMS-MSC that does not support eMLPP service
This section discusses how eMLPP interacts with the following features: call waiting call hold emergency calls voice broadcast service (VBS) and voice group call service (VGCS) call forwarding on mobile subscriber busy call forwarding on no reply call queuing
Call waiting With eMLPP service, the call waiting indication to the mobile station includes the precedence level of the waiting call. Called party pre-emption occurs if the mobile station decides to accept the waiting call. Table 3-33 describes the interactions a calling and called party experience for the call waiting, call hold, and eMLPP services. This table assumes that the
GSM
3-122
called party is already on an active call when the calling party tries to terminate to it.
Figure 3-33 Interactions between call waiting, call hold, and eMLPP User calling called calling called calling called calling called calling called calling called Call waiting * Yes * No * Yes * Yes * Yes * * Call hold * Yes * * * No * No * Yes * * eMLPP Yes No Yes No Yes Yes Yes No Yes Yes No * Result Called party pre-emption is not invoked. The new call is presented to the called party as a call waiting. If the user accepts the new call, the old call is put on hold. The new call is not presented to the called party as a call waiting. The new call is released with the cause User Busy. The called party mobile station may invoke called party pre-emption. If called party preemption is invoked, the old call is released. Called party pre-emption is not invoked. The new call is presented to the called party as a call waiting. If the user accepts the new call, the old call is released. The called party mobile station may invoke called party pre-emption. If called party preemption is invoked, the old call is put on hold. The calling party is assigned the networks default precedence level because the new call is assigned the lowest precedence level, called party pre-emption does not occur.
Yes means the user subscribes to the feature. No means the user does not subscribe to the feature. * means it does not matter whether the user subscribes to the feature.
Call hold The Hold and Hold Notification messages now have the cause value of Called Party Preemption. A user with eMLPP service can initiate call hold service during called party pre-emption. Note: Refer to Table 3-33 for a description of the interactions that the called and calling parties experience with the call hold, call waiting, and eMLPP services.
411-2231-827
Standard
02.05
September 2001
Emergency calls Point-to-point emergency calls (Type 1 and Type 2) are assigned the value of table OFCVAR OPARM HIGH_PRIORITY_CALL. An emergency call cannot be pre-empted by an eMLPP call. VBS and VGCS The eMLPP provides priority levels for call setup for VBS and VGCS. The eMLPP also provides for called party pre-emption, which allows an active mobile station involved in a VBS and VGCS call to answer an incoming call of a higher priority level than the ongoing calls priority level. Priority levels for group calls are datafilled in GCR and can only be changed through provisioning. Further details regarding the interaction between the eMLPP, VBS, and VGCS features are provided in the sections that discuss the VBS and VGCS features. Call forwarding on mobile subscriber busy Call waiting overrides call forwarding on busy (CFB). The called party is presented with the call waiting service. CFB applies only if the mobile station does not apply called party pre-emption or the user rejects the call waiting. Without call waiting, CFB functions as normal (forwarding the call when the called party is busy). Call forwarding on no reply If a mobile station does not automatically accept an incoming call while being idle and the user does not accept the call, the call may be forwarded to another party if call forwarding no reply applies. Call queuing eMLPP service overrides call queuing.
Datafill required for eMLPP service

The following tables must be datafilled for eMLPP service: table OFCVAR table GHLRSSOP table GHLRNDSC table GHLRVLR table SERVCNFG
The following paragraphs provide a brief description of these tables.
GSM
3-124
Note: For more detailed information, refer to NTP 411-2231-455, GSM DMS-MSC Office Parameters Reference Manual, and NTP 411-2831-151, GSM DMS-HLR Customer Data Schema. Table OFCVAR datafill Datafill the following office parameters EMLPP_DEFAULT_PRECEDENCE HIGH_PRIORITY_CALL
EMLPP_DEFAULT_PRECEDENCE This office parameter sets the default priority level for the network. This is also the default priority level given to any call that does not have a priority level. Values 0 to 4 can be entered into this office parameter. 0 sets the network default priority level at the highest possible level while 4 sets the network default priority level at the lowest possible level. This office parameter has a default value of 4, which is the lowest possible level. The value of this office parameter has direct consequences on all call processing, including pre-emption, billing, and signaling. HIGH_PRIORITY_CALL This office parameter defines the networks high precedence level. The range of values for this parameter is A, B, 0, 1, 2, 3. The default setting for this office parameter is 0. Table GHLRSSOP datafill Table GHLRSSOP contains supplementary service option data for provisioning, registration, and activation of supplementary services associated with a subscriber international mobile subscriber identity (IMSI) or basic service group. The table contains one tuple for each supplementary service provisioned against the IMSI. Tuples are identified with a multi-part key consisting of the IMSI MCC, IMSI MNC, the IMSI MSIN and the supplementary service. The order of tuples in table GHLRSSOP is based on a multi-part key. The primary sorting sequence based on the MCC, MNC, and MSIN is in lexical ascending order. The secondary sorting sequence is based on the supplementary services, which are displayed in the following order: CFU, CFB, CFNRY, CFNRC,..., EXT, ECT, EMLPP, USS1, FA.
411-2231-827
Standard
02.05
September 2001
Table GHLRNDSC datafill Table GHLRNDSC contains data associated with VLR screening classes. The DMS-HLR uses Table GHLRNDSC to determine the services supported by a particular VLR the encoding method to be used to propagate the service how the DMS-HLR should react if a service is not supported
Two fields contain information regarding eMLPP and USS1 service. Field Priority defines the eMLPP screening options. Field InfoXfer defines UUS1 screening options. Table GHLRVLR datafill Table GHLRVLR contains information about the VLRs with which the DMSHLR communicates. In table GHLRVLR, VLRs are listed according to their address, which is an E.164 international number. Table GHLRVLR also includes the version of supported messages. Each tuple in this table contains the VLR address and reset status. The reset status displayed refers to the DMS-HLR reset operation. Only the NEED_NOT_NOTIFY state is entered at table.control. All other values are read-only. This refers to the stage of reset of the VLR with respect to the DMS-HLR. A VLR is added to this table in one of the following ways: manually by the operator automatically by a subscriber activity, resulting in an update location message
The version stored for the application context in table GHLRVLR may not exceed the version stored in table GHLRPARM. Table SERVCNFG datafill This table stores eMLPP priority level configuration data that applies to the DMS-MSC, such as Setup class, preemption capability and VBS/VGCS TXX timer values associated with the different eMLPP priority levels.
Log reports associated with eMLPP service
When the DMS-MSC fails to present a call to an active mobile user because the mobile does not subscribe to call waiting, the system generates log report GMSC612. This log report is given a cause value of User Busy. Note: For more detailed information on these log reports, refer to NTP 411-2231-515, GSM DMS-MSC Log Reference Manual.
GSM
3-126
Operational measurements associated with eMLPP service

The following operational measurement (OM) groups contain information regarding eMLPP service: eMLPPSS HLRADM3 MLPP
The following paragraphs briefly describe these OM groups. Note: For detailed information on these OM groups, refer to NTP 4112231-815, GSM DMS-MSC Operational Measurements Reference Manual, and NTP 411-2831-814, GSM DMS-HLR Operational Measurements Reference Manual. Group eMLPPSS This group gathers information on the eMLPP supplementary service for each call. Currently, there are seven priority levels defined. Each call may belong to any one of the priority levels. Group HLRADM3 This group maintains statistics related to the DMS-HLR supplementary services. This group deals only with GSM defined supplementary services. Group MLPP This group contains registers that measure how often pre-emption occurs due to the eMLPP service. The following resources can be pre-empted: PSTN trunks terrestrial trunks
Billing
3
The GSMFMT billing format provides information regarding eMLPP calls. Field SS code indicates the type of supplementary service used by the calling mobile. Field SS action indicates the calling mobile is an eMLPP subscriber. Field SS par indicates the priority level of the call. Below is an example for a mobile with a priority level of 4: MC=005C SS INFO: SS CODE=0A1 SS ACTION=5C TIME=FFFFFFFFFFFFFC SS PAR=FFFFFFFFFFFFFFFFFFFF1C RESULT IND=021C
411-2231-827
Standard
02.05
September 2001
Fast Call Setup

Purpose of Fast Call Setup
Fast Call Setup allows a mobile station, VBS, or VGCS call to skip the authentication and cipher procedures during the setup process. These procedures are skipped regardless of how office parameters AUTH_CONTROL_PARM and GMSC_CIPHERING are datafilled.
How Fast Call Setup works
Fast Call Setup is based on the following: the eMLPP precedence selected or assigned to a mobile origination (that includes the mobile service, Voice Broadcast Service and Voice Group Call Service origination) the eMLPP precedence selected by the mobile originating party the ISDN MLPP precedence received in the incoming IAM message that includes only the Mobile Service termination the VBS/VGCS Immediate Setup message. This message allows call setup without an MM connection being previously established.
Fast call setup procedure applies to eMLPP priority mobile service (MS) origination MLPP/eMLPP mobile termination VBS/VGCS origination VBS/VGCS dispatcher termination VBS/VGCS immediate setup origination
The following subsections describe each type of fast call setup calls. MS originations and VBS/VGCS originations The eMLPP MS subscriber has a default and maximum priority level set by the service provider in the DMS-HLR. This priority information is transported to and saved in the VLR. The priority information may be included in CM_SERV_REQ message when VBS/VGCS subscriber originates a group call. Based on the priority level included in CM_SERV_REQ, table SERVCNFG is queried to determine the call setup CLASS for each MS, VBS, or VGCS origination. Table SERVCNFG is the eMLPP service configuration table. Figure 3-34 depicts the priority level used to query table SERVCNFG. If no priority level is provided in CM_SERV_REQ and the subscriber is an active eMLPP subscriber, the eMLPP default precedence is used. If the
3-128
eMLPP default precedence equals the value set in field CLASS 1 in table SERVCNFG, fast call setup is triggered. However, if the eMLPP default precedence does not equal the value set in field CLASS 1 in table SERVCNFG, fast call setup is not triggered.
411-2231-827
Standard
02.05
September 2001
Nortel Networks Confidential Figure 3-34 Selection of eMLPP Priority level for call setup class query
CMSR received at MSC/VLR
Subscribed to eMLPP?
eMLPP present in CMSR?
Is it greater than the subscribed max. eMLPP? Y
Use the selected eMLPP
Use the subscribed max eMLPP
Use the subscribed default eMLPP
Use the office parm precedence
Query SERVCNFG table for CLASS call setup
GSM
3-130
Depending on the datafilled class, the fast call setup is applied to a MS origination as follows: For class 1, fast call setup is triggered. Authentication and Cipher procedures are not performed, regardless of how AUTH_CONTROL_ PARM and GMSC_CIPHERING are datafilled. Refer to Figure 3-35.
Figure 3-35 Example of MS call with Fast Call Setup
affected node
BSS
M SC VLR EIR
HLR
Channel Request Immediate Assign SABM(CM-Service Request) Complete Layer 3 Info (CM-Service Request) UA(CM-Service Request)
MSC/VLR
eMLPP Priority selected by MS
Authentication and Ciphering are skipped
Setup Send Info Outgoing Call Complete Call Call Proceeding
The rest of the MS call flow is unchanged and omitted for brevity
Fast call setup is not triggered for classes 2 and 3. Authentication and Cipher procedures are performed as normal. Refer to Figure 3-36.
Nortel Networks Confidential Figure 3-36 Example of MS call without Fast Call Setup
affected node
BSS
HLR
Channel Request Immediate Assign SABM(CM-Service Request) Complete Layer 3 Info (CM-Service Request) UA(CM-Service Request) Authenticate Request Authentication Response
BSS M SC MSC
VLR EIR
MSC/VLR
eMLPP Priority selected by MS
Process Access Request Authenticate
Set Ciphering Cipher Mode Command BSSMAP Cipher Mode Command BSSMAP Cipher Mode Complete
Cipher Mode Complete Access Request Accepted Setup Send Info Outgoing Call Complete Call Call Proceeding
The rest of the MS call flow is unchanged and omitted for brevity
* Note: If MS call origination is NOT CLASS 1 setup, Authentication and Cipher procedures may be performed as controlled by the datafill of OPARMs AUTH_CONTROL_PARM in table OFCVAR and GMSC_CIPHERING in table OFCOPT.
MS terminations eMLPP Fast Call Setup also is applicable to priority MS terminations and VBS/VGCS dispatcher terminations. It is not applicable to VBS/VGCS listeners. For the MS termination or dispatcher termination, the priority level of call is determined based on the priority set in table GCR.
GSM
3-132
The priority level is used to query table SERVCNFG for the call setup class. Depending on the datafilled class, the fast call setup is applied to MS termination. If the query result is class 1, fast call setup is triggered. Authentication and Cipher procedures are not performed regardless of how AUTH_CONTROL_PARM and GMSC_CIPHERING are datafilled. Refer to Figure 3-37.
Figure 3-37 Example of MS termination with Fast Call Setup
affected node
BSS
MSC VLR EIR

IAM (MLPP priority) SETUP (eMLPP priority)
HLR
MSC/VLR
Paging Request Channel Request Immediate Assign Paging Response Complete Layer 3 Info (Page response)
Based on eMLPP priority, the Service Configuration Table is queried and the call setup CLASS is CLASS 1. Therefore, Authentication and Cipher procedures are not performed.
Paging (eMLPP priority)
MLPP Priority is mapped exactly oneto-one to eMLPP priority
Setup
Call Confirmed
The rest of the MS termination cal flow is unchanged and omitted for brevity
Note: This call flow is also applied to the calls which are considered security risks.
If the query result is class 2 or 3, call setup proceeds as normal. Authentication and Cipher procedures are performed as setup in OPARMs AUTH_CONTROL_PARM and GMSC_CIPHERING. Refer to Figure 338.
411-2231-827
Standard
Nortel Networks Confidential Figure 3-38 Example of MS termination without Fast Call Setup
affected node
BSS
MSC VLR EIR

IAM (MLPP priority) Setup (eMLPP priority)
HLR
Paging Request Channel Request Immediate Assign Paging Response
Paging (eMLPP priority)
MSC/VLR
if priority info included, MLPP Priority is mapped exactly one-to-one to
Complete Layer 3 Info (CM-Service Request)
Based on eMLPP priority, the Service Configuration Table is queried and the call setup CLASS is NOT CLASS 1. Therefore, the call setup behavior is
Process Access Request Authenticate Authenticate Request Authentication Response Set Ciphering Cipher Mode Command BSSMAP Cipher Mode Command BSSMAP Cipher Mode Complete
Cipher Mode Complete Setup Call Confirmed
Access Request Accepted
The rest of the MS termination call flow is unchanged and omitted for brevity
*
Immediate setup Immediate setup procedure applies to high priority VGCS/VBS calls initiated by service subscribers, where the terminal has initiated the call by using Immediate Setup message. This procedure allows setup of the call without previous establishment of an MM connection. The method bypasses authentication and ciphering. Figure 3-39 gives the call flows for Immediate Setup.
3-134
Figure 3-39 Example of Immediate setup calls with Fast Call Setup
affected node
BSS
MSC VLR
HLR
Channel Request Immediate Assign Immediate Setup Immediate Setup
MSC/VLR
Authentication and Ciphering are skipped, treat Immediate Setup as CM Service
Channel Mode Modify
Assignment Request
Channel Mode Modify ACK
Assignment Complete
The remainder of the VBS/VGCS call flow is not shown here.
Note: This call flow is also applied to the calls which are considered security risks.
Datafill required for Fast Call Setup

Fast Call Setup applies only to the precedence levels datafilled as Class 1 in field Setup Class in table SERVCNFG.
Log reports associated with Fast Call Setup

There are no log reports associated with Fast Call Setup.
Operational measurements associated with Fast Call Setup
OM group MSCGCS contains two registers that are used to count the usage of VGCS/VBS Immediate Setup. These registers are VGCSIMST - number of VGCS Immediate Setup invocations VBSIMST - number of VBS Immediate Setup invocations
Billing
Fast Call Setup does not have an impact on billing information.
GSM
3-136
Nature of Address (NOA) Format Customization

Purpose of NOA Format Customization 3
This functionality enables a network operator to control the address format of certain calling/connected party addresses.
How NOA Format Customization works
Through data tables, a craftsperson specifies the preferred address format to be either national or international. A national address consists of an optional national prefix followed by a national (significant) number. An international format consists of a country code followed by a national (significant) number. The leading digits in an international format are the CC digits. The specification of a preferred address format affects the format used for that address when it appears in mobile signaling (calling line presentation) trunk signaling billing
Address format preferences for trunk terminations can be specified both universally and by trunk group. This functionality enables the network operator to specify the preferred address format to be used for the calling party, redirecting party, and original called party. The preferred address format can be specified as one of the following or set to follow the called numbers nature of address (NOA): national international unknown
Because this functionality is controlled by datafill, network operators can tailor the format of these address parameters according to regional or network-specific requirements. Also, the network operator can specify different address format preferences for mobile and trunk terminations, and specify address format preferences for trunk terminations on a trunk group basis.
411-2231-827
Standard
02.05
September 2001
Office parameter REPLACE_MS_CC_DIGITS is used to convert an MSISDN to national format when the MSISDN is included in messages that are sent to the public switched telephone network (PSTN). However, network operators may need to change the format of address parameters for reasons other than the message is being sent to the PSTN. These additional reasons include the following: In trunk originations, when digits are received by signaling parameters on the incoming trunk, the address format of the calling party, original calling party, and original called party need to be converted to a national format before the digits are sent to the PSTN. The address format used for all parameters sent to a terminating mobile subscriber need to be in an international format so that the addresses are valid wherever the mobile subscriber roams. The address format used for all parameters sent over a particular trunk need to be in an international format, for whatever reason. Special cases of this requirement include: calls terminating to particular nodes that expect addresses in an international format (for example, certain voice mail system nodes) calls in which the originating party (and/or redirecting party) and the terminating party are in areas served by different national numbering plans The preceding reasons to change the format of address parameters may or may not be applicable for a particular office, depending on the network the office serves other networks connected to the office national and provincial regulations associated with the region being served specific local conditions
This section discusses how NOA Format Customization interacts with the following: signaling Number Identification Enhancements OPARM REPLACE_MS_CC_DIGITS OPARM REPLACE_INTL_ROAM_CLID OPARM GSM_CALLING_NUMBER_NOA
GSM
3-138
Signaling This functionality does not change the signals recognized by the DMS-MSC. Nor, does it change the possible parameters used in the signals recognized by the DMS-MSC. However, it can change the address format (NOA) of parameters, including DTAP: Calling Party Number in the DTAP Setup message ISUP: CGN, RDN, and OCN in the ISUP IAM PRI: Calling Party Number in the PRI Setup message
If office parameter USE_REDIRECTING_ADDRESS_FOR_CLIP is turned on, the Redirecting Number is presented for calling line identification presentation (CLIP). Therefore, the NOA preference in the Redirecting Number field is used to control the address format. If the USE_REDIRECTING_ADDRESS_FOR_CLIP OPARM is turned off, the calling number is presented for CLIP. Note: In Q.931, the address format is indicated by the Type of Number (TON) field in the calling/called party address parameter. Therefore, the datafill could change the TON in the calling party address in a DTAP or PRI Setup message. Number Identification Enhancements The Number Identification Enhancements functionality enables the network operator to use universal translations datafill to manipulate the digits in the calling number before it is sent to a mobile subscriber with GSM CLIP supplementary services. The modification applied to the calling number digits depends on the TON of the calling party number, which may have been modified by tables PETSIG and OFCVAR. OPARM REPLACE_MS_CC_DIGITS NOA Format Customization can be used to obtain all the functionality previously provided by OPARM REPLACE_MS_CC_DIGITS. If both preferred NOA and REPLACE_MS_CC_DIGITS are enabled, OPARM REPLACE_MS_CC_DIGITS is applied first. For example, consider the following situation. OPARM REPLACE_MS_CC_DIGITS is used to convert the CGN, RDN, and OCN from international to national format in a mobiletrunk call. The same functionality is achieved by datafilling option NATL for CGN, RDN, and OCN in table PETSIG. If the INTL option was datafilled for preferred NOA, the CGN, RDN, and OCN are converted back to the international format. OPARM REPLACE_INTL_ROAM_CLID This OPARM is checked on the originating half of the mobile call and the NOA Format Customization functionality comes in on the terminating half of the call. If the REPLACE_INTL_ROAM_CLID parameter changes any
numbers, the system uses those number for the NOA Format Customization functionality and operates on those numbers. OPARM GSM_CALLING_NUMBER_NOA The NOA Format Customization functionality overrides OPARM GSM_CALLING_NUMBER_NOA.
Datafill required for NOA Format Customization
The following tables require datafill to enable the NOA Format Customization functionality: table GSMVAR table PETSIG table OFCVAR
The following paragraphs provide a brief description of these tables. Note: For more detailed information, refer to NTP 411-2231-455, GSM DMS-MSC Office Parameters Reference Manual, and NTP 411-2231-495, GSM DMS-MSC Customer Data Schema. Table GSMVAR datafill The subfields CC_DIGITS_TO_REPLACE and MS_NP_DIGITS of OPARM REPLACE_MS_CC_DIGITS in table GSMVAR must be datafilled to use the NOA Format Customization functionality. These subfields must be datafilled even when OPARM REPLACE_MS_CC_DIGITS is not going to be used. Table PETSIG datafill This table specifies ITU-ISUP signaling options on PSTN enhanced trunks (PETs). Each tuple in table PETSIG can contain a combination of signaling options. A signaling option can appear only once in a tuple. Each tuple in PETSIG corresponds to an index obtained from subfield SIG_IDX of field GRPINFO in table TRKGRP. This creates a one-to-one relationship between table TRKGRP and PETSIG. Preferred NOA is added as an optional field to table PETSIG. This field has three subfields: Calling_Number Redirecting_Number Original_Called_Number
For trunk terminations, the DMS-MSC uses the CLLI for the terminating trunk group to index into table PETSIG through table TRKGRP.
3-140
Each of the subfields contains a value representing the address format preference. The options for address format preference are: none international national national without national prefix unknown called number (the address format of the called number)
A default tuple specifies the address format preference to use when a tuple is not found for the terminating trunk group (CLLI). A value of NONE indicates that no change should be applied. For a value of UNKNOWN, the NOA is changed to Unknown but the DMS-MSC does not perform digit manipulation. Table OFCVAR datafill The PREFERRED_NOA OPARM contains the preferred NOA information for the calling number, the redirection number, and the original called number in their respective subfields. The possible values include NONE INTL NATL NATWNP (national without national prefix) UNKNOWN CDN (the address format of the called number)
The default value for all three subfields is NONE.
Log reports associated with NOA Format Customization

There are no log reports associated with NOA Format Customization.
Operational measurements associated with NOA Format Customization

There are no OMs associated with NOA Format Customization.
411-2231-827
Standard
02.05
September 2001
Billing
3
The DMS-MSC attempts to convert addresses according to the format preference specified in tables PETSIG and OFCVAR. The DMS-MSC attempts to convert addresses before they are captured to billing records representing call terminations. This means that tables PETSIG and OFCVAR affect the format of addresses that are captured to the Calling Number field in mobile termination records, roaming records, and outgoing trunk records the Redirecting Number found in the SS Parameters field of the Supplementary Services Information Module
In most cases, the format of the number captured in these call termination records will match the format of the number as it appeared in the outgoing signaling. If the USE_ORIGINAL_CALLING_NUMBER_FOR_BILLING parameter is turned on, the original calling number is captured for billing. Therefore, the NOA preference in the Calling Number field is used to control the address format. If the USE_ORIGINAL_CALLING_NUMBER_FOR_BILLING parameter is turned off, the Redirecting Number is captured for billing purposes.
GSM
3-142
411-2231-827
Standard
02.05
September 2001
A-1

This appendix discusses the load and GSM11 features used by GSMR02.
The GSM10 load

GSMR02 is on an offstream development plan. Therefore, GSMR02 does not use the GSM11 load that other development streams use. Instead, GSMR02 uses the GSM10 load.
GSM11 functionalities used by GSMR02

To operate according to specifications, GSMR02 requires three GSM11 functionalities. This section lists the required functionalities and explains how the unsupported functionalities are handled. Supported GSM11 functionalities To operate according to specifications, GSMR02 requires the following functionalities from the GSM11 load. These functionalities are: GM2728, DMS-HLR Support for Phase 2 MS-initiated and Networkinitiated USSD GR2621, IN VLR Logic Migration GR2731, MSC Changes for End-to-End Subaddress Support GR2803, NOA Address Format Customization
Following is a brief description of these functionalities. For a listing of the data schema, operational measurements, and log reports associated with these functionalities, refer to the module entitled, Delta information. DMS-HLR support for phase 2 MS-initiated and network-initiated USSD This functionality enhances the DMS-HLR to support the following operations associated with Unstructured Supplementary Service Data (USSD): Process_Unstructured_SS_Request (PUSSR) Unstructured_SS_Request (USSR)
A-2 Appendix A: Supported GSM11 features
Unstructured_SS_Notify (USSN)
The above operations provide support for mobile station-initiated and network-initiated USSD. Through the above operations the mobile station and the network can communicate with the HLR using USSD GSM MAP Phase 2 signalling. IN VLR logic migration This functionality provides the following service interaction enhancements with IN DP2: Removes the restriction of blocking regular call hold or multi-party hold on an active call from an originating mobile to an Intelligent Peripheral (IP). Regular or multi-party hold now is permitted on an active IP call when the call is setup by triggering at the IN DP2 and receiving an EstablishTemporaryConnection message from the gsmSCF. Once the call is placed on hold, a subsequent call can be originated. Removes the restriction of blocking multi-party bridging into an active call from a mobile to an IP. Again, this call must be setup by triggering at the IN DP2 and receiving an EstablishTemporaryConnection message from the gsmSCF. Call waiting now is permitted on a mobile actively engaged in a call to an IP. Again, this IP call must be setup by triggering at the IN DP2 and receiving an EstablishTemporaryConnection message from the gsmSCF.
This functionality shifts the dependency of IN from Class Of Service (COS) translations to VLR translations for Type II Emergency checking. Finally, this functionality enables the customer to provision numbers (normally classified as Emergency Type II) through VLR translations. MSC changes for end-to-end subaddress support This functionality enhances the processing of the subaddressing information elements within the DTAP messaging used between the network GSM MSC BSS
These DTAP messages are used when dealing with mobile-originated and mobile-terminated calls. This functionality is as is described in Mobile Radio Interface, Layer 3 Specification (GSM 04.08 version 5.8.0) and Q.931. The enhancements are made so that end-to-end teleservices receive the routing information required to terminate calls and display status information. The network transparently
411-2231-827
Standard
02.05
September 2001
A-3
passes the subaddress information elements in order to enable user defined functionality. The relevant information elements include: Called Party Subaddress Calling Party Subaddress Connected Party Subaddress
NOA Address Format Customization This functionality enables the network operator to specify the preferred address format to be used for the calling party, redirecting party, and original called party. The preferred address format can be specified as one of the following or set to follow the called numbers nature of address (NOA): national international unknown
Unsupported GSM11 functionalities In order to provide GSMR02 with the three required GSM11 functionalities the entire GSM11 feature code must be put on the load. To keep the other GSM11 functionalities from interfering with GSMR02, the remaining GSM11 functionalities are turned off or disallowed. Table A-1 explains how the unsupported GSM11 features are handled for GSMR02 customers.
Table A-1 Action taken on unsupported GSM11 features Actid GR2456/ GR2474 GR2638 GR2644 Feature name Optimal Routing Anonymous Call Reject CAMEL Phase II Subscription to CAMEL Phase II MI USSD Billing iDEN Plus Dialing Action taken This feature is SOCed and SOC is turned off for GSMR01 and GSMR02. This feature is disallowed at the HLR. This feature is disallowed at the HLR.
GR2734 GR2802
This feature is SOCed and SOC is off for GSMR01 and GSMR02. This feature is SOCed and SOC is off for GSMR01 and GSMR02.
sheet 1 of 3
GSM
A-4 Appendix A: Supported GSM11 features Table A-1 Action taken on unsupported GSM11 features Actid GR2578 Feature name ISUP UUS3 Support CAMEL PHASE-II Messaging ISDN UPA Control Action taken
This feature is executed only by an external event and is not expected to be activated. This feature is executed only by an external event and is not expected to be activated. This feature is executed only by an external event and is not expected to be activated. This feature is executed only by an external event and is not expected to be activated. It is recommended that field PROTOCOL in table SCPPROT is not datafilled with CAMEL2. This feature is executed only by an external event and is not expected to be activated. It is recommended that field VARIANT in table TRKSGRP is not datafilled with ISRAEL. This feature is executed only by an external event and is not expected to be activated. This feature is executed only by an external event and is not expected to be activated. The datafill is disabled. This feature is executed only by an external event and is not expected to be activated. This feature is executed only by an external event and is not expected to be activated. This feature is executed only by an external event and is not expected to be activated.
sheet 2 of 3
GR2634
GR2644
GR2645
CAMEL CCH
GR2647
Israel ISUP
GR2654
NI USSD
GR2659
Support of CAMEL FCI CAMEL2 SSF AC AND ACR ISUP Delivery of QSIG FTSI PRI Call Forwarding
GR2715
GR2742
GR2861
411-2231-827
Standard
02.05
September 2001
A-5
Table A-1 Action taken on unsupported GSM11 features Actid GR2648/ GR2897/ GR3105 GR2798 Feature name German Carrier Selection Presentation Address Enhancements GSM Optional Record Number for FTA ETSI PRI Services - Phase II IMEI Provisioning for CI Action taken Datafill is disabled.
Datafill is disabled.
GR2671
GR2561
GR2580
This feature is disabled.
sheet 3 of 3
GSM
A-6 Appendix A: Supported GSM11 features
411-2231-827
Standard
02.05
September 2001
B-1
Appendix B: DMS-HLR GMR02 One Night Process B

This appendix discusses the necessary DMS-HLR one night process (ONP) support for GSMR02. The Dump and Restore, Persuade, Limited Persuade, SWACT, and Abortuses parts of the HLR ONP are enhanced in order to support the new GSMR02.
The TABXFR process

TABXFR transfers all the data in the database from the old software release to the new software release. There are two types of data move: External Data Move (EDM) Physical Data Move (PDM)
The DMS-HLR GMR02 ONP supports both the EDM and PDM methods of moving data. This ONP also supports the SWACT and PreSWACT processes to achieve full data transfer.
ONP data transfers

The following data transfers are supported directly: GSM10 to GSMR02, only by EDM Including: TABXFR, PreSwact, Swact, and AbortSwact GSMR01 to GSMR02, by EDM and PDM Including: TABXFR, PreSwact, Swact, and AbortSwact GSMR02 to GSMR02, by EDM and PDM Including: TABXFR, PreSwact, Swact, AbortSwact, and LimitedPreSwact
The EDM method

EDM is used on all tables (except subscriber tables) transferred during the ONP. The EDM software is modified to reformat the data structure changed by the GSMR02 activities.
GSM
B-2 Appendix B: DMS-HLR GMR02 One Night Process
The EDM software supports the following actions: Table GHLRSSOP is reformatted to include the new Class of Registration (COR) field. Also, the FA is renamed to FM by the GM3188 ForceDeregistration feature. Table GHLRAUTH is reformatted to reset the MKVER field to 1 if the MKVER is greater than 1.
The PDM method

PDM is used to transfer subscriber tables during the ONP. The External Data Transfer tool is used to transfer subscriber tables if the PDM transfer fails. During a PDM, all the subscriber data is transferred at once with the table GHLRAUTH. The following items are supported by the PDM software: The PDM aspects of table GHLRVGS (created at GSMR01) are implemented. Table GHLRSSOP is reformatted to include the new Class of Registration (COR) field introduced by GM3188 Force-De registration feature. And other necessary modifications to PDM software required are supported.
ONP tables
The following tables summarize the actions taken during the DMS-HLR ONP for GSMR02. GSM10 to GSMR02 dump and restore Table B-1 shows the subscriber tables changed during a GSM10 to GSMR02 ONP.
Table B-1 Subscriber tables changed during a GSM10 to GSMR02 ONP Table name GHLRBSVC GHLRNDSC GSM10 to GSMR02 ONP change Modified to support the VBS and VGCS services* 1) Enhanced BSVC field with VBS and VGCS services.* 2) Added field CALLPRIORITY with eMLPP .* 3) Added field INFOXFER with UUS1.*
Note: This change is a GSMR01specific change and is not needed to reformat.

sheet 1 of 2
411-2231-827
Standard
02.05
September 2001
Appendix B: DMS-HLR GMR02 One Night Process B-3
Table B-1 Subscriber tables changed during a GSM10 to GSMR02 ONP Table name GHLRSSOP GSM10 to GSMR02 ONP change 1) Enhanced SSVAR field with VBS and VGCS services.* 2) Modified to support the eMLPP FA, and USS1 services.* , 3) Added field COR. 4) FA renamed to FM. GHLRVGS Initialized with no entries.*
Note: This change is a GSMR01specific change and is not needed to reformat.

sheet 2 of 2
Table B-2 shows the OM groups changed during a GSM10 to GSMR02 ONP.
Table B-2 OM groups changed during a GSM10 to GSMR02 ONP OM group GHLRADM3 GSM10 to GSMR02 ONP change EMLPPPR (initialize to zero) UUS1PR (initialize to zero) FAPR (initialize to zero) GHLRBS VGCS and VBS (Initialize to zero)
GSMR01 to GSMR02 dump and restore Table B-3 shows the subscriber tables changed during a GSMR01 to GSMR02 ONP.
Table B-3 Subscriber tables changed during a GSMR01 to GSMR02 ONP Table name GHLRSSOP GSMR01 to GSMR02 ONP change Added field COR and renamed FA to FM.
GSMR02 to GSMR02 dump and restore All tables are transferred with no reformats. The new field COR in table GHLRSSOP and renaming the FA to FM should not cause any problem.
B-4 Appendix B: DMS-HLR GMR02 One Night Process
Interactions
This feature interacts with the following activities: GM3002 - DMS HLR eMLPP (Enhanced Multi-Level Precedence and Preemption) GM3003 - DMS HLR VBS/VGCS (Voice Broadcast/Group Call Service) GM3004 - DMS HLR Functional Addressing (FA) GM3157 HLR Mated Pair support for GSMR02 GM3188 DMS HLR FM-Forced Erasure
Restrictions and limitations

A direct ONP from GSM09 based on CSP09 to GSMR02 based on CSP13 is not supported. It is not allowed to jump more than three CSP in a single TABXFR process. The only way to upgrade from the GSM09 to the GSMR02 is to perform an incremental upgrade. For example, to get from GSM10 GSMR02 perform a GSM09 GSM10 ONP followed by a GSM10 GSMR02 ONP. The DMS-HLR does not guarantee the integrity of the data in the database if the table control operations add, change, replace, or delete are used between the data move and syncing of the HLR. The effects of performing table control operations during the ONP are not predictable.
411-2231-827
Standard
02.05
September 2001
C-1
This appendix discusses the data tables used to set up the GSM-R features. The tables discussed in this appendix are presented in alphabetical order. The tables are ACSMTRX BSSC2TMR DNROUTE GCAREA GCR GHLRBCS GHLRBSVC GHLRCUG GHLRFAID GHLRFANC GHLRNDSC GHLRPARM GHLRSCF GHLRSSOP GHLRUSSD GHLRVBCA GHLRVGCA GHLRVGS GHLRVLR GHLRXTND GSMVAR
GSM
C-2 Appendix C: Data tables used by GSM-R features
LACGID PETSERVS PETSIG SERVCNFG XLAENTRY XXCODE XXHEAD
411-2231-827
Standard
02.05
September 2001
Appendix C: Data tables used by GSM-R features C-3
Table ACSMTRX
This table is used to support the following GSM-R functionalities: Access Matrix
Table description
Table ACSMTRX enables the operator to provision which connections within a GSM-R network are allowed. Table ACSMTRX uses a two-part key to access a data tuple. The two-part key consists of the Call Type (CT) and Function Code (FC) of the calling party number (CGN). The data within a data tuple contains a boolean value ALLOWED and a list of call type and function code combinations for the called party number (CDN). Note: The function code must be entered as a range (FROMFC and TOFC). If the ALLOWED flag is datafilled as Y, the list indicates the allowed terminations of the CGN. If the ALLOWED flag is datafilled as N, the list indicates the denied terminations. The table is initialized with five tuples. These tuples specify the default permission patterns for each call type. A user can change the default tuples. However, a user cannot delete a default tuple. Call permission patterns that differ from the ones given by the default tuples are to be added as additional tuples to the table. Up to 80 AM elements are allowed in one tuple.
Field descriptions
Table C-1 describes the fields in table ACSMTRX.
GSM
C-4 Appendix C: Data tables used by GSM-R features Table C-1 Table ACSMTRX field descriptions Field name CT Description CALL TYPE ENTRY: CT234, CT6, CT7, CT89, CTdefault
EXPLANATION: Specifies the call type of the calling party. FC FUNCTION CODE ENTRY: 0000-9999, $ (depending on the CT) EXPLANATION: Specifies the function code of the calling party. ALLOWED ALLOWED ENTRY: Y or N EXPLANATION: Specifies if the following list of AM elements are allowed or disallowed terminations for the AM element of the calling party specified by the key. OPTION OPTION ENTRY: AMELEM, NIL EXPLANATION: Complete subfields CT, FROMC, and TOC when option AMELEM is entered. Use the NIL option to remove an AM element without deleting the complete data tuple and to re-enter the remaining AM elements. CT (subfield of option AMELEM) CALL TYPE ENTRY: CT234, CT6, CT7 EXPLANATION: Specifies the call type of the called party that is either an allowed or disallowed termination for the calling party given by the key. FROMFC (subfield of option AMELEM) FROM FUNCTION CODE ENTRY: 0000-9999 (depending on the CT) EXPLANATION: Specifies the first function code of a range of function codes of the called party that are either an allowed or disallowed termination for the calling party given by the key.
sheet 1 of 2
411-2231-827
Standard
02.05
September 2001
Nortel Networks Confidential Field name TOFC (subfield of option AMELEM) Description
TO FUNCTION CODE ENTRY: 0000-9999 (depending on the CT) EXPLANATION: Specifies the last function code of a range of function codes of the called party that are either an allowed or disallowed termination for the calling party given by the key.
sheet 2 of 2
Datafill sequence
The datafill of table ACSMTRX is not dependent on any other table.
Dump and restore

Not applicable
Activation
Immediate
Example tuple
Following is an example of a tuple from table ACSMTRX:
CT234 001 (AMELEM CT7 01 05) (AMELEM CT6 0003 0007)$
GSM
Table BSSC2TMR
This table is used to support the following GSM-R functionalities: Voice Broadcast Service (VBS)
Table description
Table BSSC2TMR contains BSSMAP class two engineerable timers that can be associated with a particular location area of a DMS-MSC.
Field descriptions
Table C-2 describes the fields in table BSSC2TMR.
Table C-2 Table BSSC2TMR field descriptions Field name BC2KEY Description BC2KEY ENTRY: 0-1024 EXPLANATION: This key field is a location area characteristic identifier that specifies the set of timer characteristics for a given location area. TNT2 TIMER TNT2 ENTRY: 1-30 seconds EXPLANATION: This field contains the value of the timer associated with the ASSIGNMENT to ASSIGNMENT_COMPLETE messages. The default value is five seconds. TNT3 TIMER TNT3 ENTRY: 1-30 seconds EXPLANATION: This field contains the value of the timer associated with the CLEAR_COMMAND to CLEAR_COMPLETE messages. The default value is five seconds. TNT4 TIMER TNT4 ENTRY: 1-30 seconds EXPLANATION: Timer associated with the CIPHER_MODE_COMMAND to CIPHER_MODE_COMPLETE messages. The default value is five seconds.
sheet 1 of 2
411-2231-827
Standard
02.05
September 2001
Nortel Networks Confidential Field name T101 Description TIMER T101
ENTRY: 1-10 seconds EXPLANATION: Timer associated with the HANDOVER_REQUEST to HANDOVER_REQUEST_ACKNOWLEDGE messages on MSC-A. The default value is five seconds. T201 TIMER T201 ENTRY: 1-30 seconds EXPLANATION: Timer associated with the HANDOVER_COMMAND to HANDOVER_COMPLETE messages on MSC-B. The default value is five seconds. TQT TIMER TQT ENTRY: 1 to 30 seconds EXPLANATION: Timer TQT represents the queuing time on the BSS. Default is 5 seconds. TGCHR THE GROUP CALL CHANNEL PERIODIC RETRY TIMER ENTRY: 60 to 600, default is 60 EXPLANATION: Specifies the time for the group call channel periodic retry timer.
sheet 2 of 2
Datafill sequence
Table BSSC2TMR must be datafilled before table LAC. If you create a new entry in table LAC, you can accept the default entries in BSSC2TMR and DTAPTMR or you can create new entries in BSSC2TMR and/or DTAPTMR. In the second case, you must create the entries in BSSC2TMR and DTAPTMR before creating the new entry in table LAC. If you try to delete a tuple from BSSC2TMR and the tuple is referenced in table LAC, a message will appear stating that the tuple is in use and cannot be deleted. If you still wish to delete it, you must first go into table LAC and change all tuples that reference the BSSC2TMR tuple that you want to delete.
GSM
Dump and restore

The following module sections are modified: Module: GTIMRTAI Section: GTIMRTAI Module: GTIMRTAI Module: GTIMRTAI Module: GTMRCMIF Module: GTMRCMIF Module: GTMRCMIF Module: GTMRCMIF Module: GTIMRIPL Section: GTMRTCEN Section: GTIMRTCA Section: GTMRCMEN Section: GTMRCMTC Section: GTMRCMRF Section: GTMRCMPI Section: GTIMRIPL
The following existing data types are modified: bc2_timer_elements bc2_datatuple bc2_logtuple bc2_phystuple
The following new data type is introduced: range_60to600_def60 The new equivalent type bc2_logtuple$v1 is mapped to the current type bc2_logtuple using the add_equiv_type proc.
Activation
Not applicable
Example tuple
Following is an example of a tuple for table BSSC2TMR:
5 5 5 5 5 5 60
411-2231-827
Standard
02.05
September 2001
Table DNROUTE
This table is used to support the following GSM-R functionalities: VBS VGCS
Table description
Table DNROUTE allows operating company personnel to datafill handover numbers and mobile station roaming numbers (MSRNs). An MSRN is required for any mobile-terminated call. Handover numbers (HONs) are datafilled for inter-MSC handovers only, as opposed to an intra-MSC handover, which is handled within one MSC. This table also allocates group call numbers (GCNs). GCNs are temporary routing numbers used to establish calls for the remote MSC (RMSC) at group call setup time. When processing a Prepare Group Call message from the anchor MSC (AMSC), the RMSC MAP service allocates a GCN. This allocated GCN is sent back to the AMSC embedded in the Prepare Group Call Ack message. This temporary GCN number is released later by the RMSC when the call is routed to the RMSC.
Field descriptions
Table C-3 describes the fields in table DNROUTE.
Table C-3 Table DNROUTE field descriptions Field name AREACODE Description AREACODE ENTRY: the number that represents the serving numbering plan area code EXPLANATION: The area code identifies a major geographic area served by the MSC. The area code must be previously defined in table SNPANAME and cannot begin with zero. For HONs, datafill consists of the Country Code (CC)+National Destination Code (NDC) in the area code.
sheet 1 of 3
GSM
C-10
Appendix C: Data tables used by GSM-R features Description OFFICE CODE DIGIT REGISTER
Field name OFCCODE
ENTRY: 1-7 digits in length, each digit having a range of 0-9. EXPLANATION: The office code is a subregion of Areacode. When datafilling this field, the following rules apply: STNCODE the trunk code or network code in other numbering plans can be used. must be previously defined in table TOFCNAME. cannot contain STNCODEs whose leading digits are an OFCCODE in the same area code. if a universal office code is desired for smaller country applications, $ can be entered.
STATION CODE ENTRY: 1-7 digits in length, each digit having a range of 0-9. EXPLANATION: This field identifies a telephone station within the Terminating Office (TOFC).
DNRESULT
DIRECTORY NUMBER RESULT ENTRY: See subfields. EXPLANATION: Consists of DN_SEL and refinements.
DN_SEL (subfield of DNRESULT)
DIRECTORY NUMBER SELECTOR ENTRY: D, T, L, P C, H, HC, LC, M, FEAT , EXPLANATION: Provides DN information.
FEATURE (subfield of DN_SEL entry FEAT)
FEATURE ENTRY: MEETME, GMSTRM, HON, MSC_SRI, GSMGCN, A, ILC, IHC, MM, MDN, IMC, AL, AVR, AVMM, SDN, SC, ACDTK, SCM If the feature GSMGCN is selected, complete subfield TOTLDIGS. EXPLANATION: Provides refinements to selector FEAT of field DN_SEL.
sheet 2 of 3
411-2231-827
Standard
02.05
September 2001
Nortel Networks Confidential Field name TOTLDIGS (subfield of FEAT entry HON or MSC) Description
C-11
TOTAL NUMBER OF DIGITS ENTRY: 2 to 15 EXPLANATION: Defines the total number of digits in the HON and MSRN. Starts counting at two digits because at least one digit for area code and station code is assumed. Gives the total number of digits in the MSRN including the CC if the assumption is made that it is reading a four-digit STNCODE number.
The entry for this field is calculated on the assumption that STNCODE consists of the leading digits of a four-digit STNCODE number. TOTLDIGS (subfield of FEAT entry GSMGCN) TOTAL NUMBER OF DIGITS ENTRY: 0 to 15 Default is 12. EXPLANATION: Indicates the total number of digits for a given GCN. LATAPOOL LOCAL ACCESS AND TRANSPORT AREA POOL EXPLANATION: This field provides the LATA name for the switch. When datafilling, operating company personnel are prompted to enter a name when GMSTRM is datafilled for the FEATURE field. If HON is datafilled for the FEATURE field, operating company personnel are not prompted to enter anything for LATAPOOL.
sheet 3 of 3
Datafill sequence
Datafill the following tables in the order listed before datafilling table DNROUTE. 1. Table SNPANAME 2. Table TOFCNAME Each MSC functioning as a RMSC must have a range of GCN numbers datafilled prior to initiation of a group call with GCA cells listed which belong to that RMSC.
Dump and restore

Not applicable
GSM
C-12
Activation
Immediate
Example datafill
Following is an example of datafill for table DNROUTE.
areacode >6141 ofccode >4040 stncode >02 dn_sel >feat feature >gsmgcn totldigs >12
411-2231-827
Standard
02.05
September 2001
C-13
Table GCAREA
Table description
Table GCAREA is indexed by GCA ID digits in order to retrieve the list of cells present in group call area. The maximum number of cells that can be datafilled in a GCA is 25 cells.
Field descriptions
Table C-4 describes the fields in table GCAREA.
Table C-4 Table GCAREA field descriptions Field name GCA_KEY Description GROUP CALL AREA KEY Entry: a vector of 2 to 7 digits (0 to 9) Explanation: This is the key to table GCAREA. It is a vector of {0 TO 9}s. The length of GCA_KEYdigits is less than or equal to the difference of 8 (length of GCREF) less length of GID digits, but not less then 2 digits. CELLLIST CELL LIST Entry: vector of 25 LAC + CID combinations). LAC: 0 to 65535. CID: 0 to 65535. Explanation: This is the list of cells that are defined by the service provider per a group call reference number for the given MSC. This field is composed of Location Area Code (LAC) and Cell Identifier (CID).
Datafill sequence
Table LAC must be datafilled with list of cells prior to table GCAREA.
Dump and restore

N/A
GSM
C-14
Activation
Immediate
Example tuple
Following is an example tuple from table GCAREA.
GCA_KEY 887766 CELLLIST (12 1) (12 2) (13 1) (13 3) (13 5) (13 8) (15 10) (15 11)$
411-2231-827
Standard
02.05
September 2001
C-15
Table GCR
Table description
Table GCR serves as the primary database for the VBS and VGCS. Table GCR stores the call attributes per group call references in the MSC. The key used for indexing into table GCR is GCREF (Group Call REFerence). Table GCR has two distinct views depending on whether the MSC is an anchor MSC or relay MSC.
Field descriptions
Table C-5 describes the fields in table GCR. Note: Next to each field name is parenthesis with one of the following indications: both, relay, anchor. These indications signify the inclusion of the respected fields in both (anchor, relay), relay, and anchor MSCs, respectively.
Table C-5 Table GCR field descriptions Field name
GCREF
Description GROUP CALL REFERENCE Entry: A string of up to 8 digits {0 to 9}s. Explanation: This field serves as the key to table GCR. It is a
two-part key composed of GCA and GID. The GCA is a minimum of 2 digits and a maximum of 7 digits. The GID is a minimum of 1 digit and a maximum of 6 digits. Together, the GCA and GID can be no longer than 8 digits.
(both)
ANCHOR_ RELAY (both)
ANCHOR RELAY Entry: Anchor, Relay Explanation: Specifies whether the switch is an anchor or relay for the given group call reference number.
sheet 1 of 3
GSM
C-16
Appendix C: Data tables used by GSM-R features Table C-5 Table GCR field descriptions Field name ANCHOR_ MSC (relay) Description
ANCHOR MOBILE SWITCHING CENTER Entry: A vector of up to 15 {0 to 9}s Explanation: Stores the anchor MSCs CC and NDC digits. This field marks the end of the list of fields of table GCR, should this be a relay MSC.
RELAY_MSC_ LIST (anchor)
RELAY MOBILE SWITCHING CENTER LIST Entry: A vector of up to 5 vectors of up to 15 {0 to 9}s Explanation: Stores a list of relay MSCs for this GID. It is a vector of vectors of up to 15 {0 TO 9}s. The maximum number of relay MSCs is 5.
DISPATCH_L IST (anchor)
DISPATCH LIST Entry: A vector of up to 4 vectors of up to 15 {0 to 9}s

Explanation: This is the list of dispatcher identities to whom the group call may be delivered. Dispatcher numbers should be in the MSISDN or ISDN format only.
ORIG_LIST (anchor)
ORIGINATING LIST Entry: A vector of up to 4 vectors of up to 15 {0 to 9}s

Explanation: Specifies the dispatcher identity criteria for verifying the dispatchers origination entitlement. A partial E.164 address can be datafilled in a list to cover all the dispatchers whose ISDN/MSISDN number match the partial address.
KILL_LIST (anchor)
KILL LIST Entry: A vector of up to 4 vectors of up to 15 {0 to 9}s

Explanation: Specifies the dispatcher identity criteria for verifying the dispatchers termination entitlement. A partial E.164 address can be datafilled in a list to cover all the dispatchers whose ISDN/MSISDN number match the partial address. The entry in the KILL_LIST field is a subset of the union of ORIG_LIST and DISPATCH_LIST.
sheet 2 of 3
411-2231-827
Standard
02.05
September 2001
C-17
Table C-5 Table GCR field descriptions Field name CIPHER_ KEY (anchor) Description CIPHER KEY Entry: A table of 8 tables of 4 hex digits Explanation: Specifies the ciphering key that is used. CODEC (anchor) CODEC Entry: A table of characters Explanation: Supports one of HALFRATELM or
FULLRATEBMA
TIMER (anchor)
TIMER Entry: 1 to 3600 (10 second units) Explanation: Specifies the timer that expires when no activity
occurs and the voice group call is terminated by the network.
PRIORITY (anchor)
PRIORITY Entry: 0, 1, 2, 3, 4, A, B Explanation: Specifies the priority level related to the voice
group call.
sheet 3 of 3
Datafill sequence
Table GCAREA must be datafilled before table GCR.
Dump and restore

Not applicable
Activation
Immediate
GSM
C-18
Example tuple
Following is an example of a tuple when the MSC is an anchor MSC:
GCREF ANCHOR _RELAY ANCHOR RELAY_ MSC_LIST 614199900 000 DISPATCH_ LIST (2112031100) (2112031101) (2112031102) ORIG_LIST KILL_LIST CIPHER _KEY Codec TIMER PRIORITY
9791123 1
(2112031100) (2112031101)
(2112031100) (2112031101)
200
411-2231-827
Standard
02.05
September 2001
C-19
Table GHLRBCA
This table is used to support the Functional Addressing functionality.
Table description
Table GHLRBCA stores BC information that may be used when none is available (for example, with a mobile terminated data call from the PSTN). Specifically, table GHLRBCA stores BC information against a bearer capability Key. This bearer capability key can then be stored against an MSISDN (a mobile subscribers phone number) in other DMS-MSC/HLR tables. Thus, when a data call is destined for an MSISDN but no BC information is available, the DMS-MSC/HLR provides this information by having BC information stored against that MSISDN.
Field descriptions
Table C-6 contains field descriptions for table GHLRBCA.
continTable C-6 Table GHLRBCA field descriptions Field name BCAKEY Description BEARER CAPABILITY IDENTIFIER ENTRY: 0 255 EXPLANATION: This field is the key to the tuple. It uniquely identifies an entry within the table. The user assigns the value of this field at the time of tuple creation. This value cannot be changed or deleted if table GHLRBSVC references the BCI field. DEFAULT: N/A
sheet 1 of 9
GSM
C-20 contin-
Table C-6 Table GHLRBCA field descriptions (continued) Field name BSVC Description BASIC SERVICE ENTRY: TPHNY, AUXTPHNY, SMMT, SMMO, CDA, CDA300, CDA1200, CDA1275, CDA2400, CDA4800, CDA9600, CDAGBS, CDS, CDS1200, CDS2400, CDS4800, CDS9600, CDSGBS, FAX3, ALTSPFAX, ALTSPCDA, ALTSPCDS, SPCHCDA, SPCHCDS EXPLANATION: Identifies the basic service supported by this BC: TPHNY telephony AUXTPHNY Auxiliary telephony SMMT Short Message Service Mobile Terminating SMMO Short Message Service Mobile Originating CDAnnnn Circuit Duplex Asynchronous nnnn bps CDSnnnn Circuit Duplex Synchronous nnnn bps FAX3 Automatic facsimile group 3 ALTSPFAX Alternate Speech/Fax3 ALTSPCDA Alternate Speech and Data (CDA) ALTSPCDS Alternate Speech and Data (CDS) SPCHCDA Speech followed by Data (CDA) SPCHCDS Speech followed by Data (CDS) CDAGBS Asynchronous General Bearer Service CDSGBS Synchronous General Bearer Service
DEFAULT: N/A
sheet 2 of 9
411-2231-827
Standard
02.05
September 2001
Nortel Networks Confidential contin-
C-21
Table C-6 Table GHLRBCA field descriptions (continued) Field name ITC Description INFORMATION TRANSFER CAPABILITY ENTRY: SPCH, AUXSPCH, UDI, 3K1A, FAX3, ALTSPFAX EXPLANATION: Indicates the protocol in use and the purpose of the connection: SPCH speech AUXSPCH auxiliary speech UDI unrestricted digital information (used for CDA and CDS) 3K1A 3.1 kHz audio ex PLMN (used for CDA and CDS) FAX3 facsimile group 3 ALTSPFAX Alternate Speech/Fax3
DEFAULT: N/A RCR RADIO CHANNEL REQUIREMENTS ENTRY: HR, FR, DHR, or DFR EXPLANATION: Specifies the proportion of the available capacity used: HR half-rate FR full-rate DHR dual-rate/half-rate preferred DFR dual-rate/full-rate preferred.
DEFAULT: N/A
sheet 3 of 9
GSM
C-22 contin-
Table C-6 Table GHLRBCA field descriptions (continued) Field name STR Description STRUCTURE ENTRY: SDU, U, or $ EXPLANATION: This field refers to the GSM PLMN connections ability to deliver information to the destination in a structure presented in the corresponding signal structured at the origin. This field is negotiable; that is, this parameter may be altered by the Mobile-services Switching Center or Mobile Station during call setup to a more suitable option than the one specified here. SDU Service data unit integrity This option applies when destination and origin provide protocols for identifying boundaries of service data unit. U Unstructured, for CE=T only (see field CE in this table) This option applies when the service provides neither structural boundaries nor preserves structural integrity. $ must be used for telephony and auxiliary telephony services
SAP
SIGNALING ACCESS PROTOCOL ENTRY: I440, X21, X28DPIN, X28DPUN, X28NDP X32, or $ , EXPLANATION: This field specifies the signaling protocol. $ must be used for telephony and auxiliary telephony services. DEFAULT: N/A
RA
RATE ADAPTATION ENTRY: V100, NONE, or $ EXPLANATION: This field specifies the rate adaptation standard. $ must be used for telephony and auxiliary telephony services. DEFAULT: N/A
sheet 4 of 9
411-2231-827
Standard
02.05
September 2001
C-23
Table C-6 Table GHLRBCA field descriptions (continued) Field name SYNC_M Description SYNC MODE ENTRY: S, A, or $ EXPLANATION: This field specifies the sync mode: S the link is synchronous A the link is asynchronous $ must be used for telephony and auxiliary telephony services.
DEFAULT: N/A UR USER RATE ENTRY: 300, 1200, 2400, 4800, 9600, 14400, or $ EXPLANATION: This field specifies the data transfer rate to which the subscriber has access: Enter the number indicating the bits per second (b/s) rate $ must be used for telephony and auxiliary telephony services
DEFAULT: N/A DATA NUMBER OF DATA BITS ENTRY: 7, 8, or $ EXPLANATION: This field specifies the number of bits used to carry data: $ must be used for telephony and auxiliary telephony services $ must be used when synchronous mode (field SYNC_M) is set to S
DEFAULT: N/A
sheet 5 of 9
GSM
C-24 contin-
Table C-6 Table GHLRBCA field descriptions (continued) Field name STOP Description NUMBER OF STOP BITS ENTRY: 1, 2, or $ EXPLANATION: This field specifies the number of bits required to delimit the data: $ must be used for telephony and auxiliary telephony service $ must be used when synchronous mode (field SYNC_M) is set to S
DEFAULT: N/A PARITY PARITY CONDITION ENTRY: odd, even, none, F0, F1, or $ EXPLANATION: This field specifies the condition that must be satisfied when generating the parity bit: F0 force to 0 F1 force to 1 $ must be used for telephony and auxiliary telephony services $ must be used when sync mode (field SYNC_M) is set to S
DEFAULT:N/A IR INTERMEDIATE RATE ENTRY: 8K, 16K, NONE, or $ EXPLANATION: This field specifies the data transfer rate used to carry data within the network: 8K 8 kb/s 16K 16 kb/s $ must be used for telephony and auxiliary telephony services
DEFAULT: N/A
sheet 6 of 9
411-2231-827
Standard
02.05
September 2001
C-25
Table C-6 Table GHLRBCA field descriptions (continued) Field name MODEM Description MODEM TYPE ENTRY: NONE, V21, V22, V22bis, V26ter, V32, V34, AUTOBAUD, UNDEF, or $ EXPLANATION: This field specifies the data transfer supported at the terminating equipment (modem). Entries are: NONE for FAX3 only. V21 for UR 300 (see field UR) V22 for UR 1200 (see field UR) V22bis for UR 2400 (see field UR) V26ter for UR 2400 (see field UR) V32 for UR 4800 or 9600 (see field UR) V34 for UR 14400 (see field UR) AUTOBAUD for CE NT or both (see CE field), SYNC_MA, and ITC 3K1A $ must be used for telephony and auxiliary telephony services
DEFAULT: N/A
sheet 7 of 9
GSM
C-26 contin-
Table C-6 Table GHLRBCA field descriptions (continued) Field name CE Description CONNECTION ELEMENT ENTRY: T, NT, BT, BNT, or $ EXPLANATION: This field refers to the required Quality of Service (QoS). This field determines if the air interface contains error and flow control. Entries are: T transparent Transparent QoS is characterized by constant throughput, constant transit delay, and variable error rate. The air interface provides no flow control. NT non-transparent Non-transparent QoS is characterized by variable delay and throughput. The air interface provides flow control. BT both, with transparent preferred BNT both, with non-transparent preferred $ must be used for telephony and auxiliary telephony services
DEFAULT: N/A
sheet 8 of 9
411-2231-827
Standard
02.05
September 2001
C-27
Table C-6 Table GHLRBCA field descriptions (continued) Field name ORDER Description DUAL BEARER CAPABILITIES (BCs) ORDER ENTRY: $, S, D EXPLANATION: This field specifies the order of the Dual Bearer Capabilities (BCs) Information Elements (IEs) (speech and data) in the Provide Roaming Number (PRN) for Dual Data services: D Data before Speech (used only for ALTSPCDA and ALTSPCDS basic services) S Speech before Data (used for SPCHCDA, SPCHCDS, ALTSPCDA, or ALTSPCDS) $ Null value used for the following basic services: TPHNY AUXTPHNY CDA (all) CDS (all) FAX3 ALTSPFAX DEFAULT: S for SPCHCDA and SPCHCDS D for ALTSPCDA and ALTSPCDS $ for all the following basic services: TPHNY AUXTPHNY CDA (all) CDS (all) FAX3 ALTSPFAX
sheet 9 of 9
Datafill sequence
Table GHLRBCA must be datafilled before table GHLRBSVC.
GSM
C-28
Dump and restore

Table GHLRBCA should be dumped and restored before table GHLRBSVC.
Example datafill
Figure C-1 shows the example datafill for table GHLRBCA.
Figure C-1 Example datafill for table GHLRBCA
CI: CI: >table ghlrbca TABLE: GHLRBCA >list 5 BCAKEY BSVC ITC RCR STR SAP RA SYNC_M UR DATA STOP PARITY IR MODEM CE ORD ------------------------------------------------------------------------1 CDAGBS 3KAudio FR U I440 NONE A 9600 7 1 EVEN 16K V32 T $ 2 CDSGBS UDI FR U X21 V.110 S 1200 $ $ $ 8K NONE T $ 3 CDAGBS 3KAudio FR U I440 NONE A 4800 7 1 EVEN 8K V32 T $ 4 CDAGBS UDI FR U I440 V110 A 14400 $ $ $ 16K NONE T $ 5 CDSGBS 3KAudio FR U I440 NONE S 4800 $ $ $ 8K V32 T $
411-2231-827
Standard
02.05
September 2001
C-29
Table GHLRCUG
Table description
Table GHLRCUG contains the GSM DMS-HLR Closed User Group (CUG) subscription data. There is a one-to-one relation between IMSIs and CUG subscription data in table GHLRCUG. Each IMSI can have up to 10 sets of data in a single tuple.
Field descriptions
Table C-7 contains field descriptions for table GHLRCUG.
Table C-7 Table GHLRCUG field descriptions Field name MCC Description INTERNATIONAL MOBILE SUBSCRIBER IDENTIFICATION CODE (IMSI) Mobile Country Code ENTRY: 3 digits (0-9) EXPLANATION: This field indicates the country where a subscribers IMSI is registered. MCCs are assigned to different nations by the International Telecommunications Union - Telecommunication Standardization Sector (ITU-T). The MCC must be identified for each subscriber. DEFAULT: N/A
sheet 1 of 4
GSM
C-30
Table C-7 Table GHLRCUG field descriptions (continued) Field name continMNC INTERNATIONAL MOBILE SUBSCRIBER IDENTIFICATION CODE (IMSI) MOBILE NETWORK CODE ENTRY: Vector of up to 3 {0 to 9}s EXPLANATION: This field is part one of a three-part key. An entry into this key field identifies a Public Land Mobile Network (PLMN). When combined with office parameter GHLR_IMSI_MCC in table OFCSTD and field MSIN, it identifies subscriber regardless of equipment or position. MNC must match MNC specified by office parameter GHLR_IMSI_MNC in table OFCSTD or it is rejected. The DMS-HLR supports one of the following: single two digit MNC single three digit MNC multiple two digit MNCs multiple three digit MNCs DEFAULT: N/A MSIN MOBILE SUBSCRIBER IDENTIFICATION NUMBER. ENTRY: Vector of up to 10 {0 to 9}s EXPLANATION: This field is part two of a three-part key. An entry in this key field specifies subscriber portion of the IMSI. When combined with office parameter GHLR_IMSI_MCC in table OFCSTD and field MNC, it identifies subscriber regardless of equipment or position. Values entered at table control interface are not padded out. Description
DEFAULT: N/A
sheet 2 of 4
411-2231-827
Standard
02.05
September 2001
C-31
Table C-7 Table GHLRCUG field descriptions (continued) Field name CUGSUB Description Closed User Group Subscription Data ENTRY: NI, INLK, CI, ICR, APPBSG EXPLANATION: The CUG Subscription data describes the CUGs which the subscriber is a member of and the restrictions which are placed on the subscriber within the CUG. CUG Subscription variable data can consist of up to 10 of the following: NI Network Identity. This describes the network which the CUG belongs to and also forms part of the Interlock Code. Valid entries are 00 to 9999. INLK Interlock. This code uniquely identifies a CUG within a network and also forms part of the Interlock Code. Valid entries are 00 to 99999. CI CUG Index. This code is used either to select a CUG for an outgoing call or to indicate an incoming call. Indices are passed between the user and the network. The indices are only relevant within the context of a users subscription. Different subscribers may use different indices to describe the same CUG. Valid entries are 0 to 32767. ICR Intra-CUG Restrictions. One of the following restrictions can be placed on a subscriber in relation to a CUG. Valid entries are NONE, ICB, and OCB. Incoming Calls Barred within a CUG (ICB): Access restriction that prevents a CUG member from receiving calls from other members of that CUG. Outgoing Calls Barred within a CUG (OCB): Access restriction that prevents a CUG member from placing calls to other members of that CUG. NONE: No access restrictions are placed on incoming or outgoing calls from/to that CUG.
contin-
DEFAULT: N/A
sheet 3 of 4
GSM
C-32
Table C-7 Table GHLRCUG field descriptions (continued) Field name CUGSUB (continued) Description CUG Subscription Data (continued) APPBSG Application to Basic Service Groups (BSG). The BSGs that the CUG applies to are defined here. Valid entries are ALLBSGS, BSGLIST. BSGLIST requires the following refinements. Valid entries are: SPCH Speech AUXSPCH Auxiliary Speech FAX Facsimile Group 3 CDA Circuit Duplex Asynchronous CDS Circuit Duplex Synchronous
DEFAULT: N/A
sheet 4 of 4
Datafill sequence
The following tables must be datafilled in this order: GHLRAUTH GHLRDATA GHLRBCA GHLRBSVC GHLRCUG GHLRSSOP
Dump and restore

Table GHLRCUG must be dumped and restored before table GHLRSSOP and after the following tables: GHLRBCA GHLRAUTH GHLRDATA GHLRBSVC
Example tuple
Figure C-2 shows example datafill for table GHLRCUG.
411-2231-827
Standard
02.05
September 2001
Nortel Networks Confidential Figure C-2 Example datafill for table GHLRCUG CI: >table ghlrcug TABLE: GHLRCUG >list 2 TOP MCCMNC MSIN CUGSUB
C-33
--------------------------------------------------------------------50502 3501215070 50502 3501215071 BOTTOM (0000 0 16 NONE BSGLIST ( SPCH) $)$ (0000 0 16 NONE BSGLIST ( SPCH) $)$
GSM
C-34
Table GHLRBSVC
Table description
Table GHLRBSVC contains the basic services and associated data for a subscriber. It allows basic services to be added against an IMSI along with an MSISDN. A subscriber is given one tuple for each basic subscribed service. A subscriber may have separate MSISDNs for all or some basic services with the following exceptions: Short Message Service Mobile Terminating (SMMT), Short Message Service Mobile Originating (SMMO), and Telephony (TPHNY) must have the same MSISDN. Alternate Speech and Data Circuit Duplex Asynchronous (ALTSPCDA) and Alternate Speech and Data Circuit Duplex Synchronous (ALTSPCDS) must have the same MSISDN. Speech followed by Circuit Duplex Asynchronous (SPCHCDA) and Speech followed by Circuit Duplex Synchronous (SPCHCDS) must have the same MSISDN.
(contin-
Field descriptions
Table C-8 contains field descriptions for table GHLRBSVC.
Table C-8 Table GHLRBSVC field descriptions Field name MCC Description INTERNATIONAL MOBILE SUBSCRIBER IDENTIFICATION CODE (IMSI) Mobile Country Code ENTRY: 3 digits (0-9) EXPLANATION: This field indicates the country where a subscribers IMSI is registered. MCCs are assigned to different nations by the International Telecommunications Union - Telecommunication Standardization Sector (ITU-T). The MCC must be identified for each subscriber. DEFAULT: N/A
sheet 1 of 4
411-2231-827
Standard
02.05
September 2001
C-35
Table C-8 Table GHLRBSVC field descriptions (continued) Field name MNC Description INTERNATIONAL MOBILE SUBSCRIBER IDENTIFICATION CODE (IMSI) MOBILE NETWORK CODE ENTRY: Vector of up to 3 {0 to 9}s EXPLANATION: This field is part one of a three-part key. An entry into this key field identifies a Public Land Mobile Network (PLMN). When combined with office parameter GHLR_IMSI_MCC in table OFCSTD and field MSIN, it identifies a subscriber regardless of equipment or position. MNC must match MNC specified by office parameter GHLR_IMSI_MNC in table OFCSTD or it is rejected. The DMS-HLR supports one of the following: single two digit MNC single three digit MNC multiple two digit MNCs multiple three digit MNCs DEFAULT: N/A MSIN MOBILE SUBSCRIBER IDENTIFICATION NUMBER ENTRY: Vector of up to 10 {0 to 9}s EXPLANATION: This field is part two of a three-part key. An entry in this key field specifies subscriber portion of the IMSI. When combined with office parameter GHLR_IMSI_MCC in table OFCSTD and field MNC, it identifies subscriber regardless of equipment or position. Value entered at table control interface is not padded out.
DEFAULT: N/A
sheet 2 of 4
GSM
C-36
Table C-8 Table GHLRBSVC field descriptions (continued) Field name BSVC Description BASIC SERVICE ENTRY: TPHNY, AUXTPHNY, SMMT, SMMO, CDA, CDA300, CDA1200, CDA1275, CDA2400, CDA4800, CDA9600, CDAGBS, ALTSPCDA, SPCHCDA, CDS, CDS1200, CDS2400, CDS4800, CDS9600, CDSGBS, ALTSPCDS, SPCHCDS, FAX3, ALTSPFAX EXPLANATION: This field is part three of a three-part key which identifies a basic service offered to this subscriber (identified by the MNC and MSIN fields). Valid entries are the following: TPHNY telephony AUXTPHNY auxiliary telephony. This may be entered only if TPHNY has been provided as well. SMMT short message service mobile-terminating SMMO short message service mobile-originating CDA Circuit Duplex Asynchronous. Entering this value is equivalent to providing the subscriber with all of the CDA basic services (CDA300 through CDA9600) CDAnnnn Circuit Duplex Asynchronous nnnn bps CDAGBS Circuit Data Asynchronous General Bearer Service ALTSPCDA Alternate Speech Circuit Duplex Asynchronous SPCHCDA Speech followed by Circuit Duplex Asynchronous CDS Circuit Duplex Synchronous. Entering this value is equivalent to providing the subscriber with all of the CDS basic services (CDS1200 through CDS9600) CDSnnnn Circuit Duplex Synchronous nnnn bps CDSGBS Circuit Data Synchronous General Bearer Service ALTSPCDS Alternate Speech Circuit Duplex Synchronous SPCHCDS Speech followed by Circuit Duplex Synchronous FAX3 automatic facsimile group 3 ALTSPFAX Alternate Speech Fax
DEFAULT: N/A
sheet 3 of 4
411-2231-827
Standard
02.05
September 2001
C-37
Table C-8 Table GHLRBSVC field descriptions (continued) Field name CC Description Country Code ENTRY: Vector of up to 3 {0 to 9}s EXPLANATION: This field indicates the country code of the subscribers MSISDN. For all MSISDNs belonging to a single subscriber, the CC field must contain the same value. DEFAULT: N/A NDC MSISDN NATIONAL DESTINATION CODE ENTRY: Vector of up to 13 {0 to 9}s EXPLANATION: Part of the MSISDN that identifies the PLMN DEFAULT: N/A SN MSISDN SUBSCRIBER NUMBER ENTRY: Vector of up to 13 {0 to 9}s EXPLANATION: Combination of CC (from table OFCSTD, field ghlr_imsi_mcc) +NDC+SN that maps to a single subscriber. The SN must be the same for Telephony, SMMT, and SMMO. A change to one causes a change in all three. DEFAULT: N/A BCI BEARER CAPABILITY IDENTIFIER ENTRY: NIL or BCI (If you enter BCI, you are prompted for the BCI number: 0 255, corresponding to the BCAKEY value in table GHLRBCA.) EXPLANATION: This field is a key into table GHLRBCA, which provides bearer capability information for basic services. DEFAULT: NIL
sheet 4 of 4
Datafill sequence
The subscriber must be datafilled in table GHLRAUTH before table GHLRBSVC is datafilled. When table GHLRAUTH is datafilled, entries are automatically created in tables GHLRDATA and GHLRREA.
GSM
C-38
A Bearer Capability Identifier (BCI) value cannot be datafilled unless that value exists in table GHLRBCA.
Dump and restore

Table GHLRDATA must be dumped and restored before table GHLRBSVC is dumped and restored.
Example tuple
Following is an example of a tuple from table GHLRBSVC:
505 02 1120101001 TPHNY 61 41 1000211001 NIL
411-2231-827
Standard
02.05
September 2001
C-39
Table GHLRFAID
This table is used to support the following GSM-R functionalities: Functional Addressing (FA)
Table description
Table GHLRFAID determines the implied class of registration (COR) and basic service (BS) information associated with a functional number (FN). The data is contained in two fields.
Field descriptions
Table C-9 contains field descriptions for table GHLRFAID.
(continTable C-9 Table GHLRFAID field descriptions Field name KEY Description KEY ENTRY: Vector of up to 24 (0 through 9)s EXPLANATION: Identifies the person or equipment. The KEY is derived from the functional number according to digit-collection rules. DEFAULT: None SETBSVC SET BASIC SERVICES ENTRY: Vector of up to 6 basic services from (TPHNY, AUXTPHNY,SMMT, SMMO, CDA, CDA300, CDA1200, CDA1275, CDA2400,CDA4800,CDA9600, ALTSPCDA, CDS, CDS1200, CDS2400, CDS4800, CDS9600, ALTSPCDS, SPCHCDS, FAX3, ALTSPFAX,CDAGBS,CDSGBS, SPCHCDA, VBS,VGCS) EXPLANATION: Identifies the basic services provisioned for the subscriber. DEFAULT: None
sheet 1 of 2
GSM
C-40 (contin-
Table C-9 Table GHLRFAID field descriptions (continued) Field name COR Description CLASS OF REGISTRATION ENTRY: A, B, C, D where A = engine/train cab radio basic function B = maintenance function C = operation support function D = customer support function EXPLANATION: Identifies the users class of registration. The class of registration enables the FA Service to decide whether the user has a capability for registration/de-registration/interrogation. DEFAULT: None
sheet 2 of 2
Datafill sequence
Not applicable
Dump and restore

Existing dump and restore order not affected by this feature.
Activation
Immediate
Example datafill
Figure C-3 shows an example of datafill for table GHLRFAID.
Figure C-3 Example datafill for table GHLRFAID CI: >table ghlrfaid TABLE: GHLRFAID >list all KEY SETBSVC COR
----------------------------------------------------------------201 203
TPHNY CDA300 CDA1200 AD A
411-2231-827
Standard
02.05
September 2001
C-41
Error messages
The following error message is used if PROTECT_FAID_STD in HLRDEFAULTS is TRUE:
ERROR: Access to this table is restricted, please contact to Nortel Networks technical support.
The following error message is used if no basic service is datafilled:

ERROR: At least one Basic service must be entered.
The following error message is used if the same basic service is datafilled more than once:
ERROR: Basic services can not be duplicated.
The following error message is used if no COR is datafilled:

ERROR: At least one COR must be entered.
The following error message is used if the same COR is datafilled more than once:
ERROR: CORs can not be duplicated.
The following error message is used if VGS/VGCS is tried to enter as BS:

ERROR: VBS and VGCS can not be used for Functional Numbers
GSM
C-42
Table GHLRFANC
This table is used to support the following GSM-R functionalities: FA
Table description
Table GHLRFANC contains FANC routing information relevant to HLRf. This table contains the GSM HLRm FANC number that is mapped to the HLRf.
Field descriptions
Table C-10 contains field descriptions for table GHLRFANC.
(continTable C-10 Table GHLRFANC field descriptions Field name KEY Description KEY ENTRY: Vector of up to 3 (0 through 9)s EXPLANATION: Identifies the FA Network Code which is mapped to the node address. DEFAULT: None PROCSSAT PROCSSAT ENTRY: Vector of 1 multiple with the subfield entries EXPLANATION: This field is used to select which existing table is used to find the node. For GSMSCF, it is GHLRSCF table, for XTND, it is GHLRXTND table, the related node address is found. DEFAULT: None NODETYPE (subfield of PROCSSAT) NODE TYPE ENTRY: GSMSCF, XTND EXPLANATION: Identifies the table used to find the node. DEFAULT: None
sheet 1 of 2
411-2231-827
Standard
02.05
September 2001
Nortel Networks Confidential (contin-
C-43
Table C-10 Table GHLRFANC field descriptions (continued) Field name NODEADDR (subfield of PROCSSAT) Description NODE ADDRESS ENTRY: Vector of up to 20 characters EXPLANATION: Identifies the address of the node. DEFAULT: None
sheet 2 of 2
Datafill sequence
Either GHLRSCF or GHLRXTND tables must be datafilled before this table relying on the datafill in PROCSSAT field.
Dump and restore

Dump and restore is provided after GHLRSCF and GHLRXTND tables.
Activation
Immediate
Example datafill
Figure C-4 shows an example of datafill for table GHLRFANC.
Figure C-4 Example datafill for table GHLRFANC CI: >table ghlrfanc TABLE: GHLRFANC >list all KEY PROCSSAT
------------------------------------------------------------------------------------------------------987 GSMMSF
LONDON
Error messages
There are 2 error messages based on the datafill of PROCSSAT filed if the related tables are not datafilled before. They are as follows: for the GSMSCF
GSM
C-44
<NODEADDR> must be datafilled in table GHLRSCF before it can be datafilled in this table
for the EXNODE

<NODEADDR> must be datafilled in table GHLRXTND before it can be datafilled in this table
411-2231-827
Standard
02.05
September 2001
C-45
Table GHLRNDSC
This table is used to support the following GSM-R functionalities: VBS VGCS Enhanced Multi-level Priority Pre-emption (eMLPP)
Table description
Table GHLRNDSC contains data associated with VLR screening classes. The DMS-HLR uses the contents of table GHLRNDSC to determine which services are supported by a particular VLR. This information is used to screen out all proprietary and GSM-defined services at version 1. Since version 2 VLRs indicate the services they support, GSM-defined services are always transmitted at version 2, with the exception of CUG, which is not supported. To increase efficiency, options are provided to suppress the transmission of CUG data to VLRs that do not support CUG. which encoding method should be used (phase 1 or 2) for their propagation. how the DMS-HLR should react if a service is not supported. The DMSHLR reaction, as indicated above, is determined directly from table GHLRNDSC for all proprietary and GSM-defined services (if a version 1 VLR). as a result of the VLR response (if a version 2 VLR).
(contin-
Field descriptions
CAMEL-specific options The roaming and screening options for CAMEL in table GHLRNDSC use a three character code which is defined as follows: The first character indicates whether the information concerning the service should be sent or not. S Send the service to the VLR. N Do not send the service to the VLR. The service is not supported. The second character, the underscore _ indicates that Subscriber Specific treatment should always be enforced. For CAMEL, this involves checking the subscribers UNSPVMSC flag in table GHLRCAML. This flag indicates what treatment should be taken when CAMEL is unsupported at the VLR. The third character indicates what happens if the VLR does not support CAMEL, and the Subscriber Specific flag is set to RELEASE.
C-46
It can take on the following values: R - indicates that roaming restriction, RRDTUF, will be imposed upon the subscribers profile D - indicates that roaming should be denied a. If CAMEL O-CSI data is provisioned or changed in GHLRCAMEL before an Update Location is received for the Subscriber then a Cancel Location is sent to the VLR. b. UL Ack is immediately returned (with no embedded ISD) with the Roaming Not Allowed Error S indicates that SS BAOC should be induced at the VLR for the subscriber.
Table C-11 illustrates possible VLR screening options.

Table C-11 CAMEL screening options for VLRs in GHLRNDSC VLR Version V1 N_D Possible Screening Values N_S V2 N_R N_S V3 N_R N_S S_R S_S
SMMT-specific options The following options are for the Short Message Mobile Terminated (SMMT) service only: SN Indicates that SMMT is not supported. SY Indicates that SMMT is supported. SC Indicates that SMMT is conditionally supported. Conditional support means that the response from the VLR is used to determine if SMMT is supported.
CUG-specific options The following options are for the Closed User Group (CUG) service only: NS Do not send information associated with this service. BAOC is induced. SS Sends the information associated with this serviced. If this is not supported, then BAOC is induced.
411-2231-827
Standard
C-47
Table C-12 contains field descriptions for table GHLRNDSC.

Table C-12 Table GHLRNDSC field descriptions Field name CLASS Description CLASS ENTRY: Class name defined in table GHLRSCMP or VLRDEFAULT. EXPLANATION: This is the name of the VLR screening class being defined. It must already exist in table GHLRSCMP The value VLRDEFAULT defines . a default screening class for VLRs that are not assigned to a class or a zone. If VLRDEFAULT is not explicitly defined in this table, the values shown as VLRDEFAULT values in each field are used. DEFAULT: NONE VERSION VERSION NUMBER ENTRY: 1, 2, 3 EXPLANATION: Version number indicates that the screening profile relates to a particular operations version number. This profile will only be adopted by the DMS-HLR if the VLR is at the same version level. DEFAULT: NONE BSVC BASIC SERVICES ENTRY: SMMT, ALS, CDAGBS, CDSGBS EXPLANATION: Basic Service includes Short Message Mobile Terminated (SMMT), Alternate Line Service (ALS), Circuit Data Asynchronous General Bearer Service (CDAGBS), and Circuit Data Synchronous General Bearer Service (CDSGBS) refinements. DEFAULT: NONE
sheet 1 of 33
GSM
C-48
Table C-12 Table GHLRNDSC field descriptions (continued) Field name CDAGBS (BSVC Refinement) Description CIRCUIT DATA ASYNCHRONOUS GENERAL BEARER SERVICE ENTRY: SX, SR, SS, NX, NR, NS, ND EXPLANATION: This supersedes CDA and indicates any data transmission rates greater than CDA9600. ND CDAGBS information is not sent to VLRs in this screening class. Roaming is denied. This is a valid option for Version 1 VLRs only. NS CDAGBS information is not sent to VLRs in this screening class. Roaming is allowed, but alternative services with more severe restrictions are substituted for CDAGBS. This is a valid option for Versions 1,2, and 3. NR CDAGBS information is not sent to VLRs in this screening class. Roaming is denied. This is a valid option for Versions 2 and 3. NX CDAGBS information is not sent to VLRs in this screening class. Roaming is allowed. This option is valid for all three VLR versions. SR CDAGBS information is sent to VLRs in this screening class. Roaming is denied. This is a valid option for Version 3 VLRs only. SS CDAGBS information is sent to VLRs in this screening class. If the VLR does not support CDAGBS, roaming is allowed, but alternative services with more severe restrictions will be substituted for CDAGBS. This is a valid option for Version 3 VLRs only. SX CDAGBS information is sent to VLRs in this screening class. Roaming is allowed. This is a valid option for Version 3 VLRs only.
DEFAULT: Version 1 NX, ND, NS Version 2 NX, NR, NS Version 3 SX, SR, SS, NX, NR, NS
sheet 2 of 33
411-2231-827
Standard
02.05
September 2001
C-49
Table C-12 Table GHLRNDSC field descriptions (continued) Field name CDSGBS (BSCV Refinement) Description CIRCUIT DATA SYNCHRONOUS GENERAL BEARER SERVICE ENTRY: SX, SR, SS, NX, NR, NS, ND EXPLANATION: This is a superset of CDS and denotes any data transmission rates greater than CDS9600. ND CDSGBS information is not sent to VLRs in this screening class. Roaming is denied. This is a valid option for Version 1 VLRs only. NS CDSGBS information is not sent to VLRs in this screening class. Roaming is allowed, but alternative services with more severe restrictions are substituted for CDSGBS. This is a valid option for all three versions. NR CDSGBS information is not sent to VLRs in this screening class. Roaming is denied. This is a valid option for Versions 2 and 3. NX CDSGBS information is not sent to VLRs in this screening class. Roaming is allowed. This is a valid option for all three versions. SR CDSGBS information is sent to VLRs in this screening class. Roaming is denied. This is a valid option for Version 3 VLRs only. SS CDSGBS information is sent to VLRs in this screening class. If the VLR does not support CDSGBS, roaming is allowed, but alternative services with more severe restrictions will be substituted for CDAGBS. This is a valid option for Version 3 only. SX CDSGBS information is sent to VLRs in this screening class. Roaming is allowed. This is a valid option for Version 3 only.
DEFAULT: Version 1 NX, ND, NS Version 2 NX, NR, NS Version 3 SX, SR, SS, NX, NR, NS
sheet 3 of 33
GSM
C-50
Table C-12 Table GHLRNDSC field descriptions (continued) Field name SMMT (BSVC Refinement) Description ENTRY: SY, SN, SC EXPLANATION: This refinement indicates how Short Message Mobile Terminated (SMMT) service information is handled, depending on whether a VLR supports SMMT. This information is used during the Send Routing Information for Short Messages (SRI-SM) dialogue. SY VLRs in this screening class support SMMT. SMMT information is sent to VLRs in this screening class by the Short Message ServiceService Center (SMS-SC). SY is a valid option for version 1 VLRs only. SN VLRs in this screening class do not support SMMT. However, SMMT information is sent to VLRs in this screening class by the SMSSC. SC VLRs in this screening class conditionally support SMMT. SMMT information is sent to VLRs in this screening class by the SMS-SC. The DMS-HLR will identify the SMMT as being supported or unsupported according to how it is instructed by the VLR. SC is a valid option for Version 2 and 3 VLRs only.
Note: This field does not affect the sending of the SMMT provisioned status to the VLR in an Insert Subscriber Data (ISD) or Send Parameter for Subscriber Data (SP-SD message). DEFAULT: Version 1 SN, SY Version 2 SN, SC Version 3 SN, SC
sheet 4 of 33
411-2231-827
Standard
02.05
September 2001
C-51
Table C-12 Table GHLRNDSC field descriptions (continued) Field name ALS (BSVC Refinement) Description ALTERNATE LINE SERVICE ENTRY: ND, NR, NX, SX EXPLANATION: This refinement indicates how ALS information is handled by the DMS-HLR, depending on whether a VLR supports ALS. ND ALS information is not sent to VLRs in this screening class. Roaming is denied. Only ND and SX are valid options for Version 1 VLRs. ND is not a valid option for Version 2 and 3 VLRs. NR ALS information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs only. NX ALS information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SX ALS information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 1, Version 2, and Version 3 VLRs.
DEFAULT: Version 1 SX, NX, ND Version 2 SX, NX, NR Version 3 SX, NX, NR ODB OPERATOR DETERMINED BARRING ENTRY: ODBOG, ODBPREM, ODBHPLMN, ODBCISS, ODBECT EXPLANATION: Operator determined barring includes ODB of outgoing calls (ODBOG), ODB of premium rate calls (ODBPREM), ODB of home public land mobile network calls (ODBHPLMN), ODB of call independent supplementary services (ODBCISS), and ODB of explicit call trace (ODBECT) refinements. DEFAULT: NONE
sheet 5 of 33
GSM
C-52
Table C-12 Table GHLRNDSC field descriptions (continued) Field name ODBOG (ODB Refinement) Description OPERATOR-DETERMINED BARRING OF OUTGOING CALLS ENTRY: ND, NR, SR, SX EXPLANATION: This refinement indicates how ODBOG information is handled by the DMS-HLR, depending on whether a VLR supports ODBOG. ND ODBOG information is not sent to VLRs in this screening class. Roaming is denied. Only ND and SX are valid options for Version 1 VLRs. ND is not a valid option for Version 2 or Version 3 VLRs. NR ODBOG information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs only. SR ODBOG information is sent to VLRs in this screening class. Roaming is denied. SR is a valid option for Version 2 and 3 VLRs only. SX ODBOG information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 1, Version 2, and Version 3 VLRs.
DEFAULT: Version 1 SX, ND Version 2 SX, SR, NR Version 3 SX, SR, NR

sheet 6 of 33
411-2231-827
Standard
02.05
September 2001
C-53
Table C-12 Table GHLRNDSC field descriptions (continued) Field name ODBPREM (ODB Refinement) Description OPERATOR DETERMINED BARRING OF PREMIUM RATE CALLS ENTRY: ND, NR, SR, SX EXPLANATION: This refinement indicates how ODBPREM information is handled by the DMS-HLR, depending on whether a VLR supports ODBPREM. ND ODBPREM information is not sent to VLRs in this screening class. Roaming is denied. Only ND and SX are valid options for Version 1 VLRs. ND is not a valid option for Version 2 or Version 3 VLRs. NR ODBPREM information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs only. SR ODBPREM information is sent to VLRs in this screening class. Roaming is denied. SR is a valid option for Version 2 and 3 VLRs only. SX ODBPREM information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 1, Version 2, and Version 3 VLRs. Version 2 SX, SR, NR
DEFAULT: Version 1 SX, ND Version 3 SX, SR, NR ODBHPLMN (ODB Refinement)
OPERATOR DETERMINED BARRING OF HOME PUBLIC LAND MOBILE NETWORK CALLS ENTRY: ND, NR, SX EXPLANATION: This refinement indicates how ODBHPLMN information is handled by the DMS-HLR, depending on whether a VLR supports ODBHPLMN. ND ODBHPLMN information is not sent to VLRs in this screening class. Roaming is denied. Only ND and SX are valid options for Version 1 VLRs. ND is not a valid option for Version 2 or Version 3 VLRs. NR ODBHPLMN information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs only. SX ODBHPLMN information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 1, Version 2, and Version 3 VLRs. Version 3 SX, NR
DEFAULT: Version 1 SX, ND Version 2 SX, NR

sheet 7 of 33
GSM
C-54
Table C-12 Table GHLRNDSC field descriptions (continued) Field name ODBCISS (ODB Refinement) Description OPERATOR DETERMINED BARRING OF CALL INDEPENDENT SUPPLEMENTARY SERVICES ENTRY: ND, NR, NX, SR, SX EXPLANATION: This refinement indicates how ODBCISS information is handled by the DMS-HLR, depending on whether a VLR supports ODBCISS. ND ODBCISS information is not sent to VLRs in this screening class. Roaming is denied. Only ND and SX are valid options for Version 1 VLRs. ND is not a valid option for Version 2 or Version 3 VLRs. NR ODBCISS information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs only. NX ODBCISS information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SR ODBCISS information is sent to VLRs in this screening class. Roaming is denied. SR is a valid option for Version 2 and 3 VLRs only. SX ODBCISS information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 1, Version 2, and Version 3 VLRs.
DEFAULT: Version 1 SX, NX, ND Version 2 SX, NX, SR, NR Version 3 SX, NX, SR, NR
sheet 8 of 33
411-2231-827
Standard
02.05
September 2001
C-55
Table C-12 Table GHLRNDSC field descriptions (continued) Field name ODBECT (ODB Refinement) Description OPERATOR DETERMINED BARRING EXPLICIT CALL TRACE ENTRY: SX, NX, ND, SR, NR EXPLANATION: This refinement indicates how ODBECT information is handled by the DMS-HLR, depending on whether a VLR supports ODBECT. ND ODBECT information is not sent to VLRs in this screening class. Roaming is denied. Only ND and NX are valid options for Version 1 VLRs. ND is not a valid option for Version 2 and Version 3 VLRs. NR ODBECT information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs only. NX ODBECT information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SR ODBECT information is sent to VLRs in this screening class. Roaming is denied. SR is a valid option for Version 3 VLRs only. SX ODBECT information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 3 VLRs.
DEFAULT: Version 1 NX, ND Version 2 NX, NR Version 3 SX, NX, NR, SR CALLCOMP CALL COMPLETION SUPPLEMENTARY SERVICE ENTRY: CW, HOLD EXPLANATION: Call complete includes call wait (CW) and call hold (HOLD) refinements. DEFAULT: NONE
sheet 9 of 33
GSM
C-56
Table C-12 Table GHLRNDSC field descriptions (continued) Field name CW (CALLCOMP Refinement) Description CALL WAIT ENTRY: ND, NR, NX, SR, SX, SX1, SX2 EXPLANATION: This field indicates how Call Wait (CW) information is handled by the DMS-HLR, depending on whether a VLR supports CW. ND CW information is not sent to VLRs in this screening class. Roaming is denied. Only ND and SX are valid options for Version 1 VLRs. ND is not a valid option for Version 2 or 3 VLRs. NR CW information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs. NX CW information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SR CW information is sent to VLRs in this screening class. Roaming is denied. SR is a valid option for Version 2 and 3 VLRs only. SX CW information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 1, Version 2, and Version 3 VLRs. SX1 CW information is sent in phase 1 format. This excludes Basic Service Group (BSG) information. SX2 CW information is sent in phase 2 format. This includes Basic Service Group (BSG) information
DEFAULT: Version 1 SX, NX., ND Version 2 SX, NX, SR, NR Version 3 SX, NX, SR, NR CWPH (CW_PHASE) Which one? Check defaults. CALL WAITING SUPPLEMENTARY SERVICE PHASE ENTRY: 1, 2 EXPLANATION: Specifies the MAP phase supported by the VLR for Call Waiting (CW) subscription information. 1 Send CW subscription information in phase 1 format. This excludes Basic Service Group (BSG) information. 2 Send CW subscription information in phase 2 format. This includes Basic Service Group (BSG) information
Defaults: Version 1 1, Version 2 2, Version 3

sheet 10 of 33
411-2231-827
Standard
02.05
September 2001
C-57
Table C-12 Table GHLRNDSC field descriptions (continued) Field name HOLD (CALLCOMP Refinement) Description CALL HOLD ENTRY: ND, NR, NX, SR, SX EXPLANATION: This refinement indicates how HOLD information is handled by the DMS-HLR, depending on whether a VLR supports HOLD. ND HOLD information is not sent to VLRs in this screening class. Roaming is denied. Only ND and SX are valid options for Version 1 VLRs. ND is not a valid option for Version 2 or 3 VLRs. NR HOLD information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs. NX HOLD information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SR HOLD information is sent to VLRs in this screening class. Roaming is denied. SR is a valid option for Version 2 and Version 3 VLRs only. SX HOLD information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 1, Version 2, and Version 3 VLRs.
DEFAULT: Version 1 SX, NX, ND Version 2 SX, NX, SR, NR Version 3 SX, NX, SR, NR PLMNSPEC PUBLIC LAND MOBILE NETWORK SPECIFIC SUPPLEMENTARY SERVICES ENTRY: HOTBILL, LCO, COS, ACR, ACV, MCT, CNAM EXPLANATION: PLMNSPEC includes hot billing (HOTBILL), local calls only (LCO), class of service (COS), account code required (ACR), account code voluntary (ACV), malicious call trace (MCT), and calling name delivery (CNAM) refinements. DEFAULT: NONE
sheet 11 of 33
GSM
C-58
Table C-12 Table GHLRNDSC field descriptions (continued) Field name HOTBILL (PLMNSPEC Refinement) Description HOT BILLING ENTRY: ND, NR, NX, SX EXPLANATION: This refinement indicates how HOTBILL information is handled by the DMS-HLR, depending on whether a VLR supports HOTBILL. ND HOTBILL information is not sent to VLRs in this screening class. Roaming is denied. Only ND and SX are valid options for Version 1 VLRs. ND is not a valid option for Version 2 or 3 VLRs. NR HOTBILL information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs only. NX HOTBILL information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SX HOTBILL information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 1, Version 2, and Version 3 VLRs.
DEFAULT: Version 1 SX, NX, ND Version 2 SX, NX, NR Version 3 SX, NX, NR
sheet 12 of 33
411-2231-827
Standard
02.05
September 2001
C-59
Table C-12 Table GHLRNDSC field descriptions (continued) Field name LCO (PLMNSPEC Refinement) Description LOCAL CALLS ONLY SUPPLEMENTARY SERVICE ENTRY: ND, NR, NX, SX EXPLANATION: This refinement indicates how LCO information is handled by the DMS-HLR, depending on whether a VLR supports LCO. ND LCO information is not sent to VLRs in this screening class. Roaming is denied. Only ND and SX are valid options for Version 1 VLRs. ND is not a valid option for Version 2 or Version 3 VLRs. NR LCO information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs. NX LCO information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SX LCO information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 1, Version 2 and Version 3 VLRs.
sheet 13 of 33
GSM
C-60
Table C-12 Table GHLRNDSC field descriptions (continued) Field name COS (PLMNSPEC Refinement) Description CLASS OF SERVICE SUPPLEMENTARY SERVICE ENTRY: ND, NR, NX, SX EXPLANATION: This refinement indicates how COS information is handled by the DMS-HLR, depending on whether a VLR supports COS. ND COS information is not sent to VLRs in this screening class. Roaming is denied. Only ND and SX are valid options for Version 1 VLRs. ND is not a valid option for Version 2 or Version 3 VLRs. NR COS information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs only. NX COS information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SX COS information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 1, Version 2, and Version 3 VLRs.
sheet 14 of 33
411-2231-827
Standard
02.05
September 2001
C-61
Table C-12 Table GHLRNDSC field descriptions (continued) Field name ACR (PLMNSPEC Refinement) Description ACCOUNT CODE REQUIRED ENTRY: ND, NR, NX, SX EXPLANATION: This refinement indicates how ACR information is handled by the DMS-HLR, depending on whether a VLR supports ACR. ND ACR information is not sent to VLRs in this screening class. Roaming is denied. Only ND and SX are valid options for Version 1 VLRs. ND is not a valid option for Version 2 or Version 3 VLRs. NR ACR information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs. NX ACR information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SX ACR information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 1, Version 2, and Version 3 VLRs.
DEFAULT: Version 1 SX, ND Version 2 SX, NX, NR Version 3 SX, NX, NR

sheet 15 of 33
GSM
C-62
Table C-12 Table GHLRNDSC field descriptions (continued) Field name ACV (PLMNSPEC Refinement) Description ACCOUNT CODE VOLUNTARY ENTRY: ND, NR, NX, SX EXPLANATION: This refinement indicates how ACV information is handled by the DMS-HLR, depending on whether a VLR supports ACV. ND ACV information is not sent to VLRs in this screening class. Roaming is denied. Only ND and SX are valid options for Version 1 VLRs. ND is not a valid option for Version 2 or Version 3 VLRs. NR ACV information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs. NX ACV information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SX ACV information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 1, Version 2, and Version 3 VLRs.
DEFAULT: Version 1 SX, ND Version 2 SX, NX, NR Version 3 SX, NX, NR

sheet 16 of 33
411-2231-827
Standard
02.05
September 2001
C-63
Table C-12 Table GHLRNDSC field descriptions (continued) Field name MCT (PLMNSPEC Refinement) Description MALICOUS CALL TRACE ENTRY: ND, NR, NX, SX EXPLANATION: This refinement indicates how MCT information is handled by the DMS-HLR, depending on whether a VLR supports MCT. ND MCT information is not sent to VLRs in this screening class. Roaming is denied. Only ND and NX are valid options for Version 1 VLRs. ND is not a valid option for Version 2 or Version 3 VLRs. NR MCT information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs only. NX MCT information is not sent to VLRs in this screening class. Roaming is allowed, but alternative services with more severe restrictions are substituted for MCT. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SX MCT information is sent to VLRs in this screening class. If the VLR does not support MCT, roaming is allowed, but alternative services with more severe restrictions will be substituted for MCT. SX is a valid option for Version 2 and 3 VLRs only.
DEFAULT: Version 1 NX, ND Version 2 SX, NX, NR Version 3 SX, NX, NR

sheet 17 of 33
GSM
C-64
Table C-12 Table GHLRNDSC field descriptions (continued) Field name CNAM (PLMNSPEC Refinement) Description CALLING NAME DELIVERY ENTRY: ND, NR, NX, SX EXPLANATION: This refinement indicates how CNAM information is handled by the DMS-HLR, depending on whether a VLR supports CNAM. ND CNAM information is not sent to VLRs in this screening class. Roaming is denied. Only ND and NX are valid options for Version 1 VLRs. ND is not a valid option for Version 2 or Version 3 VLRs. NR CNAM information is not sent to VLRs in this screening class. Roaming is restricted. NR is a valid option for Version 2 and 3 VLRs only. NX CNAM information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SX CNAM information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 2 and 3 VLRs only.
DEFAULT: Version 1 NX, ND Version 2 SX, NX, NR Version 3 SX, NX, NR LINEID LINE IDENTIFICATION SUPPLEMENTARY SERVICES ENTRY: CLIP CLIR, COLP, COLR , EXPLANATION: LINEID includes calling line identification presentation (CLIP), calling line identification restriction (CLIR), connected line identification presentation (COLP), and connected line identification restriction (COLR) refinements. DEFAULT: NONE
sheet 18 of 33
411-2231-827
Standard
02.05
September 2001
C-65
Table C-12 Table GHLRNDSC field descriptions (continued) Field name CLIP (LINEID Refinement) Description CALLING LINE IDENTIFICATION PRESENTATION ENTRY: ND, NR, NX, SR, SX, SX1, SX2 EXPLANATION: This refinement indicates how CLIP information is handled by the DMS-HLR, depending on whether a VLR supports CLIP In the case . of SX1 and SX2, the number indicates the MAP phase supported by the VLR. ND CLIP information is not sent to VLRs in this screening class. Roaming is denied. Only ND and SX are valid options for Version 1 VLRs. ND is a valid option for Version 1 VLRs only. NR CLIP information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs. NX CLIP information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SR CLIP information is sent to VLRs in this screening class. Roaming is denied. SR is a valid option for Version 2 and 3 VLRs only. SX CLIP information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 1, Version 2, and Version 3 VLRs. SX1 CLIP information is sent in phase 1 format and is a valid option in Version 1. SX2 CLIP information is sent in phase 2 format and is a valid option in Version 2.
DEFAULT: Version 1 SX1, SX2, NX, ND Version 2 SX, NX, SR, NR Version 3 SX, NX, SR, NR CLIPPH (CLIP_PHASE) Which one? CALLING LINE IDENTIFICATION PRESENTATION PHASE ENTRY: 1 or 2 EXPLANATION: Specifies the MAP phase supported by the VLR for CLIP subscription information. 1 Send CLIP subscription information in phase 1 format. 2 Send CLIP subscription information in phase 2 format.
Defaults: Version 1 1, Version 2 2

sheet 19 of 33
GSM
C-66
Table C-12 Table GHLRNDSC field descriptions (continued) Field name CLIR (LINEID Refinement) Description CALLING LINE IDENTIFICATION RESTRICTION ENTRY: ND, NR, NX, SR, SX, SX1, SX2 EXPLANATION: This refinement indicates how CLIR information is handled by the DMS-HLR, depending on whether a VLR supports CLIR. In the case of SX1 and SX2, the number indicates the MAP phase supported by the VLR. ND CLIR information is not sent to VLRs in this screening class. Roaming is denied. Only ND and SX are valid options for Version 1 VLRs. ND is not a valid option for Version 2 or 3 VLRs. NR CLIR information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs only. NX CLIR information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SR CLIR information is sent to VLRs in this screening class. Roaming is denied. SR is a valid option for Version 2 and 3 VLRs only. SX CLIR information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 1, Version 2, and Version 3 VLRs. SX1 CLIR information is sent in phase 1 format and is a valid option in Version 1. SX2 CLIR information is sent in phase 2 format and is a valid option in Version 2.
DEFAULT: Version 1 SX1, SX2, NX, ND Version 2 SX, NX, SR, NR Version 3 SX, NX, SR, NR CLIRPH (CLIR_PHASE) Which one? CALLING LINE IDENTIFICATION RESTRICTION PHASE ENTRY: 1 or 2 EXPLANATION: Specifies the MAP phase supported by the VLR for CLIR subscription information. 1 Send CLIR subscription information in phase 1 format. 2 Send CLIR subscription information in phase 2 format.

sheet 20 of 33
411-2231-827
Standard
02.05
September 2001
C-67
Table C-12 Table GHLRNDSC field descriptions (continued) Field name COLP (LINEID Refinement) Description CONNECTED LINE IDENTIFICATION PRESENTATION ENTRY: ND, NR, NX, SR, SX, SX1 EXPLANATION: This refinement indicates how COLP information is handled by the DMS-HLR, depending on whether a VLR supports COLP . ND COLP information is not sent to VLRs in this screening class. Roaming is denied. Only ND and SX are valid options for Version 1 VLRs. ND is not a valid option for Version 2 or Version 3 VLRs. NR COLP information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs only. NX COLP information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SR COLP information is sent to VLRs in this screening class. Roaming is denied. SR is a valid option for Version 2 and 3 VLRs only. SX COLP information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 1, Version 2, and Version 3 VLRs. SX1 COLP information is sent in phase 1 format and is a valid option in Version 1.
DEFAULT: Version 1 SX1, NX, ND Version 2 SX, NX, SR, NR Version 3 SX, NX, SR, NR COLPPH (COLP_PHASE) CONNECTED LINE IDENTIFICATION PRESENTATION PHASE IDENTIFIER ENTRY: 1, 2 EXPLANATION: Identifies whether VLRs in this screening class support Connected Line Identification Presentation (COLP) Override category (Phase 2) or support COLP Override category (Phase 1). 1 VLRs in this screening class do not support COLP Override. No COLP Override information is sent to VLRs in this screening class. 2 VLRs in this screening class support COLP Override. COLP Override information is sent to VLRs in this screening class.

sheet 21 of 33
GSM
C-68
Table C-12 Table GHLRNDSC field descriptions (continued) Field name COLR (LINEID Refinement) Description CONNECTED LINE IDENTIFICATION RESTRICTION ENTRY: ND, NR, NX, SR, SX, SX1, SX2 EXPLANATION: This refinement indicates how COLR information is handled by the DMS-HLR, depending on whether a VLR supports COLR, and/or which MAP Phase format is supported by VLRs in the screening class. ND COLR information is not sent to VLRs in this screening class. Roaming is denied. Only ND and SX are valid options for Version 1 VLRs. ND is not a valid option for Version 2 or Version 3 VLRs. NR COLR information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs only. NX COLR information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SR COLR information is sent to VLRs in this screening class. Roaming is denied. SR is a valid option for Version 2 and 3 VLRs only. SX COLR information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 1, Version 2, and Version 3 VLRs. SX1 VLRs in this screening class support COLR MAP Phase 1. COLR MAP Phase 1 information is sent to VLRs in this screening class. SX2 VLRs in this screening class support COLR MAP Phase 2. COLR MAP Phase 2 information is sent to VLRs in this screening class.
DEFAULT: Version 1 SX1, SX2, NX, ND Version 2 SX, NX, SR, NR Version 3 SX, NX, SR, NR
sheet 22 of 33
411-2231-827
Standard
02.05
September 2001
C-69
Table C-12 Table GHLRNDSC field descriptions (continued) Field name COLRPH (COLR_PHASE) Description CONNECTED LINE IDENTIFICATION RESTRICTION PHASE IDENTIFIER ENTRY: 1, 2 EXPLANATION: Indicates whether Connected Line Identification Restriction (COLR) subscription MAP Phase 1 format (1) or MAP Phase 2 format (2) is supported by VLRs in this screening class. SX1 VLRs in this screening class support COLR MAP Phase 1. COLR MAP Phase 1 information is sent to VLRs in this screening class. SX2 VLRs in this screening class support COLR MAP Phase 2. COLR MAP Phase 2 information is sent to VLRs in this screening class.
Defaults: Version 1 1, Version 2 2 MULTIPTY MULTI-PARTY SUPPLEMENTARY SERVICES ENTRY: MPTY EXPLANATION: MULTIPTY contains the multi-party supplementary services refinement. DEFAULT: NONE
sheet 23 of 33
GSM
C-70
Table C-12 Table GHLRNDSC field descriptions (continued) Field name MPTY (MULTIPTY Refinement) Description MULTI-PARTY SUPPLEMENTARY SERVICE ENTRY: ND, NR, NX, SR, SX EXPLANATION: This refinement indicates how MTPY information is handled by the DMS-HLR, depending on whether a VLR supports MTPY. ND MTPY information is not sent to VLRs in this screening class. Roaming is denied. Only ND and SX are valid options for Version 1 VLRs. ND is not a valid option for Version 2 or 3 VLRs. NR MTPY information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs only. NX MTPY information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SR MTPY information is sent to VLRs in this screening class. Roaming is denied. SR is a valid option for Version 2 and Version 3 VLRs only. SX MTPY information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 1, Version 2, and Version 3 VLRs.
DEFAULT: Version 1 - SX, NX, ND Version 2 SX, NX, SR, NR Version 3 SX, NX, SR, NR CHARGING CHARGING SUPPLEMENTARY SERVICES ENTRY: AOCI, AOCC EXPLANATION: CHARGING includes advice of charge information (AOCI) and advice of charge charging (AOCC)supplementary services refinements. DEFAULT: NONE
sheet 24 of 33
411-2231-827
Standard
02.05
September 2001
C-71
Table C-12 Table GHLRNDSC field descriptions (continued) Field name AOCI (CHARGING Refinement) Description ADVICE OF CHARGE INFORMATION SUPPLEMENTARY SERVICE ENTRY: ND, NR, NX, SR, SX EXPLANATION: This refinement indicates how AOCI information is handled by the DMS-HLR, depending on whether a VLR supports AOCI. ND AOCI information is not sent to VLRs in this screening class. Roaming is denied. Only ND and SX are valid options for Version 1 VLRs. ND is not a valid option for Version 2 and Version 3 VLRs. NR AOCI information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs only. NX AOCI information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SR AOCI information is sent to VLRs in this screening class. Roaming is denied. SR is a valid option for Version 2 and 3 VLRs only. SX AOCI information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 1, Version 2, and Version 3 VLRs.
DEFAULT: Version 1 - SX, NX, ND Version 2 SX, NX, SR, NR Version 3 SX, NX, SR, NR
sheet 25 of 33
GSM
C-72
Table C-12 Table GHLRNDSC field descriptions (continued) Field name AOCC (CHARGING Refinement) Description ADVICE OF CHARGE CHARGING SUPPLEMENTARY SERVICE ENTRY: ND, NR, NX, SR, SX EXPLANATION: This refinement indicates how AOCC information is handled by the DMS-HLR, depending on whether a VLR supports AOCC. ND AOCC information is not sent to VLRs in this screening class. Roaming is denied. Only ND and SX are valid options for Version 1 VLRs. ND is not a valid option for Version 2 or Version 3 VLRs. NR AOCC information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs only. NX AOCC information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SR AOCC information is sent to VLRs in this screening class. Roaming is denied. SR is a valid option for Version 2 and 3 VLRs. SX AOCC information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 1, Version 2, and Version 3 VLRs.
DEFAULT: Version 1 - SX, NX, ND Version 2 SX, NX, SR, NR Version 3 SX, NX, SR, NR MISCPROP MISCELLANEOUS PROPRIETARY SERVICES ENTRY: INORIG, EA EXPLANATION: MISCPROP includes intelligent network originating (INORIG) and equal access (EA) refinements. DEFAULT: NONE
sheet 26 of 33
411-2231-827
Standard
02.05
September 2001
C-73
Table C-12 Table GHLRNDSC field descriptions (continued) Field name INORIG (MISCPROP Refinement) Description INTELLIGENT NETWORK ORIGINATING ENTRY: ND, NR, NX, SX EXPLANATION: This refinement indicates how IN information is handled by the DMS-HLR, depending on whether a VLR supports IN. ND IN information is not sent to VLRs in this screening class. Roaming is denied. Only ND and SX are valid options for Version 1 VLRs. ND is not a valid option for Version 2 or Version 3 VLRs. NR IN information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs only. NX IN information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SX IN information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 1, Version 2, and Version 3 VLRs. Version 2 NX Version 3 NX
DEFAULT: Version 1 - NX EA (MISCPROP Refinement) EQUAL ACCESS ENTRY: NX, SX
EXPLANATION: This refinement indicates how EA information is handled by the DMS-HLR, depending on whether a VLR supports IN. NX Carrier selection information is not sent to the VLR. This information is not supported by the VLR. SX The VLR supports carrier selection information. SX is a valid option for Version 2 VLRs only. Version 2 NX Version 3 NX
DEFAULT: Version 1 - NX
sheet 27 of 33
GSM
C-74
Table C-12 Table GHLRNDSC field descriptions (continued) Field name EA Description EQUAL ACCESS ENTRY: NX, SX EXPLANATION: This field indicates how EA information is handled by the DMS-HLR, depending on whether a VLR supports EA. NX EA information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1 and Version 2 VLRs. SX EA information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 1 and Version 2 VLRs.
Defaults: Version 1 NX, Version 2 NX COMUNITY COMMUNITY OF INTEREST SUPPLEMENTARY SERVICES ENTRY: CUG EXPLANATION: COMUNITY contains closed user group (CUG) refinements. DEFAULT: NONE
sheet 28 of 33
411-2231-827
Standard
02.05
September 2001
C-75
Table C-12 Table GHLRNDSC field descriptions (continued) Field name CUG (COMUNITY Refinement) Description CLOSED USER GROUP ENTRY: ND, NR, NS, SR, SS EXPLANATION: This refinement indicates how CUG information is handled by the DMS-HLR, depending on whether a VLR supports CUG. ND CUG information is not sent to VLRs in this screening class. Roaming is denied. Only ND and NS are valid options for Version 1 VLRs. ND is not a valid option for Version 2 or Version 3 VLRs. NS CUG information is not sent to VLRs in this screening class. Roaming is allowed, but alternative services with more severe restrictions are substituted for CUG. Only ND and NS are valid options for Version 1 VLRs. NS is a valid option for Version 1, Version 2, and Version 3 VLRs. NR CUG information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs only. SR CUG information is sent to VLRs in this screening class. Roaming is denied. SR is a valid option for Version 2 and 3 VLRs only. SS CUG information is sent to VLRs in this screening class. If the VLR does not support CUG, roaming is allowed, but alternative services with more severe restrictions will be substituted for CUG. SS is a valid option for Version 2 and 3 VLRs only. Version 2 NR, NS, SR, SS
DEFAULT: Version 1 - ND, NS Version 3 NR, NS, SR, SS MISCGSM MISCELLANOUS GSM ENTRY: CAMEL, REGSUB
EXPLANATION: MISCGSM contains customized applications for mobile network enhanced logic (CAMEL) and regional subscription service refinements. DEFAULT: NONE
sheet 29 of 33
GSM
C-76
Table C-12 Table GHLRNDSC field descriptions (continued) Field name CAMEL (MISCGSM Refinement) Description CUSTOMIZED APPLICATIONS FOR MOBILE NETWORK ENHANCED LOGIC ENTRY: S_S, S_R, N_S, N_R, N_D EXPLANATION: This refinement indicates how CAMEL information is handled by the DMS-HLR, depending on whether a VLR supports CAMEL. The underscore between the letters indicates that it is necessary to refer to the UNSPVMSC field in table GHLRCAML to determine how to proceed. The UNSPVMSC field indicates whether to continue or release the call. These roaming restrictions depend on the per subscriber datafill of the UNSPVMSC flag in table GHLRCAML. N_D Do not send CAMEL information to VLRs in this screening class. If the UNSPVMSC flag in table GHLRCAML is set to CONTINUE, no restrictions on roaming exist. The D indicates a denial of roaming with the following options: If a UL is received, display Roaming Not Allowed error. If CAMEL data is added or changed, send a Cancel Location message.
N_D is a valid option for Version 1 VLRs only. N_S Do not send CAMEL information to VLRs in this screening class. Roaming is allowed, but alternative services with more severe restrictions can be substituted for CAMEL. Only N_D and N_S are valid options for Version 1 VLRs. N_S is a valid option for Version 1, Version 2, and Version 3 VLRs. N_R Do not send CAMEL information to VLRs in this screening class. If UNSPVMSC is set to RELEASE or CONT_HPLMN and the subscriber is in a VPLMN, impose roaming restrictions on subscribers profile at the VLR. N_R is a valid option for Version 2 and 3 VLRs only. S_R Send CAMEL information to VLRs in this screening class. If UNSPVMSC is set to RELEASE or CONT_HPLMN and the subscriber is in a VPLMN, impose roaming restrictions on subscribers profile at the VLR. S_R is a valid option for Version 3 VLRs only. S_S Send CAMEL information to VLRs in this screening class. If the VLR does not support CAMEL, roaming is allowed, but alternative services with more severe restrictions can be substituted for CAMEL. S_S is a valid option for Version 3 VLRs only.
DEFAULT: Version 1 - N_D, N_S Version 2 N_R, N_S Version 3 N_R, N_S, S_R, S_S
sheet 30 of 33
411-2231-827
Standard
02.05
September 2001
C-77
Table C-12 Table GHLRNDSC field descriptions (continued) Field name REGSUB (MISCGSM Refinement) Description REGIONAL SUBSCRIPTION SERVICE ENTRY: SX, NX, ND, SR, NR EXPLANATION: This refinement indicates how REGSUB information is handled by the DMS-HLR, depending on whether a VLR supports REGSUB. ND REGSUB information is not sent to VLRs in this screening class. Roaming is denied. Only ND and NS are valid options for Version 1 VLRs. ND is not a valid option for Version 2 or Version 3 VLRs. NR REGSUB information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs only. NX REGSUB information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SX REGSUB information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 2 and 3 VLRs only. SR REGSUB information is sent to VLRs in this screening class. Roaming is denied. SR is a valid option for Version 2 and 3 VLRs only. Version 2 SX, NX, SR, NR
0
DEFAULT: Version 1 - NX, ND Version 3 SX, NX, SR, NR CALLOFF CALL OFFICE ENTRY: ECT
EXPLANATION: CALLOFF contains the explicit call transfer (ECT) refinement. DEFAULT: NONE
sheet 31 of 33
GSM
C-78
Table C-12 Table GHLRNDSC field descriptions (continued) Field name ECT (CALLOFF Refinement) Description EXPLICIT CALL TRANSFER ENTRY: SX, NX, ND, SR, NR EXPLANATION: This field indicates how ECT information is handled by the DMS-HLR, depending on whether a VLR supports ECT. This service is activated on a per IMSI basis and can only be activated by the operator. Call Hold must be provisioned for that subscriber before ECT can be provisioned. ND ECT information is not sent to VLRs in this screening class. Roaming is denied. Only ND and NS are valid options for Version 1 VLRs. ND is not a valid option for Version 2 or Version 3 VLRs. NR ECT information is not sent to VLRs in this screening class. Roaming is denied. NR is a valid option for Version 2 and 3 VLRs only. NX ECT information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SX ECT information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 2 and 3 VLRs only. SR ECT information is sent to VLRs in this screening class. Roaming is denied. SR is a valid option for Version 2 and 3 VLRs only. Version 2 SX, NX, SR, NR
DEFAULT: Version 1 - NX, ND Version 3 SX, NX, SR, NR OCIC
OVERRIDE CARRIER IDENTIFICATION CODE ENTRY: NX, SX EXPLANATION: This field indicates how OCIC information is handled by the DMS-HLR, depending on whether a VLR supports OCIC. NX OCIC information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SX OCIC information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 2 and 3 VLRs only.
0
DEFAULT: Version 1 NX, Version 2 NX, Version 3 NX

sheet 32 of 33
411-2231-827
Standard
02.05
September 2001
C-79
Table C-12 Table GHLRNDSC field descriptions (continued) Field name PCIC Description PRIMARY CARRIER INTEREXCHANGE CODE ENTRY: NX, SX EXPLANATION: This field indicates how PCIC information is handled by the DMS-HLR, depending on whether a VLR supports PCIC. NX PCIC information is not sent to VLRs in this screening class. Roaming is allowed. NX is a valid option for Version 1, Version 2, and Version 3 VLRs. SX PCIC information is sent to VLRs in this screening class. Roaming is allowed. SX is a valid option for Version 2 and 3 VLRs only.
0
DEFAULT: Version 1 NX, Version 2 NX, Version 3 NX

sheet 33 of 33
Datafill sequence
The class name must be datafilled in table GHLRSCMP before it can be used in table GHLRNDSC.
Dump and restore

Conversion of a GSM08 tuple to a GSM09 tuple requires a reformat procedure during dump and restore. This procedure assigns appropriate datafill to the REGSUB field, with respect to VERSION, from the VLRDEFAULT. During a GSM08, GSM83 -> GSM09 ONP, the system copies the default values for ECT and ODBECT into table GHLRNDSC. The CAMEL field is set to N_S for both Version 1 and Version 2 profiles. S_S for Version 3 profiles.
Malicious call trace (MCT) When performing a reformat from GSM06 to GSM08 or from GSM07 to GSM08, the MCT screening field (in table GHLRNDSC) defaults to NX for both version 1 and version 2 profiles. When performing a reformat from GSM08 to GSM08, the data integrity is maintained.
GSM
C-80
Calling name delivery (CNAM) When performing a reformat from GSM06 to GSM08 or from GSM07 to GSM08, the CNAM screening field (in table GHLRNDSC) defaults to NX for both version 1 and version 2 profiles. When performing a reformat from GSM08 to GSM08, the data integrity is maintained.
Example datafill
Figure C-5 shows example datafill for table GHLRNDSC.
Figure C-5 Example datafill for table GHLRNDSC CI: >table ghlrndsc TABLE: GHLRNDSC > >lis all TOP CLASS VERSION BSVC LINEID CALLOFF CALLCOMP MULTIPTY COMUNITY CHARGING ODBPLMNSPEC MISCPROP MISCGSM ---------------------------------------------------------------------VLRDEFAULT 1 ALS SX SMMT SY CDSGBS NS CDAGBS NS CLIP SX2 CLIR SX2 COLP SX COLR NX ECT NX CW SX1 HOLD SX MPTY SX CUG ND AOCI SX AOCC SX ODBOG SX ODBPREM SX ODBHPLMN SX ODBCISS SX ODBECT ND HOTBILL SX LCO SX COS SX ACR NX ACV NX MCT NX CNAM NX INORIG NX EA NX CAMEL N_D REGSUB ND VLRDEFAULT 2 ALS SX SMMT SN CDSGBS NS CDAGBS NS CLIP SX CLIR SX COLP SX COLR SX ECT SX CW SX HOLD SX MPTY SX CUG SS AOCI SX AOCC SX ODBOG SX ODBPREM SX ODBHPLMN SX ODBCISS SX ODBECT NR HOTBILL SX LCO SX COS SX ACR SX ACV SX MCT SX CNAM SX INORIG SX EA SX CAMEL N_S REGSUB SX
411-2231-827
Standard
02.05
September 2001
C-81
Table GHLRPARM
Table description
Table GHLRPARM is an office parameter table that contains miscellaneous parameters that the DMS-HLR requires.Field descriptions Table C-13 provides information about table GHLRPARM. A description of each field in this table appears after the table.
Table C-13 Table GHLRPARM FIELD NAME PARMKEY PARMSEL RANGE OF VALUES VECTOR OF UP TO 8 CHARS {AC_AUDTI, AC_MAX_V, CHKSCFAD, DBMEMLIM, EXTODBON, HLRRELNO, HNESUPD, MATEDVRT, MISCSSN, NAM_DFLT, NDC_DFLT, PASSDFLT, PASSTHLD, RACENETD, REROUTER, ROAMCSI, SBYTIMER, SIMSION, STANDBY} REFINEMENTS: MULTIPLE WITH PARMSEL_TYPE
PARMVAR
PARMKEY - Parameter Key This field requires a vector of up to eight characters to identify the parameter. This field forms the key to this table. PARMSEL - Parameter Selector The PARMSEL field determines the format of the remainder of the area. The parameter PARMSEL must match the PARMKEY field. PARMVAR - Parameter Variable Data Area Refer to the appropriate parameter section in this chapter for more information on each PARMVAR in table GHLRPARM.
GSM
C-82
Table GHLRSCF
Table description
Table GHLRSCF assigns symbolic names to each actual GSM Service Control Function (gsmSCF) on the network. An entry in GHLRSCF consists of a symbolic name for the gsmSCF and its corresponding actual network address. These symbolic names are referenced in table GHLRCAML and GHLRUSSD, instead of a network address. Fields in this table also record the highest common version supported by the HLR and gsmSCF for the Network Unstructured (NUS) application context.
411-2231-827
Standard
02.05
September 2001
C-83
Field descriptions
Table C-14 contains field descriptions for table GHLRSCF.
Table C-14 Table GHLRSCF field descriptions Field name SCF_NAME Description SYMBOLIC gsmSCF ADDRESS NAME ENTRY: 1 to 20 alphanumeric characters or underscores EXPLANATION: This field holds the symbolic names of the various gsmSCF addresses defined within a GSM network. Each of the names defined here may be referenced numerous times in tables GHLRUSSD and GHLRCAML as the gsmSCF_Address for either Originating or Terminating CSI. Any changes to a gsmSCF name contained in this field may only be done when no references are made to it in table GHLRCAML or GHLRUSSD. DEFAULT: N/A SCF_NUMBER SYMBOLIC gsmSCF ADDRESS ENTRY: vector of up to 15 {0 to 9}s EXPLANATION: This field contains the corresponding E164 address of the gsmSCF whose symbolic name is contained in the SCFNAME field. Changes can easily be made to this field even when the gsmSCF address is referenced in table GHLRCAML. Deletions of any tuple in this table may be done only when no references are made to the SCF_Address in table GHLRCAML. DEFAULT: N/A NUS_AC Network Unstructured Application Context Version ENTRY: HLR_MAX, V2 EXPLANATION: This field contains the version of NUS AC used by the HLR for this GSMSCF. The version chosen cannot be higher than the one supported by the HLR. HLR_MAX is defined by the HLR parameter AC_MAX_V in table GHLRPARM. DEFAULT: HLR_MAX
sheet 1 of 2
GSM
C-84
Table C-14 Table GHLRSCF field descriptions (continued) Field name EVAL_NUS Description Evaluate Network Unstructured Application Context Flag ENTRY: Y, N EXPLANATION: This field contains the evaluate NUS AC flag. This indicates whether the NUS_AC version needs to be updated to the last common highest version supported by both the HLR and gsmSCF. This field is periodically reset by AC_AUDIT to Y. DEFAULT: Y AC_AUDIT Application Context Audit ENTRY: ENABLED, DISABLED EXPLANATION: This field specifies if the AC version audit sets the evaluate AC flags (EVAL_NUS) to Y and the value of NUS_AC to HLR_MAX for this entry. This provides the system administrator the option to turn off the AC_AUDIT for an individual gsmSCF. DEFAULT: ENABLED
sheet 2 of 2
Datafill sequence
A symbolic address for a gsmSCF must be datafilled in table GHLRSCF before that symbolic address can be used in table GHLRCAML or GHLRUSSD.
Dump and restore

Restore this table using the dump and restore mechanism. The following ONP processes are supported: ONP from GSM09 to GSM11 ONP from GSM10 to GSM11 ONP from GSM11 to GSM11
On ONP from GSM09/10 to GSM11, set NUS_AC to HLR_MAX, EVAL_NUS to Y, and AC_AUDIT to ENABLED.
Example datafill
Figure C-6 shows example datafill for table GHLRSCF.
411-2231-827
Standard
02.05
September 2001
Nortel Networks Confidential Figure C-6 Example datafill for table GHLRSCF CI: >table ghlrscf TABLE: GHLRSCF >list all SCF_NAME SCF_NUMBER
C-85
NUS_AC
EVAL_NUS
AC_AUDIT
----------------------------------------------------------------SCP_1_KEY ALTERNATE
7845548942 4589465368 v2 hlr_max Y Y ENABLED ENABLED
GSM
C-86
Table GHLRSSOP
This table is used to support the following GSM-R functionalities: FA Call Forwarding to FSNs VBS VGCS eMLPP
Table description
Table GHLRSSOP contains option data for provisioning, registering, and activating Supplementary Services associated with a subscriber or a Basic Service Group. The table contains one tuple per supplementary service provisioned against the IMSI. The tuples are identified with a three-part key consisting of the IMSI MNC, the IMSI MSIN, and the supplementary service. For a subscriber to use a Supplementary Service, the service must be provisioned, registered (for those Supplementary Services requiring registration), and activated. Provisioning consists of adding a tuple with data in the provisioning fields and nil registration fields. Registering consists of adding registration data to the fields requiring it. Registration activates automatically.
Field descriptions
Table C-15 contains field descriptions for table GHLRSSOP.
(continTable C-15 Table GHLRSSOP field descriptions Field name MCC Description INTERNATIONAL MOBILE SUBSCRIBER IDENTIFICATION CODE (IMSI) Mobile Country Code ENTRY: 3 digits (0-9) EXPLANATION: This field indicates the country where a subscribers IMSI is registered. MCCs are assigned to different nations by the International Telecommunications Union - Telecommunication Standardization Sector (ITU-T). The MCC must be identified for each subscriber. DEFAULT: N/A
sheet 1 of 18
411-2231-827
Standard
02.05
September 2001
C-87
Table C-15 Table GHLRSSOP field descriptions (continued) Field name MNC Description INTERNATIONAL MOBILE SUBSCRIBER IDENTIFICATION CODE (IMSI) MOBILE NETWORK CODE ENTRY: Vector of up to 3 {0 to 9}s EXPLANATION: This field is part one of a three-part key. An entry into this key field identifies a PLMN. When combined with office parameter GHLR_IMSI_MCC in table OFCSTD and field MSIN, it identifies subscriber regardless of equipment or position. MNC must match MNC specified by office parameter GHLR_IMSI_MNC in table OFCSTD, or it is rejected. The DMS-HLR supports one of the following: single two digit MNC single three digit MNC multiple two digit MNCs multiple three digit MNCs MSIN MOBILE SUBSCRIBER IDENTIFICATION NUMBER ENTRY: Vector of up to 10 {0 to 9}s EXPLANATION: This field is part two of a two part key. When this key field is entered, it specifies the subscriber portion of the IMSI. When combined with office parameter GHLR_IMSI_MCC in table OFCSTD and field MNC, it identifies the subscriber regardless of equipment or position. Value entered at table control interface is not padded out.
DEFAULT: N/A
sheet 2 of 18
GSM
C-88 (contin-
Table C-15 Table GHLRSSOP field descriptions (continued) Field name SSPROV Description SUPPLEMENTARY SERVICE (SS) PROVISIONING ENTRY: This is part three of a three-part key field. Enter one of the following values: ACC Accounting Codes. Allows subscribers to charge call to different projects or accounts. AOCC Advice of Charge Charging. Allows the mobile subscriber to be charged in real-time for a call. AOCI Advice of Charge Information. Allows the mobile subscriber to display the cost of a call in real-time. BAIC Barring of all Incoming Calls. The mobile subscriber cannot receive incoming calls. BAIC cannot be activated if the subscriber has one or more of the following Supplementary Services activated: CFU, CFB, CFNRy, and CFNRc. A warning message is given if the subscriber is provisioned with Call Waiting (CW) and provision is accepted. BAOC Barring of All Outgoing Calls. The mobile subscriber is not allowed to make outgoing calls if BAOC is active. BAOC activation is rejected if subscriber has one or more of the following Supplementary Services: CFB, CFU, CFNRc, and CFNRy. BICROAM Barring of all Incoming Calls when Roaming Outside the Home PLMN Country. The mobile subscriber may not receive incoming calls while roaming outside the mobile subscribers Home PLMN country if this is active. BOIC Barring of all Outgoing International Calls. The mobile subscriber cannot make any outgoing international calls. A national number does not cause BOIC rejection. BOIC and BAOC can be both provisioned but not both activated. BOICEXHC Barring of all Outgoing International Calls except those directed to the Home PLMN Country. If BOICEXHC is active, then the mobile subscriber cannot make outgoing international calls unless the subscriber is roaming and calls the Home PLMN country. CFB Call Forwarding MS Busy. Allows a subscriber to forward incoming calls to a specified destination when the mobile station is busy.
sheet 3 of 18
411-2231-827
Standard
02.05
September 2001
C-89
Table C-15 Table GHLRSSOP field descriptions (continued) Field name SSPROV (continued) Description ENTRY (continued): CFNRc Call Forwarding Not Reachable. Allows a mobile subscriber to forward incoming calls to a specified destination under one of the following three conditions: Not registered. The call is forwarded if the call forwarding mobile station has performed an IMSI detach. Radio congestion. Call is forwarded if the radio channels associated with the current location area of the call forwarding mobile station are unavailable. No page response. Call is forwarded when the call forwarding mobile station (MS) cannot be located within the MSC coverage area. CFNRy Call Forwarding No Reply. Allows a mobile subscriber to forward an incoming call to a specified destination when the call is not answered within a specified period of time. CFU Call Forwarding Unconditional. Allows a mobile subscriber to forward all incoming calls to a specified destination regardless of the current status. CLIR Calling Line Identification Restriction. Restricts the display of identification information about the calling party to the called party. CLIP Calling Line Identification Presentation Override. Allows the display of information about the calling party to the mobile subscriber. CNAM Calling Name Delivery. Allows the called mobile subscriber to receive the callers name. Operator controlled only. COLP Connected Line Identification Presenting. Allows the called partys (connected line identity) COLI to be presented to the calling party. COLR Connected Line Identification Restriction. Prevents a called partys (connected line identity) COLI from being displayed to the calling party. COS Class of Service. Provides Customer Group (CUSTGRP) and Network Class of Service (NCOS) classifications to mobile subscribers within a user group. These classifications allow a community of subscribers to have uniform and group-specific services. CUG Closed User Group. Allows subscribers connected to a PLMN to form Closed User Groups (CUGs). Access to and from CUGs is restricted.
sheet 4 of 18
GSM
C-90 (contin-
Table C-15 Table GHLRSSOP field descriptions (continued) Field name SSPROV (continued) Description ENTRY (continued): CW Call Waiting. Allows a mobile subscriber currently engaged in a call to be alerted that another party is trying to call in. The subscriber has a predetermined period of time to terminate the existing conversation and respond to the second call. ECT Explicit Call Transfer. Allows the mobile subscriber who has two active calls, either incoming or outgoing, to connect those two subscribers together, while removing himself completely from the call. EXT Extension Service. Allows the subscriber to be associated with an extension group. One member of the group serves as a pilot. The pilot is the head of the extension group. When an incoming call is received for the pilot, the members of the group are alerted either simultaneously, sequentially, or in a pre-defined combination of the two. For more information on this feature, refer to NTP 411-2831-809, DMSHLR MAP Commands and Procedures Reference Manual. HOLD Call Hold. Allows a mobile subscriber to put a caller on hold. HOTBILL Hot Billing. Provides the ability to indicate, on a per subscriber basis, whether or not the subscribers billing records are to be classified as HOT. Hot Billing does not interact with any supplementary service or ODB barring categories. LCO Local Calls Only. Allows the mobile subscriber to call only to a specific set of local destination numbers, which must be in the local source area where they are roaming. MCT Malicious Call Trace. Allows the mobile subscriber to trace the last incoming call. This gives the subscriber the ability to trace a malicious caller. Operator controlled only. MPTY Multiparty. The Multi-Party calling service allows a subscriber to connect a number of mobile phone users together to have a multi-party conference. The service allows two mutually exclusive flavours of MPTY to be provisioned (M3PORT, M6PORT). ACRJ - Anonymous Call Rejection. Provides the network with the capability to reject calls from parties who have blocked their calling line ID to subscribers who have the ACRJ service provisioned
sheet 5 of 18
411-2231-827
Standard
02.05
September 2001
C-91
Table C-15 Table GHLRSSOP field descriptions (continued) Field name SSVAR SELECTOR Description SUPPLEMENTARY SERVICES VARIABLE DATA SELECTOR ENTRY: ACC, AOCI, AOCC, BAOC, BAIC, BICROAM, BOIC, BOICEXHC, CFB, CFU, CFNRC, CFNRY, CLIP CLIR, CNAM, COLP, COLR, COS, CUG, , CW, ECT, EXT, HOLD, HOTBILL, LCO, MCT, MPTY, or ACRJ. EXPLANATION: This selector field must match the entry for field SSPROV. This value identifies the Supplementary Service for which additional information is provided in the associated subfields. The following selectors have no SSVAR information associated with them: AOCI, CNAM, CW, HOLD, HOTBILL, LCO, MCT, and ECT. Note: Only those selectors which have refinement data associated with them are described below. Subfield of SSVAR selector CFU SUPPLEMENTARY SERVICE VARIABLE DATA FOR CALL FORWARDING UNCONDITIONAL ENTRY: (NONF, NF, or NFWN), (SPCH, AUXSPCH, FAX, CDA, or CDS), and (vector from 4 to 15 numbers, 0-9) EXPLANATION: The variable data for CFU consists of three areas: NCP: Notify Calling Party Provisioning Information. Indicates whether the calling party should be notified that a call has been forwarded, and if so, with or without the forwarded-to number. Valid entries: NONF No notification NF Notification NFWN Notification with number The default is NONF. BSG: Basic Service Group for which this Supplementary Service is registered. Valid entries: SPCH Speech FAX Facsimile Group 3 CDA Circuit Duplex Asynchronous CDS Circuit Duplex Synchronous AUXSPCH Auxiliary Speech CFNUM: The call forwarding number. SSVAR data for CFU may contain up to five sets of BSG and CFNUM entries, one set for each applicable Basic Service Group.
sheet 6 of 18
GSM
C-92 (contin-
Table C-15 Table GHLRSSOP field descriptions (continued) Field name Subfield of SSVAR selector CFB Description SUPPLEMENTARY SERVICE VARIABLE DATA FOR CALL FORWARDING MS BUSY ENTRY: (NONF, NF, or NFWN), (NONF, NF, or NFWN), (SPCH, AUXSPCH, FAX, SMS, CDA, or CDS), and (vector of up to 15 {0-9}s) EXPLANATION: The variable data for CFB consists of four areas: NCP: Notify Calling Party Provisioning Information. Indicates whether the calling party should be notified that a call has been forwarded, and if so, with or without the forwarded-to number. Valid entries: NONF No notification NF Notification NFWN Notification with number DEFAULT: NONF NFP: Notify Forwarding Party Provisioning Information. Indicates whether the forwarding party should be notified that a call has been forwarded, and if so, with or without the forwarded-to number. Valid entries: NONF No notification NF Notification NFWN Notification with number DEFAULT: NONF BSG: Basic Service Group for which this Supplementary Service is registered. Valid entries: SPCH Speech AUXSPCH Auxiliary Speech FAX Facsimile Group 3 SMS Short Message Service CDA Circuit Duplex Asynchronous CDS Circuit Duplex Synchronous CFNUM: The call forwarding number. SSVAR data for CFB may contain up to five sets of BSG and CFNUM entries, one set for each Basic Service Group.
sheet 7 of 18
411-2231-827
Standard
02.05
September 2001
C-93
Table C-15 Table GHLRSSOP field descriptions (continued) Field name Subfield of SSVAR selector CFNRY Description SUPPLEMENTARY SERVICE VARIABLE DATA FOR CALL FORWARDING NO REPLY ENTRY: (NONF, NF, or NFWN), (NONF, NF, or NFWN), (SPCH, AUXSPCH, FAX, SMS, CDA, or CDS), (vector of up to 15 {0-9}s), and (multiple of 5 in range 5-30) EXPLANATION: The variable data for CFNRY consists of five areas: NCP: Notify Calling Party Provisioning Information. Indicates whether the calling party should be notified that a call has been forwarded, and if so, with or without the forwarded-to number. Valid entries: NONF No notification NF Notification NFWN Notification with number DEFAULT: NONF NFP: Notify Forwarding Party Provisioning Information. Indicates whether the forwarding party should be notified that a call has been forwarded, and if so, with or without the forwarded-to number. Valid entries: NONF No notification NF Notification NFWN Notification with number DEFAULT: NONF BSG: Basic Service Group for which this Supplementary Service is registered. Valid entries: SPCH Speech AUXSPCH Auxiliary Speech FAX Facsimile Group 3 SMS Short Message Service CDA Circuit Duplex asynchronous CDS Circuit Duplex Synchronous CFNUM: The call forwarding number NRTIME: The Call Forwarding No Reply condition timer. Indicates the period of time (in seconds) after which an unanswered call is forwarded. Valid entries are 5, 10, 15, 20, 25, or 30. Datafillable in table GSMTIMRS; the default is 15. SSVAR data for CFNRY may contain up to five sets of BSG and CFNUM entries, one set for each Basic Service Group.
sheet 8 of 18
GSM
C-94 (contin-
Table C-15 Table GHLRSSOP field descriptions (continued) Field name Description SUPPLEMENTARY SERVICE VARIABLE DATA FOR CALL FORWARDING NOT REACHABLE ENTRY: (NONF, NF, or NFWN), (SPCH, AUXSPCH, FAX, SMS, CDA, or CDS), and (vector of up to 15 {0-9}s) EXPLANATION: The variable data for CFNRC consists of three areas: NCP: Notify Calling Party Provisioning Information. Indicates whether the calling party should be notified that a call has been forwarded, and if so, with or without the forwarded-to number. Valid entries: NONF No notification NF Notification NFWN Notification with number DEFAULT: NONF BSG: Basic Service Group for which this Supplementary Service is registered. Valid entries: SPCH Speech AUXSPCH Auxiliary Speech FAX Facsimile Group 3 SMS Short Message Service CDA Circuit Duplex Asynchronous CDS Circuit Duplex Synchronous CFNUM: The call forwarding number. SSVAR data for CFNRC may contain up to five sets of BSG and CFNUM entries, one set for each Basic Service Group.
sheet 9 of 18
Subfield of SSVAR selector CFNRC
411-2231-827
Standard
02.05
September 2001
C-95
Table C-15 Table GHLRSSOP field descriptions (continued) Field name Description SUPPLEMENTARY SERVICE VARIABLE DATA FOR BARRING OF ALL OUTGOING CALLS ENTRY: SPCH, AUXSPCH, SMS, FAX, CDA, or CDS EXPLANATION: The variable data for BAOC consists of one area: BSG: Basic Service Group for which this Supplementary Service is registered. SSVAR data for BAOC may contain up to six BSGs, allowing BAOC to be provisioned separately for each of the Basic Service Groups. Valid entries: SPCH Speech AUXSPCH Auxiliary Speech SMS Short Message Service FAX Facsimile Group 3 CDA Circuit Duplex Asynchronous CDS Circuit Duplex Synchronous
Subfield of SSVAR selector BAOC
Subfield of SSVAR BOIC
SUPPLEMENTARY SERVICE VARIABLE DATA FOR BARRING OF OUTGOING INTERNATIONAL CALLS ENTRY: SPCH, AUXSPCH, SMS, FAX, CDA, or CDS EXPLANATION: The variable data for BOIC consists of one area: BSG: Basic Service Group for which this Supplementary Service is registered. SSVAR data for BOIC may contain up to six BSGs, allowing BOIC to be provisioned separately for each of the Basic Service Groups. Valid entries: SPCH Speech AUXSPCH Auxiliary Speech SMS Short Message Service FAX Facsimile Group 3 CDA Circuit Duplex Asynchronous CDS Circuit Duplex Synchronous
sheet 10 of 18
GSM
C-96 (contin-
Table C-15 Table GHLRSSOP field descriptions (continued) Field name Description SUPPLEMENTARY SERVICE VARIABLE DATA FOR BARRING OF ALL INCOMING CALLS ENTRY: SPCH, AUXSPCH, SMS, FAX, CDA, or CDS EXPLANATION: The variable data for BAIC consists of one area: BSG: Basic Service Group for which this Supplementary Service is registered. SSVAR data for BAIC may contain up to six BSGs, allowing BAIC to be provisioned separately for each of the Basic Service Groups. Valid entries: SPCH Speech AUXSPCH Auxiliary Speech SMS Short Message Service FAX Facsimile Group 3 CDA Circuit Duplex Asynchronous CDS Circuit Duplex Synchronous
Subfield of SSVAR BAIC
Subfield of SSVAR BOICEXHC
SUPPLEMENTARY SERVICE VARIABLE DATA FOR BARRING OF OUTGOING INTERNATIONAL CALLS, EXCEPT THOSE DIRECTED TO THE HOME PLMN COUNTRY ENTRY: SPCH, AUXSPCH, SMS, FAX, CDA, or CDS EXPLANATION: The variable data for BOICEXHC consists of one area. BSG: Basic Service Group for which this Supplementary Service is registered. SSVAR data for BOICEXHC may contain up to six BSGs, allowing BOICEXHC to be provisioned separately for each of the Basic Service Groups. Valid entries: SPCH Speech AUXSPCH Auxiliary Speech SMS Short Message Service FAX Facsimile Group 3 CDA Circuit Duplex Asynchronous CDS Circuit Duplex Synchronous
sheet 11 of 18
411-2231-827
Standard
02.05
September 2001
C-97
Table C-15 Table GHLRSSOP field descriptions (continued) Field name Description SUPPLEMENTARY SERVICE VARIABLE DATA FOR BARRING OF INCOMING CALLS WHEN ROAMING OUTSIDE THE HOME PLMN COUNTRY ENTRY: SPCH, AUXSPCH, SMS, FAX, CDA, or CDS EXPLANATION: The variable data for BICROAM consists of one area. BSG: Basic Service Group for which this Supplementary Service is registered. SSVAR data for BICROAM may contain up to six BSGs, allowing BICROAM to be provisioned separately for each of the Basic Service Groups. Valid entries: SPCH Speech AUXSPCH Auxiliary Speech SMS Short Message Service FAX Facsimile Group 3 CDA Circuit Duplex Asynchronous CDS Circuit Duplex Synchronous
Subfield of SSVAR BICROAM
Subfield of SSVAR selector CW
SUPPLEMENTARY SERVICE VARIABLE DATA FOR CALL WAITING ENTRY: SPCH, AUXSPCH, FAX, CDA, CDS, or SMS EXPLANATION: The variable data for CW consists of one area. BSG: Basic Service Group for which this Supplementary Service is registered. SSVAR data for CW may contain up to six BSGs, allowing CW to be provisioned separately for each of the Basic Service Groups. Valid entries: SPCH Speech AUXSPCH Auxiliary Speech FAX Facsimile Group 3 CDA Circuit Duplex Asynchronous CDS Circuit Duplex Synchronous SMS Short Message Service
sheet 12 of 18
GSM
C-98 (contin-
Table C-15 Table GHLRSSOP field descriptions (continued) Field name Description SUPPLEMENTARY SERVICE VARIABLE DATA FOR MULTI-PARTY CALLING ENTRY: M3PORT OR M6PORT EXPLANATION: The variable data for MPTY consists of one area. OPTION: MULTI-PARTY flavour option. Allows two mutually exclusive flavors of MPTY to be provisioned. This service is activated on a per IMSI basis and can only be activated by the operator. Call Hold must be provisioned for that subscriber before either flavour can be provisioned. M3PORT - 3 port Multi-Party Supplementary Service M6PORT - 6 port Multi-Party Supplementary Service
Subfield of SSVAR selector MPTY
Subfield of SSVAR selector CLIR
SUPPLEMENTARY SERVICE VARIABLE DATA FOR CALLING LINE IDENTIFICATION RESTRICTION ENTRY: P TRES, or TNRES , EXPLANATION: The variable data for CLIR consists of one area. PMODE: CLIR Presentation Mode option. Indicates the default presentation mode of temporary CLIP. When a mobile subscriber provisioned with Temporary CLIR makes a call, the default CLIR option selected at provisioning time is used, unless explicitly overridden by the subscriber at call time. Valid entries: P permanent CLI restriction mode. The CLI of the calling party is not presented to the called party. This is an operator controlled option, which cannot be overridden by the subscriber at the handset. TRES temporary CLI presentation restricted. The CLI of the calling party is not presented to the called party when this override option is invoked. TNRES temporary CLI not restricted. When this override option is invoked, the CLI of the calling party is presented to the called party. The CLI will not be presented, unless the override TNRES option is invoked on a per call basis. DEFAULT: P
sheet 13 of 18
411-2231-827
Standard
02.05
September 2001
C-99
Table C-15 Table GHLRSSOP field descriptions (continued) Field name Description SUPPLEMENTARY SERVICE VARIABLE DATA FOR CALLING LINE IDENTIFCATION PRESENTATION ENTRY: NP or P EXPLANATION: The variable data for CLIP consists of one area: OVR: CLIP Override option. Indicates if the CLIP Override option of the CLIP service is provisioned. Valid entries: NP not provisioned. The CLI of the calling party will be presented to the called party, unless the calling party has CLIR provisioned. P provisioned. The CLI of the calling party will be presented to the called party, even if the calling party has CLIR provisioned. This option can only be provisioned by the operator and may not be available to all subscribers. DEFAULT: NP
sheet 14 of 18
Subfield of SSVAR selector CLIP
GSM
C-100 (contin-
Table C-15 Table GHLRSSOP field descriptions (continued) Field name Description SUPPLEMENTARY SERVICE VARIABLE DATA FOR CLASS OF SERVICE ENTRY: (SPCH, AUXSPCH, SMS, FAX, CDA, or CDS), (0-4095), (NIL or NCOS), and (0-255 if NCOS entered in previous field) EXPLANATION: The variable data for COS consists of four areas: BSG: Basic Service Group for which this Supplementary Service is registered. Valid entries: SPCH Speech AUXSPCH Auxiliary Speech FAX Facsimile Group 3 CDA Circuit Duplex Asynchronous CDS Circuit Duplex Synchronous SMS Short Message Service CUSTGRP: Customer Group. This value must already be datafilled in table GSMCUST and must have the XLT and USERTYPE options datafilled in that table. Valid entries are 0-4095, given that the value exists in table GSMCUST. NCOS_SEL: Network Class of Service (NCOS) Selector. The value indicates there is an NCOS for this CUSTGRP Enter NIL for no NCOS, and . enter NCOS if there is an NCOS. NCOS: If NCOS is entered in the NCOS_SEL field, a valid NCOS value must be entered in this field. This value must already be datafilled in table GSMNCOS and must have the XLT and USERTYPE options datafilled in that table. Valid entries are 0-255, given that the value exists in table GSMNCOS.
sheet 15 of 18
Subfield of SSVAR selector COS
411-2231-827
Standard
02.05
September 2001
C-101
Table C-15 Table GHLRSSOP field descriptions (continued) Field name Description SUPPLEMENTARY SERVICE VARIABLE DATA FOR CONNECTED LINE PRESENTATION ENTRY: NP or P EXPLANATION: The variable data for COLP consists of one area: OVR: COLP Override option. Indicates if the COLP Override option of the COLP service is provisioned. Valid entries: NP not provisioned. The CLI of the called party will be presented to the calling party, unless the called party has COLR provisioned. P provisioned. The CLI of the called party will be presented to the calling party, even if the called party has COLR provisioned. This option can only be provisioned by the operator and may not be available to all subscribers. DEFAULT: NP
Subfield of SSVAR selector COLP
Subfield of SSVAR selector ACC
SUPPLEMENTARY SERVICE VARIABLE DATA FOR ACCOUNTING CODES ENTRY: VER, NONVER, or VOL EXPLANATION: The variable data for ACC consists of two areas: PROVOPT: ACC Provisioning option. Indicates if the subscriber must enter an accounting code for each call. Valid entries: VER verification required. An account code must be provided by the subscriber. The length of the account code must match the length of the account code specified in the Length subfield. NONVER no verification required. An account code must be provided by the subscriber, but the length of the account code does not matter. VOL voluntary. The subscriber has the option of entering an account code or not entering an account code for each call. The length of the account code does not matter. LENGTH: Verify ACC length option. This subfield only occurs when using the VER option. Indicates the length of the accounting code that must be entered by the subscriber. Valid entries: 1-16 DEFAULT: NONVER
sheet 16 of 18
GSM
C-102 (contin-
Table C-15 Table GHLRSSOP field descriptions (continued) Field name Description SUPPLEMENTARY SERVICE VARIABLE DATA FOR CLOSED USER GROUP ENTRY: (ALLBSGS, BSGLIST, or $) (SPCH, AUXSPCH, FAX, CDA, or CDS) (NONE, OA, IA, ALL) (PREFCUG or NONE) (0-32767) EXPLANATION: The variable data for CUG consists of the following areas: PROVOPT: Specifies where the CUG is associated with ALL Basic Service Groups (BSGs), or only BSGs specified in this field. Valid entries: ALLBSGS All Basic Service Groups. The CUG is associated with all BSGs. When ALLBSGS is selected, the additional field FEATURE will be displayed. BSGLIST Basic Service Groups List. The CUG is only associated with the BSGs that are defined in the BSG subfield. When BSGLIST is selected the additional field FEATURE_LIST will be displayed. FEATURE_LIST: This field is composed of subfields BSG, ICA, and CI. The subfield information should be entered in a continuous string. This subfield only appears when the BSGLIST option is entered in the PROVOPT field. BSG: Basic Service Group for which this Supplementary Service is registered. Valid entries: SPCH Speech AUXSPCH Auxiliary Speech FAX Facsimile Group 3 CDA Circuit Duplex Asynchronous CDS Circuit Duplex Synchronous SMS Short Message Service ICA: Inter CUG Accessibility defines the type of access granted for a member of the CUG. Valid entries: OA Outgoing Access. The subscriber is allowed to make outgoing calls outside the CUG. IA Incoming Access. The subscriber is allowed to receive incoming calls from outside the CUG. ALL The subscriber is allowed to both make and receive calls outside the CUG. NONE The subscriber is not allowed to make or receive calls outside the CUG.
sheet 17 of 18
Subfield of SSVAR selector CUG
411-2231-827
Standard
02.05
September 2001
C-103
Table C-15 Table GHLRSSOP field descriptions (continued) Field name SSVAR (selector CUG) continued Description SUPPLEMENTARY SERVICE VARIABLE DATA FOR CUG (continued) CI: CUG Index defines if the subscriber has a preferential CUG. Valid entries: PrefCUG The subscriber has a preferential CUG. A different preferential CUG for each BSG defined, when using the BSGLIST option in the PROVOPT field. Defining a preferential CUG is useful when a subscriber is a member of more than one CUG, but uses one CUG the majority of the time. This subfield requires the additional entry of the PREFCUG number in the range of 0-32767. NONE No preferential CUG is defined for this subscriber. FEATURE: This field is composed of subfields ICA and CI. The subfield information should be entered in a continuous string. This subfield appears only when the ALLBSGS option is entered in the PROVOPT field.
Subfield of SSVAR selector EXT
EXTENSION SERVICE ENTRY: (SPCH, AUXSPCH, SMS, CDA, CDS, FAX), (M: Up to 15 digits), (G: SL or ML), (T: 5 to 90) EXPLANATION: The variable registration data for EXT consists of four areas: BSG: Basic Service Group for which this Supplementary Service is registered. Valid entries: SPCH Speech AUXSPCH Auxiliary Speech
e MSISDN of subscriber associated with the extension group. Up to 15 digits (0 to 9)
G: Group Indicator. This field specifies if the subscriber is classified as a single user or a multiple user. Valid entries: SL Single User. A busy signal is returned to the caller whenever one member of the extension group is talking on the phone. ML Multiple User. A busy signal is only returned to the caller if all members of the extension group are talking on their phones. T: Timer. This field specifies how long the phone should continue ringing before it is transferred to the next extension group member or is sent to voicemail. Valid entries: 5 to 90 seconds in 5 second increments.
sheet 18 of 18
GSM
C-104
Datafill sequence
A subscriber cannot be datafilled with supplementary service option data in the GHLRSSOP table unless that subscriber has been previously datafilled in the GHLRAUTH, GHLRDATA, and GHLRCUG tables. has an ISTATUS of D, A, or N. has the appropriate Basic Services in the table GHLRBSVC, and/or table GHLRCUG if the Basic Service Group is specified in table GHLRSSOP.
A subscriber cannot be datafilled with the Class of Service (COS) Supplementary Service in table GHLRSSOP, unless Tables GSMCUST and GSMNCOS have been previously datafilled. A subscriber must be provisioned with CLIP (but not CLIP Override) before they can be provisioned with ACRJ.
Dump and restore

Table GHLRCUG must be dumped and restored before table GHLRSSOP. Call Hold must be provisioned in order to provision ECT supplementary service. ONP GSM10 to GSM12 supports the Anonymous Call Rejection (ACRJ) service.
Example datafill
Figure C-7 shows example datafill for table GHLRSSOP using a two-digit MNC.
411-2231-827
Standard
02.05
September 2001
C-105
Figure C-7 Example datafill for table GHLRSSOP (2 digit MNC) CI: >table ghlrssop TABLE: GHLRSSOP >list 4 TOP MCC MNC MSIN SSPROV SELECTOR SSVAR
-----------------------------------------------------------------456 789 789 23 23 23 1111111 1111111 1111111 CFU CLIP ACRJ CFNRY CFU CLIP ACRJ CFNRY NF NF NONEF SPCH12345$ NP
456 23 0000001206 (SPCH61456123451234530) $
GSM
C-106
Table GHLRUSSD
Table description
Table GHLRUSSD determines how the unstructured supplementary service data (USSD) string received in a process unstructured supplementary service request (PUSSR) should be processed.
Field descriptions
Table C-16 contains field descriptions for table GHLRUSSD.
(continTable C-16 Table GHLRUSSD field descriptions Field name USSD_STR Description Unstructured Supplementary Service Data String ENTRY: Vector of 0 to 3 characters from the set { A,a,B,b} plus a 1 to 3 digit SS code EXPLANATION: This field is the key for the tuple and contains a USSD string which is mapped to a supplementary service or an operation that is supported at the HLR. When the HLR receives a USSD string in a PUSSR request, an attempt is made to match the string to one of the strings datafilled in the USSD_STR field of each tuple. Once a match is found, the rest of the fields of the tuple are used to determine the outcome. DEFAULT: N/A SSCODE SUPPLEMENTARY SERVICE CODE ENTRY: An enumerated type of supplementary service supported at HLR by the USSD. Initially, NILSS. The range of values for this field will expand as new services which use USSD are added to the HLR. EXPLANATION: This field contains a symbolic name for a service which is supported on the HLR by the USSD. DEFAULT: N/A
sheet 1 of 2
411-2231-827
Standard
02.05
September 2001
C-107
Table C-16 Table GHLRUSSD field descriptions (continued) Field name SSOPER Description SUPPLEMENTARY SERVICE OPERATION ENTRY: ACT, DEACT, INTERR, INV, REG, ERASE ACT - activation DEACT - deactivation INTERR - interrogation INV - invocation REG - register ERASE - erase
The range of values for this field will expand as new services which use USSD are added to the HLR. EXPLANATION: This field contains a valid SS operation. Each supplementary service supported by the USSD defines a set of operations which are valid for the service. The SS operation datafilled in field SSOPER must be an operation which is valid for the supplementary service specified in the SSCODE field. DEFAULT: N/A PROCSSAT PROCESSAT SUBFIELD: NODE_SEL ENTRY: hlr, gsmSCF, ExNode gsmSCF and ExNode provides a prompt for the symbolic name of that entity in the NODE_SEL field. DEFAULT: N/A SUBFIELD: NODEADDR ENTRY: Vector of 1 to 20 characters DEFAULT: N/A EXPLANATION: Datafilling this field is optional. If this field is not datafilled or datafilled with HLR, then processing of the USSD string takes place locally at the HLR.
sheet 2 of 2
GSM
C-108
Datafill sequence
Tables GHLRSCF and GHLRXTND must be datafilled before table GHLRUSSD.
Dump and restore

Dump and restore for table GHLRUSSD occurs after GHLRSCF and GHLRXTND.
Example datafill
Figure C-8 shows example datafill for table GHLRUSSD.
Figure C-8 Example datafill for table GHLUSSD CI: >table ghlrussd TABLE: GHLRUSSD>list 1 TOP USSD_STR SSCODE SSOPER PROCSSAT
-----------------------------------------------------------------AB4 B29 Y Y INV INV gsmSCF SCP_1_KEY ExNode XNTD_2_Key
411-2231-827
Standard
02.05
September 2001
C-109
Table GHLRVBCA
Table description
This table includes the supra-PLMN group IDs. A VBS subscriber can use group IDs even if the subscriber is not in the HPLMN. A group ID that is not included in table GHLRVBCA can be datafilled in table GHLRVGS against an IMSI. In this case, the group ID is assumed to be usable only within the HPLMN.
Field descriptions
Table C-17 contains field descriptions for table GHLRVBCA.
(continTable C-17 Table GHLRVBCA field descriptions Field name GRPID Description GROUP IDENTIFICATION ENTRY: Vector of 6 BCDs EXPLANATION: Identifies the group ID of a group, to which the VBS subscriber can initiate a call also in case of roaming out of the HPLMN. It is the key to the table. DEFAULT: N/A
Datafill sequence
Not applicable
Dump and restore

Activation
Immediate
Example datafill
Figure C-9 shows an example of datafill for table GHLRVBCA.
C-110
Figure C-9 Example of datafill for table GHLRVBCA
TABLE: GHLRVBCA > lis 6 GRPID -------------------123 125 13 2 455 654
Error messages
The following error message occurs when a group ID with more than 3 digits is added to table GHLRVBCA:
A VBS group ID with a maximum of 3 digits must be datafilled.
The following error message occurs when a NIL tuple ($) is added to table GHLRVBCA:
ERROR IN ADDING DATA
411-2231-827
Standard
02.05
September 2001
C-111
Table GHLRVGCA
Table description
This table includes the supra-PLMN group IDs. A VGCS subscriber can use group IDs even if the subscriber is not in the HPLMN. A group ID that is not included in table GHLRVGCA can be datafilled in table GHLRVGS against an IMSI. In this case, the group ID is assumed to be usable only within the HPLMN.
Field descriptions
Table C-18 contains field descriptions for table GHLRVGCA.
(continTable C-18 Table GHLRVGCA field descriptions Field name GRPID Description GROUP IDENTIFICATION ENTRY: Vector of 6 BCDs EXPLANATION: Identifies the group ID of a group, to which the VBS subscriber can initiate a call also in case of roaming out of the HPLMN. It is the key to the table. DEFAULT: N/A
Datafill sequence
Not applicable
Dump and restore

Activation
Immediate
Example datafill
Figure C-10 shows an example of datafill for table GHLRVGCA.
C-112
Figure C-10 Example of datafill for table GHLRVGCA
TABLE: GHLRVGCA > lis 6 GRPID -------------------123 125 13 2 455 654
Error messages
The following error message occurs when a group ID with more than 3 digits is added to table GHLRVBCA:
A VGCS group ID with a maximum of 3 digits must be datafilled.
The following error message occurs when a NIL tuple ($) is added to table GHLRVBCA:
ERROR IN ADDING DATA
411-2231-827
Standard
02.05
September 2001
C-113
Table GHLRVGS
Table description
Table GHLRVGS holds the information related with VBS/VGCS provisioning details. The key of the table consists of the IMSI of a subscriber and the VBS/VGCS service with which the subscriber is provisioned.
If a subscriber is provisioned with both VBS and VGCS, two tuples exist for each service. Each tuple holds the group IDs for a VBS/VGCS subscriber. The group IDs indicate the groups to which the subscriber is authorized to initiate a call. A boolean (Y/N) indicates if the subscriber can use the VBS/VGCS in case of roaming out of the HPLMN or not. Each subscriber can be datafilled with up to 50 group IDs for each service. The group IDs consist of between 1 and 3 BCD digits. For VBS only, a boolean (Y/N) also is collocated with each group ID. This boolean identifies if the subscriber is actually entitled to initiate a call to that group or not. Creating a tuple for VBS/VGCS in table GHLRVGS is allowed only for subscribers that previously have been datafilled with the same BS in table GHLRBSVC.
GSM
C-114
Field descriptions
Table C-19 contains field descriptions for table GHLRVGS.
(continTable C-19 Table GHLRVGS field descriptions Field name MCC Description MOBILE COUNTRY CODE ENTRY: Table of 3 BCDs EXPLANATION: Identifies the country where the PLMN resides. This field is a part of the tables key. DEFAULT: N/A MNC MOBILE NETWORK CODE ENTRY: Vector of up to 3 BCDs. EXPLANATION: Identifies a PLMN. Together with the MCC and MSIN, it uniquely identifies a mobile subscriber, independent of location and equipment. The MNC must be in accordance with office parameter GHLR_IMSI_MNC in table OFCSTD in order to be accepted. This field is a part of the tables key. DEFAULT: N/A MSIN MOBILE STATION IDENTIFICATION NUMBER ENTRY: Vector of up to 3 BCDs. EXPLANATION: Specifies the subscriber portion of the IMSI. Together with the MCC and MNC, it uniquely identifies a mobile subscriber, independent of location and equipment. This field is a part of the tables key. DEFAULT: N/A VGBS VOICE GROUP BASIC SERVICE ENTRY: VBS, VGCS EXPLANATION: Identifies the voice group basic service (either VBS or VGCS), to which the subscriber is registered. This field is a part of the tables key. DEFAULT: N/A
sheet 1 of 2
411-2231-827
Standard
02.05
September 2001
C-115
Table C-19 Table GHLRVGS field descriptions (continued) Field name HROAM Description HLPMN ROAMING ENTRY: Y, N EXPLANATION: Identifies if the VBS/VGCS subscriber also can use VBS/ VGCS in case the subscriber roams outside of the HPLMN. DEFAULT: N/A SELECTOR SELECTOR ENTRY: VBS, VGCS EXPLANATION: Acts a selector for the basic service to which the subscriber is registered. It determines the content of the GRPINFO field. The voice group basic service datafilled in the fields VGBS and SELECTOR must be the same. DEFAULT: N/A GRPINFO GROUP INFORMATION ENTRY: REFINEMENTS: {VBS} VECTOR OF UP TO 50 MULTIPLES WITH GRP VECTOR OF UP TO 3 BCDs ORIGINATION_ENTITLEMENT {Y,N} {VGCS} VECTOR OF UP TO 50 VECTORS OF UP TO 3 BCDs EXPLANATION: Contains the data about the groups, to which the VBS/ VGCS subscriber can initiate a call. DEFAULT: N/A
sheet 2 of 2
Datafill sequence
Datafill table GHLRBSVC before datafilling this table.
GSM
C-116
Dump and restore

Table GHLRVGS must be dumped and restored after tables GHLRBSVC.
Example datafill
Figure C-11 shows an example of datafill for table GHLRVGS.
Figure C-11 Example datafill for table GHLRVGS
TABLE:GHLRVGS >lis 2 MCCiii MNC MSIN VGBS HROAM SELECTOR GRPINFO -------------------------------------------------------------------------------VBS Y 456 23 0000001206 VBS ( 125 Y) ( 236 Y ) ( 456 N )$ VGCS 456 23 0000001206 VGCS Y ( 121 ) ( 341 ) ( 344 ) ( 456 ) ( 621 ) ( 901 )$
Warning/error messages
The Mated Pair Disaster Standby functionality does not change this table or fields but does add warning and error messages. The following paragraphs describe why the warning/error messages are produced. Also, an example of the warning/error message is given. When the subscribers ASTATUS is set to STANDBY in table GHLRDATA, the STANDBY_MODE is set to ACITIVE and the subscriber is set to MAINTBLOCKED in MAPCI. Any change produces the following message.
Warning: IMSI is a standby IMSI. All table control changes for this subscriber are only guaranteed to be retained while the subscriber remains in the standby-blocked state. To maintain data synchronization with the acting mate subscriber, synchronize the acting subscriber using the SUBMNG MAP level following the removal of the standby-blocked state from this subscriber
If an add, change, or delete occurs for a subscriber in the default partition, the following message displays stating that the subscriber will be assigned to the home partition.
Warning: This table control operation will result in IMSI <IMSI number> being assigned to the HOME partition
411-2231-827
Standard
02.05
September 2001
C-117
If an add, change, or delete occurs for a subscriber in the default partition, the following message displays stating that the subscriber SIMR mate IMSI will be assigned to the home partition.
Warning: This table control operation will also result in SIMR mate IMSI <IMSI number> being assigned to the HOME partition
If unable to get the propagation status for a particular imsi, then the following message displays.
ERROR: Unable to get propagation status for IMSI
GSM
C-118
Table GHLRVLR
This table is used to support the following GSM-R functionalities: eMLPP
Table description
Table GHLRVLR contains information about VLRs with which the DMS-HLR communicates. A VLR is added to this table in one of the following ways: updates the application context for requester MAP messages between the HLR and the VLR node. This occurs when the HLR is required to change the application context to a different version than that recorded against the node. adds node to the table when the HLR receives a UL request from a VLR that is not recorded in the HLR.
The version stored for the application context in GHLRVLR may not exceed that stored in GHLRPARM. When a VLR is added via Update Location, the default OM_ID value is used. This corresponds to the OM key of value zero. This value is reserved for this purpose. When there is a change to the tuple, a unique OM_ID other than zero must be specified. In table GHLRVLR, VLRs are listed according to their address, which is an E.164 international number. Table GHLRVLR also includes the version of supported messages. Each tuple contains the VLR address and reset status. The reset status displayed in the table refers to the HLR reset operation. Only the NEED_NOT_NOTIFY state is entered at table control; all other values are read-only. This refers to the stage of reset of the VLR with respect to the DMS-HLR. GHLRVLR includes the NUS_AC and EVAL_NUS fields which store the highest AC version currently supported by the HLR and VLR.
411-2231-827
Standard
02.05
September 2001
C-119
Field descriptions
Table C-20 contains field descriptions for table GHLRVLR.
(continTable C-20 Table GHLRVLR field descriptions Field name VLRADDR Description VISITOR LOCATION REGISTER ADDRESS ENTRY: Up to 15 digits in length each digit having a range of 0-9. EXPLANATION: This key field contains VLR address in the form of an MSISDN number. DEFAULT: N/A RSTATUS RESET STATE ENTRY: Up to 17 characters EXPLANATION: This field uses the following settings to determine the VLR reset state: NEED_NOT_NOTIFY no notification is required. The only option that can be manually entered. AWAITING_RETRY the DMS-HLR in a waiting-to-renotify-VLR state. This option is entered automatically by the system. READY_TO_NOTIFY the VLR is ready to be notified of a DMS-MSC/ HLR reset.This option is entered automatically by the system. AWAITING_RESPONSE the DMS-HLR is awaiting a response from the VLR. This option is entered automatically by the system. NOTIFY_OK the VLR was successfully notified of an HLR reset. This option is entered automatically by the system. NOTIFY_FAILED the VLR was not notified of an HLR reset. This option is entered automatically by the system. ATTEMPT_FAILED an attempted VLR notification failed. This option is entered automatically by the system.
DEFAULT: NEED_NOT_NOTIFY
sheet 1 of 9
GSM
C-120 (contin-
Table C-20 Table GHLRVLR field descriptions (continued) Field name LC_AC Description LOCATION CANCELLATION APPLICATION CONTEXT VERSION ENTRY: HLR_MAX, V1, V2, V3 EXPLANATION: The LC_AC (Location Cancellation Application Context) field contains the version used by the DMS-HLR for this VLR. The version chosen cannot be higher than the one supported by the DMS-HLR. HLR_MAX the highest LC_AC version supported by the DSM-HLR will be used V1 V1 LC_AC version will be used V2 V2 LC_AC version will be used V3 - V3 LC_AC version will be used
DEFAULT: HLR_MAX EVAL_LC EVALUATE LOCATION CANCELLATION APPLICATION CONTEXT FLAG ENTRY: N, Y EXPLANATION: This field indicates if the LC_AC (Location Cancellation Application Context) version is required to be updated to the latest common (highest) version supported by both the VLR and DMS-HLR. Y update the LC_AC to the highest and most recent version that is supported by both the VLR and the DMS-HLR N do not update the LC_AC version
DEFAULT: Y
sheet 2 of 9
411-2231-827
Standard
02.05
September 2001
C-121
Table C-20 Table GHLRVLR field descriptions (continued) Field name RNE_AC Description ROAMING NUMBER ENQUIRY APPLICATION CONTEXT VERSION ENTRY: HLR_MAX, V1, V2, V3 EXPLANATION: This field contains the version of the RNE_AC (Roaming Number Enquiry Application Context) used by the DMS-HLR for this VLR. The version number cannot be higher than the one supported by the DMSHLR. HLR_MAX uses the highest RNE AC version supported by the DSMHLR V1 use V1 RNE AC version V2 use V2 RNE AC version V3 use V3 RNE AC version
DEFAULT: HLR_MAX EVAL_RNE EVALUATE ROAMING NUMBER ENQIRY APPLICATION CONTEXT FLAG ENTRY: N, Y EXPLANATION: This field indicates if the RNE_AC (Roaming Number Enquiry Application Context) version is required to be updated to the latest common (highest) version supported by both the VLR and DMS-HLR. Y update the RNE AC to the highest and most recent version that is supported by both the VLR and the DMS-HLR N do not update the RNE AC version
DEFAULT: Y RST_AC RESET APPLICATION CONTEXT VERSION ENTRY: HLR_MAX, V1, V2 EXPLANATION: This field contains the version of RST AC (Reset Application Context) used by the DMS-HLR for this VLR. The version number cannot be higher than the one supported by the DMS-HLR. HLR_MAX indicates that the highest RST AC version supported by the DSM-HLR will be used V1 indicates that V1 RST AC version will be used V2 indicates that V2 RST AC version will be used
DEFAULT: HLR_MAX
sheet 3 of 9
GSM
C-122 (contin-
Table C-20 Table GHLRVLR field descriptions (continued) Field name EVAL_RST Description EVALUATE RESET APPLICATION CONTEXT FLAG ENTRY: N, Y EXPLANATION: This field indicates if the RST AC (Reset Application Context) version is required to be updated to the latest common higher version supported by both the VLR and DMS-HLR. Y update the RST AC to the highest and most recent version that is supported by both the VLR and the DMS-HLR N do not update the RST AC version
DEFAULT: Y SDM_AC SUBSCRIBER DATA MANAGEMENT APPLICATION CONTEXT VERSION ENTRY: HLR_MAX, V1, V2, V3 EXPLANATION: This field contains the version of the SDM AC (Subscriber Data Management Application Context) used by the DMS-HLR for this VLR. This field is automatically updated by the DMS-HLR to the same version used by the Network Update Location (NLU) Application Context (AC) received from the VLR. HLR_MAX uses the highest SDM AC version supported by the DSMHLR V1 use V1 SDM AC version V2 use V2 SDM AC version V3 use V3 SDM AC version
DEFAULT: HLR_MAX
sheet 4 of 9
411-2231-827
Standard
02.05
September 2001
C-123
Table C-20 Table GHLRVLR field descriptions (continued) Field name SIE_AC Description SUBSCRIBER INFORMATION ENQUIRY VERSION ENTRY: HLR_MAX, V3 EXPLANATION: This field contains the version of SIE_AC used by the HLR for this VLR. The version chosen must be one that is supported at the HLR. The range of acceptable values by table control are HLR_MAX indicates that the highest SIE_AC version supported by the DSM-HLR will be used V3 indicates that V3 SIE_AC version will be used
DEFAULT: HLR_MAX EVAL_SIE EVALUATE SUBSCRIBER INFORMATION ENQUIRY FLAG ENTRY: N, Y EXPLANATION: This field indicates if the SIE AC version requires updating to the latest common highest version supported by both VLR and HLR. This field is periodically reset by the AC to Y. Y - update the SIE AC to the latest common highest version supported by both the VLR and the HLR. N - do not change the SIE AC version.
DEFAULT: Y NUS_AC Network Unstructured Application Context Version ENTRY: HLR_MAX, V2 EXPLANATION: This field contains the version of NUS AC used by the HLR for this VLR. The version chosen cannot be higher than the one supported by the HLR. HLR_MAX is defined by the HLR parameter AC_MAX_V in table GHLRPARM. DEFAULT: HLR_MAX
sheet 5 of 9
GSM
C-124 (contin-
Table C-20 Table GHLRVLR field descriptions (continued) Field name EVAL_NUS Description Evaluate Network Unstructured Application Context Flag ENTRY: Y, N EXPLANATION: This field contains the evaluate NUS AC flag. This indicates whether the NUS_AC version needs to be updated to the last common highest version supported by both the HLR and the VLR. This field is periodically reset by AC_AUDIT to Y. DEFAULT: Y TRC_AC TracingContext Application Context ENTRY: HLR_MAX, V1, V2, V3 EXPLANATION: This field stores the current application context of the described parameter for the associated VLR and must be set to the same version NLU_AC contained in the table. HLR_MAX - version is taken directly from that stored in GHLRPARM for TRC_AC. V1, V2, V3 - currently supported version number of TracingContext for the VLR in question.
DEFAULT: HLR_MAX
sheet 6 of 9
411-2231-827
Standard
02.05
September 2001
C-125
Table C-20 Table GHLRVLR field descriptions (continued) Field name AC_AUDIT Description APPLICATION CONTEXT AUDIT OPTION ENTRY: ENABLED, DISABLED EXPLANATION: This field specifies if the internal application context (AC) version audit sets the evaluate flags to Y and the value of the AC field (NUS_AC) to HLR_MAX for an individual VLR. The internal flag controls whether the DMS-HLR will perform context negotiation with the VLR. ENABLED the EVAL_LC, EVAL_RNE, EVAL_RST, EVAL_SIE, EVAL_NUS flags are set to Y and LC_AC, RNE_AC, RST_AC, SIE_AC, and NUS_AC is set to HLR_MAX during the internal AC version audit. During the next communication with the VLR, the DMS-HLR will perform context negotiation with the VLR to determine what AC version is supported by each node. If the DMS-HLR and the VLR both support V2, the AC version is set at V2. If the DMS-HLR and the VLR both support V3, the AC version is set at V3. If either the DMS-HLR or the VLR do not support V2 or V3, then the AC version will be set to V1. DISABLED prevents the audit changing the evaluate AC flags. AC_AUDIT also sets the AC versions associated with the evaluate flags to HLR_MAX (LC_AC, RNE_AC, RST_AC, SIE_AC and NUS_AC). DEFAULT: ENABLED
sheet 7 of 9
GSM
C-126 (contin-
Table C-20 Table GHLRVLR field descriptions (continued) Field name OM_ID Description OPERATIONAL MEASUREMENTS IDENTIFIER ENTRY: 0-999 EXPLANATION: This field contains the key used to peg any OMs for operations associated with this VLR. When a VLR is added via Update Location, the default OM_ID value is used. This corresponds to the OM key of value zero. This value is reserved for this purpose. When there is a change to the tuple, a unique OM_ID other than zero must be specified. The OM_ID identifies the key to use when pegging OMs for the following OM groups: HCISSOPS HVLRSMGT GHLRMMGT
When adding an OM_ID value, the operator must specify a unique value. Each VLR must be assigned a unique OM_ID value. Default: 0
sheet 8 of 9
411-2231-827
Standard
02.05
September 2001
C-127
Table C-20 Table GHLRVLR field descriptions (continued) Field name VLR-ID Description VLR IDENTIFICATION ENTRY: 0-4000 EXPLANATION: Identifies VLRs datafilled in GHLRVLR and is the key used to peg any OMs for operations associated with a particular VLR. There is a unique VLR-ID for each VLR in the table. When a VLR is added to table GHLRVLR, the VLR-ID field is automatically updated to a non-zero value that is unique within the table. When a VLR is manually added, operating company personnel must enter a value of zero for the VLR-ID field. When a VLR is deleted from the table, its status is amended to temporary deleted status and becomes invisible to operating company personnel via Table Control. The tuple is permanently deleted when the GHLRVLR Table Audit processes the table or when the CLEARVLRS command is executed. The VLR-ID field value cannot be modified by operating company personnel. DEFAULT: Unique value within the table assigned automatically.
sheet 9 of 9
Datafill sequence
Tables GHLRPARM and GHLRPCC must be datafilled before datafilling GHLRVLR.
Dump and restore

The dump and restore mechanism is supported across the following releases: GSM09 to GSM11 GSM10 to GSM11 GSM11 to GSM11
In the GSM09 and GSM10 to GSM11 scenarios, CAMLSUPT assumes the default value of PHASE_1.
Example datafill
Figure C-12 shows example datafill for table GHLRVLR.
GSM
C-128
Figure C-12 Example datafill for table GHLRVLR CI: >table ghlrvlr TABLE: GHLRVLR >count BOTTOM SIZE = 1 >list all TOP VLRADDR RSTATUS LC_AC EVAL_LC RNE_AC EVAL_RNE RST_AC EVAL_RST SDM_AC SIE_AC EVAL_SIE EVAL_NUS NUS_AC TRC_AC AC_AUDIT CAMLSUPT VLRID --------------------------------------------------------------------614170100000 NOTIFY_OK HLR_MAX HLR_MAX HLR_MAX Y Y V3 Y V3 N V2 PHASE_2 ENABLED N V2 HLR_MAX
411-2231-827
Standard
02.05
September 2001
C-129
Table GHLRXTND
Table description
Table GHLRXTND associates a symbolic name with the actual E164 network address of an external node. It also implements additional fields to record the highest common version supported by the HLR and external node for the network unstructured (NUS) application context. This information determines which version of the application context (AC) to use when establishing a dialogue when the HLR initiates a service request to the external node.
Field descriptions
Table C-21 contains field descriptions for table GHLRXTND
(continTable C-21 Table GHLRXTND field descriptions Field name XTND_NAME Description SYMBOLIC EXTERNAL NODE ADDRESS NAME ENTRY: (1 to 20) alphanumeric characters or underscores EXPLANATION: This field holds the symbolic names of various external node addresses. DEFAULT: N/A XTND_NUMBER EXTERNAL ADDRESS ENTRY: Vector of up to 15 {0 TO 9}s (E164 address for the external node) EXPLANATION: This field contains the corresponding E164 address of the external node whose symbolic name is contained in the XTNDNAME field. DEFAULT: N/A
sheet 1 of 2
GSM
C-130 (contin-
Table C-21 Table GHLRXTND field descriptions (continued) Field name NUS_AC Description Network Unstructured Application Context Version ENTRY: HLR_MAX, V2 EXPLANATION: This field contains the version of NUS AC used by the HLR for this external node. The version chosen cannot be higher than the one supported by the HLR. HLR_MAX is defined by the HLR parameter AC_MAX_V in table GHLRPARM. DEFAULT: HLR_MAX EVAL_NUS Evaluate Network Unstructured Application Context Flag ENTRY: Y, N EXPLANATION: This field contains the evaluate NUS AC flag. This indicates whether the NUS_AC version needs to be updated to the last common highest version supported by both the HLR and external node. This field is periodically reset by AC_AUDIT to Y. DEFAULT: Y AC_AUDIT APPLICATION CONTEXT AUDIT OPTION ENTRY: ENABLED, DISABLED EXPLANATION: This field specifies whether the internal application context (AC) version audit sets the evaluate flags to Y and the value of NUS_AC to HLR_MAX for an individual external node. The internal flag controls whether the DMS-HLR will perform context negotiation with the external node. ENABLED allows
the evaluate AC flags to be set to Y by the audit and NUS_AC to be set to HLR_MAX. DISABLED prevents the audit from changing the evaluate AC flags.
DEFAULT: ENABLED
sheet 2 of 2
Datafill sequence
A symbolic address for an external node must be datafilled in table GHLRXTND before it can be used in table GHLRUSSD.
411-2231-827
Standard
02.05
September 2001
C-131
Dump and restore

Dump and restore using the dump and restore mechanism.
Example datafill
Figure C-13 shows example datafill for table GHLRXTND.
Figure C-13 Example datafill for table GHLXTND CI: >table ghlrxtnd TABLE: GHLRXTND>list 2 TOP XTND_NAME XTND_NUMBER NUS_AC EVAL_NUS AC_AUDIT
---------------------------------------------------------------------------------------------------------------------------XTND_MAIN ALTERNATE 4595635649 7621235684 V2 HLR_MAX Y Y ENABLED DISABLED
GSM
C-132
Table LACGID
Table description
This table is used to retrieve the GCA digits datafilled against a LAC+CID+GID combination. Table LACGID is indexed by the multi-part key combination of LAC+CID+GID.
Field descriptions
Table C-22 describes the fields in table LACGID.
Table C-22 Table LACGID field descriptions Field name LAC Description LOCATION AREA CODE Entry: 0 to 65535 Explanation: Specifies the location area in which the mobile is
roaming at a given time.
CID
CELL IDENTITY Entry: 0 to 65535 Explanation: Specifies a cell within a location area.
GID
GROUP IDENTIFICATION Entry: A vector of up to 6 digits {0 to 9}s Explanation: Specifies the string of digits dialed by a service subscriber to initiate a group call. The length of this field must be the same as indicated by office parameter GID_DIGITS_LENGTH.
GCA
GROUP CALL AREA Entry: A vector of up to 7 digits {0 to 9}s Explanation: Specifies the group call area ID digits.
411-2231-827
Standard
02.05
September 2001
C-133
Datafill sequence
Before table LACGID is datafilled, the following tables must be datafilled: table GCAREA table GCR
Dump and restore

Not applicable
Activation
Immediate
Example tuple
Following is an example of an example tuple:
12 1 123 88779
GSM
C-134
Table PETSERVS
This table is used to support the following GSM-R functionalities: Access Matrix
Table description
Table PETSERVS is used for defining a group of services for an individual PSTN Enhanced Trunk (PET) trunk group defined in table TRKGRP. The services are set up in a PETSERVS tuple, then bound to a PET trunk group by datafilling the key to the PETSERVS tuple in field SERV_IDX in table TRKGRP. In table PETSERVS, option AMSCRN assigns an Access Matrix check to an incoming PET trunk. If the AMSCRN option is datafilled on a trunk, the Access Matrix functionality is applied to it. The check is based on the Access Matrix that is datafilled in table ACSMTRX. The check determines if a call between two parties, identified by their Functional Number, is allowed or not.
Field descriptions
Table C-23 describes the fields in table PETSERVS.
Table C-23 Table PETSERVS field descriptions Field name KEY Description INDEX ENTRY: 0 to 63 EXPLANATION: This is the index for each tuple. This field is mandatory and must match the corresponding index field from subfield SERV_IDX of field GRPINFO in table TRKGRP . OPTION SERVICES OPTIONS ENTRY: Vector of up to 64 multiples with {AOC,PCOS,CUGMEM,CUGOPT,CLISCRN, MCID,CUSTINFO, PARTIAL_DNSCRN, AMSCRN} and refinements EXPLANATION: All service specific information is contained in this field. Each index (tuple) can be datafilled with numerous services. This is an optional field. OPTION fields are described in Table C-24 on page Table C24-135.
411-2231-827
Standard
02.05
September 2001
C-135
Table C-24 describes the OPTION fields for table PETSERVS.

Table C-24 Table PETSERVS OPTION field descriptions Option Name CUGMEM Description CLOSED USER GROUP MEMBERSHIP ENTRY: Enter 1 to 32 CUGMEM with the following refinements: CUGINDEXIndex of the CUG ENTRY: Integer from 0 to 31 ICBOCBA string range describing the intra-CUG calling restrictions. ENTRY: NONEno inter-CUG restrictions ICBIncoming Calls Barred OCBOutgoing Calls Barred BOTHboth ICB and OCB INICInternational Network Identification Code. ENTRY: 4 digits INTERLOCKA network-specific interlock code to which the CUG index maps. ENTRY: 4 digits and a number between 0 and 65535 EXPLANATION: Describes the services for each CUG membership. Between 1 and 32 Closed User Group (CUG) memberships are supported.
sheet 1 of 5
GSM
C-136
Table C-24 Table PETSERVS OPTION field descriptions (continued) Option Name CUGOPT Description CUG SUBSCRIPTION OPTIONS ENTRY: Enter zero or one CUGOPT option with the following refinements: IAOAThe inter-CUG calling access for this basic service. ENTRY: NONE, IA, OA, BOTH NONEno inter-CUG access IAIncoming Access OAOutgoing Access BOTHboth IA and OA CUG_OPTIONCUG options. The only available option is the preferential CUG option. ENTRY: PREFCUG Refinement: PREFINDEX - Integer from 0 to 31. Must be a previously defined CUG index. EXPLANATION: Optional CUG information that applies to each CUG subscription. PCOS PRIORITY CLASS OF SERVICE ENTRY: NOPRTY, PRIORITY EXPLANATION: Describes a priority class of services for PET trunk groups. When set to PRIORITY (the default), prioritized users have privileged access to the telephone system when a catastrophe condition is activated by operating company personnel. When set to NOPRTY, calls are not allowed on this truck group when a catastrophe condition is activated. Note: PRI originating emergency calls, as determined in Universal translations using the CLASS option, are treated as priority even if the trunk group is marked as non-priority.
sheet 2 of 5
411-2231-827
Standard
02.05
September 2001
C-137
Table C-24 Table PETSERVS OPTION field descriptions (continued) Option Name AOC Description ADVICE OF CHARGE ENTRY: Multiple with AOCDEnable or disable AOC-D ENTRY: N, Y AOCEEnable or disable AOC-E ENTRY: N, Y OIDXAssign an originator discount class to the PRI trunk ENTRY: NONE, or 1 to 511 AOCRELRelease calls if the AOC service cannot be provided ENTRY: N, Y AOCCHGOVSpecify whether tariff/discount changeovers should affect active calls ENTRY: N, Y MDI: 0 to 1023 Metering data index EXPLANATION: This option is used for PRI trunks only. Both AOC-D and AOC-E can be subscribed independently of each other or also both of them at the same time. If neither AOC-D nor AOC-E is subscribed, the AOC option is not displayed in the PETSERVS tuple. CLISCRN CALLING LINE IDENTIFICATION SCREENING REFINEMENT: SCRNTYPE ENTRY: WHITELIST, BLACKLIST EXPLANATION: Triggers CLI screening on all incoming calls on the labeled trunk. Use this option to screen indirect access subscribers in conjunction with the indirect access subscriber database in table DNSCRN. The field SCRNTYPE selects the screening method, white list or black list screening.
sheet 3 of 5
GSM
C-138
Table C-24 Table PETSERVS OPTION field descriptions (continued) Option Name MCID Description MALICIOUS CALL IDENTIFICATION REFINEMENT: UNANS ENTRY: N, Y EXPLANATION: Indicates whether or not all unanswered calls are registered for MCID. CUSTINFO CUSTOMER GROUP INFORMATION ENTRY: See subfields EXPLANATION: This option consists of subfields CUSTOMER_GROUP , XLASYS, and XLANAME. It is used to associate one of the defined customer groups with an entry point into translations (XLASYS and XLANAME). Up to 5 CUSTINFO options can be entered in one PETSERVS tuple. This allows for the provisioning of 5 different entry points into translations, based on the class (that is, customer group provisioned in table DNSCRN for the given CLI) of the subscriber. Note: The CUSTINFO processing is invoked only if the CLISCRN processing has completed successfully (that is, CLISCRN passes, or the CLISCRN option was not datafilled in table PETSERVS). In other words, the CLISCRN Blacklist/Whitelist screening always takes precedence over the CUSTINFO based screening. CUSTOMER_GROU P CUSTOMER GROUP ENTRY: NIL, REG, UNREG, BLOCK, UNPAID, PRESEL EXPLANATION: Identifies the customer group with which the entry point into translations should be associated. Customer groups are: NIL REG - registered subscribers UNREG - unregistered subscribers BLOCK - blocked subscribers UNPAID - unpaid subscribers PRESEL - preselected subscribers
sheet 4 of 5
411-2231-827
Standard
02.05
September 2001
C-139
Table C-24 Table PETSERVS OPTION field descriptions (continued) Option Name XLASYS Description TRANSLATION SYSTEM ENTRY: NIL, AC, PX, CT, FA, OFC, AM, FT, NSC EXPLANATION: Defines the translations system in which the translations begin. It must first be datafilled in the appropriate xxHEAD tables of the selected system. XLANAME TRANSLATOR NAME ENTRY: Alphanumeric EXPLANATION: Identifies the translation sub-table name. The XLANAME is used as the key into table XXHEAD, and as the first part of the two-part key into the translations tables XXCODE and XXRTE. PARTIAL_DNSCRN PARTIAL DIRECTORY NUMBER SCREENING ENTRY: This option has no subfields associated with it. EXPLANATION: Enables partial screening in table DNSCRN. (The PARTIAL_DNSCRN option applies to both the CUSTINFO screening and the CLISCRN functionality.) When PARTIAL_DNSCRN is enabled, an iterative search is performed in the DNSCRN table. Each iteration searches the DNSCRN table with one less digit (the last digit is removed) from the CLI. The search continues until a match is found, or there are no digits remaining in the CLI. Note: The PARTIAL_DNSCRN functionality affects only CUSTINFO and CLISCRN screening. Therefore, this option in table PETSERVS takes effect only when PARTIAL_DNSCRN or CLISCRN is provisioned.
sheet 5 of 5
Datafill sequence
Table PETSERVS must be datafilled after the translations tables to allow the XLASYS and XLANAME fields to be populated.
Dump and restore

Not applicable
Activation
Immediate
C-140
Example tuple
Following is an example of a tuple from table PETSERVS.
1 AMSCRN
411-2231-827
Standard
02.05
September 2001
C-141
Table PETSIG
This table is used to support the following GSM-R functionalities: NOA Format Customization
Table description
Table PETSIG specifies ITU-ISUP signaling options on PSTN Enhanced Trunk (PET) trunks. Each tuple in table PETSIG can contain a combination of signaling options. A signaling option can appear only once in a tuple. Each tuple in table PETSIG corresponds to an index obtained from subfield SIG_IDX of field GRPINFO in table TRKGRP. This creates a one to one relationship between table TRKGRP and table PETSIG.
Field descriptions
Table C-25 describes the fields for table PETSIG.
Table C-25 Table PETSIG field descriptions Field name KEY Description INDEX ENTRY: 0 to 63 EXPLANATION: This is the index for each tuple. This is a mandatory field. OPTIONS SIGNALING OPTIONS ENTRY: OVLP SEND_GNI, SEND_RNN, SEND_SPC, CPC_FAIL, , CPC_REQ, CGN_HEX, CDN_HEX, RDI_LEN, PRE_INTL_NOA, ST, DELAY, PREFERRED_NOA EXPLANATION: All signaling specific information is contained within this field. For each index (tuple), enter one or more signaling options and refinements, if any. This is an optional field.
sheet 1 of 8
GSM
C-142
Table C-25 Table PETSIG field descriptions (continued) Field name (continOVLP OVERLAP OUTPULSING ENTRY: Multiple with OVLP_OUT ENTRY: N, Y EXPLANATION: Indicates if overlap outpulsing is supported or not. NUMBER_OF_DIG ENTRY: 1 to 24 EXPLANATION: Indicates the maximum number of digits carried by the ISUP Initial Address Message (IAM) if overlap outpulsing is not supported. If OVLP_OUT boolean is set to N and NUMBER_OF_DIG received is more than the datafilled value, only the specified NUMBER_OF_DIG is included in the outgoing IAM. SEND_GNI SEND GENERIC NOTIFICATION INDICATOR PARAMETER ENTRY: No refinement. EXPLANATION: This option allows the specified trunk group to generate the ISUP Generic Notification Indicator parameter. Generic Notification enables supplementary services to transfer a notification indicator to indicate an event which has occurred as the result of service invocation.The Generic Notification parameter is generated by a user or inside the network where the relevant service is invoked. The content of the notification indicator is passed unchanged inside the network and delivered to the user. SEND_RNN SEND REDIRECTION NUMBER ENTRY: No refinement. EXPLANATION: This option allows the ISUP Redirection Number (RNN) parameter to be sent in a Release (REL) message. The RNN parameter is information sent in the backward direction indicating whether a user to which a call is diverted allows the presentation of his number. Note: RNN is a national parameter in a REL message and should not be sent on a ISUP international interface or a national gateway. If the SEND_RNN option is not present in the tuple, the RNN is not sent.
sheet 2 of 8
Description
411-2231-827
Standard
02.05
September 2001
C-143
Table C-25 Table PETSIG field descriptions (continued) Field name SEND_SPC Description SEND SIGNALING POINT CODE ENTRY: No refinement. EXPLANATION: This option allows the ISUP Signalling Point Code (SPC) parameter to be sent in a Release (REL) message. The SPC parameter allows the originating exchange to determine at which node a call failed. The SPC parameter is included in a REL message when the DMS-MSC is the originating as well as the transit node for the SPC. Note: The SPC is a national parameter and should not be sent on a ISUP international interface or a national gateway. If the SEND_SPC option is not present in the tuple, the SPC is not sent. CPC_FAIL CALLING PARTY CATEGORY FAILURE OPTIONS ENTRY: Multiple with CPC_FAIL_OPTION ENTRY: NOCONT, CONT EXPLANATION: This option determines what action to take if the request for CPC fails or the value of CPC_REQ prevents the request being initiated. The DMS-MSC generates this request when receiving an invalid value in the IAM (CPC is known). Actions are NOCONT If there is not a valid CPC returned in an INF message or if the value of CPC_REQ prevents the request being initiated, the call is taken down. If a CPC is not received in the IAM and any subsequent requests for it fail, the call is allowed to continue.
If the CPC is not available, then the Information Indicator in the INF message is set to calling partys category not included.
sheet 3 of 8
GSM
C-144
Table C-25 Table PETSIG field descriptions (continued) Field name CPC_REQ Description REQUEST CALLING PARTY CATEGORY ENTRY: Multiple with CPC_REQ_GENERATED ENTRY: ALWAYS, ALLOWED, NEVER EXPLANATION: This option chooses the action to take if the Calling Party Category (CPC) is not received in the incoming Initial Address Message (IAM), or a request for CPC is received. Actions are ALWAYSIf the CPC is not received in the IAM, a request for the CPC is generated and sent to the preceding node. Subsequent requests from the Terminating Trunk are also allowed to proceed to the previous node. ALLOWEDIf the CPC is not received in the IAM, no action is taken. However, if a request is received from the Terminating Trunk for the CPC, it is allowed to proceed to the previous node. NEVERUnder no circumstances is a request for the CPC allowed to be made to the previous node.
CGN_HEX
CALLING PARTY ADDRESS HEX DIGITS ENTRY: Multiple with HEX_DIGIT_OPT ENTRY: Multiple of up to 4 of B, C, D, E EXPLANATION: This option indicates what digits (other than the default 0 to 9 digits) are supported for calling party addresses. At least one and no more than 4 unique digit option(s) must be entered for each address option.
CDN_HEX
CALLED PARTY ADDRESS HEX DIGITS ENTRY: Multiple with HEX_DIGIT_OPT ENTRY: Multiple of up to 4 of B, C, D, E EXPLANATION: This option indicates what digits (other than the default 0 to 9 digits) are supported for called party addresses. At least one and no more than 4 unique digit option(s) must be entered for each address option.
sheet 4 of 8
411-2231-827
Standard
02.05
September 2001
C-145
Table C-25 Table PETSIG field descriptions (continued) Field name RDI_LEN Description REDIRECTION INFORMATION LENGTH ENTRY: Multiple with RDI_LEN ENTRY: len1, len1_or_2, len2 EXPLANATION: The redirection information (RDI) field included in the ISUP IAM message provides redirection information for diverted or rerouted calls. The RDI_LEN field selects RDI length to accommodate network requirements in countries that are not compliant with the standard. RDI lengths are len1the RDI length is fixed at 1 byte len1_or_2 the RDI length is obtained from the RDI counter len2the RDI length is fixed at 2 bytes
When this option is not datafilled, the RDI length is obtained from the RDI counter. Note: When the datafill option is 1 byte, the 2nd byte information (redirection counter and redirecting reason) of the RDI, if any, is lost. In effect, the call is considered as being redirected once. PRE_INTL_NOA PREPENDED INTERNATIONAL ACCESS DIGITS ENTRY: Multiple with ACCESS_DIGITS ENTRY: Vector of up to 4 digits (0 to 9999) EXPLANATION: Based on Nature of Address (NOA), prepends the international access digits specified in ACCESS_DIGITS to the called party number on a per trunk group basis.
sheet 5 of 8
GSM
C-146
Table C-25 Table PETSIG field descriptions (continued) Field name ST Description STOP DIGIT ENTRY: Multiple with STOP_DIGIT_OUT ENTRY: N, Y EXPLANATION: Indicates whether or not the stop (ST) digit is outpulsed in the outgoing Called Party Number (CDPN) parameter. When set to Y (yes) or when the ST option is not datafilled, the ST digit is outpulsed in the outgoing CDPN. When set to N (no), the ST digit is not outpulsed. DELAY PROPAGATION DELAY ENTRY: Multiple with DELAY ENTRY: 0 to 32767 EXPLANATION: Specifies the propagation delay value in milliseconds for the specified trunk group.
sheet 6 of 8
411-2231-827
Standard
02.05
September 2001
C-147
Table C-25 Table PETSIG field descriptions (continued) Field name PREFERRED_NOA Description PREFERRED NATURE OF ADDRESS ENTRY: See subfields. EXPLANATION: This option has 3 subfields: CGN, RDN, and OCN. This option enables the operator to specify the preferred address format (NOA) that is to be used for the calling number (CGN), the redirecting number (RDN), and the original called number (OCN). The NOA can be NONEunspecified NATLnational NATWNPnational without national prefix INTLinternational UNKNOWNunknown CDNaddress format (NOA) of the Called Number
A default tuple specifies the address format preference to use when a tuple is not found for the terminating trunk group (CLLI). A value of NONE indicates that no change should be applied, and for a value of UNKNOWN, the NOA is changed to Unknown, but the DMS MSC performs no manipulation of digits. CGN CALLING NUMBER ENTRY: NONE, NATL, NATWNP INTL, CDN, UNKNOWN , EXPLANATION: This subfield indicates the preferred NOA that should be used for the party that originated the call. The default is value is NONE. RDN REDIRECTING NUMBER ENTRY: NONE, NATL, NATWNP INTL, CDN, UNKNOWN , EXPLANATION: This subfield indicates the preferred NOA that should be used for the party that forwarded the call. The default value is NONE.
sheet 7 of 8
GSM
C-148
Table C-25 Table PETSIG field descriptions (continued) Field name OCN Description ORIGINAL CALLED NUMBER ENTRY: NONE, NATL, NATWNP INTL, CDN, UNKNOWN , EXPLANATION: This subfield indicates the preferred NOA that should be used for the party that was originally called. The default value is NONE.
sheet 8 of 8
Datafill sequence
To datafill table PETSIG: 1. Position on a trunk group in TRKGRP. 2. Determine the index, SIG_IDX, in table TRKGRP. 3. Add or modify the truck groups SIG_IDX in table TRKGRP as necessary so that it matches the corresponding KEY field in table PETSIG. 4. Set options in table PETSIG as needed.
Dump and restore

Since these are optional fields, no changes are required when upgrading to a later software version. The CDN_HEX and CGN_HEX options may be automatically added to existing tuples in table PETSIG on the restore (inactive) CPU CM side after a One Night Process (ONP). For any ITU-T ISUP trunk that has a valid PETSIG index and where the corresponding PETSIG tuple exists (in a GSM09 or later release), the following options are added to the PETSIG tuple unless the corresponding option already exists for the tuple (that is, the tuple was transferred from the dump (active) side during the ONP): If the VARIANT of trunk subgroup 0 in table TRKSGRP for the trunk group that references the PETSIG tuple is provisioned with GE (German Variant) then the following options are added: (CDN_HEX (C) (D) $) (CGN_HEX (B) (C) (D) $) Otherwise, for all other VARIANT types the following option is added: (CGN_HEX (B) (C) $)
411-2231-827
Standard
02.05
September 2001
C-149
For an ONP from a GSM08 dump side to a GSM09 or later restore side, the restore side contains only one default, empty tuple (tuple 0). The CDN_HEX and CGN_HEX options are not added to this tuple since it is not referenced by any TRKGRP tuples.
Activation
Immediate
Example tuple
Following is an example of a tuple from table PETSIG:
3 4 (ST Y) $ (CDN_HEX (E) $) (CGN_HEX (B) (C) (D) $) $
GSM
C-150
Table SERVCNFG
This table is used to support the following GSM-R functionalities: eMLPP
Table description
Table SERVCNFG allows the network operator the capability of allocating call set-up class, resource preemption capability information for each priority level call on the Mobile Services Switching Center (MSC), and Txx timer value information.
Field descriptions
Table C-26 describes the fields in table SERVCNFG.
Table C-26 Table SERVCNFG field descriptions Field name PRIORITY Description PRIORITY Entry: A, B, 0, 1, 2, 3, 4 Explanation: This field is the key into the table. This field specifies the priority level identifier. Each of the seven priority values are datafilled by default at IPL. Therefore, there are always seven tuples in this table with the keys A, B, 0, 1, 2, 3, and 4. The seven tuples cannot be added or deleted. The tuples only can be changed. The tuples are changed by changing fields SETUP_CLASS and PREEMPT_CAPABLE and Txx. If a deletion attempt occurs, it is denied. SETUP_ CLASS SETUP CLASS Entry: class1, class2, class3 Default is class2. Explanation: Assigns a call setup class to each of the seven priority levels. Class1 is for fast setup. Class2 is for normal setup. Class3 is for slow setup.
sheet 1 of 2
411-2231-827
Standard
02.05
September 2001
C-151
Table C-26 Table SERVCNFG field descriptions Field name PREEMPT_ CAPABLE Description PREEMPT CAPABLE Entry: N, Y Default is N. Explanation: Indicates if a call is allowed to pre-empt other calls of lower priority than itself. A Y indicates that a call may pre-empt calls of a lower priority. A N indicates that the call may not pre-empt any call. Txx TIMER ENTRY: 1-10 Default is 4. EXPLANATION: This field assigns a timer value.
sheet 2 of 2
Datafill sequence
The tuples cannot be added or deleted. They only can be changed.
Dump and restore

Not applicable
Activation
Immediate
Example tuple
Following is an example tuple for table SERVCNFG.
4 CLASS3 N 6
GSM
C-152
Table XLAENTRY
This table is used to support the following GSM-R functionalities: Call Forwarding to FSNs
Table description
Table XLAENTRY is used for GSM Source Directed Routing (SDR) which provides the ability to perform different translations based on the call origination. The table has an index referenced in table LAC. Data for the key includes an entry point into universal translations. When used with table LAC, this entry point is based on the cell of call origination. The key or index zero must be datafilled with the default translation entry data. The system accesses the table with index zero if the default entry data is relevant for translation. This occurs when, for example, table LAC does not reference table XLAENTRY. Zero in the key field is used for translations on subsequent calls, such as for call forwarding, if a previous inter-MSC handover has occurred and the current cell of origin is not traceable in table LAC. Indexes 1 to 7 of table XLAENTRY have to provide default translation entry points for several applications using this table for translation on special numbers like a Call Forwarding (CF) number, Mobile Station Roaming Number (MSRN), and Handover Numbers (HON).
(contin-
Table XLAENTRY provides the starting point for digit analysis as a call makes its way through the various stages of translation. Note: Table XLAENTRY applies to mobile-originated calls only.
411-2231-827
Standard
02.05
September 2001
C-153
Field descriptions
Table C-27 describes the fields in table XLAENTRY.
Table C-27 Table XLAENTRY field descriptions Field name XLAKEY Description TRANSLATIONS KEY ENTRY: 0 to 1023 EXPLANATION: Key field used by field XLAIDX of table LAC to enter table XLAENTRY. This tuple cannot be deleted if referenced in table LAC. Index numbers 0 through 7 have the following specific uses: Index 0Provides default translation entry data if the cell of origin (COO) tuple in table LAC has no index into table XLAENTRY. Default translation entry data can also be provided if the COO is not known in table LAC such as for subsequent calls after an inter-MSC handover.
Note: Index 0 must be datafilled. Index 1Reserved for call forwarding. It applies to the second leg of a call forwarding call. Index 2Reserved for translations on Mobile Subscriber Roaming Numbers (MSRNs). Index 3Reserved for translations of Handover Numbers (HONs). Index 4Used to route Operator Determined Call Barred (ODB) Local mobile subscribers. Index 5Used to route ODB Roamer mobile subscribers. Index 6Used for Intelligent Network (IN) translations. Index 7Used for Local Number Portability (LNP) translations.
Note: If the LNP SOC is enabled, index 7 must be datafilled. In addition, table PXHEAD must have the following datafill: LNPXLA SDFLT NODFOP NOCON STD TABREF TABLE REFERENCE ENTRY: See explanation. EXPLANATION: Consists of subfields XLASYS and XLANAME.
sheet 1 of 2
GSM
C-154
Table C-27 Table XLAENTRY field descriptions (continued) Field name XLASYS Description TRANSLATION SYSTEM START LOCATION ENTRY: NIL, AC, PX, CT, FA, OFC, FT, NSC EXPLANATION: Defines where the translations system starts. Valid entries are NILnone ACaccess PXprefix CTcountry FAforeign area OFCoffice FTutility NSCnumber service code
Note: The AM (ambiguous) translation system is not a valid entry for this field. XLANAME TRANSLATION SYSTEM NAME ENTRY: See explanation. EXPLANATION: Refinement of subfield XLASYS. It acts as a tag to move a number through the translations table system. If a call does not go past the home office, XLANAMEs only need to be defined in the translations tables. For calls that arrive on an IBN trunk or that require routing out of the home office or that must be sent to treatment, XLANAMEs must first be defined in table XLANAME.
sheet 2 of 2
Datafill sequence
Datafill the following tables in the order listed before datafilling table LAC: 1. Table XLANAME 2. Table PXHEAD 3. Table XLAENTRY
Dump and restore

Not applicable
411-2231-827
Standard
02.05
September 2001
C-155
Activation
Not applicable
Example tuple
Following is an example of a tuple from table XLAENTRY:
0 PX GSMOBILE 1 PX CFXLA
GSM
C-156
Table xxCODE
This table is used to support the following GSM-R functionalities: VBS VGCS IAC Call Forwarding to FSNs
Table description
The name xxCODE is not an actual table name. xxCODE signifies the tables that are used in universal translations. Following is a list of the universal translations tables: ACCODE AMCODE CTCODE FACODE FTCODE NSCCODE OFCCODE PXCODE
With the exception of AMCODE, each xxCODE table has an identical syntax with other xxCODE tables. The code tables perform the majority of the translations required. In the code tables, dialed digits and the datafilled digits are matched and UXLA continuation or termination information is found. The code table lists the information stored against the dialed digits. The universal translation groups perform the following functions: Access code (AC) tables provide entry into another network. For instance, entering the digit nine from a private network can give local operatingcompany-provided second dial tone and caller access to the public network. Prefix code (PX) tables provide dialed-call type information. Typically, this is where digit modification occurs. Country code (CC) tables provide internationally agreed upon, one, two or three digit zones. They are chosen to prevent ambiguity. When dialing a destination inside the same country or an adjacent country, the CC can be omitted. Foreign area (FA) code tables provide specific areas within a country.
411-2231-827
Standard
C-157
Office code (OFC) tables identify a specific DMS-MSC within an area of a country.
Field descriptions
Table C-28 describes the XXCODE fields that pertain to the GSM-R functionalities.
Table C-28 Table xxCODE table field descriptions Field name XLANAME Description TRANSLATION NAME ENTRY: 1 to 8 alphanumeric characters EXPLANATION: Enter the name assigned to table xxCODE. The name must be datafilled in table xxHEAD. FROMD FROM DIGITS ENTRY: up to 11 numeric digits EXPLANATION: Enter the single code or the first in a block of consecutive codes that have the same screening route. TOD TO DIGITS ENTRY: up to 11 numeric digits EXPLANATION: If field FROMD represents a single code, the entry in this field is the same as the entry in the FROMD field. XLADATA TRANSLATIONS DATA EXPLANATION: This field consists of subfield XLASEL plus refinements based on the XLASEL entry.
sheet 1 of 2
GSM
C-158
Appendix C: Data tables used by GSM-R features Description TRANSLATION SELECTOR
Field name XLASEL
ENTRY: CONT, CRSC, DBQ, DMOD, DNRTE, EA, FEAT, FEATINFO, FGB, GCP IAC, NCNT, RTE, TNUM, TRMT , EXPLANATION: Enter one of the following values. Enter CONT and refinements if further translation is required. Enter CRSC and refinements to screen carriers for Equal Access (EA) calls. Enter DBQ and refinements to perform a database query. Enter DMOD and refinements if the input digit stream requires modification. Enter DNRTE and refinements if the input digits are routed. Enter EA and refinements if Equal Access (EA) translations are required. Enter FEAT and refinements if it is necessary to access a feature. Enter FEATINFO and refinements to trigger screening. Enter FGB and refinements to handle Feature Group B calls. Enter GCP and refinements to set certain call attributes. Enter IAC and refinements if it is necessary to insert an area code when an ambiguous area code is found through translation. Enter NCNT and refinements to terminate the translation instance without resulting in any route, treatment, or feature. Enter RTE and refinements if a translation result is found and translation terminates. Enter TRMT and refinements if a call is routed to a treatment. Enter TNUM and refinements translations to dynamically switch translations between related numbers.
sheet 2 of 2
411-2231-827
Standard
02.05
September 2001
C-159
XLASEL = DBQ If the XLASEL value is DBQ, datafill the refinements listed in Table C-29.
Table C-29 Table xxCODE, XLASEL = DBQ Field name OPT Description OPTIONS EXPLANATION: This is a vector comprising up to ten options, each of which consists of subfield OSEL and refinements that depend on it. For each option specify OSEL followed by a space and the refinements, each separated by a space. OSEL OPTIONS SELECTOR ENTRY: NSC, DBQCONT, NTFSAC, PCSSAC, NWSSAC, IN1TF, INAP , LNP GSMIDX, MM, PF, AC, GQC , EXPLANATION: Subfields NSC, DBQCONT, IN1TF, INAP, LNP, GSMIDX, MM, and PF contain refinements that need to be datafilled correctly to ensure that the call is handled correctly. The proper call attributes need to be set under this selector. Subfields NTFSAC, PCSSAC, and NWSSAC have no refinements. NSC NUMBER SERVICE CODE REFINEMENT: NSCODE EXPLANATION: NSC option provides the number of the service operation to be performed on the call. NSCODE NUMBER SERVICE CODE ENTRY: GSMSRI EXPLANATION: If the OSEL value is NSC, enter GSMSRI to trigger the SRI data base query.
sheet 1 of 5
GSM
C-160
Table C-29 Table xxCODE, XLASEL = DBQ (continued) Field name DBQCONT Description DATABASE QUERY CONTINUATION REFINEMENT: XLASYS, XLANAME EXPLANATION: DBQCONT option is for use with, but not limited to, the IN1TF option. This specifies the next translations instance and name to use when re-entering universal translations after the IN1 Feature has queried the SCP database. When retranslating on the returned routing number, this translations system and name is used. XLASYS TRANSLATION SYSTEM ENTRY: NIL, AC, PX, CT, FA, OFC, AM, FT, NSC EXPLANATION: If the OSEL value is DBQCONT, enter the next translation system to use, followed by a space, and then the XLANAME value. AC = access PX = prefix CT = country FA = foreign area OFC = office AM = ambiguous FT = utility NSC = number service code
NIL is used only to satisfy an internal software function. XLANAME TRANSLATION NAME ENTRY: one to eight alphanumeric characters EXPLANATION: If the OSEL value is DBQCONT, enter the translation name of the table instance within the XLASYS to which the call is routed. NTFSAC NON-TOLL FREE SERVICE ACCESS CODE ENTRY: No refinements. EXPLANATION: Specifies numbers that are not toll free to the calling party, like the existing 900 numbers.
sheet 2 of 5
411-2231-827
Standard
02.05
September 2001
C-161
Table C-29 Table xxCODE, XLASEL = DBQ (continued) Field name PCSSAC Description PERSONAL COMMUNICATION SYSTEM SERVICE ACCESS CODE ENTRY: No refinements. EXPLANATION: Specifies that numbers terminating to this option are PCS SAC numbers. The PCS SAC is 500, however, nothing prevents operating company personnel from datafilling any number to terminate to this option. This option simply marks the call as a PCS SAC call and returns the call to translations. Subsequent translations must be set up correctly so that the call is routed appropriately. No Carrier Access Code (CAC) + PCS SAC (that is, CAC + 500) screening is performed. NWSSAC NETWORK SPECIFIC SERVICE ACCESS CODE ENTRY: No refinements. EXPLANATION: Specifies that numbers terminating to this option are Network Specific SAC numbers. The Network Specific SAC is 700, however, there is nothing to prevent operating company personnel from datafilling any number to terminate to this option. This option simply marks the call as a Network Specific SAC call and returns the call to translations. Subsequent translations must be set up correctly so that the call is routed appropriately. No CAC + NWSSAC (that is, CAC + 700) screening is performed. IN1TF INTELLIGENT NETWORK 1 TOLL FREE REFINEMENT: SCP_TIMER EXPLANATION: Specifies numbers that are to be treated as TR-533 defined Toll Free Numbers and initiates the Toll Free Database query using the IN1 Feature. An example of a Toll Free SAC is 800. SCP_TIMER SERVICE CONTROL POINT TIMER ENTRY: 1 to 9 EXPLANATION: If the OSEL value is IN1TF, enter the value for SCP_TIMER. This timer specifies the amount of time the DMS-MSC waits for the response from the SCP without timing out.
sheet 3 of 5
GSM
C-162
Table C-29 Table xxCODE, XLASEL = DBQ (continued) Field name INAP Description INTELLIGENT NETWORK APPLICATION PROTOCOL REFINEMENT: INAP_IDX EXPLANATION: INAP option causes DP3 triggering. INAP_IDX INDEX INTO TABLE MSCINAP ENTRY: 0 to 255 EXPLANATION: If the OSEL value is INAP enter the index number from , table MSCINAP The index is used to extract the SCP address and Service . Key from table MSCINAP . LNP LOCAL NUMBER PORTABILITY REFINEMENT: SCP_TIMER EXPLANATION: LNP option specifies that the number is a portable number. The call is sent to the LNPQ feature which queries the LNP SCP database. SCP_TIMER SERVICE CONTROL POINT TIMER ENTRY: 1 to 9 EXPLANATION: If the OSEL value is LNP enter the value for SCP_TIMER. , This timer specifies the amount of time the DMS-MSC waits for the response from the SCP without timing out. GSMIDX GSM INDEX ENTRY: DEFAULT, NATL, INTL, INTLNGEO EXPLANATION: Specifies an index datafilled in table GSMDEFS which defines the Send Routing Information (SRI) database query options associated with the index. Note: GSMIDX applies only if the NSC option in the DBQ selector is datafilled.
sheet 4 of 5
411-2231-827
Standard
02.05
September 2001
C-163
Table C-29 Table xxCODE, XLASEL = DBQ (continued) Field name MM Description MINIMUM AND MAXIMUM DIGITS REFINEMENT: MIN, MAX EXPLANATION: The MM option specifies the minimum and maximum number of digits needed before routing the call. MIN MINIMUM DIGITS ENTRY: 0 to 30 EXPLANATION: If the OSEL value is MM, enter the minimum number of digits expected. This value includes the digits used to index the current tuple and must include the prefix digits specified therein. MAX MAXIMUM DIGITS ENTRY: 0 to 30 EXPLANATION: If the OSEL value is MM, enter the maximum number of digits expected. This value includes the digits used to index the current tuple and must include the prefix digits specified therein. PF PREFIX REFINEMENT: PFDIGS EXPLANATION: The PF option specifies the number of prefix digits. PFDIGS NUMBER OF PREFIX DIGITS ENTRY: 0 to 24 EXPLANATION: If the OSEL value is PF, enter the number of prefix digits. If prefix digits were specified in a previous table, this number is added to that one.
sheet 5 of 5
Table modifications made for the IAC functionality These tables are modified by adding option AC to the existing Data Base Query (DBQ) selector. Option AC identifies acknowledgment calls. When translations (UXLA) on the called number hits the AC option, the call is identified as an acknowledgment call. At this point, the normal mobile station
GSM
C-164
basic call is altered to capture the acknowledgment record. Then the call is released immediately. Through datafill, there are two numbers that can be manipulated to hit the AC option. If the operator does not want acknowledgment calls to be blocked by BAOC, the operator should datafill "VLRXLA" translations to return a "CLASS = SPECIAL" for the acknowledgment calls called number. Table modifications made for the VBS/VGCS functionalities These tables add a new option to the existing database query (DBQ) selector to identify group/broadcast calls and the need to perform GCR query screening. The DBQ option is: GCQ (Group Call Query). When translations (UXLA) on the called number hits the GCQ option, it is identified as a group or broadcast call. At this point, the system performs GCR screening on the group call reference (GCRef). To handle the possibility that retranslation on the same GCRef could occur, the following existing option can be used in conjunction with the GCQ option: DBQCONT. Retranslations on the GCRef results in a loop. The DBQCONT option can be used in these cases if deemed necessary. This option specifies a new translation system (XLASYS) and translation name (XLANAME) to use when re-entering UXLA. Specifying a new XLASYS and XLANAME keeps looping from occurring.
Datafill sequence
The datafill sequence for the AC option in the xxCODE table is shown in Figure C-14.
Figure C-14 Datafill sequence for table xxCODE Table xxHead
Table xxCODE
Dump and restore

Not Applicable.
Activation
Immediate
411-2231-827
Standard
02.05
September 2001
C-165
Example tuple
Following is an example of a tuple from table xxCODE.
GSMOBILE 1612 1612 DBQ (AC)
GSM
C-166
xxHEAD
This table is used to support the following GSM-R functionalities: Call Forwarding to FSNs VBS VGCS IAC
With the exception of table AMHEAD, all xxHEAD tables have identical syntax. The head table defines the name and characteristics of the instances of each code table.
Table description
The universal translation groups perform the following functions: Access code (AC) tables provide entry into another network. For instance, entering the digit nine from a private network can give local operatingcompany-provided second dial tone and caller access to the public network. Prefix code (PX) tables provide dialed-call type information. Country code (CC) tables provide internationally agreed upon, one-, twoor three-digit zones. They are chosen to prevent ambiguity. When dialing a destination inside the same country or an adjacent country, the CC can be omitted. Foreign area (FA) code tables provide specific areas within a country. Office code (OFC) tables identify a specific DMS-MSC within an area of a country.
411-2231-827
Standard
02.05
September 2001
C-167
Field descriptions
Table C-30 describes the fields for table xxHEAD.
Table C-30 Table xxHEAD field descriptions Field name XLANAME Description TRANSLATION NAME ENTRY: one to eight alphanumeric characters EXPLANATION: The name of the translation being specified; must match an XLANAME entered in GSMCUST or GSMNCOS. DFLTSEL DEFAULT SELECTOR ENTRY: SDFLT, DFLT EXPLANATION: SDFLT is used when only one translation system is required to be examined before routing a call. First, the system analyzes the information in the corresponding CODE table. If no digit match is found, the system defaults back to the head table, sees the SDFLT entry, and sends the call to VACT treatment. DFLT is used when more than one translation system is required to be examined before routing a call. First, the system analyzes the information in the corresponding code table. If no digit match is found, the system defaults back to the head table, finds the CONT selector, and indexes into the translation system identified for further translations. XLASEL Enter SDFLT for the standard default, TRMT OFC VACT (vacant code treatment). No additional datafill is necessary. Enter DFLT and then refinement XLASEL if the standard default is incorrect.
TRANSLATION SELECTOR ENTRY: CONT, CRSC, DBQ, DMOD, DNRTE, EA, FGB, FEAT, FEATINFO, GCP IAC, NCNT, RTE, TNUM, TRMT , EXPLANATION: Datafill these fields only if DFLT is selected for DFLTSEL (see DFLTSEL above).
Dump and restore

During the ONP of a switch that already contains xxHEAD or xxCODE tuples with DBQ INAP options, the nil value, $, is used in the INDEX field. Presence of a $ in INDEX causes the system to use the OFCVAR
C-168
parameters for GSM_DP3_SCP_ADDRESS and GSM_DP3_IN_SVC_KEY as default values for DP3 Triggering.
411-2231-827
Standard
02.05
September 2001
D-1
Appendix D: OPARMS used by GSM-R features
Office parameters (OPARMs) are variables that perform special functions and allocate specific DMS-MSC and HLR resources. DMS-MSC and HLR OPARMs reside in five tables: GSMVAR, OFCENG, OFCOPT, OFCSTD, and OFCVAR. Tables GSMVAR, OFCENG, and OFCVAR contain OPARMs that set up GSM-R features. This appendix discusses these OPARMs. Note 1: For a description of other DMS-MSC OPARMs that are not specifically related to GSM-R functionalities, refer to NTP 411-2231-455, DMS-MSC Office Parameters Reference Manual. Note 2: For a description of other DMS-HLR OPARMs that are not specifically related to GSM-R functionalities, refer to NTP 411-2831-455, DMS-HLR Office Parameters Reference Manual.
GSM
D-2 Appendix D: OPARMS used by GSM-R features
Table GSMVAR
This table contains the following office parameters: CF_MS_CPC GSMEIR_NUMBER GSM_PAGE_RETRY IAA_GEN_FREQUENCY MS_CPC MSCLOC REPLACE_INTL_ROAM_CLID REPLACE_MS_CC_DIGITS USE_HANDOVER_DETECT_NTWK_CONN
CF_MS_CPC
This OPARM contains the values used for the call forwarding leg of an originating mobile calling party category and override boolean. These values are CF_MS_CPC_VALUE (for the calling party category) and CF_REPLACE_CPC (for the override boolean). These values signify whether to override the present value with the tuples value. The range of values for CF_MS_CPC_VALUE is 0-255. The default value is 0. The range of values for CF_REPLACE_CPC is Y and N. The default value is N.
GSMEIR_NUMBER
This OPARM specifies the ISDN number used by GSM applications to address an Equipment Identity Register (EIR). This OPARM has three parts: country code (cc), national destination code (ndc), and subscriber number (sn). These three parts comprise the ISDN number of the EIR. Following are the range of values for the three parts of the OPARM: cc: vector up to three digits {0-9} ndc: vector up to six digits {0-9} sn: vector up to 13 digits {0-9}
The default value for all three parts is NULL.
411-2231-827
Standard
02.05
September 2001
D-3
GSM_PAGE_RETRY
This OPARM specifies the total number of page retries attempted after an unsuccessful page request attempt. This OPARM is comprised of three attributes: TOTAL_RETRIES RETRY_ID_TYPE RETRIES_WITH_SECID
The TOTAL_RETRIES attribute determines the number of page retries attempted by the DMS-MSC on the expiration of the page interval timer (GSM_PAGE_INTRVL_TIMER, which is 12 seconds). The range of values for this attribute is 0-2. The default value is 1. The RETRY_ID_TYPE attribute specifies the ID used for page retries sent to the MS. Page retries can be attempted with a Temporary Mobile Subscriber Identity (TMSI) and International Mobile Subscriber Identity (IMSI) or IMSI_ONLY. The type of ID used depends on the setting of Retry ID_Type: DEFAULT- both the TMSI and IMSI are sent to the Base Station Subsystem (BSS). BSS in turn picks TMSI, if is present. Otherwise, it uses the IMSI in the paging message to the MS. IMSI_ONLY - only the IMSI is sent to the BSS, and in turn to the MS during paging.
The range of values for the RETRY_ID_TYPE attribute is IMSI_ONLY and DEFAULT. The default value is IMSI_ONLY. The RETRIES_WITH_SECID attribute specifies the page retry count at which to use the secondary ID as specified in the RETRY_ID_TYPE attribute. The range of values for this attribute is 0-2. The default value is 1.
IAA_GEN_FREQUENCY
This OPARM determines the time period between record generation through the Inter-Admin Accounting feature. This feature provides the capability to measure bulk conversation time and number of answered calls and subsequently records the results in meters. These meters are then periodically produced in a format which allows the operators involved to reconcile accounts. Two attributes make up this OPARM. These attributes are Start Time and Frequency. Start Time (HH) designates the hour of the day at which the first record is generated. The range of values for the Start Time is 0 to 23. The default value is 2.
GSM
The second attribute is Frequency (HRS). This attribute designates the number of hours that pass before the next record is generated. The range of values is 0 to 24. The default value is 24. A frequency of 0 disables record generation capability.
MS_CPC
This OPARM identifies the activation of the DMS-MSC CPC/CLI Enhancement software. This software requires datafill in table GSMVAR of office parameter MS_CPC. This parameter specifies the numerical value to use for mobile originating Calling Party Category (CPC) (MS_CPC_VALUE) and the Override Boolean (MS_REPLACE_CPC) that signifies whether to actually override the present value with the tuples value. This OPARM has two attributes: MS_CPC_VALUE and REPLACE_CPC. The range of values for MS_CPC_VALUE is 0-255. The default value is 0. The range of values for MS_REPLACE_CPC is Y and N. The default value is N.
MSCLOC
This OPARM identifies the location of a DMS-MSC. The data from this parameter is sent to the originator of a call if the cell site location is not available. MSCLOC contains subfields identifying the latitude and longitude of a DMS -MSC. All subfields are mandatory and shown in Table D-1.
Table D-1 MSCLOC subfields range of values FIELD NAME LAT_DEG LAT_MM LAT_SS LAT_DIR LONG_DE G LONG_MM LONG_SS LONG_DIR RANGE OF VALUES 00 ~ 90 00 ~ 59 00 ~ 59 N or S 000 ~ 180 00 ~ 59 00 ~ 59 E or W STATUS New New New New New New New New DEFAULT VALUES N/A N/A N/A N/A N/A N/A N/A N/A DESCRIPTION Latitude in degrees Latitude Minutes Latitude Seconds Latitude Direction Longitude in Degree Longitude Minutes Longitude Seconds Longitude Direction
The default value is $.

D-5
REPLACE_INTL_ROAM_CLID
This OPARM allows any customer to replace the international roaming Calling Line Identification (CLI) with any specified set of digits.This parameter contains fields for identifying the following values: the Local Country Code (CC) for the particular switch the value to replace the Operating Company Number (OCN) and Remote Directory Number (RDN) with, in case the CC is from an International Roaming MS a Boolean flag to specify whether to actually override the present value with the specified digits
When this office parameter is active (the REPLACE_INTL_ROAM_CLID boolean is set to Y), the CLI (during roamer origination) and RDN/OCN (during roamer redirection) are totally replaced by the datafilled string. Following are the range of values and default values for this OPARMs fields. LOCAL_CC_DIGITS (character: ...) Default is NilString CLI_REPLACEMENT_VALUE (character: ...) Default is NilString REPLACE_CLID (boolean Y or N) Default is N
REPLACE_MS_CC_DIGITS
This OPARM allows any customer to manipulate the CLI by replacing a specified Country Code with a specified National Prefix. This parameter manipulates the Original Called Number (OCN) and Redirecting Number (RDN) by replacing the specified Country Code with a specified National Prefix when call redirection is active. This parameter contains fields for verifying if this is the correct CC value to replace for the CC of OCN and RDN, and the override boolean which signifies whether to actually override the present value with the tuples value. Following are the range of values and default values for this OPARMs fields. CC_DIGITS-TO_REPLACE (character: ...) Default is NilString MS_NP_VALUE (character: ...) Default is NilString REPLACE_CC (boolean Y or N) Default is N
USE_HANDOVER_DETECT_NTWK_CONN
This OPARM updates the network connection. The range of values for this OPARM is Y or N. The default value is Y.
GSM
Table OFCENG
Table OFCENG contains numerous office parameters. This section describes the OPARMs that specifically affect GSM-R features. These OPARMs are arranged in alphabetical order as follows: CRS_SUBRU_POOL4_SIZE GID_DIGITS_LENGTH MAX_VGS_SUBS_IN_VLR NCCBS NO_OF_HIS_CONTROL_BLKS NO_OF_HIS_DATA_BLKS NUMBER_OF_BSC_CLSTR_CELL_TIDS NUMBER_OF_CPIPP_ADDR_PAIR_BLOCKS NUMBER_OF_DMS_SYSTEM_TIDS NUMBER_OF_FPF_HUGE_AUX_BLOCKS NUMBER_OF_FPF_LARGE_AUX_BLOCKS NUMBER_OF_FPF_MEDIUM_AUX_BLOCKS NUMBER_OF_FPF_SMALL_AUX_BLOCKS NUMBER_OF_FPF_XLARGE_AUX_BLOCKS NUMBER_OF_MDM_CONTROL_BLOCKS NUMBER_OF_MM_TIDS NUMBER_OF_MOBILE_CLUSTER_TIDS NUMBER_OF_MS_TIDS NUMBER-OF_PI_CLIENT_TIDS NUMBER_OF_PI_OBC_TIDS NUMBER_OF_RELAY_LOGICAL_TIDS NUMBER_OF_TLK_HO_MAP_TTIDS NUMBER_OF_TTID_SERVER_TIDS
CRS_SUBRU_POOL4_SIZE
This parameter controls the provisioning of the CRS_SUBRU_POOL4 extension block. This extension block is required for the generation of the GSM IN Charge Info MRU (Modular Recording Unit). The range of values for this parameter is 0 - 4294967295. The default value is 100.
411-2231-827
Standard
02.05
September 2001
D-7
This parameter follows various provisioning rules. Each provisioning rule uses the following abbreviations: VHT: Average Voice Call Hold Time MM: % of mobile to mobile calls: MM/(MM+ML+LM+LL) ML: % of mobile to land calls: ML/(MM+ML+LM+LL) LM: % of land to mobile calls: LM/(MM+ML+LM+LL) LL: % of land to land calls: LL/(MM+ML+LM+LL) OB ROAM: % of calls to outbound roamers: (MLSRI + LLSRI)/ (MM+ML+LM+LL) CF: % of calls that are redirected HD: % of calls that are held/retrieved MPTY: % of conference calls (multi-party) SMS: number of Short Message Services per call DP2: % calls that trigger at DP2 (includes forwarding legs) DP3: % calls that trigger at DP3 (includes forwarding legs) DP12: % calls that trigger at DP12 SN: % calls that are routed to a service node BHCA: Supportable Busy Hour Call Attempts
Provision the number of SUBRU POOL4 resources as follows:

Xsru4 = ( 2*(MM + ML) + LM + Inter-BSC HO + Inter-MSC HO) * VHT
The following is a list of provisioning rules which accommodate the GSM INAP application. a. Maximum number of IN calls during a specific time period b. Number of secondary or subsequent IP interaction
(contin-
c. Number of calls originated by the IP d. Number of off-board IN calls e. 4*A
Operand B through F in the above formula calculated as follows:

A = 1 * (DP2 + DP3 + DP12) - based on one GSM IN Info. module per IN call B = .01 * (DP2 + DP3 + DP12) - based on one GSM IN Info. module per secondary or subsequent IP interaction C = DP12 - based on one GSM IN Info. module per IP RLT D = SN - based on one GSM IN Info. module per off-board IN call GSM MSC/HLR Services Guide GSMR02
E = 4 * (DP2 + DP3 + DP12) - based on a maximum of four FurnishChargingInformation operations received in a single SSP to SCP dialogue
To accommodate the GSM INAP application, add the following to the above calculation for Xsru4.
(A + B + C + D + E) * VHT
If using PCS1900_PROTOCOL_IN_USE, add the following to the above calculation.

(TF*VHT)
Xsru4 is the sum of all SUBRU Pool 4 resources required to support the recording of call related data for the following billing information modules. Location and Channel Information Module Other Agent Information Module GSM IN Information Module GSM IN Charging Information Module Toll Free Information Module Local Number Portability (LNP) Information Module
Rsru4 is the number of SUBRU Pool 4 resources required to support the call model at a given BHCA call capacity. Rsru4 is intended to be the real number of SUBRU Pool 4 resources no margin for error. CRS_SUBRU_POOL4_SIZE is the final number of calculated SUBRU Pool 4 resources. This is calculated from Rsru4 with a 50% mark-up for spikes in traffic, expansion of call hold times, et cetera.
GID_DIGITS_LENGTH
This parameter determines the length of the Group Id (GID) portion within the Group Call Reference (GCREF). The possible range of values is 0 to 6. The default setting is 3. The MSC expects the GID to be of length set by this parameter. VBS or VGCS calls cannot be set up if the length of the GID sent into the MSC from external nodes does not match the length set within the MSC.
MAX_VGS_SUBS_IN_VLR
This parameter allows the customer to provision the number of subscribers that may have group call data in the VLR. This parameter has a relationship to parameter MAX_SUBSCRIBERS_IN_VLR in that the value of MAX_VGS_SUBS_IN_VLR cannot exceed the current value of MAX_SUBSCRIBERS_IN_VLR.
D-9
Each increment of this parameter translates to 1024 (1K) entries in the table. For example, if the parameter value is 3, that means 3K entries are allocated for the table. By allowing the customer to specify this data, the customer controls the amount of memory used to store group call data. For instance, if the VLR does not support VGS, then MAX_VGS_SUBS_IN_VLR will be 0 and no memory is used. The range of values for this OPARM is 0 to 50. The default is 0.
NCCBS
Office parameter NCCBS (Number of CCBs) is a DMS-100 office parameter. The following information relates only to its functionality within the GSM framework. Refer to 411-3001-455, Wireless Networks Base/Telecom Office Parameters Reference Manual, for DMS-specific information on NCCBS. During call processing, a mobile uses two CCBs. Other agents (trunks, announcements, and tones) use one CCB, and redirected calls (CF, RLT) use two CCBs. CCBs are also associated with non-call mobility transactions such as SMS, CISS, Location Updates, Attach/Detach, and Inter MSC Handovers. The number of CCBs (N) are provisioned as follow:
Xccb = (4 x mm + 3 x (ml + lm) + 2 x ll) x HT + (2cf + hd + cf + i) x HT + att x 3 + det x 2 + lu x 5 + sms x 7 + ho x HT Rccb = BHCA x Xccb 3600 NCCBs = Rccb x 1.5
Table D-2 lists the abbreviations used in the equations for each provisioning rule.
Table D-2 Abbreviations for provisioning equations Abbreviation HT ml mm lm Definition average voice call Hold Time % of mobile to land calls : ml / (mm + ml + lm + ll) % of mobile to mobile calls : mm / (mm + ml + lm + ll) % of land to mobile calls: lm / (mm + ml + lm + ll)
0
GSM
D-10
Appendix D: OPARMS used by GSM-R features Table D-2 Abbreviations for provisioning equations Abbreviation ll cf hd c: i lu: att det ho: sms BHCA Definition
% of land to land calls : ll / (mm + ml + lm + ll) % of number of redirect calls % of number of held calls % of conference calls (Multiparty) % of monitored calls (Call Intercept) number of location updates per call number of International Mobile Subscriber Identity (IMSI) attaches per call number of IMSI Detaches per call number of handovers (inter-MSC) per call number of Short Message Service per call supportable Busy Hour Call Attempts
0
(contin-
The possible range of values for this OPARM is 0 to 65535. The default value is 80.
NO_OF_HIS_CONTROL_BLKS
This parameter is associated with the Stored Program Control Call Management Service (SPC-CMS) that enables SPC switches to be included in the CMS network. This parameter is used in mobility calls, location updates, and detaches. The range of values for this OPARM is 0 4294967295. The default value is 0.
NO_OF_HIS_DATA_BLKS
This parameter controls the number of regular history data blocks. This is the first index in the NO_OF_HIS_HSITORY_BLKS parameter. The range of values is 0 to 4294967295. The default value is 0.
NUMBER_OF_BSC_CLSTR_CELL_TIDS
This parameter controls the size of a logical terminal identifier pool required by active group call feature control software for internal messaging purposes. The range of values for this OPARM are 0 to 32767. The default value is calculated by the following formula:
Nortel Networks Confidential (NCCBS) * (0.375)
D-11
This default value is an estimated required number assuming 5% of all MSC calls are group calls and each group spans an average of five (5) cells on each MSC.
NUMBER_OF_CPIPP_ADDR_PAIR_BLOCKS
This office parameter allocates the address blocks for inter-node messaging using CPIPP (Call Processing Inter-Process Protocol). The range of values for this OPARM is 0 to 65536. The default value is equal to the value in OPARM NCCBS.
NUMBER_OF_DMS_SYSTEM_TIDS
This parameter controls the size of a logical terminal identifier pool required by active group call feature control software for internal messaging purposes. The range of values for this parameter is 0 to 32767. The default setting for this office parameter is (NCCBS) * (0.04). This default value is an estimated required number assuming 5% of all MSC calls are group calls.
NUMBER_OF_FPF_HUGE_AUX_BLOCKS
This OPARM allocates auxiliary data blocks that may be used by a call on the MSC to store data pertinent to that call. The range of values for this OPARM is 0 to 65535. The default value is calculated by the following formula:
(0.75) * (0.75) * NCCBS.
NCCBS is an OPARM in table OFCENG that specifies the number of CCBS allocated in an MSC.
NUMBER_OF_FPF_LARGE_AUX_BLOCKS
This OPARM allocates auxiliary data blocks that may be used by a call on the MSC to store data pertinent to that call. The range of values for this OPARM is 0 to 65536. The default value is determined by the following formula:
(0.75) * (1.85) * NCCBS
NUMBER_OF_FPF_MEDIUM_AUX_BLOCKS
This OPARM allocates auxiliary data blocks that may be used by a call on the MSC to store data pertinent to that call. The range of values is 0 to 65536. The default value is determined by the following formula:
GSM
D-12
Appendix D: OPARMS used by GSM-R features (0.75) * (2.68) * NCCBS
NUMBER_OF_FPF_SMALL_AUX_BLOCKS
This OPARM allocates auxiliary data blocks that may be used by a call on the MSC to store data pertinent to that call. This range of values for this OPARM is 0 to 65536. The default value is determined by the following formula:
(0.75) * (0.46) * NCCBS
NUMBER_OF_FPF_XLARGE_AUX_BLOCKS
This OPARM allocates auxiliary data blocks that may be used by a call on the MSC to store data pertinent to that call. The range of values for this OPARM are 0 to 65536. The default value is calculated by the following formula:
(0.75) * (4.86) * NCCBS
NUMBER_OF_MDM_CONTROL_BLOCKS
This OPARM allocates MDM (Mobility Data Management) control blocks which contain mobility related data for a call on the MSC. The range of values for this OPARM is 0 to 65536. The default value is determined by the following formula:
(0.60) * (0.75)* NCCBS
NUMBER_OF_MM_TIDS
This OPARM provisions the number of tids available for use when communicating with the MM (Mobility Management) call. The range of values for this OPARM is 0 to 32767. The default value is determined by the following formula:
NCCBS/3
411-2231-827
Standard
02.05
September 2001
D-13
NUMBER_OF_MOBILE_CLUSTER_TIDS
This parameter controls the size of a logical terminal identifier pool required by active group call feature control software for internal messaging purposes. The range of values for this OPARM are 0 to 32767. The default value is calculated by the following formula:
(NCCBS) * (0.375)
This default value is an estimated required number assuming 5% of all MSC calls are group calls and each group has an average of five (5) associated BSC on each MSC.
NUMBER_OF_MS_TIDS
This OPARM provisions the number of tids available for use when communicating with a MS call on the MSC. The range of values for this OPARM is 0 to 32767. The default value is determined by the following formula:
NCCBS/2
NCCBS is an OPARM in table OFCENG that specifies the number of CCBS allocated on an MSC.
NUMBER_OF_PI_CLIENT_TIDS
This OPARM provisions the number of TID used for communication between the MM (Mobility Management) call and the Physical Interface (PI) call. The PI call is used to communicate with either the BSS or Inter-Machine Trunk (IMT). The possible range of values for this OPARM include 0 to 32767. The default value is determined by the following formula:
NCCBS/3.
NUMBER_OF_PI_OBC_TIDS
This OPARM provisions the number of TID used for communication between the MM (Mobility Management) call and the Physical Interface (PI) call that communicates with a given Inter-Machine Trunk (IMT). The possible range of values for this OPARM are 0 to 32767. The default value is determined by the following formula:
(0.08) * (0.75) * NCCBS
D-14
NUMBER_OF_RELAY_LOGICAL_TIDS
This OPARM specifies the number of the logical TIDs required on the DMSMSC for the relay feature software. One TID is required for each relay feature. Anchor-MSC supports setting up a group call for three relay-MSC. Therefore, three TIDs are required for each group call. The possible range of values for this OPARM is 0-32K. The value is the number of the logical TIDs. The default for this OPARM is determined by the following formula:
NCCBs/10
NUMBER_OF_TLK_HO_MAP_TTIDS
This OPARM specifies the number of TID pools used to talk to the handover MAP ASE.
NUMBER_OF_TTID_SERVER_TIDS
This OPARM provisions the number of TID used for communication between the MM (Mobility Management) call and the Physical Interface (PI) call used to communicate with a given BSS. The possible range of values for this OPARM is 0 to 32767. The default value is determined by the following formula:
NCCBS/3.
411-2231-827
Standard
02.05
September 2001
D-15
Table OFCVAR
Table OFCVAR contains numerous office parameters. This section describes the OPARMs that specifically affect GSM-R features. These table OFCVAR OPARMs are arranged in alphabetical order as follows: DISP_DISC_SEQ EMLPP_DEFAULT_PRECEDENCE GSM_VGCS_VBS_ORIG_XLAENTRY GSM_VGCS_VBS_TERM_XLAENTRY GSMR_FUNCTIONAL_ADDRESS_ENABLED HIGH_PRIORITY_CALL MLPP_PBX_FULL_SUPPORT MLPP_SERVICE_DOMAIN PREFERRED_NOA RAILWAY_ACCESS_CODE VGCS_DISPATCHER_TALK_CONTROL
DISP_DISC_SEQ
Office parameter DISP_DISC_SEQ stores the predetermined dispatcher disconnect sequence digits. These digits are matched with the incoming DTMF tone sequences from authorized dispatchers while they attempt to tear down an on-going group call. The possible range of values for this OPARM is three digits of either OCT and STAR and an interdigit timer value. The default value is set to STAR STAR STAR for the sequence and 30 seconds for the timer.
EMLPP_DEFAULT_PRECEDENCE
This office parameter sets the default priority level for the network. This is also the default priority level given to any call that does not have a priority level. Values 0 to 4 can be entered into this office parameter. 0 sets the network default priority level at the highest possible level while 4 sets the network default priority level at the lowest possible level. This office parameter has a default value of 4, which is the lowest possible level. The value of this office parameter has direct consequences on all call processing, including pre-emption, billing, and signaling.
GSM
D-16
GSM_VGCS_VBS_ORIG_XLAENTRY
This parameter determines the entry point into XLAENTRY table only if table XLAENTRY has an index that is equal to the GSM_VGCS_VBS_ ORIG_XLAENTRY number. Provision this matching XLAENTRY index for VBS and VGCS service subscriber originated calls. When provisioning this parameter, follow the derivation of the group call reference (GCRef) from the dialed GID, LAC, and Cell ID. The GCRef enters translations indicated by this parameter. If the GSM_VGCS_VBS_ORIG_XLAENTRY number does not match the XLAENTRY index, the default index (which is 0) is used to enter into the XLAENTRY table. The range of values for this parameter is 0 to 1023. The default value is 0.
GSM_VGCS_VBS_TERM_XLAENTRY
This parameter determines the entry point into XLAENTRY table only if table XLAENTRY has an index that is equal to the GSM_VGCS_VBS_ TERM_XLAENTRY number. Provision this matching XLAENTRY index for VBS and VGCS calls that require translations toward dispatchers and relay MSCs. If the GSM_VGCS_VBS_ORIG_XLAENTRY number does not match the XLAENTRY index, the default index (which is 0) is used to enter into the XLAENTRY table. The range of values for this parameter is 0 to 1023. The default value is 0.
GSMR_FUNCTIONAL_ADDRESS_ENABLED
This office parameter prevents breaking GSM calls when the GSMR01 stream is merged back into the GSMXX stream determines the presence of the GSM-R network where users may make Functional Address calls overwrites the bearer capability AFE-OCN with the OCN received from the Connect message sends the appropriate bearer capability in the outgoing DTAP SETUP message
The values that can be entered in this office parameter are Y and N. The default value is N. A value of N means there is only a GSM network. A value of Y means there is a hybrid network - GSM and GSM-R.
D-17
HIGH_PRIORITY_CALL
This parameter defines the networks high precedence level. The range of values for this parameter is A, B, 0, 1, 2, 3. The default setting for this office parameter is 0.
MLPP_PBX_FULL_SUPPORT
The OPARM is set to Y when all the PBXs in the network support the MLPP service. When at least one PBX in the network does not support the MLPP service, then the OPARM is set to N. The possible values for this OPARM are Y and N. The default value is N.
MLPP_SERVICE_DOMAIN
This OPARM value is used as the default MLPP Service Domain value in the outgoing ISUP IAM. A value must be sent out in the MLPP Service Domain field of the outgoing ISUP IAM. This OPARM is that value. The possible range of values is 000000 to FFFFFF. The default value is 000000.
PREFERRED_NOA
This OPARM contains the preferred NOA information for the calling number, the redirection number, and the original called number in their respective subfields. The possible values include NONE INTL NATL NATWNP (national without national prefix) UNKNOWN CDN (the address format of the called number)
The default value for all three subfields is NONE.
RAILWAY_ACCESS_CODE
Office parameter RAILWAY_ACCESS_CODE specifies the RAC of the local GSM-R network. This information is necessary for the Access Matrix feature to decide if the Access Matrix check has to be performed (in case the called party belongs to the local GSM-R network) or not. The possible range of values for this OPARM is three digits consisting of 0 to #F. The default value is #F#F#F.
GSM
D-18
VGCS_DISPATCHER_TALK_CONTROL
This office parameter is implemented as a vector. It contains the following fields: ENABLED START_TALKING END_TALKING GRANT_TONE REJECT_TONE
Table D-3 describes the fields that make up the DISPATCHER_TALK_ CONTROL vector.
Table D-3 DISPATCHER_TALK_CONTROL vector fields Field name ENABLED Description ENABLED ENTRY: N or Y Default is N. EXPLANATION: Determines the function control option in a Voice Group Call Service (VGCS) call. START_TALKING START_TALKING ENTRY: 3 digits of either * or # or combination of
both.
Default is ***. EXPLANATION: Defines a DTMF tone sequence used for dispatcher to request talk in a VGCS call. END_TALKING END_TALKING ENTRY: 3 digits of either * or # or combination of
both.
Default is *##. EXPLANATION: Defines a DTMF tone sequence used for dispatcher to release the talk.
sheet 1 of 2
411-2231-827
Standard
02.05
September 2001
D-19
Table D-3 DISPATCHER_TALK_CONTROL vector fields Field name GRANT_TONE Description GRANT_TONE ENTRY: 0-255 Default is 9. EXPLANATION: Defines a tone that is a market defined warning tone used to notify the dispatcher that his talk request was granted. REJECT_TONE REJECT_TONE ENTRY: 0-255 Default is 5. EXPLANATION: Defines a market defined warning tone that is used to notify the dispatcher that his talk request was rejected.
sheet 2 of 2
GSM
D-20
411-2231-827
Standard
02.05
September 2001
E-1
Log reports are video screen displays or printouts that contain information vital to the efficient operation of the system. There are hundreds of different types of log reports. This appendix describes only the log reports that provide information specific to GSM-R functionalities. GSM-R functionalities generate both HLR and MSC log reports. Therefore, the GSM-R-specific log reports are separated into two sections: HLR log reports and MSC log reports.
HLR log reports

Following are the HLR log reports that provide information specific to GSMR functionalities: GHLR401 GVLR300
GHLR401 Log GHLR401, also known as the HLR Hourly Report, presents the following information: real-time capacity usage the average subscriber transaction profile performance indicators transaction resource usage
The information applies to the HLR activity over the last hour. It also includes the history related to the busiest hour over the last 24 hours.
GSM
E-2
Format GHLR401 mmmdd hh:mm:ss ssdd SUMM Hourly Report Last Hour Subscribers Activated Real-time Capacity Usage Average Peak Average Subscriber Transaction Profile Call Routing Requesting Involving a PRN Requests Involving a PSI Other Call Routing Requests ATI - PSI Requests SRI - PSI Requests Location Update Requests Location Update Requests(No ISD) GPRS Location Update Requests Authentication Requests CISS Requests SMS Routing Requests Report SM Delivery Requests Ready For SM Requests USSD Indication & Requests Standby Requests Standby Indicators Performance Indicators Requests Acceptance Ratio Network Acceptance Ratio Transaction Success Ratio Off-board AUC Success Ratio Off-board AUC Distribution Ratio Supercharger Effectiveness Ratio USSD Acceptance Ratio Transaction Resource High Water Mark HLR Save Buffers Transaction Control Blocks(TCB) Transaction Identities (TRID) Transaction Components Extension Blocks (EXT) Busy Hour
hh:00-hh:00 hh:00-hh:00 <subs> <subs> <percent> <percent> <requests> <requests> <requests> <requests> <requests> <requests> <requests> <requests> <requests> <requests> <requests> <requests> <requests> <requests> <requests> <requests> <percent> <percent> <percent> <percent> <percent> <percent> <percent> <percent> <percent> <percent> <percent> <percent> <percent> <percent> <requests> <requests> <requests> <requests> <requests> <requests> <requests> <requests> <requests> <requests> <requests> <requests> <requests> <requests> <requests> <requests> <percent> <percent> <percent> <percent> <percent> <percent> <percent> <percent> <percent> <percent> <percent> <percent>
411-2231-827
Standard
02.05
September 2001
E-3
Report example GHLR401 OCT09 16:04:19 5504 SUMM Hourly Report Last Hour Subscribers Activated Real-time Capacity Usage Average Peak Average Subscriber Transaction Profile Call Routing Requesting Involving a PRN Requests Involving a PSI Other Call Routing Requests ATI - PSI Requests SRI - PSI Requests Location Update Requests Location Update Requests (No ISD) Authentication Requests GPRS Location Update Requests CISS Requests SMS Routing Requests Report SM Delivery Requests Ready For SM Requests USSD Indication & Requests Standby Requests Standby Indications Performance Indicators Requests Acceptance Ratio Network Acceptance Ratio Transaction Success Ratio Off-board AUC Success Ratio Off-board AUC Distribution Ratio Supercharger Effectiveness Ratio USSD Acceptance Ratio Transaction Resource High Water Mark HLR Save Buffers Transaction Control Blocks (TCB) Peak Transaction Control Block Usage Peak Transaction Control Block Usage Peak Transaction Control Block Usage Busy Hour
00:00-01:00 10:00-11:00 1000000 1000000 30% 40% 0.001 0.001 0.010 0.001 0.001 0.200 0.100 1.000 0.069 0.009 0.099 0.999 9.999 0.010 0.001 0.000 1% 100% 10% N/A 0% 50% 95% 3% 8% 5% 4% 10% 30% 40% 0.001 0.001 0.010 0.001 0.001 0.500 0.400 1.000 0.069 0.009 0.099 0.999 9.999 0.010 0.100 0.100 1% 100% 10% N/A 0% 80% 80% 4% 9% 6% 5% 12%
GSM
E-4
Action No action needs to be taken when the figures are within normal operating ranges. High values may indicate that the node is overloaded. Contact Nortel Networks System Engineering for further information. Analysis Certain combinations of values may indicate a messaging problem, for example
PRN% > 0 when SRI% = 0
is an inconsistent reading. If the value of USSD Acceptance Ratio falls below an operator determined acceptable level the number of resources available to USSD messages must be increased. This can be achieved by: Increase the value of the HLRDEFAULTS parameter MAX_USSD_TRANSAC. Decrease the value of the HLRDEFAULTS parameter NWI_USSD_TIMER.
Associated OM groups The following OM groups are associated with Log GHLR401: AUCSTATSGSM HLR Authentication Centers
411-2231-827
GHLRCHGSM HLR Call Handling GHLRFRECGSM HLR Fault Recovery GHLRMMGT GSM HLR Mobility Management GHLRSMGTGSM HLR Subscriber Management GHLRSMSGSM HLR Short Message Service GHLRSSCBGSM HLR Supplementary Service Call Barring GHLRSSCFGSM HLR Supplementary Service Call Forwarding GHLRSSCWGSM HLR Supplementary Service Call Waiting GHLRSSPWGSM HLR Password Registration HISTATSubscriber IMSI Status HLRWORKHLR Workload Handling HLRUSSDTHLR Unstructured Supplementary Services Data Traffic HSMG2HLR Subscriber Management V2 HSMQLOADHLR SMS Queue Overload HSMSOPSHLR Short Message Service Operations RREQUEST (OM group GHSBYACT) for Standby Requester Attempts
Standard
E-5
PREQUEST (OM group GHSBYACT) for Standby Provider Attempts
Real-time capacity usage and subscriber profile The peak and average capacity usage figures give an indication of the work demand made of the product. Since real-time capacity usage is related to the activity of subscribers in the network, the number of activated subscribers and the average transaction profile may be used to plan network growth. Requests acceptance ratio The Request Acceptance Ratio is the percentage of network requests accepted for processing by the HLR Application Entity. At this stage the message is a partially decoded TCAP request. Anything less than 100% means that the DMS-HLR has entered overload and has reduced its load by discarding or aborting requests.
Request Acceptance Ratio = Requests Accepted Total Number of Requests Requests Accepted = NETWORK + ADMIN +INTERNAL Total Number of Requests = Requests Accepted + DISCARD
Network acceptance ratio The Network Acceptance Ratio is the percentage of CCS7 Network requests accepted for processing by the HLR Application Entity. Any amount less than 100% indicates that the HLR is discarding network requests in order to reduce outgoing link overload.
Network Acceptance Ratio = Network Requests Accepted Total Number of Network Requests Network Requests Accepted = NETWORK Total Number of Network Request = NETWORK + LINKDIS
Transaction success ratio This is the percentage of accepted network requests that the DMS-HLR has completed without any error. Anything less than 100% indicates that transaction errors are occurring. The following log reports should be examined to identify the source of the errors. GHLR600 GSM MAP Transaction Error GHLR605 Supplementary Service Registration Error GHLR606 Supplementary Service Activation Error GHLR607 Supplementary Service Deactivation Error GHLR608 Supplementary Service Erasure Error GHLR609 Supplementary Service Interrogation Error
E-6
GHLR610 Supplementary Service VLR Inconsistency Error GHLR614 Supplementary Password Registration Error GHLR660 Unknown Subscriber GHLR661 Unknown Subscriber For SRI
Off-board AUC success ratio The Off-board AUC Success Ratio is the percentage of off-board authentication center (AUC) requests that are completed successfully. Anything less than 100% could indicate: a software inconsistency between the DMS-HLR and off-board AUC a temporary or persistent communication failure a possible hardware failure
The GHLR304 AUC Failure log reports should be examined to identify the cause. This indicator will not be generated if no off-board AUC requests are made. Off-board AUC distribution ratio The Off-board AUC Distribution Ratio is the percentage of authentication requests distributed to off-board processors. If there are no off-board AUCs provisioned, this ratio will always be zero. If there are off-board AUCs provisioned then in order to get the maximum capacity saving all AUC requests should be sent off-board. Anything less than 100% could indicate: too few off-board AUCs have been provisioned for the number of authentication requests being received a number of off-board AUCs have not been available to process requests (for example, taken off-line for maintenance) requests are being made for authentication algorithms which are not supported by the off-board AUCs
Supercharger effectiveness ratio This formula gives an indication of how well the Supercharger functionality is performing. It gives the ratio of Location Updates Requests to the Location Update Requests that result in no ISD being sent. Transaction resource high water mark This is the HLR transaction resource high water marks for: HLR Save Buffers, which are needed to process multiple Insert Subscriber Data (ISD) requests. Transaction Control Blocks (TCB), which are needed to process every request that reaches the HLR Application layer.
411-2231-827
Standard
E-7
Transaction Identities (TRID), which are needed to process every request that reaches the Transaction layer. Transaction Components, which are needed to process every component within a transaction. Extension Blocks (EXT), which are needed to process every request that reaches the Network Routing layer.
The number of transaction resources allocated should be engineered to ensure that the high water mark does not exceed 80%. Note: The transaction resources are sampled once per minute and the high water mark is the highest sampled value within the reported hour. This value may not be as great as the peak number of transaction resources used, but is useful for resource engineering. Transaction resource usage The DMS-HLR transaction management software is allocated the resources to handle concurrent transactions for: different subscribers, using Subscriber Control Blocks (SCBs) the same subscriber, using Transaction Control Blocks (TCBs) Note 1: The number of subscriber and transaction control blocks is set by Nortel. Note 2: No change should be attempted without consulting the Nortel. Changing this value requires a restart to take effect. The effect of not having enough subscriber of transaction control blocks is that new transactions will be aborted with a reason of resource unavailable temporary. The transaction resource usage indicators provide the operator with the peak percentage resource usage over the last hour. If the peak resource usage exceeds 90% then increasing the number of control blocks should be considered. An number of queue elements are allocated for handling internal Short Message Service (SMS) requests. Note: The number of queue elements is set by Nortel and is engineered to meet predicted SMS traffic levels under normal conditions. The effect of not having enough queue elements is that internal SMS messages may be lost. This is acceptable in overload conditions, but not under normal operating conditions. If the peak SMS queue resource usage exceeds 90% under normal operating conditions, then increasing the number of control blocks should be considered. This will require Nortels involvement.
E-8 (contin-
Requests involving a PSI A new tuple is added to the added to the log indicating the number of requests involving the PSI Operation. The Requests Involving a PSI count gives the number of SRI requests where a PSI was produced per subscriber in a given hour and maintains a count for the hour where the average was greatest.
Figure E-1 Requests Involving a PSI PSI Requests Requests Involving a PSI = --------------------------------------------------------Activated Subscribers
The PSI Requests count is taken from the PSIRQ OM register. USSD Messages A new entry is added to the log indicating the number of USSD messages handled by the HLR as a percentage of total subscribers active on the HLR. The USSD Indications & Requests count gives the number of ProcessUnstructuredSS-Request, UnstructuredSS-Request and UnstructuredSSNotify messages handled at the HLR over all subscribers in a given hour and maintains a count for the hour where the average was greatest. Please refer to the figure below - USSD Indications & Requests (PUSSR, USSR, USSN).
Figure E-2 USSD Indications & Requests (PUSSR, USSR, USSN) PUSSIN + USSRIN + USSNIN + PUSSRQ + USSRRQ + USSNRQ USSD Indications & Request = ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Total number of active Subscribers
(end)<zfmt;
GPRS Location Update Requests A new entry is added to the log indicating the number of GPRS Location Update Requests received by the HLR as a percentage of total subscribers registered on the HLR. The GPRS Location Update Requests count gives the number of GUL Requests received from SGNSs over all Subscribers in a given hour and maintains a count for the hour where the average was greatest. Please refer to the figure below - GPRS Location Update Request- for the formula
Figure E-3 GPRS Location Update Requests UGLRQ GPRS Location Update Requests = --------------------------------------------------------Total num Subscribes
411-2231-827
Standard
02.05
September 2001
E-9
The total number of subscribers refers to the total number of activated subscribers on the HLR. The figure is displayed in the log. GVLR300 This log report generates when the VLR does not have enough memory to store VGS data at ISD time. This log report informs the craftsperson of the memory exhaustion and any possible action to take. Format GHLR300 mmmdd hh:mm:ss ssdd TBL Resource Unavailable CPID Location: <object description> Status: <trouble status> Action: <trouble action> Description: <application-specific text> Report example MSCI***GVLR300 APR23 15:26:17 0544 TBL Resource Unavailable Location: GSMVLR Database Resource Status: Trouble alert Trouble: Lack of system resources Action: Review resource provisioning Description: Unable to add Voice Group Service data to VLR database. Check MAX_VGS_SUBS_IN_VLR in table OFCENG. Action The office parameter MAX_VGS_SUBS_IN_VLR is increased by the network operator to allocate more memory to hold subscriber data. Associated OM registers There are no OM groups associated with this log report.
MSC log reports

Following are the MSC log reports that provide information specific to GSMR functionalities: GBCS300 GC6000 GGCN300 GMSC301 GMSC302 GMSC609 GMSC612
GSM
E-10
GBCS300 This log report generates when the MSC attempts to establish a portion of a VGCS/VBS call on a BSC in the group call area. However, the BSC responds to the VGCS/VBS Setup message with a VGCS/VBS Setup Refuse with the cause value, 0100101 Resource Unavailable, BSS not equipped. Format GBCS300 <mmdd hh:mm:ss> <ssdd> TBL Datafill Fault Routeset Name: <BSS NAME> Group Call Area: <Group Call Area ID> Group ID: <Group ID> Description: BSS not equipped to support VGCS/VBS group call Action: Ensure all cells that belong to the group call are controlled by a BSS that supports VGCS/VBS group calls. Report example GBCS300 MAR22 08:23:01 7635 TBL Datafill Fault Routeset Name: BSC0538 Group Call Area: 2153 Group ID: 1190 Description: BSS not equipped to support VGCS/VBS group call Action: Ensure all cells that belong to group call are controlled by a BSS that supports VGCS/VBS group calls. Action Ensure all cells that belong to the group/broadcast service area (table GCAREA) are controlled by a BSS that supports VGCS/VBS calls. Associated OM registers When this log report is generated for a VGCS call, the following registers from OM group MCLUSTER are pegged: BBSCATT BBSCEST
When this log report is generated for a VBS call, the following registers from OM group MCLUSTER are pegged: GBSCATT GBSCEST
GC6000 This log report is generated when the VGCS database free queue is corrupted
411-2231-827
the VGCS database bucket queue is corrupted the VBS database free queue is corrupted
Standard
E-11
the VBS database bucket queue is corrupted
Format <NodeName> <LogNameReportId> <MMMDD> <HH:MM:SS> <XXXX> <LogType> <Log Name> <Description in Text> Report example MSCI GC6000 NOV11 11:57:35 9600 INFO GC LOG 0001: VGCS Audit - Rebuild Free Queue. Action to be taken No action is required. Associated OM registers There are no OM registers associated with this log report. GGCN300 This log report generates when a group call (GC) number cannot be allocated. Format GGCN300 <mmdd hh:mm:ss> <ssdd> GCN Resource Unavailable Group Call Reference: <GCRef> Action: Review GCN resource provisioning in table DNROUTE. Description: Unable to allocate Group Call Number. Report example MSCA GGCN300 MAR02 08:23:01 7635 GCN Resource Unavailable Group Call Reference: 12345678 Action: Review GCN resource provisioning Description: Unable to allocate Group Call Number. Action When this log report generates because a GC number cannot be allocated, datafill additional GC numbers in table DNROUTE. Associated OM registers There are no OM registers associated with this log report. GMSC301 This log report generates when hardware is inappropriately installed or datafill is incorrect.
GSM
E-12
Format GMSC301 mmdd hh:mm:ss ssdd Resource Unavailable Location: <GRID> Status: <Trouble Status> Trouble: <Trouble Text> Action: <Action Text> Description: <Description Text> Report example Following is an example when there is an error in the call processing software. GMSC301 OCT17 05:22:01 2104 Resource Unavailable Location: GSMMSC Software Call Processing Status: Trouble alert Trouble: Request denied Action: Lack of system resources Description: The digit collection cannot be started. Check the datafill or resource. Action Check the system resources and datafill. Associated OM registers There are no OM registers associated with this log report. GMSC302 This log report generates when: a service subscriber originates a VGCS/VBS call from RMSC, a dispatcher originated VGCS/VBS call where GCR query is triggered in RMSC.
Format GMSC302 mmdd hh:mm:ss ssdd TBL Datafill Fault Location: <GRID> Status: <Trouble Status> Trouble: <Trouble Text> Action: <Action Text> Description: <Description Text> Report example Following is an example when a service subscriber dials GID from RMSC: GMSC302 OCT17 05:22:01 2104 TBL Datafill Fault MSCPS 010000 Location: GSMMSC Software Call Processing
E-13
Status: Trouble alert Trouble: Request denied Action: Check datafill and correct if necessary LAC: 1 Cell ID: 1 MSISDN: 614112401011 Dialed Digits: 123 Description: Illogical triggering of GCR query in RMSC. Following is an example when a dispatcher originated VGCS/VBS call triggers a GCR query in non-AMSC: GMSC302 OCT17 05:22:01 2104 TBL Datafill Fault MSCPS 010000 Location: GSMMSC Software Call Processing Status: Trouble alert Trouble: Request denied Action: Check datafill and correct if necessary Dialed Digits: 9268989123 Description: Illogical triggering of GCR query in RMSC Action The action to be taken is as follows: Check the ANCH_RLF field in table GCR against the GCRef given. Check the translation datafill in the gateway MSC (for dispatcheroriginator VGCS/VBS call in RMSC only).
Associated OM registers There are no OM registers associated with this log report. GMSC609 This log report reports successful or unsuccessful setup of an emergency call. The information contained in this log depends upon several factors, including successful or unsuccessful call setup and the type of mobile identifier that is known to the system. Successful emergency call setup log information The GMSC609 log indicates success when the setup of the emergency call to the MSC was successful but the call could not complete due to a lack of system resources. The lack of system resources, and thus the non-completion of the call, is reported in log GMSC610.
GSM
E-14
After a successful emergency call setup, Log GMSC609 reports the following information: Mobile Station ISDN number (MSISDN). May be issued if the MSISDN is known, as is the case for emergency calls set up by the SETUP message when a national emergency code has been dialed. International Mobile Subscriber Identity (IMSI). Issued if the Mobile Station (MS) has been identified by the IMSI and the MSISDN is not known, as is the case for emergency calls set up by the EMERGENCY SETUP message when the international GSM PCS1900 emergency code 112 (911 for U.S.) has been dialed. International Mobile Equipment Identity (IMEI). Issued if the MS has been identified by the IMEI, as is the case for emergency calls set up by the EMERGENCY SETUP message after the international GSM PCS1900 emergency code 112 (911 for U.S.) has been dialed and no Subscriber Identity Module (SIM) is provided in the mobile. Location Area Code (LAC). Shown in Table LAC. Cell Identifier (CELL ID). Shown in Table LAC. Emergency Number (EMRG NUMBER). Obtained from Table LAC and used to route the call to an emergency center based on the cell of call origination and the Emergency Code.
Log information for emergency call setup that is unsuccessful An unsuccessful attempt to set up an emergency call may occur when the International Mobile Equipment Identity is provided by the MS, but the IMEI is not accepted by the network operator. The following information is provided in Log GMSC609: International Mobile Equipment Identity (IMEI). Provided by MS. Location Area Code (LAC). Shown in Table LAC. Cell Identifier (CELL ID). Shown in Table LAC.
Format The following are two formats for Log GMSC609: Format for successful emergency call setup GMSC609 mmdd hh:mm:ss ssdd INFO EMERGENCY CALL Location: <object description> LAC:<Location Area Code> Cell ID: <cell identifier> MSISDN: <MSIDN number> IMSI: <IMSI number> IMEI: <IMEI number> EMRG NUMBER: <Emergency Number> Description: <application-specific text>
E-15
Format for unsuccessful emergency call setup GMSC609 mmmdd hh:mm:ss ssdd INFO EMERGENCY CALL Location: <object description> LAC: <Location Area Code> Cell ID: <cell identifier> IMEI:<IMEI number> Description: <application-specific text> Report example Following are examples of log report GMSC609: Successful emergency call setup using MSISDN GMSC609 JAN01 00:00:07 2600 INFO EMERGENCY CALL Location: GSMMSC Software Call Processing LAC: 2 Cell ID: 21 MSISDN: 123456789876 EMRG NUMBER: 123456999 Description: Emergency Call Setup Successful emergency call setup using IMEI GMSC609 JAN01 00:00:07 2600 INFO EMERGENCY CALL Location: GSMMSC Software Call Processing LAC: 2 Cell ID: 21 IMEI: 232012010000101 EMRG NUMBER: 123456112 Description: Emergency Call Setup Emergency call setup: IMEI as mobile identifier not accepted by the network. Rel. Cause: 5. GMSC609 JAN01 00:00:07 2600 INFO EMERGENCY CALL Location: GSMMSC Software Mobility Management LAC: 2 Cell ID: 21 IMEI: 232012010000101 Description: Emergency call setup: IMEI as mobile identifier not accepted by the network. Rel. Cause: 5. Action No action is required. Associated OM registers There are no OM registers associated with this log report.
GSM
E-16
GMSC612 This log report generates when one of the following events occurs: no route to destination is found forced release caused by: integrity lost lockout call failure release call forced release caused by: CCS7 circuit release reset circuit when a mobile originates a call and the call gets barred due to operator imposed barring
Format GMSC612 mmdd hh:mm:ss ssdd INFO Fail Complete <CPID> Location: GSMMSC Software Call Processing MSG: <IWF message received> Code: <response code> MIT: <mobile-side IWF trunk group> NIT: <network-side trunk group> MSISDN: <MSIDN number> IPADDR: <Internet Protocol Address> Ele: <Element number> Port Number: <UDP/IP port> Description: <application-specific text> Report example GMSC612 JUN01 14:45:17 2007 INFO Fail Complete MSCPS 01001C Location: GSMMSC IWF Data Services MSISDN: 61411000233001 MIT=T1MIT 18 msg: Activate-Resp Code: Request Denied Description: The IWF Element selected could not be activated. Maintenance action is required. MIT and NIT were set SB. Analysis This log report is generated when the response code included in the IWFActivate Response message indicates that the select IWF Element was not activated. The MIT and mate NIT for this IWF Element are set system busy so that this pair is not selected until the problem is corrected.
411-2231-827
Standard
02.05
September 2001
E-17
Also, this log report is generated when the response code included in the IWF-Release-Response message indicates that the select IWF Element failed when being released. The MIT and mate NIT for this IWF Element are set system busy so that this pair is not selected until the problem is corrected. Action Perform maintenance on the indicated IWF Element. Associated OM registers The OM OUTFAIL is pegged for both the MIT and mate NIT groups each time this log report is generated.
GSM
E-18
411-2231-827
Standard
02.05
September 2001
F-1
The Operational Measurements (OM) system provides the operating company with switch performance measurements, traffic measurements, and service data. System engineers and technicians use OM records to ensure that the system operates at its full potential and optimum efficiency. Operational Measurements are broken down to specific OM groups and their associated registers. Each OM group applies to some aspect of call processing. There are hundreds of OM groups. This appendix describes only the OM groups that provide information specific to the GSM-R functionalities. These OM groups include eMLPPSS EVGCS GHLRADM3 GHLRBS GMAPCH2 HLRFA MCLUSTER MLPP MSCGCS MSCUPLNK
Group eMLPPSS
This group gathers information on the eMLPP supplementary service for each call. Currently, there are seven precedence levels defined. Each call may belong to any one of the precedence level.
GSM
F-2
The OM for the calling subscriber pegs only if the calling subscriber has an eMLPP subscription. The OM for the calling subscriber pegs with whatever the precedence level {4, 3, 2, 1, 0, B, A} found in the CM Service Request message. If no precedence is found in the CM Service Request message, the OM does not peg for the originator. Since the precedence level for the called party is the precedence of the calling subscriber, it always pegs for the called party. Registers eMLPP registers are displayed at the Maintenance and Administration Position (MAP) as follows:
PRECDNC4 PRECDNC0 PRECDNC3 PRECDNCB PRECDNC2 PRECDNCA PRECDNC1
Table F-1 describes the registers in group eMLPP. The registers appear in alphanumeric order and not in the order in which they are displayed at the MAP.
Table F-1 Descriptions of registers in OM group eMLPP Register name PRECDNCA Definition This register pegs when the subscriber originating the call has precedence level A. This register also pegs when a call terminates to a mobile station with precedence level A.
PRECDNCB
This register pegs when the subscriber originating the call has precedence level B. This register also pegs when a call terminates to a mobile station with precedence level B.
This register pegs when the subscriber originating the call has precedence level 0. This register also pegs when a call terminates to a mobile station with precedence level 0.
PRECDNC0
PRECDNC1
sheet 1 of 2
411-2231-827
Standard
02.05
September 2001
F-3
Table F-1 Descriptions of registers in OM group eMLPP Register name PRECDNC2 Definition This register pegs when the subscriber originating the call has precedence level 2. This register also pegs when a call terminates to a mobile station with precedence level 2.
PRECDNC3
sheet 2 of 2
PRECDNC4
OMSHOW example
CI> omshow eMLPP active eMLPP CLASS: ACTIVE START:1999/05/17 11:30:00 MON; STOP: 1999/05/17 11:50:10 MON; SLOWSAMPLES: 13 ; FASTSAMPLES: 121 ; PRECDNC4 PRECDNC0 0 55 45 PRECDNC3 PRECDNCB 32 49 PRECDNC2 PRECDNCA 23 56 PRECDNC1 45
Group EVGCS
EVGCS contains registers that count the number of Emergency VGCS calls. Registers EVGCS registers are displayed at the MAP as follows:
EVGCSSS EVGCSSS2 EVGCSDI EVGCSDI2
Table F-2 describes the registers in OM group EVGCS. The registers appear in alphanumeric order and not in the order in which they are displayed at the MAP.
GSM
F-4
Appendix F: OMs generated by GSM-R features Table F-2 Descriptions of registers in OM group EVGCS Register name EVGCSSS EVGCSSS2 EVGCSDI EVGCSDI2 Definition
This peg counts the Emergency VGCS calls originated by a service subscriber. This is an extension register of EVGCSSS. This peg counts the Emergency VGCS calls originated by a dispatcher. This is an extension register of EVGCSDI.
OMSHOW
>omshow evgcs active EVGCS CLASS: ACTIVE START:2000/06/28 14:30:00 WED; STOP: 2000/06/28 14:54:47 WED; SLOWSAMPLES: 15 ; FASTSAMPLES: 149 ; EVGCSSS EVGCSSS2 23 4 EVGCSDI EVGCSDI2 56 2
Group GHLRADM3
GHLRADM3 maintains statistics related to the DMS-HLR supplementary services. This OM group deals with GSM defined supplementary services only. Registers GHLRADM3 registers are displayed at the MAP as follows:
MPYT3PR MPTYPR CLIRPR AOCCPR COLRPR ECTPR UUS1PR MPTY3PR2 MPTYPR2 CLIRPR2 AOCCPR2 COLRPR2 ECTPR2 UUS1PR2 MPTY6PR CLIPPR AOCIPR COLPPR CUGPR FAPR EMLPPPR MPTY6PR2 CLIPPR2 AOCIPR2 COLPPR2 CUGPR2 FAPR2 EMLPPPR2
411-2231-827
Standard
02.05
September 2001
F-5
Table F-3 describes the registers in group GHLRADM3. The registers appear in alphanumeric order and not in the order in which they are displayed at the MAP.
Table F-3 Descriptions of registers in OM group GHLRADM3 Register name AOCCPR AOCCPR2 AOCIPR AOCIPR2 CLIPPR Definition This peg counts the number of subscribers provisioned with Advice of Charge Charges. This is an extension register of AOCCPR. This peg counts the number of subscribers provisioned with Advice of Charge Information. This is an extension register of AOCIPR. This peg counts the instantaneous number of subscribers who are provisioned with the Supplementary Service Calling Line Identification Presentation (CLIP). This register is set on a periodic basis, to the value held within the database. The value within the database is incremented when a subscriber has CLIP provisioned and decremented when CLIP is withdrawn. CLIPPR2 CLIRPR This is an extension register of CLIPPR. This peg counts the instantaneous number of subscribers who are provisioned with the Supplementary Service Calling Line Identification Restriction (CLIR). This register is set on a periodic basis, to the value held within the database. The value within the database is incremented when a subscriber has CLIR provisioned and decremented when CLIR is withdrawn. CLIRPR2 COLPPR This is an extension register of CLIRPR. This peg counts the number the number of subscribers provisioned with the Supplementary Service Connected Line Identification Presentation (COLP) at the DMSHLR. This is an extension register of COLPPR.
sheet 1 of 3
COLPPR2
GSM
F-6
Appendix F: OMs generated by GSM-R features Table F-3 Descriptions of registers in OM group GHLRADM3 Register name COLRPR Definition
This peg counts the number of subscribers provisioned with the Supplementary Service, Connected Line Identification Restriction (COLR) at the DMS-HLR. This is an extension register of COLRPR. This peg counts the number of subscribers provisioned with the supplementary service, Closed User Group (CUG) at the DMS-HLR. This is an extension register of CUGPR. This peg counts the number of subscribers provisioned with the Call Transfer supplementary service at the DMS-HLR. This is an extension register of ECTPR. This pegs counts the number of subscribers provisioned with eMLPP service. This is an extension register of EMLPPPR. This pegs counts the number of subscribers provisioned with functional addressing service. This is an extension register of FAPR. This peg counts the instantaneous number of subscribers who are provisioned with the Supplementary Service Multi Party (MPTY). This register is set, on a periodic basis, to the value held with the database. The value within the database is incremented when a subscriber has MPTY provisioned and decremented when MPTY is withdrawn.
COLRPR2 CUGPR
CUGPR2 ECTPR
ECTPR2 EMLPPPR EMLPPPR2 FAPR FAPR2 MPTYPR
MPTYPR2 MPTY3PR MPTY3PR2 MPTY6PR
This is an extension register of MPTYPR. This peg counts the number of subscribers provisioned with the Multi-Party flavour M3PORT at the DMS-HLR. This is an extension register of MPTY3PR. This peg counts the number of subscribers provisioned with the Multi-Party flavour M6PORT at the DMS-HLR.
sheet 2 of 3
411-2231-827
Standard
02.05
September 2001
F-7
Table F-3 Descriptions of registers in OM group GHLRADM3 Register name MPTY6PR2 UUS1PR UUS1PR2 Definition This is an extension register of MPTY6PR. This pegs counts the number of subscribers provisioned with user-to-user signaling 1 service. This is an extension register of UUS1PR.
sheet 3 of 3
OMSHOW
OMSHOW GHLRADM3 ACTIVE GHLRADM3 CLASS: ACTIVE START:1999/03/23 03:30:00 TUE; STOP: 1999/03/23 11:38:46 TUE; SLOWSAMPLES: 3 ; FASTSAMPLES: 27 ; MPTY3PR MPTYPR CLIRPR AOCCPR COLRPR ECTPR UUS1PR 0 0 0 0 0 0 0 0 MPTY3PR2 MPTYPR2 CLIRPR2 AOCCPR2 COLRPR2 ECTPR2 UUS1PR2 0 0 0 0 0 0 0 MPTY6PRMPTY6PR2 CLIPPRCLIPPR2 AOCIPRAOCIPR2 COLPPRCOLPPR2 CUGPRCUGPR2 FAPRFAPR2 EMLPPPREMLPPPR2 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Group GHLRBS
This OM group maintains statistics related to the DMS-HLR basic services. Registers GHLRBS registers are displayed at the MAP as follows:
TPHNY SMMT CDA FAX3 SPCHCDA ALTSCDA VBS TPHNY2 SMMT2 CDA2 FAX32 SPCHCDA2 ALTSCDA2 VBS2 AXTPHNY SMMO CDS ALTSPFX SPCHCDS ALTSCDS VGCS AXTPHNY2 SMMO2 CDS2 ALTSPFX2 SPCHCDS ALTSCDS2 VGCS2
GSM
F-8
Table F-4 describes the registers in group GHLRBS. The registers appear in alphanumeric order and not in the order in which they are displayed at the MAP . Table F-4 Descriptions of registers in OM group GHLRBS Register name ALTSCDA Definition This register counts the number of subscribers provisioned with alternate speech and data circuit asynchronous service. This is an extension register of ALTSCDA. This register counts the number of subscribers provisioned with alternate speech and data circuit synchronous service. This is an extension register of ALTSCDS. This register counts the number of subscribers provisioned with alternate speech fax service. This is an extension register of ALTSPFX. This register counts the number of subscribers provisioned with auxiliary telephony service. This is an extension register of AXTPHNY. This register counts the number of subscribers provisioned with circuit duplex asynchronous service. This is an extension register of CDA. This register counts the number of subscribers provisioned with circuit duplex synchronous service. This is an extension register of VBS. This register counts the number of subscribers provisioned with fax service. This is an extension register of FAX. This register counts the number of subscribers provisioned with originating mobile service. This is an extension register of SMMO.
sheet 1 of 2
ALTSCDA2 ALTSCDS
ALTSCDS2 ALTSPFX
ALTSPFX2 AXTPHNY
AXTPHNY2 CDA CDA2 CDS CDS2 FAX FAX2 SMMO SMMO2
411-2231-827
Standard
02.05
September 2001
F-9
Table F-4 Descriptions of registers in OM group GHLRBS Register name SMMT SMMT2 SPCHCDA Definition This register counts the number of subscribers provisioned with terminating mobile service. This is an extension register of SMMT. This register counts the number of subscribers provisioned with speech followed by circuit duplex asynchronous service. This is an extension register of SPCHCDA. This register counts the number of subscribers provisioned with speech followed by circuit duplex synchronous service. This is an extension register of SPCHCDS. This register counts the number of subscribers provisioned with telephony service. This is an extension register of TPHNY. This register counts the number of subscribers provisioned with VBS through datafill in table GHLRBSVC. This is an extension register of VBS. This register counts the number of subscribers provisioned with VGCS through datafill in table GHLRBSVC. This is an extension register of VGCS.
sheet 2 of 2
SPCHCDA2 SPCHCDS
SPCHCDS2 TPHNY TPHNY2 VBS
VBS2 VGCS
VGCS2
GSM
F-10 Appendix F: OMs generated by GSM-R features
OMSHOW example
CI> omshow GHLRBS active GHLRBS CLASS: ACTIVE START:1999/05/17 11:30:00 MON; STOP: 1999/05/17 11:50:10 MON; SLOWSAMPLES: 13 ; FASTSAMPLES: 121 ; TPHNY SMMT CDA FAX3 SPCHCDA ALTSCDA VBS 0 9 7 16 15 0 0 4 TPHNY2 SMMT2 CDA2 FAX32 SPCHCDA2 ALTSCDA2 VBS2 0 0 0 0 0 0 0 AXTPHNY SMMO CDS ALTSPFX SPCHCDS ALTSCDS VGCS 5 11 9 0 0 0 4 AXTPHNY2 SMMO2 CDS2 ALTSPFX2 SPCHCDS2 ALTSCDS2 VGCS 9 0 0 0 0 0 0
Group GMAPCH2
This OM group measures the number of requests and responses received for each Prepare Group Call operation, the number of Forward Group Call, and the number of Process Group Call Operations that are implemented in the MAP layer. Registers GMAPCH2 registers are displayed at the MAP as follows:
PRHOREQ PRSHREQ GMPSIRES RCHRES PGCRES PRGCREQ PRHORQ2 PRSHRES GMPSIRS2 RCHRS2 PGCRS2 PRGCRQ2 PRHORES GMPSIREQ RCHREQ PGCREQ FGCREQ PRHORS2 GMPSIRQ2 RCHRQ2 PGCRQ2 FGCRQ2
411-2231-827
Standard
02.05
September 2001
F-11
Table F-5 describes the GMAPCH2 registers that pertain to GSMR02 functionality. The registers appear in alphanumeric order and not in the order in which they are displayed at the MAP.
Table F-5 Descriptions of registers in OM group GMAPCH2 Register name FGCREQ FGCRQ2 PGCREQ PGCRQ2 PGCRES PGCRS2 PRGCREQ PRGCRQ2 Definition This register counts the number of Forward Group Call requests. This register is an extension of register FGCREQ. This register counts the number of Prepare Group Call requests. This register is an extension of register PGCREQ. This register counts the number of Prepare Group Call results. This register is an extension of register PGCRES. This register counts the number of Process Group Call requests. This register is an extension of register PRGCREQ.
OMSHOW
GMAPCH2 CLASS: ACTIVE START: 2001/05/12 12:00:00 TUE; STOP: 2001/05/12 12:29:03 TUE; SLOWSAMPLES: 1 FASTSAMPLES: 0; PRHOREQ PRSHREQ GMPSIRES RCHRES PGCRES PRGCREQ 0 0 0 0 0 0 PRHORQ2 PRSHRQ2 GMPSIRS2 RCHRS2 PGCRS2 PRGCRQ2 0 0 0 0 0 0 PRHORES GMPSIREQ RCHREQ PGCREQ FGCREQ 0 0 0 0 0 PRHORS2 GMPSIRQ2 RCHRQ2 PGCRQ2 FGCRQ2 0 0 0 0 0
GSM
Group HLRFA
This OM group measures the data related with functional addressing. Registers HLRFA registers are displayed at the MAP as follows:
REGISRQ REGRQER DEREGRQ DRGRQERR INTERRQ INTRQER FERAREQ FERRQER REGISRQ2 REGRQER2 DEREGRQ2 DRGRQERR2 INTERRQ2 INTRQER2 FERAREQ2 FERRQER2 REGINER REGCNERR DRGINER DRGCNERR INTINER INTCNER FERINER FERCNER REGINER2 REGCNER2 DRGINER2 DRGCNERR2 INTINER2 INTCNER2 FERINER2 FERCNER2
Table F-6 describes the registers in group GHLRFA. The registers appear in alphanumeric order and not in the order in which they are displayed at the MAP.
Table F-6 Descriptions of registers in OM group GHLRFA Register name DEREGRQ DEREGRQ2 DRGINER Definition This register counts the total number of all FA deregistration requests. This register is an extension of register DEREGRQ. This register counts the total number of errors sent to the mobile through the MSC by the HLRm after processing the FA deregistration request from the mobile. This register is an extension of register DRGINER. This register counts the total number of FA deregistration Request errors that occurred because of no response from the HLRf (timeout error). This register is an extension of register DRGRQERR. This register counts the total number of FA deregistration errors sent from the HLRf. This register is an extension of register DRGCNERR. This register counts the number of Follow Me (FM) Forced Erasure requests.
sheet 1 of 3
DRGINER2 DRGRQERR
DRGRQERR2 DRGCNERR DRGCNERR2 FERAREQ
411-2231-827
Standard
02.05
September 2001
F-13
Table F-6 Descriptions of registers in OM group GHLRFA Register name FERAREQ2 FERINER Definition This register is an extension of register FERAREQ. This register counts the errors the HLR sends to the mobile through the MSC/VLR after the HLR processes the FM Forced Erasure request from the mobile. This register is an extension of register FERINER. This register counts the number of FM Forced Erasure Request errors that occurred because of no response from the Follow Me functional node (time-out error). This register is an extension of register FERRQER. This register counts the number of FM Forced Erasure errors received from the Follow Me functional node. This register is an extension of register FERCNER. This register counts the total number of FA interrogation errors sent from the HLRf. This register is an extension of register INTCNER. This register counts the total number of all FA interrogation requests. This register is an extension of register INTERRQ. This register counts the total number of errors sent to the mobile through MSC by the HLRm after processing the FA interrogation request came from mobile. This register is an extension of register INTINER. This register counts the total number of FA Interrogation Request errors that occurred because of no response from the HLRf (timeout error). This register is an extension of register INTRQER. This register counts the total number of FA Registration errors sent from the HLRf. This register is an extension of register REGCNER.
sheet 2 of 3
FERINER2 FERRQER
FERRQER2 FERCNER FERCNER2 INTCNER INTCNER2 INTERRQ INTERRQ2 INTINER
INTINER2 INTRQER
INTRQER2 REGCNERR REGCNER2
GSM
F-14 Appendix F: OMs generated by GSM-R features Table F-6 Descriptions of registers in OM group GHLRFA Register name REGINER Definition
This register counts the total number of errors sent to the mobile through the MSC by the HLRm after processing the FA Registration request from the mobile. This register is an extension of register REGINER. This register counts the total number of all FA registration requests. This register is an extension of register REGISRQ. This register counts the total number of FA Registration Request errors that occurred because of no response from the HLRf (timeout error). This register is an extension of register REGRQER.
sheet 3 of 3
REGINER2 REGISRQ REGISRQ2 REGRQER
REGRQER2
OMSHOW
> OMSHOW HLRFA ACTIVE CLASS: ACTIVE START: 1997/12/31 23:59:59 WED; STOP: 1998/01/01 00:00:00 THU; SLOWSAMPLES: 3; FASTSAMPLES: 21; KEY ( ) REGISRQ REGRQER DEREGRQ DRGRQERR INTERRQ INTRQER FERAREQ FERRQER 0 0 0 0 0 0 0 0 REGISRQ2 REGRQER2 DEREGRQ2 DRGRQERR2 INTERER2 INTRQER2 FERAREQ2 FERRQER2 0 0 0 0 0 0 0 REGINER REGCNERR DRGINER DRGCNERR INTINER INTCNER FERINER FERCNER 0 0 0 0 0 0 0 REGINER2 REGCNER2 DRGINER2 DRGCNERR2 INTINER2 INTCNER2 FERINER2 FERCNER2 0 0 0 0 0 0
OM logic flow or pseudo code Figures F-1 through F-3 show the logic flow or pseudo code for the OM registers in this group. Figure F-1 shows the logic flow for the FA registration process.
Nortel Networks Confidential Figure F-1 OM logic flow for the FA registration process
F-15
Getting node selector from table GHLRUSSD
Is this FA node selector? Y Operation type= Registration? Y Increment REGISRQ register
(1)
Error sent after processing reg. message by HLR? Y Increment REGINER register.
(1.1)
Finish
GSM
(1.1)
Any error sent by HLRm because of not response from HLR? Y Increment REGRQER register
Any error sent to HLRm by HLRf?
Y Increment REGCNER register
Finish
Figure F-2 shows the logic flow for an FA deregistration process.
411-2231-827
Standard
02.05
September 2001
F-17
OM logic flow for a FA deregistration process (1) N Operation type = deregistration? Y Error sent after processing dereg. message by HLRm? Y (2)
(2.1)
Increment DRGINER register
Finish
GSM
(2.1)
Any error sent by HLRm because of no response from HLRf? Y Increment DRGRQER register
Any error sent to HLRm by HLRf?
Y Increment DRGCNER register
Finish
Figure F-2 shows the logic flow for an FA interrogation process.
411-2231-827
Standard
02.05
September 2001
F-19
Figure F-2 OM logic flow for an FA interrogation process
(2) Y N Operation type = Interrogation? Y Error sent after processing inter. message by HLRm? Y
(3.1)
Increment INTINER register
Finish
GSM
(3.1)
Any error sent by HLRm because of no response from HLRf? Y Increment INTRQER register
Any error sent to HLRm by HLRf? Y Increment INTCNER register
Finish Figure F-3 shows the logic flow for an FM Forced Erasure process.
411-2231-827
Standard
02.05
September 2001
F-21
Figure F-3 OM logic flow for an FM Forced Erasure process
Getting node selector from table GHLRUSSD
Is SSCODE=FA? Y
GM2728 application
Operation Type = Erasure & optional parameter1= 88 ? Y Increment FERAREQ register.
N GM3004 application
Any error sent during processing forced erasure message by HLR? Y Increment FERINER register
(1.1)
F in ish
GSM
(1.1)
Any error sent by HLRm because of no response from FFN? Y Increment FERRQER register
Any error sent to HLR by FFN ?
Y Increment FERCNER register
Finish
Group MCLUSTER
This OM group stores operational measurements of events that take place in a mobile cluster call (VBS or VGCS) terminating to a list of cells in the service area.
411-2231-827
Standard
02.05
September 2001
F-23
Registers MCLUSTER registers are displayed at the MAP as follows:

BMCLATT BMCLEST BBSCATT BBSCEST BCHLREQ BCHLASG BMCLATT2 BMCLEST2 BBSCATT2 BBSCEST2 BCHLREQ2 BCHLASG2 GMCLATT GMCLEST GBSCATT GBSCEST GCHLREQ GCHLASG GMCLATT2 GMCLEST2 GBSCATT2 GBSCEST2 GCHLREQ2 GCHLASG2
Table F-7 describes the registers in group MCLUSTER. The registers appear in alphanumeric order and not in the order in which they are displayed at the MAP.
Table F-7 Descriptions of registers in OM group MCLUSTER Register name BBSCATT BBSCATT2 BBSCEST BBSCEST2 BCHLASG BCHLASG2 BCHLREQ BCHLREQ2 BMCLATT BMCLATT2 BMCLEST BMCLEST2 GBSCATT Definition This peg counts the attempts to setup a VBS call on the BSC. This is an extension register of BBSCEST. This peg counts the times a call controlling SCCP connection is established for a VBS call. This is an extension register of BBSCEST. This peg stores the channel assigned for a VBS cluster call. This is an extension register of BCHLASG2. This peg counts the channel assignment requested for a VBS cluster call. This is an extension register of BCHLREQ2. This peg counts the attempts to setup a VBS call on The MSC. This is an extension register of BMCLATT. This peg counts the VBS calls established on the MSC. This is an extension register of BMCLEST. This peg counts the attempts to setup a VGCS call on the BSC.
sheet 1 of 2
GSM
F-24 Appendix F: OMs generated by GSM-R features Table F-7 Descriptions of registers in OM group MCLUSTER Register name GBSCATT2 GBSCEST GBSCEST2 GBSLASG GBSLASG2 GBSLREQ GBSLREQ2 GMCLATT GMCLATT2 GMCLEST GMCLEST2 Definition
This is an extension register of GBSCATT. This peg counts the times a call controlling SCCP connection is established for a VGCS call. This is an extension register of GBSCEST. This peg stores the channel assigned for a VGCS cluster call. This is an extension register of GBSLASG. This peg counts the channel assignment requested for a VGCS cluster call. This is an extension register of GBSLREQ. This peg counts the attempts to setup a VGCS call on The MSC. This is an extension register of GMCLATT. This peg counts the VGCS calls established on the MSC. This is an extension register of GMCLEST.
sheet 2 of 2
411-2231-827
Standard
02.05
September 2001
F-25
OMSHOW example
CI> omshow MCLUSTER active MCLUSTER CLASS: ACTIVE START:1999/05/17 11:30:00 MON; STOP: 1999/05/17 11:50:10 MON; SLOWSAMPLES: 13 ; FASTSAMPLES: 121 ; BMCLATT BMCLEST BBSCATT BBSCEST BCHLREQ BCHLASG 49 47 490 485 4880 4857 BMCLATT2 BMCLEST2 BBSCATT2 BBSCEST2 BCHLREQ2 BCHLASG2 0 0 0 0 0 0 GMCLATT GMCLEST GBSCATT GBSCEST GCHLREQ GCHLASG 39 37 390 384 3870 3847 GMCLATT2 GMCLEST2 GBSCATT2 GBSCEST2 GCHLREQ2 GCHLASG2 0 0 0 0 0
OM logic flow or pseudocode Figure F-4 shows the logic flow or pseudocode for OM group MCLUSTER.
GSM
F-26 Appendix F: OMs generated by GSM-R features Figure F-4 Pseudocode for OM group MCLUSTER
MSC
BSCZ
VGCS/VBS Setup
Peg OM -BSCATT for each BSC
VGCS/VBS Setup Ack

Peg OM -BSCEST for each Setup ACK from BSC
VGCS/VBS Assignment Request
Peg OM -CHLREQ for each channel resource (cell)
VGCS/VBS Assignment Result
Peg OM -CHLASG for each Assignment Result (success) from BSC
Signalling on the Call Controlling SCCP connection Signalling on the Resource Controlling SCCP connections
Group MSCGCS
This OM group captures the usage information for the VGCS and VBS services. In particular, this group captures the number of times that the service is invoked (successfully and unsuccessfully), and how it is invoked (by the service subscriber, the dispatcher, or the network-initiated group call origination).
411-2231-827
Standard
02.05
September 2001
F-27
Registers MSCGCS registers are displayed at the Maintenance and Administration Position (MAP) as follows:
VGCSINV VGCSNDT VBSINV VBSNDT VGCSSUB VGCSULGR VBSSUB VBSFAIL VGCSDSP VGCSFAIL VBSDSP VGCSDSPJ VBSDSPJ
Table F-8 describes the registers in group MSCGCS. The registers appear in alphanumeric order and not in the order in which they are displayed at the MAP.
Table F-8 Descriptions of registers in OM group MSCGCS Register name VBSDSP VBSDSPJ VBSFAIL VBSINV VBSNDT VBSSUB VGCSDSP Definition This peg counts the number of times a dispatcher invokes a VBS call. This peg counts the number of times a dispatcher joins in an ongoing VBS call. This peg counts the number of unsuccessful VBS invocations. This peg counts the number of VBS invocations. This peg counts the number of times the network invokes a VBS call. This peg counts the number of times a VBS call is invoked by a service subscriber. This peg counts the number of times a dispatcher invokes a VGCS call. This peg counts the number of times a dispatcher joins in an ongoing VGCS call. This peg counts the number of unsuccessful VGCS invocations. This peg counts the number of VGCS invocations. This peg counts the number of times the network invokes a VGCS call.
sheet 1 of 2
VGCSDSPJ VGCSFAIL VGCSINV VGCSNDT
GSM
F-28 Appendix F: OMs generated by GSM-R features Table F-8 Descriptions of registers in OM group MSCGCS Register name VGCSSUB VGCSULGR Definition
This peg counts the number of times a VGCS call is invoked by a service subscriber. This peg counts the number of granted uplink requests.
sheet 2 of 2
OMSHOW example
> OMSHOW MSCGCS ACTIVE MSCGCS CLASS: ACTIVE START:1999/04/23 16:00:00 FRI; STOP: 1999/04/23 16:18:37 FRI; SLOWSAMPLES: 12 ; FASTSAMPLES: 112 ; VGCSINV VGCSNDT VBSINV VBSNDT 250 11 270 20 VGCSSUB VGCSULGR VBSSUB VBSFAIL 65 600 150 4 VGCSDSP VGCSFAIL VBSDSP 24 2 30 VGCSDSPJ VBSDSPJ 150 70
Group MSUPLNK
This OM group provides information about uplink channel control for a GSM VGCS group call terminating to a list of cells. Registers MSUPLNK registers are displayed at the MAP as follows:
UPLKREQ UPLKREQ2 UPLKREJ UPLKREJ2
411-2231-827
Standard
02.05
September 2001
F-29
Table F-9 describes the registers in group MSUPLINK. The registers appear in alphanumeric order and not in the order in which they are displayed at the MAP.
Table F-9 Descriptions of registers in OM group MSUPLNK Register name UPLKREQ Definition This register increments when the MSC receives a VGCS Uplink Request from a BSC through the VGCS Call Control SCCP connection. This register is an extension register of UPLKREQ. This register increments when the MSC receives a VGCS Uplink Reject from a BSC through the VGCS Call Control SCCP connection. This register is an extension register of UPLKREJ.
UPLKREQ2 UPLKREJ
UPLKREJ2
OMSHOW example
>omshow MSCUPLNKactive MSCUPLNK CLASS: ACTIVE START:1999/05/17 11:30:00 MON; STOP: 1999/05/17 11:50:10 MON; SLOWSAMPLES: 13 ; FASTSAMPLES: 121 ; UPLKREQ 27 UPLKREQ2 0 UPLKREJ 9 UPLKREJ2 0
OM Logic Flow or Pseudocode Figure F-5 shows the logic flow or pseudocode for OM group MSCUPLNK.
GSM
Figure F-5 Logic flow or pseudocode for OM group MSCUPLNK
MSC
BSC
Uplink Request
Peg OM UPLKREQ
Uplink Request REJ

Peg OM UPLKREJ
411-2231-827
Standard
02.05
September 2001
G-1
Glossary
AC Account Code. ACRJ Anonymous Call Rejection. A-MSC Anchor MSC. AoCC Advice of Charge (Charging). AoCI Advice of Charge (Information). ASCI Advanced Speech Call Items. BAIC Barring of All International Calls. BAOC Barring of All Outgoing Calls. BHCA Busy Hour Completed Attempts. BIC-Roam Barring of Incoming Calls when Roaming outside the Home PLMN country.
Bearer services Services providing the lower layer communication functions according to layers 1 to 3 of those reference model.
GSM
G-2
Glossary
BOIC-exHC Barring of Outgoing International Calls Except those directed to the home PLMN Country. Breakout code Allow users within a GSM-R network to access other GSM-R networks and private networks. Each GSM-R network is assigned its own unique breakout code. Broadcast call A call made to all members of a pre-defined group within a local geographical area. BS Basic Service. BSC Base Station Controller. BSS Base Station Subsystem. Call type A prefix used to identify the user number dialed. Calling subscriber In context of VBS and VGCS, a calling subscriber is a service subscriber who subscribes to the VBS/VGCS service and initiates a VBS or VGCS call. A calling subscriber also can be a dispatcher. CC Country Code. CDN Called Number. CFB Call Forward Busy. CFN Call Forwarding Number. CFU Call Forward Unconditional. CFNRc Call Forward on Mobile Subscriber Not Reached.
Glossary
G-3
CFNRy Call Forward No Reply. CGN Calling Number. Class of registration The class of registration (CoR) defines a mobiles specific subscription capabilities. The following CoRs are available: A = engine/train cab-radio basic function, B = maintenance service user, C = operation support user and D = customer support user. CLIP Calling Line Identification Presentation. CLIR Calling Line Identification Restriction. CNAM Calling Name Display. COLP Connected Line Identification Presentation. COLR Connected Line Identification Restriction. COO Cell of Origin. CoR Class of Registration. COS Class of Service. CT Call Type. This is the first digit of the functional number or the functionally structured number that is used to distinguish between the different types of numbers allowed within the EIRENE numbering plan. It is an indication to the network of how to interpret the number dialled. CUG Closed User Group.
GSM
G-4
Glossary
CW Call Waiting. DBQ Database Query. Destination subscriber In context of VBS and VGCS, a destination subscriber is a subscriber or dispatcher that receives a VBS or VGCS call. Dispatcher A railways employee who connects to the network through standard radio links or ISDN. Dispatchers receive all VBS or VGCS calls to a certain group ID in a group call area. In addition, they can initiate VBS and VGCS calls. Dispatchers using the GSM-R network can be located outside the group call area. DMS-HLR Digital Multiplex System - Home Location Register. The master database of all GSM-R subscriber data. The DMS-HLR contains information such as subscriber provisioning and service information. The DMS-HLR also contains dynamic information, such as a subscribers current location. DMS-MSC Digital Multiplex System - Mobile Services-switching Center. The DMS-MSC is a member of the DMS family of switching systems. DTAP Direct Transfer Application Part. A category of signaling that uses MTP (layer 2) and SCCP (layer 3) from CCS7 between the BSS and DMS-MSC. DTAP messages are exchanged between the mobile station and the DMS-MSC. DTMF Dual-tone Multifrequency. E.164 A standard numbering plan for ISDN numbers that are of the format CC + NDC + SN. The number is at most 15 digits in length. EC European Commission. ECT Explicit Call Transfer.
411-2231-827
Standard
02.05
September 2001
Glossary
G-5
EFN Engine Function Number. EIRENE European Integrated Railway Radio Enhanced Network. A specification that defines the requirements for the GSM-R network. eMLPP Enhanced Multi-Level Precedence and Pre-emption. Provides subscribers various priority levels (also called precedence levels). The system uses the priority levels to provide precedence to network resources during call setup and call handover. The system also uses priority levels to pre-empt ongoing calls and applications. European Commission A group responsible for proposing and implementing the European Unions legislation. EXT Extension Service. FA Functional Addressing. For definition, see Functional Addressing. FANC Functional Address Network Code. FC Function Code. Function code Used within the functional addressing scheme. The FC identifies a user by the function the user performs rather than the public number of the users terminal. Functional Addressing A term used to describe the process of addressing a call using an address that represents the function a user performs, rather than a number identifying the users terminal equipment. Functional identity The full alphanumeric description of an end user or system used within the functional addressing scheme, identifying them by function rather than by a specific item of radio equipment or user subscription. Functional number The full number used within the functional addressing scheme to identify an end
G-6
Glossary
user or system by function rather than by a specific item of radio equipment or user subscription. FSN Functionally Structured Number. This number, like a functional number, also identifies a user by the function he represents rather than the public number of his terminal. However, unlike functional numbers, they are translated by MSC (not HLRf) into their corresponding public number. Such numbers are not registered (therefore, neither deregistered or interrogated) via USSD. FTN Forward-to Number. GCA Group Call Area. A group of cells in a particular DMS-MSC to which a VBS or VGCS call can be established. GCN Group Call Number. GCR Group Call Register. A database of al group call attributes. The GCR is indexed by the GCRef. GCRef Group Call Reference. The GCRef uniquely identifies a group of cells and the dispatchers to which a VBS or VGCS call can be established. GCQ Group Call Query. GHOT GSM Hot Billing Stream. GID Group Identity. The GID uniquely identifies a particular group of cells. The GID can be a maximum of 6 BCD digits (3 octets). Group call A call made to all members of a pre-defined group within a local geographic area. Only one member of the group may talk at any instant with all other members listening only. Group call digits Group call digits contain group call area digits and group IDs. The group call digits
Glossary
G-7
identify the cells and subscribers/dispatchers setup for the requested group call service. GSM Global System for Mobile Communications. An ETSI (European Telecommunication Standards Institute) driven standard for mobile communications. GSM-R GSM-Railways is a pan-European radio system that provides digital communications for multiple railway operations. Handover The process by which a connection between the GSM mobile and the network is maintained as the mobile moves from area to area. Control of the communication channel is passed from one base station to another or between different channels in one cell. HLR Home Location Register. A database that stores permanent data (identity information, authentication information, supplementary services etc.) of subscribers of the home network. HLRf One of the two logical parts of the DMS-HLR. The HLRf provides registration, deregistration, or interrogation capabilities based on the request type. The HLRf then sends the result back to the mobile through the HLRm and the DMS-MSC and VLR. The HLRf also processes requests from the DMS-MSC and VLR for FA call setup information. The HLRf provides the DMS-MSC and VLR with the MSISDN that corresponds to the functional number (FN). HLRm One of the two logical parts of the DMS-HLR. The HLRm stores all the subscriberbased data. When a mobile makes a registration-related request, the DMS-MSC and VLR send the request to the HLRm. The HLRm verifies the request based on the subscribers subscription data. HO Handover. HPLMN Home Public Land Mobile Network. IAC Integrated Acknowledgement Center.
G-8
Glossary
IAM Incoming Acknowledgement Message. IE Information Elements. IMSI International Mobile Subscriber Identity. A 15-digit radio path subscriber identity that is used during signaling transactions between the mobile and the fixed network to uniquely identify each mobile subscriber. IN VLR Intelligent VLR International calls The following types of GSM-R calls are considered to be international calls: calls from one RAC to another RAC and calls from one country code (CC) to another CC for public calls. ISDN Integrated Services Digital Network. ISUP ISDN User Part. Q.730, Q.761-Q.764. LCO Local Calls Only. Location dependent addressing A term used to describe the process of addressing a particular function (typically a controller) based on the current location of the user (typically a train). MCT Malicious Call Trace. MHz Megahertz. MLPP Multi-level Precedence and Pre-emption. MORANE MObile RAdio for Railways Networks in Europe. A project funded by the European Commission. The objective of MORANE is to specify, develop, test, and validate prototypes of a new radio system that would meet the global requirements of
Glossary
G-9
railways. MPTY Multi-party service. For definition, see Multi-party call. MSC Mobile Switching Center. The network entity that performs the calling processing and all its related functions. MSISDN Mobile Station International ISDN Number. An ISDN number (E.164) for routing to a gateway DMS-MSC. MSRN Mobile Station Roaming Number. Temporary ISDN/PSTN number issued by the VLR to the roaming mobile station during location update or on a per-call basis. It is used to route calls to the mobile station by the network. National calls In the GSM-R network, national calls are those calls that route within the same GSM-R network. National destination code Part of the set of public numbers (MSISDNs) for GSM-R subscribers. Each GSMR network is assigned a unique national destination code (NDC). NDCs vary from RACs in that NDCs are unique for each country. Therefore, if GSM-R networks span more than one country, the NDC is different for each country involved. NDC National Destination Code. NOA Nature of Address. NSS Network and switching subsystem. NSS performs the main switching functions in a public land mobile network. The NSS manages communication among GSM-R mobile subscribers and communication between GSM-R mobile subscribers and users in other networks. The GSM-R NSS consists of the following components: GSM Mobile Services Switching Center (DMS-MSC), Visitor Location Register (VLR), and Home Location Register (DMS-HLR). NUS Network Unstructured.
GSM
G-10 Glossary
ODB Operator Determined Barring. PLMN Public Land Mobile Network. A network, established and operated by an administration or its licensed operator(s), for the specific purpose of providing mobile communication services to the public. PRI Primary Rate Interface. Private calls In the GSM-R network, private calls are those calls that stay within the GSM-R network or go between GSM-R networks. Protocol A set of rules that control the operation of a communication system. PSTN Public Switched Telephone Network. A telephony switching system that provides switching transmission facilities to many customers. Public calls In the GSM-R network, public calls are calls to subscriber numbers that begin with 8 or 55 through 59. PUSSR Process Unstructured Supplementary Service Request RAC Railway Access Code. Railway access code A prefix used to identify an EIRENE network outside the network in which the calling party is operating. R-MSC Remote MSC. Roaming The use of a mobile on any communications network other than the users home network. Running number An identity assigned to a train for a particular journey. The identity is assigned by
Glossary
G-11
the operational staff. A running number may form a component of a functional number used to address users or systems on a train. SA Subaddress. SCP Service Control Point. SDR Source Directed Routing. Service subscriber In the context of VBS and VGCS, a service subscriber is a mobile subscriber who subscribes to the VBS or VGCS service and is a member of a VBS or VGCS group. Short code digits Short code digits allow a user to speed dial a number. Short codes are dialed only by mobile stations. Shunting team A group of people maneuvering trains in order to change their composition. Communications for shunting are particularly critical when a driver at the front of a train is pushing it backwards towards buffers or other potential obstructions. In this case, a lookout is often required to report progress to the driver. SMS Short Message Service. SOC Software Optionality Code. SSN Subsystem Number. Teleservices Services providing the complete user-user communication capabilities including terminal functions according to layers 1 to 7 of the OSI reference model. TFN Train Functional Number. TMSI Temporary Mobile Subscriber Identity. A 4 octet temporary subscriber identity having only local significance to the VLR. Used to support subscriber identity
G-12 Glossary
confidentiality. UIC Union Internationale des Chemins de Fer. Uplink The one-way speech path from the mobile to the network. USSD Unstructured Supplementary Service Data USSN Unstructured Supplementary Service Number. USSR Unstructured Supplementary Service Request. User number The entry in a routing database. It consists of the user identity number and the functional number. UUI User-to-user Information. UUS1 User-to-user Supplementary Service 1. UUS1 presents the calling functional number to the users. UUS1 transfers the information transparently across the network. VBS Voice Broadcast Service. Enables a VBS subscriber to broadcast a unidirectional speech call simultaneously to a predefined group of destination subscribers located in a particular geographical area and entitled dispatchers. VGCS Voice Group Call Service. Enables a pre-defined set of destination subscribers in a pre-defined geographical area and entitled dispatchers to hold speech conversations. VLR Visitor Location Register. The VLR is integrated within the DMS-MSC and resides entirely in the DMS-core memory. Although the DMS-MSC contains the integrated VLR, the DMS-MSC and VLR are two separate functional entities within the GSMR network. The VLR performs the following functions: it maintains information about subscribers that have roamed into the area, it supports call establishment, it assigns temporary mobile subscriber identity, it allocates mobile station roaming
Glossary
G-13
number and it supports supplementary services and Short Message Service. Term Definition
GSM
G-14 Glossary
411-2231-827
Standard
02.05
September 2001
Family Product Manual Contacts Copyright Confidentiality Legal
GSM
MSC/HLR
Services Guide
To order documentation from Nortel Networks Global Wireless Knowledge Services, call (1) (877) 662-5669 To report a problem in this document, call (1) (877) 662-5669 or send e-mail from the Nortel Networks Customer Training & Documentation World Wide Web site at http://www.nortelnetworks.com/td Copyright 19992001 Nortel Networks, All Rights Reserved
NORTEL NETWORKS CONFIDENTIAL

The information contained herein is the property of Nortel Networks and is strictly confidential. Except as expressly authorized in writing by Nortel Networks, the holder shall keep all information contained herein confidential, shall disclose it only to its employees with a need to know, and shall protect it, in whole or in part, from disclosure and dissemination to third parties with the same degree of care it uses to protect its own confidential information, but with no less than reasonable care. Except as expressly authorized in writing by Nortel Networks, the holder is granted no rights to use the information contained herein. Information is subject to change without notice. Nortel Networks reserves the right to make changes in design or components as progress in engineering and manufacturing may warrant. This equipment has been tested and found to comply with the limits for a Class A digital devl of the FCC Rules, and the radio interference regulations of the Canadian Department of Communications. These limits are designed to provide reasonable protection comply with the limits for a Class A digital devl of the FCC Rules, and the radio interference regulations of the Canadian Department of Communications. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses and can radiate radio frequency energy. If not installed and used in accordance with the instruction manual, this equipment may cause harmful interference to radio communications. Operations of this equipment in a residential area is likely to cause harmful interference in which case, the user will be required to correct the interference at his own expense. * Nortel Networks, the Nortel Networks logo, the Globemark HOW the WORLD SHARES IDEAS, and Unified Networks are trademarks of Nortel Networks. DMS, DMS-MSC, DMS-HLR, DMS-100, and NORTEL are trademarks of Nortel Networks.GSM is a trademark of France Telecom. Trademarks are acknowledged with an asterisk (*) at their first appearance in the document. Document number: 411-2231-827 Product release: GSMR02 Document version: Standard 02.05 Date: September 2001 Printed in the United States of America

MSC - HLR Service Guild

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MSC - HLR Service Guild

Uploaded by

Copyright:

Available Formats

411-2231-827

Copyright Country of printing Confidentiality Legal statements Trademarks

Nortel Networks Confidential

Nortel Networks Confidential

MSC/HLR Services Guide GSMR02

Nortel Networks Confidential

Nortel Networks Confidential

Overview of the GSMR network

MSC/HLR Services Guide GSMR02

Nortel Networks Confidential

Network and switching components

Appendix A: Supported GSM11 features

Appendix B: DMS-HLR GSMR02 One Night Process

Appendix C: Data tables used by GSM-R features

Appendix D: Oparms used by GSM-R features

MSC/HLR Services Guide GSMR02

Appendix E: Log reports generated by GSM-R features

Appendix F: OMs generated by GSM-R features

MSC/HLR Services Guide GSMR02

Nortel Networks Confidential

Nortel Networks Confidential

About this document

Audience for this document

Organization of this document

MSC/HLR Services Guide GSMR02

About this document

Nortel Networks Confidential

Software release applicability

Nortel Networks Confidential

About this document

Software release applicability

MSC/HLR Services Guide GSMR02

About this document

Nortel Networks Confidential

Nortel Networks Confidential

GSM11 functionality information

MSC/HLR Services Guide GSMR02

Nortel Networks Confidential

Nortel Networks Confidential

Nortel Networks Confidential

GHLR600 GHLR601 GHLR612 GHLR664

Nortel Networks Confidential

MSC/HLR Services Guide GSMR02

Nortel Networks Confidential

GSMR01 to GSMR02 delta information

Nortel Networks Confidential

xxii Delta information

Nortel Networks Confidential

Nortel Networks Confidential

xxiv Delta information

Nortel Networks Confidential

Nortel Networks Confidential

MSC/HLR Services Guide GSMR02

xxvi Delta information

Nortel Networks Confidential

Nortel Networks Confidential

Nortel Networks Confidential

Nortel Networks Confidential

MSC/HLR Services Guide GSMR02

Nortel Networks Confidential

Nortel Networks Confidential

inter-MSC handback (MSC-B to MSC-A)