Msc_hlr Service Guild

GSM

MSC/HLRServices Guide

GSMR02 Standard 02.05 September 2001

411-2231-827

GSM


Document number: 411-2231-827Product release: GSMR02Document version: Standard 02.05 Date: September 2001

Copyright Country of printing Confidentiality Legal statements Trademarks

Copyright 1999–2001 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

411-2231-827 Standard 02.05 September 2001

* 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.

Nortel Networks Confidential iii

GSM MSC/HLR Services Guide GSMR02

Publication historySeptember 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

• 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

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:

iv Publication history Nortel Networks Confidential


• Access Matrix

• Call Forwarding to Functionally Structured Numbers

• Integrated Acknowledgement Center (IAC)

• Fast Call Setup

September 1999

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)

Nortel Networks Confidential v


Contents 1

About this document xi Audience for this document xiOrganization of this document xi Software release applicability xiiRelated documents xiiSoftware release applicability xiii

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 xxviiiVGCS 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 1-1 Purpose of the GSM-R network 1-1 History 1-1

The European Commission and MORANE 1-1 The EIRENE specification 1-2

vi Contents Nortel Networks Confidential


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 2-1 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

GSM-R functionalities 3-1 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

Appendix A:Supported GSM11 features A-1The GSM10 load A-1GSM11 functionalities used by GSMR02 A-1

Supported GSM11 functionalities A-1Unsupported GSM11 functionalities A-3

Appendix B:DMS-HLR GSMR02 One Night Process B-1The TABXFR process B-1ONP data transfers B-1The EDM method B-1The PDM method B-2ONP tables B-2

GSM10 to GSMR02 dump and restore B-2GSMR01 to GSMR02 dump and restore B-3GSMR02 to GSMR02 dump and restore B-3

Interactions B-4Restrictions and limitations B-4

Appendix C:Data tables used by GSM-R features C-1

Nortel Networks Confidential Contents vii


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

Appendix D:Oparms used by GSM-R features D-1Table 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

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 E-1HLR log reports E-1

GHLR401 E-1 GVLR300 E-9

MSC log reports E-9 GBCS300 E-10 GC6000 E-10 GGCN300 E-11GMSC301 E-11 GMSC302 E-12 GMSC609 E-13 GMSC612 E-16

Appendix F:OMs generated by GSM-R features F-1

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

Nortel Networks Confidential Contents ix


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

Appendix G: Glossary G-1

x Contents Nortel Networks Confidential


Nortel Networks Confidential xi


About this document 1This 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 1This publication is applicable for any person involved in the planning, engineering, administration, or maintenance of the GSM-R network.

Organization of this document 1This 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.

xii About this document Nortel Networks Confidential


• 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 1This 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 1The 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

Nortel Networks Confidential 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 1This 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.

xiv About this document Nortel Networks Confidential


Nortel Networks Confidential xv


Delta information 2This 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 2GSMR02 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 USSDThis 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 schemaThis functionality adds two new tables (table GHLRUSSD and table GHLRXTND). This functionality also modifies tables GHLRSCF, GHLRVLR, GSMTIMRS, and GHLRPARM.

xvi Delta information Nortel Networks Confidential


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 tuple’s 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.

Nortel Networks Confidential 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 reportsThis functionality modifies the following existing logs:

• GHLR401

xviii Delta information Nortel Networks Confidential


• 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 measurementsThis 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 interfaceThis functionality modified the QVLR command located in the HLRADMIN directory. This command is updated to display the networkUnstructuredSS AC at version 2.

BillingThis functionality does not make any additions or changes to the billing.

IN VLR logic migrationThis 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.

Nortel Networks Confidential 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 schemaThis functionality does not introduce any data schema changes.

Log reportsThis functionality does not add or change any log reports.

Operational measurementsThis functionality does not add or change any OMs.

Man-machine interface This functionality does not make any additions or changes to the man-machine interface.

BillingThis functionality does not make any additions or changes to the GSM-R billing.

MSC changes for end-to-end subaddress supportThis 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

xx Delta information Nortel Networks Confidential


Data schemaThis functionality does not introduce any data schema changes.



Man-machine interface This functionality does not make any additions or changes to the man-machine interface.


GSMR01 to GSMR02 delta information 2This section lists the functionality changes that occurred from GSMR01 to GSMR02. GMR02 adds the following functionalities:

• Mated Pair Disaster Standby for GSM-R

• 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

Nortel Networks Confidential 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-RThis 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 schemaThis functionality adds error and warning messages to the existing set of messages for table GHLRVGS.


Operational measurementsOM 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 Nortel Networks Confidential


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 interfaceThis 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.


HLR Call Forwarding to Functionally Structured NumberThis 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 schemaThis functionality does not add or change any data tables.



Nortel Networks Confidential Delta information xxiii


Man-machine interfaceThis functionality does not make any additions or changes to the man-machine interface.


USSD Enhancement for HLRThis 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 schemaThis functionality does not add or change any data tables.



Man-machine interfaceThis 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-1Example of the modified HLRTRACE display


Ind Inv Process Unstructur MSG 10:10:21.860 710 IMSI ..................: 456231234567890 ProcessUnstructuredSSRequest ---------------------------- USSD Coding Scheme: 0F USSD String Info (7-bit HEX): AA116D04 (8-bit HEX): 2A233423 (ASCII): *#4#

...USSD MSISDN : 6112300001...

xxiv Delta information Nortel Networks Confidential


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 schemaThis 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


Operational measurementsThis 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


Nortel Networks Confidential Delta information xxv


BillingWhen pre-emption occurs, the SS module code is generated and appended to the pre-empted call’s billing record. The SS module code captures both the pre-empting and pre-empted call’s precedence level. The pre-empted’s 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-RThis 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 schemaThis 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

xxvi Delta information Nortel Networks Confidential


GSM-R network. This information is necessary for the Access Matrix feature to decide if the Access Matrix check must be performed.





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 originator’s terminal.

Data schemaThis functionality does not add or change data schema.

Log reportsThis functionality does not add or change log reports.

Operational measurementsThis 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

Nortel Networks Confidential Delta information xxvii



Integrated Acknowledgment Center on DMS-MSCThis 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 schemaThis 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.


Operational measurementsThis functionality does not add or change any operational measurements.


BillingThis 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 Nortel Networks Confidential


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-2Example of an acknowledgement record

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 schemaThis 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.

HEX ID = AA STRUCT CODE = 00020C

CALL CODE = 016C

STUDY IND = 0C

CALLING NUM = 2C01000CFFFFFFFFFFFFFFFFF61411000231001C

CALLED NUM = 2C01000CFFFFFFF61411000231001C

MSCID= 01000CFFFFFFFFF614180700000C

GROUP REF = 000001612C RECORD TIME = 921115044730700C

FUNCT NUM = 00003026178911101C REL = 00214755300C

CALL DURATION = 001200600C PRIORITY LEVEL = 006C

PRIORITY CALL CAUSE = 000C HOTBILL = 1C

RECORD NUMBER= 0000254C

Nortel Networks Confidential 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 MSC’s 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 reportsThis functionality adds log report GGCN300. This log report is generated when a group call number cannot be allocated.

Operational measurementsThis 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.


xxx Delta information Nortel Networks Confidential



VGCS Dispatcher Talk Control and Mute/Unmute ServiceThis 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 schemaThis 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.





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’)

Nortel Networks Confidential 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 inter-MSC 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 schemaThis functionality uses the following OPARM in table OFCENG:

• NUMBER_OF_TLK_HO_MAP_TIDS





Voice Group Call Service (VGCS) Emergency CallThis 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 schemaThis functionality does not add or change data schema.


xxxii Delta information Nortel Networks Confidential


Operational measurementsThis 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.



Dispatcher DisconnectThis 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 schemaThis 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 reportsThis 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

Nortel Networks Confidential Delta information xxxiii


• when datafill is not correct




Five Dispatchers in a VGCS and VBSThis feature enhances the VGCS/VBS to support up to five dispatchers in one VGCS/VBS call.

Data schemaThis 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.





Connect Indication EnhancementThis 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 Nortel Networks Confidential


— 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 schemaThis functionality adds a new subfield to table SERVCHFG. The subfield is Txx. This subfield assigns a timer value of 1 to 10 seconds.





MAP Enhancements for Inter-MSC Group CallsThis 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 schemaThis functionality does not add or change any data schema tables.


Operational measurementsThis 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

Nortel Networks Confidential 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



Delta tables 2This 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-1Summary of data schema changes made by GSM11 and GSMR02 features

Table name New/modified

Description of changes

ACSMTRX new This new table specifies the Access Matrix used for the Access Matrix feature.

DNROUTE modified Adds feature selector GSMGCN.

GCR modified 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.

GHLRPARM modified Parameter AC_MAX_V is changed to include the NUS_AC entry. Also, parameter MISCSSN is added.

—sheet 1 of 3—

xxxvi Delta information Nortel Networks Confidential


GHLRSCF modified Adds fields NUS_AC, EVAL_NUS, and AC_AUDIT.

GHLRVGS modified Adds error and warning messages to the existing set of messages

GHLRVLR modified Adds fields NUS_AC and EVAL_NUS.

GHLRUSSD new This new table determines how to process the USSD string received in a PUSSR.

GHLRXTND new 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.

GSMTIMRS modified 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.

OFCENG modified 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 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—

Nortel Networks Confidential Delta information xxxvii


Table 2-2 summarizes the additions and changes made to log reports. The log reports are listed in alphanumeric order.

PETSERVS modified Option ‘AMSCRN’ is added to this table. The AMSCRN option allows the Access Matrix feature to be activated on a per PET trunk basis.

SERVCHFG modified 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.

Table 2-2Summary of log report changes made by GSM11 and GSMR02 features

Log report name

New/modified


GGCN300 new This new log report generates when a group call number cannot be allocated.

GHLR401 modified 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.

—sheet 1 of 2—




—sheet 3 of 3—

xxxviii Delta information Nortel Networks Confidential


GHLR600 modified 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 modified GHLR664 is a generic log used to indicate a problem with the USSD Resource Monitoring too.

GMSC600 new This new log report generates when there is an issue with allocating the STR card.

Table 2-2Summary of log report changes made by GSM11 and GSMR02 features

Log report name

New/modified


—sheet 2 of 2—

Nortel Networks Confidential 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-3Summary of OM changes made by GSM11 and GSMR02 features

OM group New/modified


EVGCS new This OM group contains registers that count the number of Emergency VGCS calls.

GHLRADM3 modified 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.

GHLRBSG modified 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.

GMAPCH2 modified The following registers are added to this OM group: PGCREQ, PGCRQ2, PGCRES, PGCRS2, FGCREQ, FGCRQ2, PRGCREQ, and PRGCRQ2.

HLRUSSDT new The registers in the HLRUSSDT group measure USSD traffic between the HLR and VLR and between the HLR and gsmSCF/external node.

MLPP new This group contains registers that measure how often pre-emption occurs due to the MLPP service.

MSCGCS modified The following registers are added to this OM group: VGCSIMST, VBSIMST, VGCSINVR, VBSINVR, and GCNFAIL.

xl Delta information Nortel Networks Confidential


Table 2-4 summarizes the changes made to the man-machine interface (MMI). The MMI changes are listed in alphabetical order.

Table 2-5 summarizes the additions or changes made to billing. The billing additions and changes are listed in alphabetical order.

Table 2-4Summary of MMI changes made by GSM11 and GSMR02 features

MMI command New/modified


DBOMCALC modified The tool is modified to recognize and support the changes made to the GHLRBSG and GHLRADM3 OM groups.

HLRADMIN modified Changed the QVLR command located in the HLRADMIN directory. Updated the command to display the networkUnstructuredSS AC at version 2.

HLRTRACE modified The HLRTRACE tool is enhanced to display the new MSISDN field. The field is displayed only if it exists in the message under consideration.

Table 2-5Summary of billing changes made by GSM11 and GSMR02 features

Billing New/modified


Acknowledgement record

new 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.

SS module code modified The SS module code is enhanced to capture both the pre-empting and pre-empted call’s precedence level.

Nortel Networks Confidential 1-1


Overview of the GSMR network 1This 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 1GSM-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 1Today, 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 MORANEThe European Commission (EC) is a group responsible for proposing and implementing the European Union’s legislation. The EC wanted to overcome

1-2 Overview of the GSMR network Nortel Networks Confidential


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 specificationIn 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 1The 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.

Nortel Networks Confidential Overview of the GSMR network 1-3


Figure 1-1Diagram of the GSM-R network

Benefits of the GSM-R network 1Following 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 1The 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.

National EIRENE networkOther EIRENE

network(s)

Voice and data communications, eg:- driver- ERTMS/ETCS- other on train users- passenger information

Shunting communications

Train communications

Wide area communications

Railway fixednetwork

International trains

1-4 Overview of the GSMR network Nortel Networks Confidential


Figure 1-2The frequency band for the GSM-R system

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 R-GSM bandwidth.

f/MHz

R- P-GSME-GSM

870 880 890 900 910 920 930 940 950 960 970

DownlinkUplink

E-GSMR- P-GSM



Network and switching components 2The 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) 2The 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 functionsThe 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)

2-2 Network and switching components Nortel Networks Confidential


• control echo

• capture and format billing data

• support supplementary services

Establish, re-establish, and route subscriber callsThe 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 GSM-R

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 digitsThe 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 signalingThe 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.

Nortel Networks Confidential Network and switching components 2-3


Handle data callsThe DMS-MSC support mobile-originated and mobile-terminated data calls.

Manage call facilities and proceduresThe 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 subscriber’s 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 terminationFor mobile-terminated calls, the DMS-MSC locates the mobile station and establishes radio contact with it.

Handover calls from one cell to anotherThe 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 PLMNsThe DMS-MSC supports subscribers in roaming to other PLMNs, both within and outside the subscriber’s home country.

Control echoEcho 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



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 dataThe 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 DMS-MSC 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 servicesA 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) 2The 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 GSM-R 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.



VLR functionsThe 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 subscribersA 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 establishmentWhen 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 identityUpon 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 ServiceThe VLR communicates with the DMS-MSC and DMS-HLR to support call-related 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) 2The 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 subscriber’s current geographical location.



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 functionsThe 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 routingThe 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 servicesThe DMS-HLR provisions, controls, and manages supplementary services information. The DMS-HLR stores a subscriber’s 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 ServiceShort Message Service (SMS) is a service that allows messages of a limited size to be sent to and from GSM-R subscribers.

Maintains network consistencyThe 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.



Types of data stored in the DMS-HLRThe DMS-HLR stores two main types of data: permanent data and temporary data. Refer to Figure 2-1.

Figure 2-1DMS-HLR data types

Temporary dataTemporary 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 subscriber’s 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.

Includes information such as current locationof a subscriber. Updated in real-time by theGSM-R network.

Non-transient dataIncludes information such as a subscriber’sforwarded-to number. Updated in real-timeby the GSM-R network or the service provider.

Transient data

Operational dataIncludes individual subscriber IDs, subscriberISDN number, and authentication key. Changedmanually by the service provider.

Subscriber dataIncludes the basic services available to theGSM-R subscriber, o ptions related to thoseservices, and su pplementar y services.Changed manuall y by the service provider.

Temporar y data

Permanent data



Permanent dataPermanent 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.



GSM-R functionalities 3GSM-R functionality 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 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.

3-2 GSM-R functionalities Nortel Networks Confidential


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.

Nortel Networks Confidential GSM-R functionalities 3-3


Access Matrix

Purpose of Access Matrix 3The 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 3Access 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)



— 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 typesAccording 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).



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 trunksAccess 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 3The 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 networkand originating from a GSM-R network

• From the public PSTNs

— E.164 numbers

Datafill required for Access Matrix 3The following tables must be datafilled for the Access Matrix functionality:



• table OFCVAR

• table PETSERVS

• table ACSMTRX

Table OFCVAROffice 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 PETSERVSIn 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 ACSMTRXTable 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 3There are no log reports associated with Access Matrix.

Operational measurements associated with Access Matrix 3There are no operational measurements associated with Access Matrix.

Billing 3The Access Matrix functionality does not affect billing.



Functional Addressing

Purpose of Functional Addressing (FA) 3Functional 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 3To 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 user’s 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 mobile’s 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.



How the FA registration, deregistration, and interrogation phase worksThe FA registration, deregistration, and interrogation responsibility is divided into two logical parts:

• Home Location Register-mobile (HLRm)

• Home Location Register-functional (HLRf)

The HLRmThe 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 subscriber’s subscription data.

The HLRfIf 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 transactionFigure 3-1 illustrates the FA architecture.



Figure 3-1FA architecture

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).

HLRm

MMI

Provisioning and CI tool query

Database

Processing

Subscription andfunctional checking

Forwarding

IMSI MSISDN

Provisioning for:- FA service with details- Mapping to gsmSCF/ external node- System requirements

MS

PUSSR indication(with string-1)

PUSSR response(with string-4)

1

3

2

6

Database

FN MSISDN

PUSSR request

(with string-2)

4

PUSSR confirm.(with string-3)

5

FFN

Note: The DMS-MSC/VLR are not shown because they are passing the information in a transparent way.

includ. MSISDN



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 3Figure 3-2 illustrates the steps that occur during call processing of an FA call.

Figure 3-2Call processing an FA call

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.

Mobile MSC/SSP SCP

GatewayMSC

VisitingMSC

HLR

VLR

Station1) DTAP Setup

FN, UUI

2) InitDP(FN)

3) Connect(MSISDN, FN)

4) IAM ODDUUIMSISDN

5) Send routing info (SRI)(MSISDN)

8) Routing InfoAck (SRI-Ack)(MSRN)

MobileStation

10) Setup

MSRN,SA,BC,UUI

6) Provide roaming #(MSISDN)

7) PRN response #(MSRN)

9) IAMMSRNUUIODD



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 DMS-MSC. 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 3The DMS-MSC supports FA service by performing the following functions:

• passes the USSD messaging between the mobile station and the DMS-HLR. Refer to Figure 3-3.

• obtains MSISDN and routes the MSISDN as the called party number.



Figure 3-3Call flow showing the DMS-MSC passing USSD messaging between the MS and the HLR m

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 3The DMS-HLR supports FA service by performing the following functions:

• stores all subscriber-based data

• receives all registration-related requests initiated by a mobile

Mobilestation MSC VLR HLRm SCP

USSD string 1

USSD string 4

USSD string 2

USSD string 3



• verifies registration-related requests based on the subscriber’s subscription data

• provides registration, deregistration, and interrogation functions based on the request type

• sends the result back to the mobile

Feature interactions 3Since 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 3The following tables must be datafilled for FA service:

• table OFCVAR

• table GHLRBCA

• table GHLRFAID

• table GHLRFANC

• table GHLRSSOP

• table GHLRUSSD

• table GHLRSCF



• 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 datafillDatafill 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 datafillTable 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 subscriber’s 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 datafillThis 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).



• 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 datafillTable 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 datafillThis 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 datafillThis 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.



A symbolic address must be datafilled in table GHLRSCF before symbolic address can be used in table GHLRCAML or GHLRSSD.

Table GHLRXTND datafillThis 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 datafillThis 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 3Field “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 411-2831-510, GSM DMS-HLR Log Reference Manual.

Operational measurements associated with FA service 3The 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 411-2831-814, GSM DMS-HLR Operational Measurements Reference Manual.



Group GHLRADM3This 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 HLRFAThis 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 3FA service does not have an impact on billing information.



Location Dependent Addressing

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

How Location Dependent Addressing works 3Location 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 serviceThe 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.



Figure 3-4Example of a short code LDA delivery

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.

MS MSC/SSP SCP

Setup

DP3InitDP (SrvKe y, LocNum, C gPN, CdPN) SCP executes FA

service, retrieves MSISDN

D

SCP analyzes thelocation and shortcode

D

SCP ends serviceexecution

P

ERConnect (DestRt gAddr)

D

Key:

Disk table read

P OM pegged

ER Event record generated



How the DMS-MSC supports LDA 3The 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 DMS-MSC 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.

Feature interactions 3Location de pendent addressin gLocation 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 user’s 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.



Call Forwarding to Functionally Structured Numbers

Purpose of Call Forwarding to FSNs 3This 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 3The 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 formatsThe following FSN formats can register as an FTN:

• 00 + CC + NDC + 8 + <other SN digits>






• 0 + NDC + 8 + <other SN digits>






• 8 + <other SN digits>








The plus key (+) also can be used to register the FSN formats described below:

• (+) + CC + NDC + 8 + <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>





How the DMS-HLR supports Call Forwarding to FSNs 3The 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 FTNsThe 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 DMS-HLR 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 FTN’s 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 operator’s network.



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 operator’s 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 operator’s network NDC, the request is rejected

3. If the FTN is registered as 00 + CC + NDC + 8 or 00 + CC + NDC + 95-99, the 00 is stripped off.

— If the CC and NDC is the railway operator’s 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 operator’s network CC, the request is rejected.

— If the CC is the railway operator’s network CC but the NDC is not the railway operator’s network NDC, the request is rejected.

Processing FTNsThe DMS-HLR processes the FTNs received when a mobile sends a Call Forwarding Activation request. Figure 3-5 illustrates this process.



Figure 3-5Processing FTNs

CF Activation Request M essage contains “FTN”

Call Forwarding

Y

N

SS ERROR

PX tables

OFC tables

Translations

Save the Inlt. E.164 format FTN in thedatabase ( GHLRSSOP )

SS - ACK

SuccessfulTranslationfailed

Necessary info. not found up to FTN Abort M essage

step-1

step-2

step-4 step-5

step-6

step-7

step-8

Number is ininternational

Y

Step-9Step-10

form at?

provisioned?

CT tables

Table XLA EN TRY

System Based Approach

N

HLR

translation



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 DMS-HLR 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 3This functionality does not change the current Call Forwarding functionality.

Datafill required for Call Forwarding to FSNs 3The following tables are used to perform Call Forwarding to FSNs:

• GHLRSSOP

• XLAENTRY

• PXHEAD

• PXCODE

• OFCHEAD

• OFCCODE

• CTHEAD



• CTCODE


Note: For more detailed information, refer to NTP 411-2831-151, GSM DMS-HLR Customer Data Schema.

Table GHLRSSOPThis 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 XLAENTRYThis table is used to initiate System-Based translations.

Table PXHEAD, OFCHEAD, and CTHEADThese tables are used to datafill default values for Universal Translations.

Table PXCODE, OFCCODE, and CTCODEThese tables contain the necessary information used in Universal Translations.

Log reports associated with Call Forwarding to FSNs 3There are no log reports associated with Call Forwarding to FSNs.

Operational measurements associated with Call Forwarding to FSNs 3

There are no operational measurement (OM) groups associated with Call Forwarding to FSNs.

Billing 3Call Forwarding to FSNs does not have an impact on billing information.



Voice Broadcast Service (VBS)

Purpose of Voice Broadcast Service (VBS) 3VBS 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-6Voice Broadcast Service

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 3With 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.

Copyright ©

1996 Northern Telecom

VBSOriginatingSubscriber

GSMGSMAccessAccess

DispatcherDispatcher

DispatcherDispatcher

PSTN/PSTN/ISDNISDN

Copyright © 1996 Northern Telecom

Co

pyr

igh

t ©

19

96

No

rth

ern

Te

leco

m

Co

pyr

igh

t ©

19

96

No

rth

ern

Te

leco

m

Co

pyr

igh

t ©

19

96

No

rth

ern

Te

leco

m



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 callA 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 callsTo 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 subscriber’s cell of origin (COO) to determine the group call reference (GCRef).



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 callsA 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 dispatcher’s 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 callsTo place a network-initiated VBS call, the network operator must provision DMS-MSC translations to derive the following called number:


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.



Joining an ongoing VBS callIf 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 callThe 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 dispatchersA 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 dispatcher’s terminal or through external equipment connected to the dispatcher’s terminals.

Mobile dispatchersA 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 dispatcher’s 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 subscribersA 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 areasFigure 3-7 depicts the distribution of group calls in GSM-R networks consisting of multiple MSC serving areas.



Figure 3-7Distribution of group calls in GSM-R networks with multiple DMS-MSC serving areas

Within a network, each defined group is assigned one anchor DMS-MSC (A-MSC). The other DMS-MSCs in the network are configured as relay DMS-MSCs (R-MSCs) for the defined group. The R-MSC controls the group call area cells that are not controlled by the A-MSC.

R-MSC

VLR GCR

HLR SCP

A-MSC

VLR GCR

R-MSC

VLR GCR

BSC2 BSC3

INAPMAP

MAP-E

D

ISUP

ISUP

DPRI

FISUP

D

CC

-DT

AP

B

BC

C-D

TA

P

G

GC

C-D

TA

P

F

D

B

G

X

X

XX

X

X

X

----- VGCS/VBS dispatcher (mobile or fixed (ISUP or PRI))

----- call over fixed network ----- VBS originator

----- VGCS talker ----- VGCS/VBS service subscriber

Cell Cell

GC area

X

XX

BSC1

D

CC

-DT

AP

terr

estr

ial t

runk

BTS not shown

Key:



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

MessagingThe 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 AckThe 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 SignalThe 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 A-MSC 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 AckThe A-MSC sends the Send Group Call End Signal Ack message to the R-MSC. 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 messageThe 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 timerA 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 procedureThis 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



End Signal message. Once the R-MSC sends the connect indication, the A-MSC 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.



Figure 3-8Example of a normal VBS messaging dialogue

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)))

MAP_FORWARD_GROUP_CALL_SIGNALLING **

CONTINUE ((INVOKE,(Invoke ID = l,Operation = forwardGroupCallSignallingParameters = IMSI,

Uplink Request Acknowledgement Uplink Release Indication Uplink Reject Command, Uplink Seized Comman, Uplink Release Command)))

Continued on next page .....

RelayMSC

AnchorMSC



Periodic group call channel retrySometimes 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.

MAP_PROCESS_GROUP_CALL_SIGNALLING **

CONTINUE ((INVOKE,(Invoke ID = m,Operation = processGroupCallSignallingParameters = Uplink Request,

Uplink Release Indication, Release Group Call)))

MAP_SEND_GROUP_CALL_END_SIGNAL_ACK

END ((RESULT(Invoke ID = k,Operation = sendGroupCallEndSignal,Parameters = none)))

AnchorMSC

RelayMSC

** These messages are relevant for VGCS calls only.



Figure 3-9Two-stages of periodic retry procedure

Stage 1AF

Stage 2

Stage 1CC

ABORTIDLE

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 not assigned at call setup or lost during on-going call (Assignment Failure, Clear Request or Clear Command with unacceptable cause value)

Group call channel not assignedafter single immediateretry (No response or Assign.Failure with acceptable cause value)

Periodic Retry (Assign. Failure with acceptable cause value)

Assign. Failure with unacceptable causevalue received during periodic retry

Assign. Failure with unacceptable cause value received on single delayed retry

Group call channel not assigned after single delayed retry (No response or Assign. Failure with acceptable cause value)

Group call channel assigned after periodic retry

Group call channel lost during on-going call (Clear Request or Clear Command with acceptable cause value or no response to Clear Command)

Group call channel assigned after single delayed retry

Group call channel assigned after single immediate retry

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.



Stage 1AFStage 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 re-attempt 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



• pre-emption

Following is a list of the acceptable cause values for the Clear Command message:



• 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.



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 ICCA 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.




Period between retriesThe 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 handoversVBS supports inter-MSC handover functionality using circuit connections. This functionality includes the following:




The following figures show the message flows for each type of VBS inter-MSC 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.



Figure 3-10Inter-MSC handover (MSC-A to MSC-B) with call terminating request by the originating talker

HO Required

HO Request

HO Request Ack

HO Command

HO Detect

HO Complete

BSSold MSC-A MSC-B BSS new

Prepare HO

Prepare HO Ack

PAS [HO Detect]

SES [HO Complete]

SES Ack

Termination Request

IAM [HON]

ACM

ANM

Release

Clear Cmd/CmpSCCP RLSD/RLC

PAS [Termination Req.]

[HO RequestTgt_Cell_ID]

[HO Request Ack

HON]


MS

TerminationFAS [Termination]



Figure 3-11Subsequent handover (MSC-B to MSC-B’)

Note: After a subsequent handover, MSC-B’ becomes MSC-B. So the call termination signaling is the same as Figure 3-11.

MSC-A

HO Request

HO Request Ack

HO Command

HO Detect

HO Complete

BSSold MSC-B'MSC-B

HO Required

Prepare Subsequent HO Ack [HO Request Ack]

Prepare Subsequent HO

IAM [HON]

Prepare HO

ACM

PAS [HO Detect]

SES [HO Complete]

SES Ack

ANM

Release

BSSnew

[HO RequestTgt_Cell_IDTgt_MSC_Num]


Prepare HO Ack

[HO Request Ack

HON]




Figure 3-12Inter-MSC handback (MSC-B to MSC-A)

Handover failuresWhen an inter-MSC handover occurs to a target MSC outside the talker’s 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 talker’s 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-BWhen 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.

HO Required

HO Request

HO Req Ack

HO Command

HO Detect

HO Complete

BSSnew MSC-A MSC-B BSSold


Prepare Subsequent HO Ack[HO Request Ack]

SES Ack

Release





Handover failure on the MSC-B sideIf 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 AckWhen 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 sideIf 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 sideIf 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 conditionsFollowing 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 errorsDatafill errors usually are caused by

• inconsistent datafill existing in DMS-MSC tables or

• incorrect datafill resulting in call establishment failure

Authorization errorsAuthorization errors occur when an unauthorized subscriber or dispatcher attempts to originate a group call or join an ongoing group call.



Resource failuresA 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 behaviorThe 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 originator’s dedicated link

• a radio failure on a broadcast channel

• the group call register (GCR) access fails

Protocol errorsThe 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 conditionsA 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 3The 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 3The DMS-HLR supports VBS service by performing the following functions:

• stores VBS subscription information on a per user basis



• 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

Feature interactions 3This 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 presentationDestination dispatchers and calling service subscribersIf 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 subscribersIf 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



[COLR]). The DMS-MSC always includes the GCRef as the presented number.

Supplementary servicesSupplementary 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-1Supplementary services applicable to a VBS service subscriber

Supplementar y service A pplicable to VBS subscriber?

Enhanced Multi-level Priority Preemption (eMLPP) Yes

Functional Addressing (FA) No

Calling Line Identification Presentation (CLIP) Yes

Calling Line Identification Restriction (CLIR) Yes

Connected Line Identification Presentation (COLP) Yes

Connected Line Identification Restriction (COLR) Yes

Call Forwarding Unconditional (CFU) No

Call Forwarding Busy (CFB) No

Call Forwarding on No Reply (CFNRy) No

Call Forwarding on Mobile Subscriber Not Reached (CFNRc)

No

Call Waiting (CW) No

Hold No

Multi-party Service (MPTY) No

Closed User Group (CUG) No

—sheet 1 of 2—



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.

Advise of Charge (Information) (AoCI) No

Advise of Charge (Charging) (AoCC) No

User-to-user Signaling 1 (UUS1) No

Barring of All Outgoing Calls (BAOC) Yes

Barring of Outgoing International Calls (BAIC) No

Barring of Outgoing International Calls except those directed to the Home PLMN country (BOIC-exHC)

No

Barring of All Incoming Calls (BAIC) No

Barring of Incoming Calls when Roaming outside the Home PLMN country (BIC-Roam)

No

Explicit Call Transfer (ECT) No

Local Calls Only (LCO) No

Class of Service (COS) No

Hotbill No

Account Code (AC) No

Calling Name Display (CNAM) No

Malicious Call Trace (MCT) No

Extension Service (EXT) No

Anonymous Call Rejection (ACRJ) No

Table 3-1Supplementary services applicable to a VBS service subscriber

Supplementar y service A pplicable to VBS subscriber?

—sheet 2 of 2—



• 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.

eMLPPThe 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.

PrecedenceFollowing 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.



• NOTIF_REQ. The priority level is indicated with the related notification request messages for the called mobile stations.

Called party pre-emptionIf 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 barringThe 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.

Intelligent network feature usageThe 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 callsSince 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

Table 3-2When ODB is applicable to a VBS subscriber

ODB Applicable to VBS subscriber?

ODB outgoing Yes for Barring for All Outgoing Calls

ODB incoming No

ODBMISC No

ODBECT No



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 callsPartial 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 interceptCall 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 TokenInteraction 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 3The 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-2231-455, GSM DMS-MSC Office Parameters Reference Manual, NTP 411-2231-495, GSM DMS-MSC Customer Data Schema, and NTP 411-2831-151, GSM DMS-HLR Customer Data Schema.



Table OFCENG datafillIn this table, datafill parameters

• GID_LENGTH

• MAX_GROUP_CALL_SUBS_IN_VLR

GID_LENGTHOffice 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_VLROffice 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 datafillIn 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_XLAENTRYThis 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_XLAENTRYThis 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.



DISP_DISC_SEQOffice 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_TIDSThis 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 datafillTable 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 datafillThis 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



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.

Table GCR datafillTable 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 datafillTable 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 datafillTable 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 datafillXXCODE 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.

Table GHLRVGS datafillTable GHLRVGS stores subscriber VBS and VGCS provisioning details. The table’s key consists of a subscriber’s 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 datafillTable 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.



Table GHLRBSVC datafillTable 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.


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 datafillThis table contains data associated with VLR screening classes. The DMS-HLR 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 datafillSubfield Txx in this table contains the Connect Indication Timer (Txx) values in seconds.

Log reports associated with VBS service 3The 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 reportThis 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 reportThis log report indicates illogical triggering of the GCR query occurred in the R-MSC due to datafill errors.

The GBCS300 log reportThis log report indicates failures in attempting to establish a group call in the base station subsystem (BSS).

The GGCN300 log reportThis log is generated when a GC number can not be allocated.

Operational measurements associated with VBS service 3The following operational measurement (OM) groups contain information regarding VBS service:

• MSCGCS

• MCLUSTER

• GHLRBS

• GMAPCH2




Note: For detailed information on these OM groups, refer to NTP 411-2231-815, GSM DMS-MSC Operational Measurements Reference Manual, and NTP 411-2831-814, GSM DMS-HLR Operational Measurements Reference Manual.

Group MSCGCSThis 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 MCLUSTERThe 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 GHLRBSThis 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 GMAPCH2This 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 3The 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.



Figure 3-13VBS call billing record

MSCD GCDR600 JAN04 23:27:15 3751 INFO Billing Record Data

Location: GSMMSC Software Call RecordingHEX ID=AA STRUCT CODE=10002CCALL CODE=001CSTUDY IND=0C CALL FORWARDING IND=0CCALLING PARTY=1CFFFFFCFFFFFF505021120311003CCALLING NUM=2C01000CFFFFFFFF0411002131001CCALLED NUM=0C01000CFFFFFFF61601112CCALLING EQUIP=FFFFFFFFFFFFFFFFFFFFFC ADDITIONAL INFO=FFFCCALLTS: CH ALLOC=FFFFFFFFFFFFFFFC ANSWER=706104232711400C DISC=760104232714200C REL=760104232714200COFF-AIR-CALL-SET-UP=0C HALF-RATE-IN-USE=0CCAUSE FOR TERM=000C CALL REFERENCE=03475CMS CLASSMARK=FFF0FFFC CLASSMARK TS=FFFFFFFFFFFFFFFCDIALED DIGITS=6CFFFFFFFFFFFFFFFFFFCOG TRUNK GROUP=00719C OG TRUNK MEMBER=00001COG ROUTE GROUP=086C TRK SEIZ TIME=760104232711000CCALLING SUBSCR CTGY=000C CALL INDICATOR=0000000CCALL DURATION=0000003C DIAGNOSTIC=00016CMSCID=01101CFFFFFFFFF614180400000C RECORD NUMBER=0000290CMC=006C TELESERV=092C TIME=760104232711000CMC=000C

NOTE #1: Dialed Digits=GIDNOTE #2: Called Num=GCRef



Voice Group Call Service (VGCS)

Purpose of Voice Group Call Service (VGCS) 3VGCS 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-14Voice Group Call Service

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 3With 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.)

Dispatcher


ShuntingLeader

Co

pyrig

ht ©

19

96

No

rthe

rn T

ele

com

Co

pyrig

ht ©

19

96

No

rthe

rn T

ele

com

Co

pyrig

ht ©

19

96

No

rthe

rn T

ele

com

ShuntingTeam

Members


Driver

ShuntingShuntingGroupGroup

CallCall



Establishing a VGCS callA 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 callsTo 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 subscriber’s 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.



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 callsA 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


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 dispatcher’s 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.



Network-initiated callsTo place a network-initiated VGCS call, the network operator must provision DMS-MSC translations to derive the following called number:


The DMS-MSC does not perform entitlement checking on network-initiated calls.

Joining an ongoing VGCS callIf 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 callThe 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 dispatchersA 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 dispatcher’s terminal or through external equipment connected to the dispatcher’s terminals.

Mobile dispatchersA 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 dispatcher’s 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 subscribersA 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 talkersThe system verifies the group ID of all subsequent talkers on the group call. When a subsequent talker begins talking, the system checks the talker’s group ID against the link the subscriber is on.

GSM-R networks with multiple DMS-MSC serving areasFigure 3-15 depicts the distribution of group calls in GSM-R networks consisting of multiple MSC serving areas.



Figure 3-15Distribution of group calls in GSM-R networks with multiple DMS-MSC serving areas

Within a network, each defined group is assigned one anchor DMS-MSC (A-MSC). The other DMS-MSCs in the network are configured as relay DMS-MSCs (R-MSCs) for the defined group. The R-MSC controls the group call area cells that are not controlled by the A-MSC.

R-MSC

VLR GCR

HLR SCP

A-MSC

VLR GCR

R-MSC

VLR GCR

BSC2 BSC3

INAPMAP

MAP-E

D

ISUP

ISUP

DPRI

FISUP

D

CC

-DT

AP

B

BC

C-D

TA

P

G

GC

C-D

TA

P

F

D

B

G

X

X

XX

X

X

X

----- VGCS/VBS dispatcher (mobile or fixed (ISUP or PRI))

----- call over fixed network ----- VBS originator

----- VGCS talker ----- VGCS/VBS service subscriber

Cell Cell

GC area

X

XX

BSC1

D

CC

-DT

AP

terr

estr

ial t

runk

BTS not shown

Key:



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

MessagingThe 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 AckThe R-MSC sends a Prepare Group Call Ack message to the A-MSC in response to the Prepare Group Call message.



Process Group Call SignalingThe 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 SignalThe 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 A-MSC 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 AckThe A-MSC sends the Send Group Call End Signal Ack message to the R-MSC. 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 messageThe 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 timerThe 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



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 timersTwo 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 timerThe 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 dispatcher-originated 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 procedureThis 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 End Signal message. Once the R-MSC sends the connect indication, the A-MSC 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 A-MSC 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.



Figure 3-16Example of a normal VGCS messaging dialogue

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 AP _FO R W A R D _G R O U P _C A LL_S IG N A LLIN G * *

CONTINUE ((INVOKE,(Invoke ID = l,Operation = forwardGroupCallSignallingParameters = IMSI,

Uplink Request Acknowledgement Uplink Release Indication Uplink Reject Command, Uplink Seized Comman, Uplink Release Command)))

Continued on next page .....

RelayMSC

AnchorMSC



Periodic group call channel retrySometimes 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-17 illustrates the two stages of the periodic retry procedure.

MAP_PROCESS_GROUP_CALL_SIGNALLING **

CONTINUE ((INVOKE,(Invoke ID = m,Operation = processGroupCallSignallingParameters = Uplink Request,

Uplink Release Indication, Release Group Call)))

MAP_SEND_GROUP_CALL_END_SIGNAL_ACK

END ((RESULT(Invoke ID = k,Operation = sendGroupCallEndSignal,Parameters = none)))

AnchorMSC

RelayMSC

** These messages are relevant for VGCS calls only.



Figure 3-17Two-stages of periodic retry procedure

Stage 1AF

Stage 2

Stage 1CC

ABORTIDLE

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 not assigned at call setup or lost during on-going call (Assignment Failure, Clear Request or Clear Command with unacceptable cause value)

Group call channel not assignedafter single immediateretry (No response or Assign.Failure with acceptable cause value)

Periodic Retry (Assign. Failure with acceptable cause value)

Assign. Failure with unacceptable causevalue received during periodic retry

Assign. Failure with unacceptable cause value received on single delayed retry

Group call channel not assigned after single delayed retry (No response or Assign. Failure with acceptable cause value)

Group call channel assigned after periodic retry

Group call channel lost during on-going call (Clear Request or Clear Command with acceptable cause value or no response to Clear Command)

Group call channel assigned after single delayed retry

Group call channel assigned after single immediate retry

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.



Stage 1AFStage 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



• 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 re-attempt 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



• pre-emption

Following is a list of the acceptable cause values for the Clear Command message:



• 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.



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.


Stage ICCA 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



that cell contains an unacceptable cause value.


Period between retriesThe 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 handoversVGCS supports two types of inter-MSC handovers:

• handovers using circuit connections

• signaling-only handovers

Handovers using circuit connectionsInter-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:




The following figures show the message flows for each type of VGCS inter-MSC 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.



Figure 3-18Inter-MSC handover (MSC-A to MSC-B) with call terminating request by the originating talker

HO Required

HO Request

HO Request Ack

HO Command

HO Detect

HO Complete


Prepare HO

Prepare HO Ack

PAS [HO Detect]

SES [HO Complete]

SES Ack

Termination Request

IAM [HON]

ACM

ANM

Release




[HO Request Ack

HON]


MS

TerminationFAS [Termination]



Figure 3-19Inter-MSC handover from MSC-A to MSC-B with an uplink release

Note: When the uplink is released, an SES Ack message is sent due to the signaling on the group call control connection.

HO Required

HO Request

HO Request Ack

HO Command

HO Detect

HO Complete


Prepare HO

Prepare HO Ack

PAS [HO Detect]

SES [HO Complete]

SES Ack

IAM [HON]

ACM

ANM

Release



[HO Request Ack

HON]


Uplink Release Ind.

Clear Request

Clear Command

Uplink Release Cmd.



Figure 3-20Subsequent handover (MSC-B to MSC-B’)

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.

MSC-A

HO Request

HO Request Ack

HO Command

HO Detect

HO Complete

BSSold MSC-B'MSC-B

HO Required



IAM [HON]

Prepare HO

ACM

PAS [HO Detect]

SES [HO Complete]

SES Ack

ANM

Release

BSSnew



Prepare HO Ack

[HO Request Ack

HON]




Figure 3-21Inter-MSC handback (MSC-B to MSC-A)

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 handoversA 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.

HO Required

HO Request

HO Req Ack

HO Command

HO Detect

HO Complete




SES Ack

Release





• 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-22Signaling-only handover from MSC-A to MSC-B with a call termination request by the originating talker

HO Required

HO Request

HO Request Ack

HO Command

HO Detect

HO Complete

HO Succeeded


Prepare HO

Prepare HO Ack [HO Request Ack]

PAS [HO Detect]

SES [HO Complete]

SES Ack

Termination Request


[HO RequestTgt_Cell_ID, HON_Not_Required


Termination

MS

FAS [Termination]

Private Ta g(GCRef)]



Figure 3-23Signalin g-onl y handover from MSC-A to MSC-B with an u plink release

Note: When the uplink is released, an SES Ack message is sent due to the signaling on the group call control connection.

HO Required

HO Request

HO Request Ack

HO Command

HO Detect

HO Complete

HO Succeeded


Prepare HO


PAS [HO Detect]

SES [HO Complete]

SES Ack

Uplink Release Cmd.

[HO RequestTgt_Cell_ID, HON_Not_Required

Uplink Release Ind.

Private Ta g(GCRef)]



Figure 3-24Signaling-only subsequent handover from MSC-B to MSC-B’

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.

MSC-A

HO Request

HO Request Ack

HO Command

HO Detect

HO Complete

BSSold MSC-B'MSC-B

HO Required

HO Succeeded


Prepare Subsequent HOPrepare HO

Prepare HO Ack[HO Request Ack]

PAS [HO Detect]

SES [HO Complete]

SES Ack

BSSnew

[HO RequestTgt_Cell_ID,

[HO RequestTgt_Cell_ID, Tgt_MSC_Num]

HON_Not_Re q uiredPrivate Ta g (GCRef)]



Figure 3-25Signaling-only subsequent handback from MSC-B back to MSC-A

Handover failuresWhen an inter-MSC handover occurs to a target MSC outside the talker’s 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-BWhen 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 sideIf 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.

HO Required

HO Request

HO Req Ack

HO Command

HO Detect

HO Complete




SES Ack

[HO RequestTgt_Cell_ID, Tgt_MSC_Num]



When an inter-MSC handover occurs to a target cell outside the talker’s 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 AckWhen 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 sideIf 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 sideIf 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 CommandThe 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 MSC-B to terminate its transaction.

Talker release uplink after receiving HO CompleteThe 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 callsA VGCS call is identified as an emergency VGCS call when the call’s 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.



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 restrictionsIf 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 ‘end-of-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 conditionsFollowing are the types of errors and abnormal conditions that affect the behavior of group calls:

• datafill errors

• authorization errors

• resource failures



• unexpected behavior

• protocol errors

• race conditions

Datafill errorsDatafill errors usually are caused by

• inconsistent datafill existing in DMS-MSC tables or

• incorrect datafill resulting in call establishment failure1

Authorization errorsAuthorization errors occur when an unauthorized subscriber or dispatcher attempts to originate a group call or join an ongoing group call.

Resource failuresA 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 behaviorThe 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 originator’s 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 errorsThe following protocol errors can affect VGCS calls:

• syntactic errors

• receipt of unexpected messages

• receipt of unexpected information elements



• receipt of unexpected transaction ID

• mismatch in teleservice type

Race conditionsA 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 3The 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 3The 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

Feature interactions 3This section discusses how VGCS interacts with the following features:

• group call reference presentation

• supplementary services



• eMLPP

• operator determined barring

• intelligent feature usage

• dispatcher talk token

Group call reference presentationDestination dispatchers and calling service subscribersIf 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 subscribersIf 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 servicesSupplementary 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.



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-3Supplementary services applicable to a VGCS subscriber

Supplementar y service A pplicable to VGCS subscriber?

Enhanced Multi-level Priority Preemption (eMLPP) Yes

Functional Addressing (FA) No

Calling Line Identification Presentation (CLIP) Yes

Calling Line Identification Restriction (CLIR) Yes

Connected Line Identification Presentation (COLP) Yes

Connected Line Identification Restriction (COLR) Yes

Call Forwarding Unconditional (CFU) No

Call Forwarding Busy (CFB) No

Call Forwarding on No Reply (CFNRy) No

Call Forwarding on Mobile Subscriber Not Reached (CFNRc)

No

Call Waiting (CW) No

Hold No

Multi-party Service (MPTY) No

Closed User Group (CUG) No

Advise of Charge (Information) (AoCI) No

Advise of Charge (Charging) (AoCC) No

User-to-user Signaling 1 (UUS1) No

Barring of All Outgoing Calls (BAOC) Yes

Barring of Outgoing International Calls (BAIC) No

Barring of Outgoing International Calls except those directed to the Home PLMN country (BOIC-exHC)

No

—sheet 1 of 2—



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.



Barring of All Incoming Calls (BAIC) No

Barring of Incoming Calls when Roaming outside the Home PLMN country (BIC-Roam)

No

Explicit Call Transfer (ECT) No

Local Calls Only (LCO) No

Class of Service (COS) No

Hotbill No

Account Code (AC) No

Calling Name Display (CNAM) No

Malicious Call Trace (MCT) No

Extension Service (EXT) No

Anonymous Call Rejection (ACRJ) No

Table 3-3Supplementary services applicable to a VGCS subscriber

Supplementar y service A pplicable to VGCS subscriber?

—sheet 2 of 2—



• 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.

eMLPPThe 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.

PrecedenceFollowing 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-emptionIf 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.



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 barringThe 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.

Intelligent network feature usageThe 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 callsSince 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.

Table 3-4When ODB is applicable to a VGCS subscriber

ODB Applicable to VGCS subscriber?

ODB outgoing Yes for Barring for All Outgoing Calls

ODB incoming No

ODBMISC No

ODBECT No



Subscriber-originated group callsPartial 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 interceptCall 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 TokenInteraction 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



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 3The 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-2231-455, GSM DMS-MSC Office Parameters Reference Manual, NTP 411-2231-495, GSM DMS-MSC Customer Data Schema, and NTP 411-2831-151, GSM DMS-HLR Customer Data Schema.

Table OFCENG datafillIn this table, datafill parameters

• GID_LENGTH

• MAX_GROUP_CALL_SUBS_IN_VLR


GID_LENGTHOffice 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_VLROffice 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 datafillIn this table, datafill parameters



• DISP_DISC_SEQ

• VGCS_Dispatcher_TALK_CONTROL












VGCS_DISPATCHER_TALK_CONTROLThis 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 dispatcher’s request.

Table BSSC2TMR datafillTable 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 datafillAllocates 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.



Table GCR datafillTable 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 datafillTable 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 datafillTable 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 datafillXXCODE 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:






Table GHLRVGS datafillTable GHLRVGS stores subscriber VBS and VGCS provisioning details. The table’s key consists of a subscriber’s 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 datafillTable 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 datafillTable 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.


• 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.


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 datafillThis table contains data associated with VLR screening classes. The DMS-HLR 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 datafillSubfield Txx in this table contains the Connect Indication Timer (Txx) values in seconds.

Log reports associated with VGCS service 3The following log reports contain information regarding VGCS service:

• GVLR300

• GMSC301

• GMCS302

• GBCS300

• GGCN300

The following paragraphs briefly describe these log reports.




The GVLR300 log reportThis 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 reportThis log report generates when hardware is not properly installed or datafill is incorrect.

The GMCS302 log reportThis log report indicates illogical triggering of the GCR query occurred in the R-MSC due to datafill errors.

The GBCS300 log reportThis log report indicates failures in attempting to establish a group call in the base station subsystem (BSS).

The GGCN300 log reportThis log is generated when a GC number can not be allocated.

Operational measurements associated with VGCS service 3The following operational measurement (OM) groups contain information regarding VGCS service:

• EVGCS

• GHLRBS

• GMAPCH2

• MCLUSTER

• MSCGCS

• MSCUPLNK



Group EVGCSEVGCS contains registers that count the number of Emergency VGCS calls.



Group GHLRBSThis 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 MCLUSTERThe 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 MSCGCSThis 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 MSCUPLNKThis group provides information about uplink channel control for a GSM VGCS group call terminating to a list of cells.

Billing 3The 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.



Figure 3-268VGCS call billing record

MSCD GCDR600 JAN04 23:27:15 3751 INFO Billing Record Data

Location: GSMMSC Software Call RecordingHEX ID=AA STRUCT CODE=10002CCALL CODE=001CSTUDY IND=0C CALL FORWARDING IND=0CCALLING PARTY=1CFFFFFCFFFFFF505021120311003CCALLING NUM=2C01000CFFFFFFFF0411002131001CCALLED NUM=0C01000CFFFFFFF61601112CCALLING EQUIP=FFFFFFFFFFFFFFFFFFFFFC ADDITIONAL INFO=FFFCCALLTS: CH ALLOC=FFFFFFFFFFFFFFFC ANSWER=706104232711400C DISC=760104232714200C REL=760104232714200COFF-AIR-CALL-SET-UP=0C HALF-RATE-IN-USE=0CCAUSE FOR TERM=000C CALL REFERENCE=03475CMS CLASSMARK=FFF0FFFC CLASSMARK TS=FFFFFFFFFFFFFFFCDIALED DIGITS=6CFFFFFFFFFFFFFFFFFF112COG TRUNK GROUP=00719C OG TRUNK MEMBER=00001COG ROUTE GROUP=086C TRK SEIZ TIME=760104232711000CCALLING SUBSCR CTGY=000C CALL INDICATOR=0000000CCALL DURATION=0000003C DIAGNOSTIC=00016CMSCID=01101CFFFFFFFFF614180400000C RECORD NUMBER=0000290CMC=006C TELESERV=091C TIME=760104232711000CMC=000C

NOTE #1: Dialed Digits=GIDNOTE #2: Called Num=GCRef



Integrated Acknowledgement Center (IAC)

Purpose of the IAC 3IAC 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 3After 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.



Figure 3-27Message flow of an acknowledgement call

Normal operation with successful outcomeThe 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.

MSC/VLR

HLR

BSS

Channel Request

MSC/VLR

Authentication Response

Complete Layer 3 Info

Authenticate Request

Immediate Assign

Cipher Mode CommandBSSMAP CipherMode Command

BSSMAP CipherMode Complete

Cipher Mode Complete

EIR

(CM-Service Request)

* Note: IAC resides on the MSC

IAC feature

SETUP message (UUIE)

RELEASE COMPLETE

(UUIE-acknowledge)

The information from the UUIEis captured into an Acknow-ledgment record.



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 outcomeIt 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 3The 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).

Feature interactions 3This section discusses how the IAC interacts with the following features:

• hot billing

• UUS1

• Barring of All Outgoing Calls (BAOC)



Hot billingThe 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.

UUS1The 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 call’s called number.

Datafill required for the IAC functionality 3The following tables should be datafilled for the IAC functionality:

• XXCODE tables

• table VLRXLA


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 tablesThe 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 VLRXLAThe 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 call’s called number.

Log reports associated with IAC 3There are no log reports associated with the IAC.

Operational measurements associated with IAC 3There are no operational measurements associated with the IAC.

Billing 3IAC 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 recordThe 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.



Figure 3-28Acknowledgement record fields

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.

Field M/C/NS Descri ption

GSM Record Header M

M

M

Hexidecimal ID - Identifies record to be good or data errors occurred.

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 M Indicates nature of the call/event record.

Calling Number C For mobile originated calls this number will be the MSISDN.

Called Number M 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.

MSC Number M The id number of the MSC.

Record Time M Absolute time of when record is captured.

Priority Release Time C Time between end of high priority call and confirmation call

Priority Level C Priority of broadcast/group call

Group Reference C Group call reference number of high priority call

Functional Number C Functional number of the confirming mobile

Priority Call Duration C The duration of the high priority call.

Priority Call Cause C The reason for the release of the connection of the high priority call.

HotBill M Indicate whether or not the record is output to the GHOT stream.

Record Number M The number assigned to the record generated.



Figure 3-29 shows an example of an acknowledgement record.

Figure 3-29Example 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

STRUCT CODE=00020C

RECORD TIME=921115044730700C

REL=00214755300C

PRIORITY LEVEL=006C

HOTBILL=1C

RECORD NUMBER=0000254C



enhanced Multi-level Precedence and Pre-emption (eMLPP)

Purpose of eMLPP 3MLPP 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 3When 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 subscriber’s needs.

eMLPP priority levelsThere 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



mapping occurs because ISUP and PRI protocols do not support the precedence levels A and B.

ISDN MLPP priority levelsThere 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 callWhen 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 subscriber’s maximum priority level.

If the requested priority level is equal to or less than the subscriber’s maximum priority level, the DMS-MSC assigns the requested priority level to the call.

If the requested priority level is greater than the subscriber’s maximum priority level, the DMS-MSC assigns the subscriber’s 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 DMS-MSC retrieves the subscriber’s default priority level from the VLR. The DMS-MSC then assigns the subscriber’s 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 originationsIn 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 callsWhen 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



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-emptionResource 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 call’s 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 party’s 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-emptionCalled party pre-emption allows an active mobile station to answer an incoming call when the incoming call’s priority is greater than the ongoing



call’s 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 serviceWhen 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 serviceWhen 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 PRIThe 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.



PRI-originated callsOffice 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 NIf 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 YIf 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 callsFigure 3-30 illustrates the MLPP calls originated at a PBX.



Figure 3-30MLPP calls originated at a PBX

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 callsAs previously stated, office parameter MLPP_PBX_FULL_SUPPORT indicates whether all of the PBXs in the network support MLPP service.

Invoke:

IAM

Setup

ACM1Alerting

Connect ANM

OriginatingPBX

MSC

MLPP Precedence

NETWORK

MLPP Call Request

MLPPUser Status Return R esu lt: MLPP Call Request

Call Proceeding

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 MLPP_PBX_FULL_SUPPORT is set to NThe 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 YThe 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 callsFigure 3-31 illustrates MLPP calls terminating on a PBX.

Figure 3-31MLPP calls terminating on a PBX

Invoke

IAM

Setup

ACM1Alerting

ANM

TerminatingPBX

MSC

MLPP Precedence

N

E

T

W

O

R

K

MLPP Call Request

MLPPUser Status

Call Proceeding

Connect

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.

Return ResultMLPP Call Request



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 handoverIn 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.



Figure 3-32Precedence on inter-MSC handover

Call precedence and catastrophe screeningCatastrophe 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 handoversWhen a call is being handed over, the DMS-MSC sends the call’s 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.

Handover Request

eMLPP Precedence

Handover Required

Handover Request Ack

Handover Command

Clear Command

Handover Detect

Clear Complete

ServingBSS

TargetBSS

Handover Complete

Prepare HO [HO Request]


IAM

ACM

PAS [HO Detect]

SES [HO Complete]

ANM

MLPP Precedence

ServingMSC

TargetMSC

MLPP Precedence



How the DMS-MSC supports eMLPP 3The DMS-MSC supports eMLPP service by performing the following functions:

• determines the precedence levels of mobile-originated or mobile-terminated calls

• performs called party pre-emption

How the DMS-HLR supports eMLPP 3The 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

Feature interactions 3This 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 waitingWith 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



called party is already on an active call when the calling party tries to terminate to it.

Call holdThe 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.

Figure 3-33Interactions between call waiting, call hold, and eMLPP

User Call waiting Call hold eMLPP Result

calling

called

*

Yes

*

Yes

Yes

No

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.

calling

called

*

No

*

*

Yes

No

The new call is not presented to the called party as a call waiting. The new call is released with the cause “User Busy.”

calling

called

*

Yes

*

No

Yes

Yes

The called party mobile station may invoke called party pre-emption. If called party pre-emption is invoked, the old call is released.

calling

called

*

Yes

*

No

Yes

No

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.

calling

called

*

Yes

*

Yes

Yes

Yes

The called party mobile station may invoke called party pre-emption. If called party pre-emption is invoked, the old call is put on hold.

calling

called

*

*

*

*

No

*

The calling party is assigned the network’s 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.



Emergency callsPoint-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 VGCSThe 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 call’s 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 busyCall 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 replyIf 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 queuingeMLPP service overrides call queuing.

Datafill required for eMLPP service 3The following tables must be datafilled for eMLPP service:

• table OFCVAR

• table GHLRSSOP

• table GHLRNDSC

• table GHLRVLR

• table SERVCNFG




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 datafillDatafill the following office parameters

• EMLPP_DEFAULT_PRECEDENCE


EMLPP_DEFAULT_PRECEDENCEThis 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_CALLThis office parameter defines the network’s 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 datafillTable 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.



Table GHLRNDSC datafillTable 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 datafillTable GHLRVLR contains information about the VLRs with which the DMS-HLR 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 datafillThis 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 3When 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.”




Operational measurements associated with eMLPP service 3The following operational measurement (OM) groups contain information regarding eMLPP service:

• eMLPPSS

• HLRADM3

• MLPP



Grou p eMLPPSSThis 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 HLRADM3This group maintains statistics related to the DMS-HLR supplementary services. This group deals only with GSM defined supplementary services.

Group MLPPThis 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 3The 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=FFFFFFFFFFFFFCSS PAR=FFFFFFFFFFFFFFFFFFFF1CRESULT IND=021C



Fast Call Setup

Purpose of Fast Call Setup 3Fast 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 3Fast 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 originationsThe 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



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.



Figure 3-34Selection of eMLPP Priority level for call setup class query

CMSR received atMSC/VLR

N

Y

N

Y

Query SERVCNFGtable for CLASS callsetup

eMLPP present in CMSR?

Is it greater than the sub-scribed max.

eMLPP?

Use the officeparm precedence

Use the subscribedmax eMLPP

Y

N

Use the selectedeMLPP

Subscribed to eMLPP?

Use the subscribeddefault eMLPP



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-35Example of MS call with Fast Call Setup

Fast call setup is not triggered for classes 2 and 3. Authentication and Cipher procedures are performed as normal. Refer to Figure 3-36.

MSC/VLR

HLR

BSS

Channel Request


Immediate Assign

SABM(CM-Service Request)

Setup

EIR

UA(CM-Service Request)(CM-Service Request)

eMLPP Priority selected by MS

Call Proceeding

Authentication and Ciphering are skipped

affected node

VLRMSC

Send Info Outgoing Call

Complete Call

The rest of the MS call flow is unchanged and omitted for brevity



Figure 3-36Example of MS call without Fast Call Setup

MS terminationseMLPP 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.

MSC/VLR

HLR

BSS

Channel Request




Immediate Assign

SABM(CM-Service Request)

Cipher Mode Command

BSSMAP CipherMode Command

BSSMAP Cipher

Mode Complete Cipher Mode Complete

Setup

EIR

(CM-Service Request)UA(CM-Service Request)

eMLPP Priority selected by MS

* 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.

Call Proceeding

The rest of the MS call flow is unchanged and omitted for brevity

affected node

MSCMSCBSSVLR

Process Access Request

Authenticate

Set Ciphering

Access Request Accepted

Send Info Outgoing Call

Complete Call



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-37Example of MS termination with Fast Call Setup

• 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 3-38.

MSC/VLR

HLR

BSS


Immediate Assign

Paging Response

Setup

EIR

MLPP Priority is mapped exactly one-to-one to eMLPP priority

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.

Call Confirmed

IAM (MLPP priority)

Channel Request

Paging Request Paging (eMLPP priority)

The rest of the MS termination cal flow is unchanged and omitted for brevity

SETUP (eMLPP priority)

affected node

Note: This call flow is also applied to the calls which are considered security risks.

(Page response)

MSC

VLR



Figure 3-38Example of MS termination without Fast Call Setup

Immediate setupImmediate 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.

MSC/VLR

HLR

BSS




Immediate Assign

Paging Response

Cipher Mode Command

BSSMAP CipherMode Command

BSSMAP CipherMode Complete Cipher Mode Complete

Setup

EIR

if priority info included, MLPP Priority is mapped exactly one-to-one to

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

*

Call Confirmed

IAM (MLPP priority)

Channel Request

Paging Request Paging (eMLPP priority)

The rest of the MS termination call flow is unchanged and omitted for brevity

Setup (eMLPP priority)

affected node

(CM-Service Request)

MSC

VLR

Process Access Request

Authenticate

Access Request Accepted

Set Ciphering



Figure 3-39Example of Immediate setup calls with Fast Call Setup

Datafill required for Fast Call Setup 3Fast 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 3There are no log reports associated with Fast Call Setup.

MSC/VLR

HLR

BSS

Channel Request

Immediate Assign

Immediate SetupImmediate Setup

Authentication and Ciphering are skipped, treat Immediate Setup as CM Service

Assignment Request

Assignment Complete

affected node

Note: This call flow is also applied to the calls which are considered security risks.

MSC

VLR

The remainder of the VBS/VGCS call flow is not shown here.

Channel Mode Modify

Channel Mode Modify ACK



Operational measurements associated with Fast Call Setup 3OM 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 3Fast Call Setup does not have an impact on billing information.



Nature of Address (NOA) Format Customization

Purpose of NOA Format Customization 3This functionality enables a network operator to control the address format of certain calling/connected party addresses.

How NOA Format Customization works 3Through 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 number’s 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.



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

Feature interactions 3This 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



SignalingThis 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 EnhancementsThe 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_DIGITSNOA 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 mobile-trunk 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_CLIDThis 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_NOAThe NOA Format Customization functionality overrides OPARM GSM_CALLING_NUMBER_NOA.

Datafill required for NOA Format Customization 3The following tables require datafill to enable the NOA Format Customization functionality:

• table GSMVAR

• table PETSIG

• table OFCVAR


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 datafillThe 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 datafillThis 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.



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 datafillThe 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 3There are no log reports associated with NOA Format Customization.

Operational measurements associated with NOA Format Customization 3

There are no OMs associated with NOA Format Customization.



Billing 3The 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.



Nortel Networks Confidential A-1


Appendix A: Supported GSM11 features A

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

The GSM10 loadGSMR02 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 GSMR02To 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 functionalitiesTo 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 Network-initiated 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 USSDThis 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 Nortel Networks Confidential


• 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 migrationThis 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 supportThis 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

Nortel Networks Confidential Appendix A: Supported GSM11 features 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 CustomizationThis 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 number’s nature of address (NOA):

• national

• international

• unknown

Unsupported GSM11 functionalitiesIn 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-1Action taken on unsupported GSM11 features

Actid Feature name Action taken

GR2456/GR2474

Optimal Routing This feature is SOCed and SOC is turned off for GSMR01 and GSMR02.

GR2638 Anonymous Call Reject

This feature is disallowed at the HLR.

GR2644 CAMEL Phase II Subscription to CAMEL Phase II

This feature is disallowed at the HLR.

GR2734 MI USSD Billing This feature is SOCed and SOC is off for GSMR01 and GSMR02.

GR2802 iDEN Plus Dialing This feature is SOCed and SOC is off for GSMR01 and GSMR02.

—sheet 1 of 3—



GR2578 ISUP UUS3 Support

This feature is executed only by an external event and is not expected to be activated.

GR2634 CAMEL PHASE-II Messaging


GR2644 ISDN UPA Control This feature is executed only by an external event and is not expected to be activated.

GR2645 CAMEL CCH 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.

GR2647 Israel ISUP 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.

GR2654 NI USSD This feature is executed only by an external event and is not expected to be activated.

GR2659 Support of CAMEL FCI

This feature is executed only by an external event and is not expected to be activated. The datafill is disabled.

GR2715 CAMEL2 SSF AC AND ACR


GR2742 ISUP Delivery of QSIG


GR2861 FTSI PRI Call Forwarding




—sheet 2 of 3—

Nortel Networks Confidential Appendix A: Supported GSM11 features A-5


GR2648/GR2897/GR3105

German Carrier Selection

Datafill is disabled.

GR2798 Presentation Address Enhancements


GR2671 GSM Optional Record Number for FTA


GR2561 ETSI PRI Services - Phase II


GR2580 IMEI Provisioning for CI

This feature is disabled.



—sheet 3 of 3—



Nortel Networks Confidential 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 enhancedin order to support the new GSMR02.

The TABXFR processTABXFR 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 transfersThe 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 methodEDM 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.

B-2 Appendix B: DMS-HLR GMR02 One Night Process Nortel Networks Confidential


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 Force-Deregistration feature.

• Table GHLRAUTH is reformatted to reset the MKVER field to “1” if the MKVER is greater than “1.”

The PDM methodPDM 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 tablesThe following tables summarize the actions taken during the DMS-HLR ONP for GSMR02.

GSM10 to GSMR02 dump and restoreTable B-1 shows the subscriber tables changed during a GSM10 to GSMR02 ONP.

Table B-1Subscriber tables changed during a GSM10 to GSMR02 ONP

Table name GSM10 to GSMR02 ONP change

GHLRBSVC Modified to support the VBS and VGCS services*

GHLRNDSC 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—

Nortel Networks Confidential Appendix B: DMS-HLR GMR02 One Night Process B-3


Table B-2 shows the OM groups changed during a GSM10 to GSMR02 ONP.

GSMR01 to GSMR02 dum p and restoreTable B-3 shows the subscriber tables changed during a GSMR01 to GSMR02 ONP.

GSMR02 to GSMR02 dump and restoreAll tables are transferred with no reformats. The new field COR in table GHLRSSOP and renaming the FA to FM should not cause any problem.

GHLRSSOP 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.*

Table B-2OM groups changed during a GSM10 to GSMR02 ONP

OM group GSM10 to GSMR02 ONP change

GHLRADM3 EMLPPPR (initialize to zero)

UUS1PR (initialize to zero)

FAPR (initialize to zero)

GHLRBS VGCS and VBS

(Initialize to zero)

Table B-3Subscriber tables changed during a GSMR01 to GSMR02 ONP

Table name GSMR01 to GSMR02 ONP change

GHLRSSOP Added field COR and renamed FA to FM.

Table B-1Subscriber tables changed during a GSM10 to GSMR02 ONP

Table name GSM10 to GSMR02 ONP change

Note: This change is a GSMR01specific change and is not needed to reformat.

—sheet 2 of 2—

B-4 Appendix B: DMS-HLR GMR02 One Night Process Nortel Networks Confidential


InteractionsThis 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 limitationsA 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 notpredictable.

Nortel Networks Confidential C-1


Appendix C:Data tables used by GSM-R features C

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

C-2 Appendix C: Data tables used by GSM-R features Nortel Networks Confidential


• LACGID

• PETSERVS

• PETSIG

• SERVCNFG

• XLAENTRY

• XXCODE

• XXHEAD

Nortel Networks Confidential 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 descriptionTable 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 descriptionsTable C-1 describes the fields in table ACSMTRX.



Table C-1Table ACSMTRX field descriptions

Field name Description

CT 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—



Datafill sequenceThe datafill of table ACSMTRX is not dependent on any other table.

Dump and restoreNot applicable

ActivationImmediate

Example tupleFollowing is an example of a tuple from table ACSMTRX:

CT234 001 (AMELEM CT7 01 05) (AMELEM CT6 0003 0007)$

TOFC (subfield of option AMELEM)

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—



Table BSSC2TMR



Table descriptionTable BSSC2TMR contains BSSMAP class two engineerable timers that can be associated with a particular location area of a DMS-MSC.

Field descriptionsTable C-2 describes the fields in table BSSC2TMR.

Table C-2Table BSSC2TMR field descriptions


BC2KEY 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—



Datafill sequenceTable 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.

T101 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—



Dump and restoreThe following module sections are modified:

• Module: GTIMRTAI Section: GTIMRTAI

• Module: GTIMRTAI Section: GTMRTCEN

• Module: GTIMRTAI Section: GTIMRTCA

• Module: GTMRCMIF Section: GTMRCMEN

• Module: GTMRCMIF Section: GTMRCMTC

• Module: GTMRCMIF Section: GTMRCMRF

• Module: GTMRCMIF Section: GTMRCMPI

• Module: GTIMRIPL 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.

ActivationNot applicable

Example tupleFollowing is an example of a tuple for table BSSC2TMR:

5 5 5 5 5 5 60



Table DNROUTE


• VBS

• VGCS

Table descriptionTable 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 descriptionsTable C-3 describes the fields in table DNROUTE.

Table C-3Table DNROUTE field descriptions


AREACODE 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—



OFCCODE OFFICE CODE DIGIT REGISTER

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:

• 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.

STNCODE 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—



Datafill sequenceDatafill 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.


TOTLDIGS (subfield of FEAT entry HON or MSC)

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 15Default 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—



ActivationImmediate

Example datafillFollowing is an example of datafill for table DNROUTE.

areacode>6141ofccode>4040stncode>02dn_sel>featfeature>gsmgcntotldigs>12



Table GCAREA


• VBS

• VGCS

Table descriptionTable 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 descriptionsTable C-4 describes the fields in table GCAREA.

Datafill sequenceTable LAC must be datafilled with list of cells prior to table GCAREA.

Dump and restoreN/A

Table C-4Table GCAREA field descriptions


GCA_KEY 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).



ActivationImmediate

Example tupleFollowing is an example tuple from table GCAREA.

GCA_KEY CELLLIST887766 (12 1) (12 2) (13 1) (13 3) (13 5) (13 8) (15 10) (15 11)$



Table GCR


• VBS

• VGCS

Table descriptionTable 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 descriptionsTable 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-5Table GCR field descriptions


GCREF (both)

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.

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—



ANCHOR_ MSC (relay)

ANCHOR MOBILE SWITCHING CENTER

Entry: A vector of up to 15 {0 to 9}’s

Explanation: Stores the anchor MSC’s 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_LIST (anchor)

DISPATCH LIST


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


Explanation: Specifies the dispatcher identity criteria for verifying the dispatcher’s 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


Explanation: Specifies the dispatcher identity criteria for verifying the dispatcher’s 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—



Datafill sequenceTable GCAREA must be datafilled before table GCR.


ActivationImmediate

CIPHER_ KEY (anchor)

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—



Example tupleFollowing is an example of a tuple when the MSC is an anchor MSC:

GCREF ANCHOR_RELAY

RELAY_ MSC_LIST

DISPATCH_LIST

ORIG_LIST KILL_LIST CIPHER_KEY

Codec TIMER PRIORITY

97911231

ANCHOR 614199900000

(2112031100) (2112031101) (2112031102)

(2112031100) (2112031101)

(2112031100) (2112031101)

200 3



Table GHLRBCA

This table is used to support the Functional Addressing functionality.

Table descriptionTable 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 subscriber’s 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 descriptionsTable C-6 contains field descriptions for table GHLRBCA.

Table C-6Table GHLRBCA field descriptions


BCAKEY 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—

contin-



BSVC 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

Table C-6Table GHLRBCA field descriptions (continued)


—sheet 2 of 9—

contin-



ITC 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—

contin-



STR STRUCTURE

ENTRY: SDU, U, or $

EXPLANATION : This field refers to the GSM PLMN connection’s 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—

contin-



SYNC_M 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


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 when synchronous mode (field SYNC_M) is set to S

DEFAULT: N/A



—sheet 5 of 9—

contin-



STOP 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 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


DEFAULT: N/A



—sheet 6 of 9—

contin-



MODEM 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)


• V22bis for UR – 2400 (see field UR)

• V26ter for UR – 2400 (see field UR)

• V32 for UR – 4800 or 9600 (see field UR)


• AUTOBAUD for CE – NT or both (see CE field), SYNC_M–A, and ITC–3K1A


DEFAULT: N/A



—sheet 7 of 9—

contin-



CE 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 – transparentTransparent QoS is characterized by constant throughput, constant transit delay, and variable error rate. The air interface provides no flow control.

• NT – non-transparentNon-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


DEFAULT: N/A



—sheet 8 of 9—

contin-



Datafill sequenceTable GHLRBCA must be datafilled before table GHLRBSVC.

ORDER 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—

contin-



Dump and restoreTable GHLRBCA should be dumped and restored before table GHLRBSVC.

Example datafillFigure C-1 shows the example datafill for table GHLRBCA.

Figure C-1 Example datafill for table GHLRBCA

CI:

CI:>table ghlrbcaTABLE: GHLRBCA>list 5BCAKEY 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 $



Table GHLRCUG

Table descriptionTable 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 descriptionsTable C-7 contains field descriptions for table GHLRCUG.

Table C-7Table GHLRCUG field descriptions


MCC INTERNATIONAL MOBILE SUBSCRIBER IDENTIFICATION CODE (IMSI) Mobile Country Code

ENTRY: 3 digits (0-9)

EXPLANATION : This field indicates the country where a subscriber’s 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—



MNC 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.


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.

DEFAULT: N/A

Table C-7Table GHLRCUG field descriptions (continued)


—sheet 2 of 4—

contin-



CUGSUB 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.

DEFAULT: N/A



—sheet 3 of 4—

contin-



Datafill sequenceThe following tables must be datafilled in this order:

• GHLRAUTH

• GHLRDATA

• GHLRBCA

• GHLRBSVC

• GHLRCUG

• GHLRSSOP

Dump and restoreTable GHLRCUG must be dumped and restored before table GHLRSSOP and after the following tables:

• GHLRBCA

• GHLRAUTH

• GHLRDATA

• GHLRBSVC

Example tupleFigure C-2 shows example datafill for table GHLRCUG.

CUGSUB(continued)

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—



Figure C-2Example datafill for table GHLRCUG

CI:>table ghlrcugTABLE: GHLRCUG

>list 2

TOP

MCCMNC MSIN CUGSUB

---------------------------------------------------------------------

50502 3501215070 (0000 0 16 NONE BSGLIST ( SPCH) $)$

50502 3501215071 (0000 0 16 NONE BSGLIST ( SPCH) $)$

BOTTOM



Table GHLRBSVC


• VBS

• VGCS

Table descriptionTable 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.


• Speech followed by Circuit Duplex Asynchronous (SPCHCDA) and Speech followed by Circuit Duplex Synchronous (SPCHCDS) must have the same MSISDN.

Field descriptionsTable C-8 contains field descriptions for table GHLRBSVC.

Table C-8Table GHLRBSVC field descriptions





DEFAULT: N/A

—sheet 1 of 4—

(contin-






• 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.






DEFAULT: N/A

MSIN MOBILE SUBSCRIBER IDENTIFICATION NUMBER


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

Table C-8Table GHLRBSVC field descriptions (continued)


—sheet 2 of 4—



BSVC 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—



Datafill sequenceThe 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.

CC Country Code


EXPLANATION : This field indicates the country code of the subscriber’s 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


EXPLANATION : Part of the MSISDN that identifies the PLMN

DEFAULT: N/A

SN MSISDN SUBSCRIBER NUMBER


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—



A Bearer Capability Identifier (BCI) value cannot be datafilled unless that value exists in table GHLRBCA.

Dump and restoreTable GHLRDATA must be dumped and restored before table GHLRBSVC is dumped and restored.

Example tupleFollowing is an example of a tuple from table GHLRBSVC:

505 02 1120101001 TPHNY 61 41 1000211001 NIL



Table GHLRFAID


• Functional Addressing (FA)

Table descriptionTable 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 descriptionsTable C-9 contains field descriptions for table GHLRFAID.

Table C-9Table GHLRFAID field descriptions


KEY 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—

(contin-



Datafill sequenceNot applicable

Dump and restoreExisting dump and restore order not affected by this feature.

ActivationImmediate

Example datafillFigure C-3 shows an example of datafill for table GHLRFAID.

Figure C-3Example datafill for table GHLRFAID

COR CLASS OF REGISTRATION

ENTRY: A, B, C, D where A = engine/train cab radio basic functionB = maintenance functionC = operation support functionD = customer support function

EXPLANATION : Identifies the user’s 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

Table C-9Table GHLRFAID field descriptions (continued)


—sheet 2 of 2—

(contin-

CI:>table ghlrfaidTABLE: GHLRFAID>list all

KEY SETBSVC COR

-----------------------------------------------------------------

201 TPHNY AD

203 CDA300 CDA1200 A



Error messagesThe 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’



Table GHLRFANC


• FA

Table descriptionTable GHLRFANC contains FANC routing information relevant to HLRf. This table contains the GSM HLRm FANC number that is mapped to the HLRf.

Field descriptionsTable C-10 contains field descriptions for table GHLRFANC.

Table C-10Table GHLRFANC field descriptions


KEY 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—

(contin-



Datafill sequenceEither GHLRSCF or GHLRXTND tables must be datafilled before this table relying on the datafill in PROCSSAT field.

Dump and restoreDump and restore is provided after GHLRSCF and GHLRXTND tables.

ActivationImmediate

Example datafillFigure C-4 shows an example of datafill for table GHLRFANC.

Figure C-4Example datafill for table GHLRFANC

Error messagesThere 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

NODEADDR (subfield of PROCSSAT)

NODE ADDRESS

ENTRY: Vector of up to 20 characters

EXPLANATION: Identifies the address of the node.

DEFAULT: None

Table C-10Table GHLRFANC field descriptions (continued)


—sheet 2 of 2—

(contin-

CI:>table ghlrfancTABLE: GHLRFANC>list all

KEY PROCSSAT

-------------------------------------------------------------------------------------------------------

987 GSMMSF LONDON



‘<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’



Table GHLRNDSC


• VBS

• VGCS

• Enhanced Multi-level Priority Pre-emption (eMLPP)

Table descriptionTable 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 DMS-HLR 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).

Field descriptionsCAMEL-specific optionsThe 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 subscriber’s 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.

(contin-



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-11CAMEL screening options for VLRs in GHLRNDSC

SMMT-specific optionsThe 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 optionsThe 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.

VLR Version V1 V2 V3

Possible

Screening

Values

N_D N_R N_R

N_S N_S N_S

S_R

S_S



Table C-12 contains field descriptions for table GHLRNDSC.

Table C-12Table GHLRNDSC field descriptions


CLASS 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—



CDAGBS (BSVC Refinement)

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

Table C-12Table GHLRNDSC field descriptions (continued)


—sheet 2 of 33—



CDSGBS (BSCV Refinement)

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—



SMMT (BSVC Refinement)

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 Service-Service 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 SMS-SC.

• 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—



ALS (BSVC Refinement)

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—



ODBOG (ODB Refinement)

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—



ODBPREM (ODB Refinement)

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.

DEFAULT: Version 1 –SX, ND Version 2 –SX, SR, NR 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.

DEFAULT: Version 1 –SX, ND Version 2 –SX, NR Version 3 –SX, NR



—sheet 7 of 33—



ODBCISS (ODB Refinement)

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—



ODBECT (ODB Refinement)

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—



CW (CALLCOMP Refinement)

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—



HOLD (CALLCOMP Refinement)

CALL HOLD


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






HOTBILL (PLMNSPEC Refinement)

HOT BILLING


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.







LCO (PLMNSPEC Refinement)

LOCAL CALLS ONLY SUPPLEMENTARY SERVICE


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.







COS (PLMNSPEC Refinement)

CLASS OF SERVICE SUPPLEMENTARY SERVICE


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.







ACR (PLMNSPEC Refinement)

ACCOUNT CODE REQUIRED


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






ACV (PLMNSPEC Refinement)

ACCOUNT CODE VOLUNTARY


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






MCT (PLMNSPEC Refinement)

MALICOUS CALL TRACE


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






CNAM (PLMNSPEC Refinement)

CALLING NAME DELIVERY


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






CLIP (LINEID Refinement)

CALLING LINE IDENTIFICATION PRESENTATION


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






CLIR (LINEID Refinement)

CALLING LINE IDENTIFICATION RESTRICTION


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.


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.







COLP (LINEID Refinement)

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.







COLR (LINEID Refinement)

CONNECTED LINE IDENTIFICATION RESTRICTION


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.







COLRPH (COLR_PHASE)

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.


MULTIPTY MULTI-PARTY SUPPLEMENTARY SERVICES

ENTRY: MPTY

EXPLANATION : MULTIPTY contains the multi-party supplementary services refinement.

DEFAULT: NONE






MPTY (MULTIPTY Refinement)

MULTI-PARTY SUPPLEMENTARY SERVICE


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






AOCI (CHARGING Refinement)

ADVICE OF CHARGE INFORMATION SUPPLEMENTARY SERVICE


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.







AOCC (CHARGING Refinement)

ADVICE OF CHARGE CHARGING SUPPLEMENTARY SERVICE


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.


MISCPROP MISCELLANEOUS PROPRIETARY SERVICES

ENTRY: INORIG, EA

EXPLANATION : MISCPROP includes intelligent network originating (INORIG) and equal access (EA) refinements.

DEFAULT: NONE






INORIG (MISCPROP Refinement)

INTELLIGENT NETWORK ORIGINATING


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.

DEFAULT: Version 1 - NX Version 2 –NX Version 3 –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.

DEFAULT: Version 1 - NX Version 2 –NX Version 3 –NX






EA 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






CUG (COMUNITY Refinement)

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.

DEFAULT: Version 1 - ND, NS Version 2 –NR, NS, SR, SS 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






CAMEL (MISCGSM Refinement)

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 subscriber’s 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 subscriber’s 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






REGSUB (MISCGSM Refinement)

REGIONAL SUBSCRIPTION SERVICE


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.

0

DEFAULT : Version 1 - NX, ND Version 2 –SX, NX, SR, NR Version 3 –SX, NX, SR, NR

CALLOFF CALL OFFICE

ENTRY: ECT

EXPLANATION : CALLOFF contains the explicit call transfer (ECT) refinement.

DEFAULT: NONE






ECT (CALLOFF Refinement)

EXPLICIT CALL TRANSFER


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.

DEFAULT: Version 1 - NX, ND Version 2 –SX, NX, SR, NR 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






Datafill sequenceThe class name must be datafilled in table GHLRSCMP before it can be used in table GHLRNDSC.

Dump and restoreConversion 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.

PCIC 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






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-5Example datafill for table GHLRNDSC

CI:>table ghlrndscTABLE: 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



Table GHLRPARM

Table descriptionTable 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.

PARMKEY - Parameter KeyThis field requires a vector of up to eight characters to identify the parameter. This field forms the key to this table.

PARMSEL - Parameter SelectorThe PARMSEL field determines the format of the remainder of the area. The parameter PARMSEL must match the PARMKEY field.

PARMVAR - Parameter Variable Data AreaRefer to the appropriate parameter section in this chapter for more information on each PARMVAR in table GHLRPARM.

Table C-13Table GHLRPARM

FIELDNAME RANGE OF VALUES

PARMKEY VECTOR OF UP TO 8 CHARS

PARMSEL {AC_AUDTI, AC_MAX_V, CHKSCFAD, DBMEMLIM, EXTODBON, HLRRELNO, HNESUPD, MATEDVRT, MISCSSN, NAM_DFLT, NDC_DFLT, PASSDFLT, PASSTHLD, RACENETD, REROUTER, ROAMCSI, SBYTIMER, SIMSION, STANDBY}

PARMVAR REFINEMENTS:

MULTIPLE WITH PARMSEL_TYPE



Table GHLRSCF


• FA

Table descriptionTable 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.



Field descriptionsTable C-14 contains field descriptions for table GHLRSCF.

Table C-14Table GHLRSCF field descriptions


SCF_NAME 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—

(contin-



Datafill sequenceA 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 restoreRestore this table using the dump and restore mechanism. The following ONP processes are supported:

• ONP from GSM09 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 datafillFigure C-6 shows example datafill for table GHLRSCF.

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 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

Table C-14Table GHLRSCF field descriptions (continued)


—sheet 2 of 2—



Figure C-6Example datafill for table GHLRSCF

CI:>table ghlrscfTABLE: GHLRSCF>list all

SCF_NAME SCF_NUMBER NUS_AC EVAL_NUS AC_AUDIT

-----------------------------------------------------------------

SCP_1_KEY 7845548942 v2 Y ENABLED

ALTERNATE 4589465368 hlr_max Y ENABLED



Table GHLRSSOP


• FA

• Call Forwarding to FSNs

• VBS

• VGCS

• eMLPP

Table descriptionTable 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 descriptionsTable C-15 contains field descriptions for table GHLRSSOP.

Table C-15Table GHLRSSOP field descriptions





DEFAULT: N/A

—sheet 1 of 18—

(contin-






• 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.






MSIN MOBILE SUBSCRIBER IDENTIFICATION NUMBER


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

Table C-15Table GHLRSSOP field descriptions (continued)


—sheet 2 of 18—

(contin-



SSPROV 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 subscriber’s 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—

(contin-



SSPROV(continued)

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 caller’s name. Operator controlled only.

• COLP – Connected Line Identification Presenting. Allows the called party’s (connected line identity) COLI to be presented to the calling party.

• COLR – Connected Line Identification Restriction. Prevents a called party’s (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—

(contin-



SSPROV(continued)

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, DMS-HLR 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 subscriber’s 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—

(contin-



SSVAR SELECTOR 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 notificationNF – NotificationNFWN – Notification with numberThe default is NONF.

BSG: Basic Service Group for which this Supplementary Service is registered. Valid entries:SPCH – SpeechFAX – Facsimile Group 3CDA – Circuit Duplex AsynchronousCDS – Circuit Duplex SynchronousAUXSPCH – 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—

(contin-



Subfield of SSVAR - selector CFB

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 notificationNF – NotificationNFWN – Notification with numberDEFAULT: 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 notificationNF – NotificationNFWN – Notification with numberDEFAULT: NONF

BSG: Basic Service Group for which this Supplementary Service is registered. Valid entries:SPCH – SpeechAUXSPCH – Auxiliary SpeechFAX – Facsimile Group 3SMS – Short Message ServiceCDA – Circuit Duplex AsynchronousCDS – Circuit Duplex Synchronous


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—

(contin-



Subfield of SSVAR - selector CFNRY

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:


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 notificationNF – NotificationNFWN – Notification with numberDEFAULT: NONF

BSG: Basic Service Group for which this Supplementary Service is registered. Valid entries:SPCH – SpeechAUXSPCH – Auxiliary SpeechFAX – Facsimile Group 3SMS – Short Message ServiceCDA – Circuit Duplex asynchronousCDS – 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—

(contin-



Subfield of SSVAR - selector CFNRC

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:


BSG: Basic Service Group for which this Supplementary Service is registered. Valid entries:SPCH – SpeechAUXSPCH – Auxiliary SpeechFAX – Facsimile Group 3SMS – Short Message ServiceCDA – Circuit Duplex AsynchronousCDS – Circuit Duplex Synchronous


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—

(contin-



Subfield of SSVAR - selector BAOC

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 – SpeechAUXSPCH – Auxiliary SpeechSMS – Short Message ServiceFAX – Facsimile Group 3CDA – Circuit Duplex AsynchronousCDS – Circuit Duplex Synchronous

Subfield of SSVAR - BOIC

SUPPLEMENTARY SERVICE VARIABLE DATA FOR BARRING OF OUTGOING INTERNATIONAL CALLS


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 – SpeechAUXSPCH – Auxiliary SpeechSMS – Short Message ServiceFAX – Facsimile Group 3CDA – Circuit Duplex AsynchronousCDS – Circuit Duplex Synchronous




(contin-



Subfield of SSVAR - BAIC

SUPPLEMENTARY SERVICE VARIABLE DATA FOR BARRING OF ALL INCOMING CALLS


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 – SpeechAUXSPCH – Auxiliary SpeechSMS – Short Message ServiceFAX – Facsimile Group 3CDA – Circuit Duplex AsynchronousCDS – Circuit Duplex Synchronous

Subfield of SSVAR - BOICEXHC

SUPPLEMENTARY SERVICE VARIABLE DATA FOR BARRING OF OUTGOING INTERNATIONAL CALLS, EXCEPT THOSE DIRECTED TO THE HOME PLMN COUNTRY


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 – SpeechAUXSPCH – Auxiliary SpeechSMS – Short Message ServiceFAX – Facsimile Group 3CDA – Circuit Duplex AsynchronousCDS – Circuit Duplex Synchronous




(contin-



Subfield of SSVAR - BICROAM

SUPPLEMENTARY SERVICE VARIABLE DATA FOR BARRING OF INCOMING CALLS WHEN ROAMING OUTSIDE THE HOME PLMN COUNTRY


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 – SpeechAUXSPCH – Auxiliary SpeechSMS – Short Message ServiceFAX – Facsimile Group 3CDA – Circuit Duplex AsynchronousCDS – Circuit Duplex Synchronous

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 – SpeechAUXSPCH – Auxiliary SpeechFAX – Facsimile Group 3CDA – Circuit Duplex AsynchronousCDS – Circuit Duplex SynchronousSMS – Short Message Service




(contin-



Subfield of SSVAR - selector MPTY

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 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




(contin-



Subfield of SSVAR - selector CLIP

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




(contin-



Subfield of SSVAR - selector COS

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 – SpeechAUXSPCH – Auxiliary SpeechFAX – Facsimile Group 3CDA – Circuit Duplex AsynchronousCDS – Circuit Duplex SynchronousSMS – 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.




(contin-



Subfield of SSVAR - selector COLP

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 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




(contin-



Subfield of SSVAR - selector CUG

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 – SpeechAUXSPCH – Auxiliary SpeechFAX – Facsimile Group 3CDA – Circuit Duplex AsynchronousCDS – Circuit Duplex SynchronousSMS – 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.




(contin-



SSVAR (selector CUG) continued

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 – SpeechAUXSPCH – 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.




(contin-



Datafill sequenceA 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 restoreTable 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 datafillFigure C-7 shows example datafill for table GHLRSSOP using a two-digit MNC.



Figure C-7Example datafill for table GHLRSSOP (2 digit MNC)

CI:>table ghlrssopTABLE: GHLRSSOP>list 4

TOP

MCC MNC MSIN SSPROV SELECTOR SSVAR

------------------------------------------------------------------

456 23 1111111 CFU CFU NONEF SPCH12345$

789 23 1111111 CLIP CLIP NP

789 23 1111111 ACRJ ACRJ

456 23 0000001206 CFNRY CFNRY NF NF (SPCH61456123451234530) $



Table GHLRUSSD


• FA

Table descriptionTable GHLRUSSD determines how the unstructured supplementary service data (USSD) string received in a process unstructured supplementary service request (PUSSR) should be processed.

Field descriptionsTable C-16 contains field descriptions for table GHLRUSSD.

Table C-16Table GHLRUSSD field descriptions


USSD_STR 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—

(contin-



SSOPER 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.

Table C-16Table GHLRUSSD field descriptions (continued)


—sheet 2 of 2—

(contin-



Datafill sequenceTables GHLRSCF and GHLRXTND must be datafilled before table GHLRUSSD.

Dump and restoreDump and restore for table GHLRUSSD occurs after GHLRSCF and GHLRXTND.

Example datafillFigure C-8 shows example datafill for table GHLRUSSD.

Figure C-8Example datafill for table GHLUSSD

CI:>table ghlrussdTABLE: GHLRUSSD>list 1TOP

USSD_STR SSCODE SSOPER PROCSSAT

------------------------------------------------------------------

AB4 Y INV gsmSCF SCP_1_KEY

B29 Y INV ExNode XNTD_2_Key



Table GHLRVBCA


• VBS

• VGCS

Table descriptionThis 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 descriptionsTable C-17 contains field descriptions for table GHLRVBCA.



ActivationImmediate

Example datafillFigure C-9 shows an example of datafill for table GHLRVBCA.

Table C-17Table GHLRVBCA field descriptions


GRPID 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

(contin-



Figure C-9Example of datafill for table GHLRVBCA

Error messagesThe 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

TABLE: GHLRVBCA> lis 6GRPID --------------------123125132455654



Table GHLRVGCA


• VBS

• VGCS

Table descriptionThis 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 descriptionsTable C-18 contains field descriptions for table GHLRVGCA.



ActivationImmediate

Example datafillFigure C-10 shows an example of datafill for table GHLRVGCA.

Table C-18Table GHLRVGCA field descriptions


GRPID 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

(contin-



Figure C-10Example of datafill for table GHLRVGCA

Error messagesThe 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

TABLE: GHLRVGCA> lis 6GRPID --------------------123125132455654



Table GHLRVGS


• VBS

• VGCS

Table descriptionTable 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.



Field descriptionsTable C-19 contains field descriptions for table GHLRVGS.

Table C-19Table GHLRVGS field descriptions


MCC MOBILE COUNTRY CODE

ENTRY: Table of 3 BCDs

EXPLANATION : Identifies the country where the PLMN resides. This field is a part of the table’s 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 table’s 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 table’s 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 table’s key.

DEFAULT: N/A

—sheet 1 of 2—

(contin-



Datafill sequenceDatafill table GHLRBSVC before datafilling this table.

HROAM 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 WITHGRP VECTOR OF UP TO 3 BCDsORIGINATION_ENTITLEMENT {Y,N}

{VGCS}VECTOR OF UP TO 50VECTORS 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

Table C-19Table GHLRVGS field descriptions (continued)


—sheet 2 of 2—

(contin-



Dump and restoreTable GHLRVGS must be dumped and restored after tables GHLRBSVC.

Example datafillFigure C-11 shows an example of datafill for table GHLRVGS.

Figure C-11Example datafill for table GHLRVGS

Warning/error messagesThe 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 subscriber’s 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

TABLE:GHLRVGS>lis 2

iii MSINMCC MNC

VGBS HROAM GRPINFO

--------------------------------------------------------------------------------456 23 0000001206 VBS

( 125 Y) ( 236 Y ) ( 456 N )$456 23 0000001206 VGCS ( 121 ) ( 341 ) ( 344 ) ( 456 ) ( 621 ) ( 901 )$

Y

Y

SELECTOR

VBS

VGCS



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



Table GHLRVLR


• eMLPP

Table descriptionTable 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.



Field descriptionsTable C-20 contains field descriptions for table GHLRVLR.

Table C-20Table GHLRVLR field descriptions


VLRADDR 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—

(contin-



LC_AC 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

Table C-20Table GHLRVLR field descriptions (continued)


—sheet 2 of 9—

(contin-



RNE_AC ROAMING NUMBER ENQUIRY APPLICATION CONTEXT VERSION


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 DMS-HLR.

• HLR_MAX – uses the highest RNE AC version supported by the DSM-HLR

• V1 – use V1 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—

(contin-



EVAL_RST 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


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 DSM-HLR

• V1 – use V1 SDM AC version



DEFAULT: HLR_MAX



—sheet 4 of 9—

(contin-



SIE_AC 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


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.


DEFAULT : HLR_MAX



—sheet 5 of 9—

(contin-




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


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—

(contin-



AC_AUDIT APPLICATION CONTEXT AUDIT OPTION


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—

(contin-



OM_ID 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—

(contin-



Datafill sequenceTables GHLRPARM and GHLRPCC must be datafilled before datafilling GHLRVLR.

Dump and restoreThe 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 datafillFigure C-12 shows example datafill for table GHLRVLR.

VLR-ID 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—

(contin-



Figure C-12Example datafill for table GHLRVLR

CI:>table ghlrvlrTABLE: 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 Y V3 N V2 N V2 HLR_MAX HLR_MAX HLR_MAX Y Y V3 PHASE_2 ENABLED



Table GHLRXTND


• FA

Table descriptionTable 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 descriptionsTable C-21 contains field descriptions for table GHLRXTND

Table C-21Table GHLRXTND field descriptions


XTND_NAME 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—

(contin-



Datafill sequenceA symbolic address for an external node must be datafilled in table GHLRXTND before it can be used in table GHLRUSSD.


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.


DEFAULT : HLR_MAX


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


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

Table C-21Table GHLRXTND field descriptions (continued)


—sheet 2 of 2—

(contin-



Dump and restoreDump and restore using the dump and restore mechanism.

Example datafillFigure C-13 shows example datafill for table GHLRXTND.

Figure C-13Example datafill for table GHLXTND

CI:>table ghlrxtndTABLE: GHLRXTND>list 2TOP

XTND_NAME XTND_NUMBER NUS_AC EVAL_NUS AC_AUDIT

----------------------------------------------------------------------------------------------------------------------------

XTND_MAIN 4595635649 V2 Y ENABLED ALTERNATE 7621235684 HLR_MAX Y DISABLED



Table LACGID


• VBS

• VGCS

Table descriptionThis 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 descriptionsTable C-22 describes the fields in table LACGID.

Table C-22Table LACGID field descriptions


LAC 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.



Datafill sequenceBefore table LACGID is datafilled, the following tables must be datafilled:

• table GCAREA

• table GCR


ActivationImmediate

Example tupleFollowing is an example of an example tuple:

12 1 123 88779



Table PETSERVS


• Access Matrix

Table descriptionTable 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 descriptionsTable C-23 describes the fields in table PETSERVS.

Table C-23Table PETSERVS field descriptions


KEY 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 C-24-135.



Table C-24 describes the OPTION fields for table PETSERVS.

Table C-24Table PETSERVS OPTION field descriptions

Option Name Description

CUGMEM CLOSED USER GROUP MEMBERSHIP

ENTRY: Enter 1 to 32 CUGMEM with the following refinements:

• CUGINDEX—Index of the CUG

ENTRY: Integer from 0 to 31

• ICBOCB—A string range describing the intra-CUG calling restrictions.

ENTRY:

— NONE—no inter-CUG restrictions

— ICB—Incoming Calls Barred

— OCB—Outgoing Calls Barred

— BOTH—both ICB and OCB

• INIC—International Network Identification Code.

ENTRY: 4 digits

• INTERLOCK—A 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—



CUGOPT CUG SUBSCRIPTION OPTIONS

ENTRY: Enter zero or one CUGOPT option with the following refinements:

• IAOA—The inter-CUG calling access for this basic service.

ENTRY: NONE, IA, OA, BOTH

— NONE—no inter-CUG access

— IA—Incoming Access

— OA—Outgoing Access

— BOTH—both IA and OA

• CUG_OPTION—CUG options. The only available option is the preferential CUG option.

ENTRY: PREFCUGRefinement: 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.

Table C-24Table PETSERVS OPTION field descriptions (continued)


—sheet 2 of 5—



AOC ADVICE OF CHARGE

ENTRY: Multiple with

• AOCD—Enable or disable AOC-D

ENTRY: N, Y

• AOCE—Enable or disable AOC-E

ENTRY: N, Y

• OIDX—Assign an originator discount class to the PRI trunk

ENTRY: NONE, or 1 to 511

• AOCREL—Release calls if the AOC service cannot be provided

ENTRY: N, Y

• AOCCHGOV—Specify 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—



MCID 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_GROUP

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—



Datafill sequenceTable PETSERVS must be datafilled after the translations tables to allow the XLASYS and XLANAME fields to be populated.


ActivationImmediate

XLASYS 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—



Example tupleFollowing is an example of a tuple from table PETSERVS.

1 AMSCRN



Table PETSIG


• NOA Format Customization

Table descriptionTable 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 descriptionsTable C-25 describes the fields for table PETSIG.

Table C-25Table PETSIG field descriptions


KEY 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—



OVLP OVERLAP OUTPULSING


• 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


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.

Table C-25Table PETSIG field descriptions (continued)


—sheet 2 of 8—

(contin-



SEND_SPC SEND SIGNALING POINT CODE


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


• 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 party’s category not included”.



—sheet 3 of 8—



CPC_REQ REQUEST CALLING PARTY CATEGORY


• 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

• ALWAYS—If 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.

• ALLOWED—If 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.

• NEVER—Under no circumstances is a request for the CPC allowed to be made to the previous node.

CGN_HEX CALLING PARTY ADDRESS HEX DIGITS


• 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


• 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—



RDI_LEN REDIRECTION INFORMATION LENGTH


• 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

• len1—the RDI length is fixed at 1 byte

• len1_or_2— the RDI length is obtained from the RDI counter

• len2—the 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


• 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—



ST STOP DIGIT


• 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


• DELAY

ENTRY: 0 to 32767

EXPLANATION: Specifies the propagation delay value in milliseconds for the specified trunk group.



—sheet 6 of 8—



PREFERRED_NOA 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

• NONE—unspecified

• NATL—national

• NATWNP—national without national prefix

• INTL—international

• UNKNOWN—unknown

• CDN—address 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


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—



Datafill sequenceTo 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 group’s 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 restoreSince 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) $)

OCN ORIGINAL CALLED NUMBER


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—



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.

ActivationImmediate

Example tupleFollowing is an example of a tuple from table PETSIG:

3 (ST Y) $

4 (CDN_HEX (E) $) (CGN_HEX (B) (C) (D) $) $



Table SERVCNFG


• eMLPP

Table descriptionTable 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 descriptionsTable C-26 describes the fields in table SERVCNFG.

Table C-26Table SERVCNFG field descriptions


PRIORITY 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, class3Default 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—



Datafill sequenceThe tuples cannot be added or deleted. They only can be changed.


ActivationImmediate

Example tupleFollowing is an example tuple for table SERVCNFG.

4 CLASS3 N 6

PREEMPT_CAPABLE

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-10Default is 4.

EXPLANATION: This field assigns a timer value.

Table C-26Table SERVCNFG field descriptions


—sheet 2 of 2—



Table XLAENTRY



Table descriptionTable 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).

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.

(contin-



Field descriptionsTable C-27 describes the fields in table XLAENTRY.

Table C-27Table XLAENTRY field descriptions


XLAKEY 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 0—Provides 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 1—Reserved for call forwarding. It applies to the second leg of a call forwarding call.

• Index 2—Reserved for translations on Mobile Subscriber Roaming Numbers (MSRNs).

• Index 3—Reserved for translations of Handover Numbers (HONs).

• Index 4—Used to route Operator Determined Call Barred (ODB) Local mobile subscribers.

• Index 5—Used to route ODB Roamer mobile subscribers.

• Index 6—Used for Intelligent Network (IN) translations.

• Index 7—Used 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—



Datafill sequenceDatafill the following tables in the order listed before datafilling table LAC:

1. Table XLANAME

2. Table PXHEAD

3. Table XLAENTRY


XLASYS TRANSLATION SYSTEM START LOCATION

ENTRY: NIL, AC, PX, CT, FA, OFC, FT, NSC

EXPLANATION : Defines where the translations system starts. Valid entries are

• NIL—none

• AC—access

• PX—prefix

• CT—country

• FA—foreign area

• OFC—office

• FT—utility

• NSC—number 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.

Table C-27Table XLAENTRY field descriptions (continued)


—sheet 2 of 2—



ActivationNot applicable

Example tupleFollowing is an example of a tuple from table XLAENTRY:

0 PX GSMOBILE

1 PX CFXLA



Table xxCODE


• VBS

• VGCS

• IAC


Table descriptionThe 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 operating-company-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.



• Office code (OFC) tables identify a specific DMS-MSC within an area of a country.

Field descriptionsTable C-28 describes the XXCODE fields that pertain to the GSM-R functionalities.

Table C-28Table xxCODE table field descriptions


XLANAME 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—



XLASEL TRANSLATION SELECTOR

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—



XLASEL = DBQIf the XLASEL value is DBQ, datafill the refinements listed in Table C-29.

Table C-29Table xxCODE, XLASEL = DBQ


OPT 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—



DBQCONT 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.


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.

Table C-29Table xxCODE, XLASEL = DBQ (continued)


—sheet 2 of 5—



PCSSAC PERSONAL COMMUNICATION SYSTEM SERVICE ACCESS CODE


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


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—



INAP 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—



Table modifications made for the IAC functionalityThese 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

MM 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—



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 call’s called number.

Table modifications made for the VBS/VGCS functionalitiesThese 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:




Datafill sequenceThe datafill sequence for the AC option in the xxCODE table is shown in Figure C-14.

Figure C-14Datafill sequence for table xxCODE

Dump and restoreNot Applicable.

ActivationImmediate

Table xxHead

Table xxCODE



Example tupleFollowing is an example of a tuple from table xxCODE.

GSMOBILE 1612 1612 DBQ (AC)



xxHEAD



• 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 descriptionThe 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 operating-company-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-, 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.

• Office code (OFC) tables identify a specific DMS-MSC within an area of a country.



Field descriptionsTable C-30 describes the fields for table xxHEAD.

Dump and restoreDuring 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

Table C-30Table xxHEAD field descriptions



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.

• 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.

XLASEL 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).

(contin-



parameters for GSM_DP3_SCP_ADDRESS and GSM_DP3_IN_SVC_KEY as default values for DP3 Triggering.

Nortel Networks Confidential D-1


Appendix D:OPARMS used by GSM-R features D

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.

D-2 Appendix D: OPARMS used by GSM-R features Nortel Networks Confidential


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_CPCThis 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 tuple’s 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_NUMBERThis 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.

Nortel Networks Confidential Appendix D: OPARMS used by GSM-R features D-3


GSM_PAGE_RETRYThis 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_FREQUENCYThis 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.



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_CPCThis 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 tuple’s 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.

MSCLOCThis 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-1MSCLOC subfields range of values

The default value is $.

FIELDNAME

RANGE OF VALUES STATUS DEFAULT VALUES

DESCRIPTION

LAT_DEG 00 ~ 90 New N/A Latitude in degrees

LAT_MM 00 ~ 59 New N/A Latitude Minutes

LAT_SS 00 ~ 59 New N/A Latitude Seconds

LAT_DIR N or S New N/A Latitude Direction

LONG_DEG

000 ~ 180 New N/A Longitude in Degree

LONG_MM 00 ~ 59 New N/A Longitude Minutes

LONG_SS 00 ~ 59 New N/A Longitude Seconds

LONG_DIR E or W New N/A Longitude Direction



REPLACE_INTL_ROAM_CLIDThis 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 OPARM’s 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_DIGITSThis 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 tuple’s value.

Following are the range of values and default values for this OPARM’s 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_CONNThis OPARM updates the network connection. The range of values for this OPARM is Y or N. The default value is Y.



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_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_SIZEThis 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.



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

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

(contin-



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_LENGTHThis 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_VLRThis 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.



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.

NCCBSOffice 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 X ccb 3600

NCCBs = Rccb x 1.5

Table D-2 lists the abbreviations used in the equations for each provisioning rule.

Table D-2Abbreviations for provisioning equations

Abbreviation Definition

HT average voice call Hold Time

ml % of mobile to land calls : ml / (mm + ml + lm + ll)

mm % of mobile to mobile calls : mm / (mm + ml + lm + ll)

lm % of land to mobile calls: lm / (mm + ml + lm + ll)

0



The possible range of values for this OPARM is 0 to 65535. The default value is 80.

NO_OF_HIS_CONTROL_BLKSThis 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_BLKSThis 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_TIDSThis 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:

ll % of land to land calls : ll / (mm + ml + lm + ll)

cf % of number of redirect calls

hd % of number of held calls

c: % of conference calls (Multiparty)

i % of monitored calls (Call Intercept)

lu: number of location updates per call

att number of International Mobile Subscriber Identity (IMSI) attaches per call

det number of IMSI Detaches per call

ho: number of handovers (inter-MSC) per call

sms number of Short Message Service per call

BHCA supportable Busy Hour Call Attempts

Table D-2Abbreviations for provisioning equations

Abbreviation Definition

0

(contin-



(NCCBS) * (0.375)

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_BLOCKSThis 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_FPF_HUGE_AUX_BLOCKSThis 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_BLOCKSThis 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_BLOCKSThis 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:



(0.75) * (2.68) * NCCBS


NUMBER_OF_FPF_SMALL_AUX_BLOCKSThis 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_BLOCKSThis 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_BLOCKSThis 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_TIDSThis 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




NUMBER_OF_MOBILE_CLUSTER_TIDSThis 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_TIDSThis 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_TIDSThis 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_TIDSThis 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




NUMBER_OF_RELAY_LOGICAL_TIDSThis OPARM 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. 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_TTIDSThis OPARM specifies the number of TID pools used to talk to the handover MAP ASE.

NUMBER_OF_TTID_SERVER_TIDSThis 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.




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



• GSMR_FUNCTIONAL_ADDRESS_ENABLED


• MLPP_PBX_FULL_SUPPORT

• MLPP_SERVICE_DOMAIN

• PREFERRED_NOA

• RAILWAY_ACCESS_CODE

• VGCS_DISPATCHER_TALK_CONTROL


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_PRECEDENCEThis 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.











GSMR_FUNCTIONAL_ADDRESS_ENABLEDThis 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.



HIGH_PRIORITY_CALLThis parameter defines the network’s 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_SUPPORTThe 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_DOMAINThis 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_CODEOffice 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.



VGCS_DISPATCHER_TALK_CONTROLThis 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-3DISPATCHER_TALK_CONTROL vector fields


ENABLED ENABLED

ENTRY: N or YDefault 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—



GRANT_TONE GRANT_TONE


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


EXPLANATION: Defines a market defined warning tone that is used to notify the dispatcher that his talk request was rejected.

Table D-3DISPATCHER_TALK_CONTROL vector fields


—sheet 2 of 2—



Nortel Networks Confidential E-1


Appendix E:Log reports generated by GSM-R features E

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 reportsFollowing are the HLR log reports that provide information specific to GSM-R functionalities:

• GHLR401

• GVLR300

GHLR401Log 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.

E-2 Appendix E: Log reports generated by GSM-R features Nortel Networks Confidential


FormatGHLR401 mmmdd hh:mm:ss ssdd SUMM Hourly Report

Last Hour Busy Hour

Subscribers hh:00-hh:00 hh:00-hh:00Activated <subs> <subs>

Real-time Capacity UsageAverage <percent> <percent>Peak <percent> <percent>

Average Subscriber Transaction ProfileCall Routing Requesting Involving a PRN <requests> <requests>Requests Involving a PSI <requests> <requests>Other Call Routing Requests <requests> <requests>ATI - PSI Requests <requests> <requests>SRI - PSI Requests <requests> <requests>Location Update Requests <requests> <requests>Location Update Requests(No ISD) <requests> <requests>GPRS Location Update Requests <requests> <requests>Authentication Requests <requests> <requests>CISS Requests <requests> <requests>SMS Routing Requests <requests> <requests>Report SM Delivery Requests <requests> <requests>Ready For SM Requests <requests> <requests>USSD Indication & Requests <requests> <requests>Standby Requests <requests> <requests>Standby Indicators <requests> <requests>

Performance IndicatorsRequests Acceptance Ratio <percent> <percent>Network Acceptance Ratio <percent> <percent>Transaction Success Ratio <percent> <percent>Off-board AUC Success Ratio <percent> <percent>Off-board AUC Distribution Ratio <percent> <percent>Supercharger Effectiveness Ratio <percent> <percent>USSD Acceptance Ratio <percent> <percent>

Transaction Resource High Water MarkHLR Save Buffers <percent> <percent> Transaction Control Blocks(TCB) <percent> <percent>Transaction Identities (TRID) <percent> <percent>Transaction Components <percent> <percent>Extension Blocks (EXT) <percent> <percent>

Nortel Networks Confidential Appendix E: Log reports generated by GSM-R features E-3


Report exampleGHLR401 OCT09 16:04:19 5504 SUMM Hourly Report

Last Hour Busy Hour

Subscribers 00:00-01:00 10:00-11:00Activated 1000000 1000000

Real-time Capacity UsageAverage 30% 30%Peak 40% 40%

Average Subscriber Transaction ProfileCall Routing Requesting Involving a PRN 0.001 0.001Requests Involving a PSI 0.001 0.001Other Call Routing Requests 0.010 0.010ATI - PSI Requests 0.001 0.001SRI - PSI Requests 0.001 0.001Location Update Requests 0.200 0.500Location Update Requests (No ISD) 0.100 0.400Authentication Requests 1.000 1.000GPRS Location Update Requests 0.069 0.069CISS Requests 0.009 0.009SMS Routing Requests 0.099 0.099Report SM Delivery Requests 0.999 0.999Ready For SM Requests 9.999 9.999USSD Indication & Requests 0.010 0.010Standby Requests 0.001 0.100Standby Indications 0.000 0.100

Performance IndicatorsRequests Acceptance Ratio 1% 1%Network Acceptance Ratio 100% 100%Transaction Success Ratio 10% 10%Off-board AUC Success Ratio N/A N/AOff-board AUC Distribution Ratio 0% 0%Supercharger Effectiveness Ratio 50% 80%USSD Acceptance Ratio 95% 80%

Transaction Resource High Water MarkHLR Save Buffers 3% 4%Transaction Control Blocks (TCB) 8% 9%Peak Transaction Control Block Usage 5% 6%Peak Transaction Control Block Usage 4% 5%Peak Transaction Control Block Usage 10% 12%

(contin-



ActionNo 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.

AnalysisCertain combinations of values may indicate a messaging problem, for examplePRN% > 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 groupsThe following OM groups are associated with Log GHLR401:

• AUCSTATS—GSM HLR Authentication Centers

• GHLRCH—GSM HLR Call Handling

• GHLRFREC—GSM HLR Fault Recovery

• GHLRMMGT— GSM HLR Mobility Management

• GHLRSMGT—GSM HLR Subscriber Management

• GHLRSMS—GSM HLR Short Message Service

• GHLRSSCB—GSM HLR Supplementary Service Call Barring

• GHLRSSCF—GSM HLR Supplementary Service Call Forwarding

• GHLRSSCW—GSM HLR Supplementary Service Call Waiting

• GHLRSSPW—GSM HLR Password Registration

• HISTAT—Subscriber IMSI Status

• HLRWORK—HLR Workload Handling

• HLRUSSDT—HLR Unstructured Supplementary Services Data Traffic

• HSMG2—HLR Subscriber Management V2

• HSMQLOAD—HLR SMS Queue Overload

• HSMSOPS—HLR Short Message Service Operations

• RREQUEST (OM group GHSBYACT) for ‘Standby Requester Attempts’



• PREQUEST (OM group GHSBYACT) for ‘Standby Provider Attempts’

Real-time capacity usage and subscriber profileThe 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 ratioThe 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 ratioThe 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 ratioThis 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



• GHLR610 Supplementary Service VLR Inconsistency Error

• GHLR614 Supplementary Password Registration Error

• GHLR660 Unknown Subscriber

• GHLR661 Unknown Subscriber For SRI

Off-board AUC success ratioThe 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 ratioThe 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 ratioThis 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 markThis 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.



• 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 usageThe 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 Nortel’s involvement.



Requests involving a PSIA 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-1Requests Involving a PSI

The PSI Requests count is taken from the PSIRQ OM register.

USSD MessagesA 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 Process-UnstructuredSS-Request, UnstructuredSS-Request and UnstructuredSS-Notify 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-2USSD Indications & Requests (PUSSR, USSR, USSN)

GPRS Location Update RequestsA 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-3GPRS Location Update Requests

(contin-

Requests Involving a PSI PSI RequestsActivated Subscribers----------------------------------------------------------=

USSD Indications & Request PUSSIN USSRIN USSNIN PUSSRQ USSRRQ USSNRQ+ + + + +Total number of active Subscribers

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------=

(end)<zfmt;

GPRS Location Update Requests UGLRQTotal num Subscribes----------------------------------------------------------=



The total number of subscribers refers to the total number of activated subscribers on the HLR. The figure is displayed in the log.

GVLR300This 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.

FormatGHLR300 mmmdd hh:mm:ss ssdd TBL Resource Unavailable CPIDLocation: <object description>Status: <trouble status>Action: <trouble action>Description: <application-specific text>

Report exampleMSCI***GVLR300 APR23 15:26:17 0544 TBL Resource UnavailableLocation: GSMVLR Database ResourceStatus: Trouble alertTrouble: Lack of system resourcesAction: Review resource provisioningDescription: Unable to add Voice Group Service data to VLR database. Check MAX_VGS_SUBS_IN_VLR in table OFCENG.

ActionThe office parameter MAX_VGS_SUBS_IN_VLR is increased by the network operator to allocate more memory to hold subscriber data.

Associated OM registersThere are no OM groups associated with this log report.

MSC log reportsFollowing are the MSC log reports that provide information specific to GSM-R functionalities:

• GBCS300

• GC6000

• GGCN300

• GMSC301

• GMSC302

• GMSC609

• GMSC612



GBCS300This 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.”

FormatGBCS300 <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 callAction: Ensure all cells that belong to the group call are controlled by a BSS that supports VGCS/VBS group calls.

Report exampleGBCS300 MAR22 08:23:01 7635 TBL Datafill Fault Routeset Name: BSC0538 Group Call Area: 2153Group ID: 1190Description: BSS not equipped to support VGCS/VBS group callAction: Ensure all cells that belong to group call are controlled by a BSS that supports VGCS/VBS group calls.

ActionEnsure all cells that belong to the group/broadcast service area (table GCAREA) are controlled by a BSS that supports VGCS/VBS calls.

Associated OM registersWhen 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

GC6000This log report is generated when

• the VGCS database free queue is corrupted

• the VGCS database bucket queue is corrupted

• the VBS database free queue is corrupted



• the VBS database bucket queue is corrupted

Format<NodeName> <LogNameReportId> <MMMDD> <HH:MM:SS> <XXXX> <LogType> <Log Name>

<Description in Text>

Report exampleMSCI GC6000 NOV11 11:57:35 9600 INFO GC LOG0001: VGCS Audit - Rebuild Free Queue.

Action to be takenNo action is required.

Associated OM registersThere are no OM registers associated with this log report.

GGCN300This log report generates when a group call (GC) number cannot be allocated.

FormatGGCN300 <mmdd hh:mm:ss> <ssdd> GCN Resource UnavailableGroup 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 UnavailableGroup Call Reference: 12345678Action: Review GCN resource provisioning

Description: Unable to allocate Group Call Number.

ActionWhen this log report generates because a GC number cannot be allocated, datafill additional GC numbers in table DNROUTE.


GMSC301This log report generates when hardware is inappropriately installed or datafill is incorrect.



FormatGMSC301 mmdd hh:mm:ss ssdd Resource UnavailableLocation: <GRID>Status: <Trouble Status>Trouble: <Trouble Text>Action: <Action Text>Description: <Description Text>

Report exampleFollowing is an example when there is an error in the call processing software.

GMSC301 OCT17 05:22:01 2104 Resource UnavailableLocation: GSMMSC Software Call ProcessingStatus: Trouble alertTrouble: Request deniedAction: Lack of system resourcesDescription: The digit collection cannot be started. Check the datafill or resource.

ActionCheck the system resources and datafill.


GMSC302This 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.

FormatGMSC302 mmdd hh:mm:ss ssdd TBL Datafill FaultLocation: <GRID>Status: <Trouble Status>Trouble: <Trouble Text>Action: <Action Text>Description: <Description Text>

Report exampleFollowing is an example when a service subscriber dials GID from RMSC:

GMSC302 OCT17 05:22:01 2104 TBL Datafill FaultMSCPS 010000Location: GSMMSC Software Call Processing



Status: Trouble alertTrouble: Request deniedAction: Check datafill and correct if necessaryLAC: 1Cell ID: 1MSISDN: 614112401011Dialed Digits: 123Description: 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 FaultMSCPS 010000Location: GSMMSC Software Call ProcessingStatus: Trouble alertTrouble: Request deniedAction: Check datafill and correct if necessaryDialed Digits: 9268989123Description: Illogical triggering of GCR query in RMSC

ActionThe 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 dispatcher-originator VGCS/VBS call in RMSC only).


GMSC609This 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 informationThe 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.



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 unsuccessfulAn 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.

FormatThe following are two formats for Log GMSC609:

Format for successful emergency call setup GMSC609 mmdd hh:mm:ss ssdd INFO EMERGENCY CALLLocation: <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>



Format for unsuccessful emergency call setup GMSC609 mmmdd hh:mm:ss ssdd INFO EMERGENCY CALLLocation: <object description>LAC: <Location Area Code>Cell ID: <cell identifier>IMEI:<IMEI number>Description: <application-specific text>

Report exampleFollowing are examples of log report GMSC609:

Successful emergency call setup using MSISDN GMSC609 JAN01 00:00:07 2600 INFO EMERGENCY CALLLocation: GSMMSC Software Call ProcessingLAC: 2Cell ID: 21MSISDN: 123456789876EMRG NUMBER: 123456999Description: Emergency Call Setup

Successful emergency call setup using IMEI GMSC609 JAN01 00:00:07 2600 INFO EMERGENCY CALLLocation: GSMMSC Software Call ProcessingLAC: 2Cell ID: 21IMEI: 232012010000101EMRG NUMBER: 123456112Description: 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 CALLLocation: GSMMSC Software Mobility ManagementLAC: 2Cell ID: 21IMEI: 232012010000101Description: Emergency call setup: IMEI as mobile identifier not accepted by the network. Rel. Cause: 5.

ActionNo action is required.




GMSC612This 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

FormatGMSC612 mmdd hh:mm:ss ssdd INFO Fail Complete <CPID>Location: GSMMSC Software Call ProcessingMSG: <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 exampleGMSC612 JUN01 14:45:17 2007 INFO Fail CompleteMSCPS 01001CLocation: GSMMSC IWF Data ServicesMSISDN: 61411000233001MIT=T1MIT 18 msg: Activate-Resp Code: Request DeniedDescription: The IWF Element selected could not be activated.Maintenance action is required. MIT and NIT were set SB.

AnalysisThis log report is generated when the response code included in the IWF-Activate 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.



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.

ActionPerform maintenance on the indicated IWF Element.

Associated OM registersThe OM OUTFAIL is pegged for both the MIT and mate NIT groups each time this log report is generated.



Nortel Networks Confidential F-1


Appendix F:OMs generated by GSM-R features F

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 eMLPPSSThis 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.

F-2 Appendix F: OMs generated by GSM-R features Nortel Networks Confidential


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.

RegisterseMLPP registers are displayed at the Maintenance and Administration Position (MAP) as follows:

PRECDNC4 PRECDNC3 PRECDNC2 PRECDNC1PRECDNC0 PRECDNCB PRECDNCA

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-1Descriptions of registers in OM group eMLPP

Register name Definition

PRECDNCA 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.

PRECDNC0 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.


—sheet 1 of 2—

Nortel Networks Confidential Appendix F: OMs generated by GSM-R features F-3


OMSHOW exampleCI> omshow eMLPP active

eMLPPCLASS: ACTIVESTART:1999/05/17 11:30:00 MON; STOP: 1999/05/17 11:50:10 MON;SLOWSAMPLES: 13 ; FASTSAMPLES: 121 ;

PRECDNC4 PRECDNC3 PRECDNC2 PRECDNC1PRECDNC0 PRECDNCB PRECDNCA

0 55 32 23 4545 49 56

Group EVGCS EVGCS contains registers that count the number of Emergency VGCS calls.

RegistersEVGCS 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.




Table F-1Descriptions of registers in OM group eMLPP


—sheet 2 of 2—



Table F-2Descriptions of registers in OM group EVGCS

OMSHOW>omshow evgcs activeEVGCSCLASS: ACTIVESTART:2000/06/28 14:30:00 WED; STOP: 2000/06/28 14:54:47 WED;SLOWSAMPLES: 15 ; FASTSAMPLES: 149 ;

EVGCSSS EVGCSSS2 EVGCSDI EVGCSDI2

23 4 56 2

Group GHLRADM3GHLRADM3 maintains statistics related to the DMS-HLR supplementary services. This OM group deals with GSM defined supplementary services only.

RegistersGHLRADM3 registers are displayed at the MAP as follows:

MPYT3PR MPTY3PR2 MPTY6PR MPTY6PR2MPTYPR MPTYPR2 CLIPPR CLIPPR2CLIRPR CLIRPR2 AOCIPR AOCIPR2AOCCPR AOCCPR2 COLPPR COLPPR2COLRPR COLRPR2 CUGPR CUGPR2ECTPR ECTPR2 FAPR FAPR2UUS1PR UUS1PR2 EMLPPPR EMLPPPR2


EVGCSSS This peg counts the Emergency VGCS calls originated by a service subscriber.

EVGCSSS2 This is an extension register of EVGCSSS.

EVGCSDI This peg counts the Emergency VGCS calls originated by a dispatcher.

EVGCSDI2 This is an extension register of EVGCSDI.



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-3Descriptions of registers in OM group GHLRADM3


AOCCPR This peg counts the number of subscribers provisioned with Advice of Charge Charges.

AOCCPR2 This is an extension register of AOCCPR.

AOCIPR This peg counts the number of subscribers provisioned with Advice of Charge Information.

AOCIPR2 This is an extension register of AOCIPR.

CLIPPR 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 This is an extension register of CLIPPR.

CLIRPR 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 This is an extension register of CLIRPR.

COLPPR This peg counts the number the number of subscribers provisioned with the Supplementary Service Connected Line Identification Presentation (COLP) at the DMS-HLR.

COLPPR2 This is an extension register of COLPPR.

—sheet 1 of 3—



COLRPR This peg counts the number of subscribers provisioned with the Supplementary Service, Connected Line Identification Restriction (COLR) at the DMS-HLR.

COLRPR2 This is an extension register of COLRPR.

CUGPR This peg counts the number of subscribers provisioned with the supplementary service, Closed User Group (CUG) at the DMS-HLR.

CUGPR2 This is an extension register of CUGPR.

ECTPR This peg counts the number of subscribers provisioned with the Call Transfer supplementary service at the DMS-HLR.

ECTPR2 This is an extension register of ECTPR.

EMLPPPR This pegs counts the number of subscribers provisioned with eMLPP service.

EMLPPPR2 This is an extension register of EMLPPPR.

FAPR This pegs counts the number of subscribers provisioned with functional addressing service.

FAPR2 This is an extension register of FAPR.

MPTYPR 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.

MPTYPR2 This is an extension register of MPTYPR.

MPTY3PR This peg counts the number of subscribers provisioned with the Multi-Party flavour M3PORT at the DMS-HLR.

MPTY3PR2 This is an extension register of MPTY3PR.

MPTY6PR This peg counts the number of subscribers provisioned with the Multi-Party flavour M6PORT at the DMS-HLR.



—sheet 2 of 3—



OMSHOWOMSHOW GHLRADM3 ACTIVEGHLRADM3CLASS: ACTIVESTART:1999/03/23 03:30:00 TUE; STOP: 1999/03/23 11:38:46 TUE;SLOWSAMPLES: 3 ; FASTSAMPLES: 27 ;

MPTY3PR MPTY3PR2 MPTY6PRMPTY6PR2 MPTYPR MPTYPR2 CLIPPRCLIPPR2 CLIRPR CLIRPR2 AOCIPRAOCIPR2 AOCCPR AOCCPR2 COLPPRCOLPPR2 COLRPR COLRPR2 CUGPRCUGPR2 ECTPR ECTPR2 FAPRFAPR2 UUS1PR UUS1PR2 EMLPPPREMLPPPR2

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Group GHLRBSThis OM group maintains statistics related to the DMS-HLR basic services.

RegistersGHLRBS registers are displayed at the MAP as follows:

TPHNY TPHNY2 AXTPHNY AXTPHNY2SMMT SMMT2 SMMO SMMO2CDA CDA2 CDS CDS2FAX3 FAX32 ALTSPFX ALTSPFX2SPCHCDA SPCHCDA2 SPCHCDS SPCHCDSALTSCDA ALTSCDA2 ALTSCDS ALTSCDS2VBS VBS2 VGCS VGCS2

MPTY6PR2 This is an extension register of MPTY6PR.

UUS1PR This pegs counts the number of subscribers provisioned with user-to-user signaling 1 service.

UUS1PR2 This is an extension register of UUS1PR.



—sheet 3 of 3—



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-4Descriptions of registers in OM group GHLRBS


ALTSCDA This register counts the number of subscribers provisioned with alternate speech and data circuit asynchronous service.

ALTSCDA2 This is an extension register of ALTSCDA.

ALTSCDS This register counts the number of subscribers provisioned with alternate speech and data circuit synchronous service.

ALTSCDS2 This is an extension register of ALTSCDS.

ALTSPFX This register counts the number of subscribers provisioned with alternate speech fax service.

ALTSPFX2 This is an extension register of ALTSPFX.

AXTPHNY This register counts the number of subscribers provisioned with auxiliary telephony service.

AXTPHNY2 This is an extension register of AXTPHNY.

CDA This register counts the number of subscribers provisioned with circuit duplex asynchronous service.

CDA2 This is an extension register of CDA.

CDS This register counts the number of subscribers provisioned with circuit duplex synchronous service.

CDS2 This is an extension register of VBS.

FAX This register counts the number of subscribers provisioned with fax service.

FAX2 This is an extension register of FAX.

SMMO This register counts the number of subscribers provisioned with originating mobile service.

SMMO2 This is an extension register of SMMO.

—sheet 1 of 2—



SMMT This register counts the number of subscribers provisioned with terminating mobile service.

SMMT2 This is an extension register of SMMT.

SPCHCDA This register counts the number of subscribers provisioned with speech followed by circuit duplex asynchronous service.

SPCHCDA2 This is an extension register of SPCHCDA.

SPCHCDS This register counts the number of subscribers provisioned with speech followed by circuit duplex synchronous service.

SPCHCDS2 This is an extension register of SPCHCDS.

TPHNY This register counts the number of subscribers provisioned with telephony service.

TPHNY2 This is an extension register of TPHNY.

VBS This register counts the number of subscribers provisioned with VBS through datafill in table GHLRBSVC.

VBS2 This is an extension register of VBS.

VGCS This register counts the number of subscribers provisioned with VGCS through datafill in table GHLRBSVC.

VGCS2 This is an extension register of VGCS.

Table F-4Descriptions of registers in OM group GHLRBS


—sheet 2 of 2—



OMSHOW exampleCI> omshow GHLRBS active

GHLRBSCLASS: ACTIVESTART:1999/05/17 11:30:00 MON; STOP: 1999/05/17 11:50:10 MON;SLOWSAMPLES: 13 ; FASTSAMPLES: 121 ;

TPHNY TPHNY2 AXTPHNY AXTPHNY2 SMMT SMMT2 SMMO SMMO2CDA CDA2 CDS CDS2FAX3 FAX32 ALTSPFX ALTSPFX2SPCHCDA SPCHCDA2 SPCHCDS SPCHCDS2ALTSCDA ALTSCDA2 ALTSCDS ALTSCDS2 VBS VBS2 VGCS VGCS

0 9 0 5 97 0 11 0 16 0 9 015 0 0 00 0 0 00 0 0 04 0 4 0


RegistersGMAPCH2 registers are displayed at the MAP as follows:

PRHOREQ PRHORQ2 PRHORES PRHORS2PRSHREQ PRSHRES GMPSIREQ GMPSIRQ2GMPSIRES GMPSIRS2 RCHREQ RCHRQ2RCHRES RCHRS2 PGCREQ PGCRQ2PGCRES PGCRS2 FGCREQ FGCRQ2PRGCREQ PRGCRQ2



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.

OMSHOWGMAPCH2CLASS: ACTIVESTART: 2001/05/12 12:00:00 TUE; STOP: 2001/05/12 12:29:03 TUE;SLOWSAMPLES: 1 FASTSAMPLES: 0;

PRHOREQ PRHORQ2 PRHORES PRHORS2PRSHREQ PRSHRQ2 GMPSIREQ GMPSIRQ2GMPSIRES GMPSIRS2 RCHREQ RCHRQ2RCHRES RCHRS2 PGCREQ PGCRQ2PGCRES PGCRS2 FGCREQ FGCRQ2PRGCREQ PRGCRQ2

0 0 0 00 0 0 00 0 0 00 0 0 00 0 0 00 0

Table F-5Descriptions of registers in OM group GMAPCH2


FGCREQ This register counts the number of Forward Group Call requests.

FGCRQ2 This register is an extension of register FGCREQ.

PGCREQ This register counts the number of Prepare Group Call requests.

PGCRQ2 This register is an extension of register PGCREQ.

PGCRES This register counts the number of Prepare Group Call results.

PGCRS2 This register is an extension of register PGCRES.

PRGCREQ This register counts the number of Process Group Call requests.

PRGCRQ2 This register is an extension of register PRGCREQ.



Group HLRFAThis OM group measures the data related with functional addressing.

RegistersHLRFA registers are displayed at the MAP as follows:

REGISRQ REGISRQ2 REGINER REGINER2 REGRQER REGRQER2 REGCNERR REGCNER2DEREGRQ DEREGRQ2 DRGINER DRGINER2 DRGRQERR DRGRQERR2 DRGCNERR DRGCNERR2INTERRQ INTERRQ2 INTINER INTINER2INTRQER INTRQER2 INTCNER INTCNER2FERAREQ FERAREQ2 FERINER FERINER2FERRQER FERRQER2 FERCNER 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-6Descriptions of registers in OM group GHLRFA


DEREGRQ This register counts the total number of all FA deregistration requests.

DEREGRQ2 This register is an extension of register DEREGRQ.

DRGINER 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.

DRGINER2 This register is an extension of register DRGINER.

DRGRQERR This register counts the total number of FA deregistration Request errors that occurred because of no response from the HLRf (timeout error).

DRGRQERR2 This register is an extension of register DRGRQERR.

DRGCNERR This register counts the total number of FA deregistration errors sent from the HLRf.

DRGCNERR2 This register is an extension of register DRGCNERR.

FERAREQ This register counts the number of Follow Me (FM) Forced Erasure requests.

—sheet 1 of 3—



FERAREQ2 This register is an extension of register FERAREQ.

FERINER 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.

FERINER2 This register is an extension of register FERINER.

FERRQER 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).

FERRQER2 This register is an extension of register FERRQER.

FERCNER This register counts the number of FM Forced Erasure errors received from the Follow Me functional node.

FERCNER2 This register is an extension of register FERCNER.

INTCNER This register counts the total number of FA interrogation errors sent from the HLRf.

INTCNER2 This register is an extension of register INTCNER.

INTERRQ This register counts the total number of all FA interrogation requests.

INTERRQ2 This register is an extension of register INTERRQ.

INTINER 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.

INTINER2 This register is an extension of register INTINER.

INTRQER This register counts the total number of FA Interrogation Request errors that occurred because of no response from the HLRf (timeout error).

INTRQER2 This register is an extension of register INTRQER.

REGCNERR This register counts the total number of FA Registration errors sent from the HLRf.

REGCNER2 This register is an extension of register REGCNER.



—sheet 2 of 3—



OMSHOW> OMSHOW HLRFA ACTIVECLASS: ACTIVESTART: 1997/12/31 23:59:59 WED; STOP: 1998/01/01 00:00:00 THU; SLOWSAMPLES: 3; FASTSAMPLES: 21;

KEY ( )

REGISRQ REGISRQ2 REGINER REGINER2 REGRQER REGRQER2 REGCNERR REGCNER2DEREGRQ DEREGRQ2 DRGINER DRGINER2 DRGRQERR DRGRQERR2 DRGCNERR DRGCNERR2INTERRQ INTERER2 INTINER INTINER2INTRQER INTRQER2 INTCNER INTCNER2FERAREQ FERAREQ2 FERINER FERINER2FERRQER FERRQER2 FERCNER FERCNER2

0 0 0 00 0 0 0 0 0 0 00 0 0 00 0 0 00 0 0 00 0 0 0

OM logic flow or pseudo codeFigures 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.

REGINER 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.

REGINER2 This register is an extension of register REGINER.

REGISRQ This register counts the total number of all FA registration requests.

REGISRQ2 This register is an extension of register REGISRQ.

REGRQER This register counts the total number of FA Registration Request errors that occurred because of no response from the HLRf (timeout error).

REGRQER2 This register is an extension of register REGRQER.



—sheet 3 of 3—



Figure F-1OM logic flow for the FA registration process

Finish

Getting node selectorfrom table GHLRUSSD

Increment REGINER

Y

(1)N

Y

Y

register.

N (1.1)

Is this FA nodeselector? N

Operation type=Registration?

Increment REGISRQ register

Error sentafter processing reg. message

by HLR?



Figure F-2 shows the logic flow for an FA deregistration process.

register

N

(1.1)

Any error sent by HLRm because of not response from

Y

Any error sent to HLRmby HLRf?

Increment REGCNER

Y

Finish

N

HLR?

Increment REGRQER

register



OM logic flow for a FA deregistration process

Finish

Increment DRGINER

Operation type =deregistration?

Y

N

Y

N(2.1)

(2)

(1)

Error sent afterprocessing dereg. message

by HLRm?

register



Figure F-2 shows the logic flow for an FA interrogation process.

register

N

(2.1)

Y


Increment DRGCNER

Y

Finish

N

Any error sent byHLRm because of no response

from HLRf?

Increment DRGRQER

register



Figure F-2OM logic flow for an FA interrogation process

Finish

Increment INTINER

Operation type =Interrogation?

Y

N

Y

Y

N(3.1)

(2)

Error sentafter processing inter. message by HLRm?

register



Figure F-3 shows the logic flow for an FM Forced Erasure process.

register

N

(3.1)

Y


Increment INTCNER

Y

Finish

N


from HLRf?

Increment INTRQER

register



Figure F-3OM logic flow for an FM Forced Erasure process

F in ish

Getting node selectorfrom table GHLRUSSD

N

Increment FERINER

Operation Type =Erasure

Y

GM3004N

Y

Y

N (1.1)

Increment FERAREQ

&optional parameter1=

88 ?

application

GM2728application

Is SSCODE=FA?

register.

Any error sent duringprocessing forced erasure message

by HLR?

register



Group MCLUSTERThis 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.

register

N

(1.1)

Y

Any error sent to HLRby FFN ?

Increment FERCNER

Y

Finish

N


from FFN?

Increment FERRQER

register



RegistersMCLUSTER registers are displayed at the MAP as follows:

BMCLATT BMCLATT2 GMCLATT GMCLATT2BMCLEST BMCLEST2 GMCLEST GMCLEST2BBSCATT BBSCATT2 GBSCATT GBSCATT2BBSCEST BBSCEST2 GBSCEST GBSCEST2BCHLREQ BCHLREQ2 GCHLREQ GCHLREQ2BCHLASG BCHLASG2 GCHLASG 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-7Descriptions of registers in OM group MCLUSTER


BBSCATT This peg counts the attempts to setup a VBS call on the BSC.

BBSCATT2 This is an extension register of BBSCEST.

BBSCEST This peg counts the times a call controlling SCCP connection is established for a VBS call.

BBSCEST2 This is an extension register of BBSCEST.

BCHLASG This peg stores the channel assigned for a VBS cluster call.

BCHLASG2 This is an extension register of BCHLASG2.

BCHLREQ This peg counts the channel assignment requested for a VBS cluster call.

BCHLREQ2 This is an extension register of BCHLREQ2.

BMCLATT This peg counts the attempts to setup a VBS call on The MSC.

BMCLATT2 This is an extension register of BMCLATT.

BMCLEST This peg counts the VBS calls established on the MSC.

BMCLEST2 This is an extension register of BMCLEST.

GBSCATT This peg counts the attempts to setup a VGCS call on the BSC.

—sheet 1 of 2—



GBSCATT2 This is an extension register of GBSCATT.

GBSCEST This peg counts the times a call controlling SCCP connection is established for a VGCS call.

GBSCEST2 This is an extension register of GBSCEST.

GBSLASG This peg stores the channel assigned for a VGCS cluster call.

GBSLASG2 This is an extension register of GBSLASG.

GBSLREQ This peg counts the channel assignment requested for a VGCS cluster call.

GBSLREQ2 This is an extension register of GBSLREQ.

GMCLATT This peg counts the attempts to setup a VGCS call on The MSC.

GMCLATT2 This is an extension register of GMCLATT.

GMCLEST This peg counts the VGCS calls established on the MSC.

GMCLEST2 This is an extension register of GMCLEST.

Table F-7Descriptions of registers in OM group MCLUSTER


—sheet 2 of 2—



OMSHOW exampleCI> omshow MCLUSTER active

MCLUSTERCLASS: ACTIVESTART:1999/05/17 11:30:00 MON; STOP: 1999/05/17 11:50:10 MON;SLOWSAMPLES: 13 ; FASTSAMPLES: 121 ;

BMCLATT BMCLATT2 GMCLATT GMCLATT2BMCLEST BMCLEST2 GMCLEST GMCLEST2BBSCATT BBSCATT2 GBSCATT GBSCATT2BBSCEST BBSCEST2 GBSCEST GBSCEST2BCHLREQ BCHLREQ2 GCHLREQ GCHLREQ2BCHLASG BCHLASG2 GCHLASG GCHLASG249 0 39 047 0 37 0490 0 390 0485 0 3844880 0 3870 04857 0 3847 0

OM logic flow or pseudocodeFigure F-4 shows the logic flow or pseudocode for OM group MCLUSTER.



Figure F-4Pseudocode for OM group MCLUSTER

Group MSCGCSThis 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).

MSC

VGCS/VBS Assi gnment Re quest

BSCZ

VGCS/VBS Setu p Ack

Signalling on the Call Controlling SCCP connection

Signalling on the Resource Controlling SCCP connections

VGCS/VBS Assi gnment Result

VGCS/VBS Setu p

Peg OM -BSCATT for each BSC

Peg OM -BSCEST for each Setup ACK from BSC

Peg OM -CHLREQ for each channel resource (cell)

Peg OM -CHLASG for each Assignment Result (success) from BSC



RegistersMSCGCS registers are displayed at the Maintenance and Administration Position (MAP) as follows:

VGCSINV VGCSSUB VGCSDSP VGCSDSPJVGCSNDT VGCSULGR VGCSFAILVBSINV VBSSUB VBSDSP VBSDSPJVBSNDT VBSFAIL

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-8Descriptions of registers in OM group MSCGCS


VBSDSP This peg counts the number of times a dispatcher invokes a VBS call.

VBSDSPJ This peg counts the number of times a dispatcher joins in an ongoing VBS call.

VBSFAIL This peg counts the number of unsuccessful VBS invocations.

VBSINV This peg counts the number of VBS invocations.

VBSNDT This peg counts the number of times the network invokes a VBS call.

VBSSUB This peg counts the number of times a VBS call is invoked by a service subscriber.

VGCSDSP This peg counts the number of times a dispatcher invokes a VGCS call.

VGCSDSPJ This peg counts the number of times a dispatcher joins in an ongoing VGCS call.

VGCSFAIL This peg counts the number of unsuccessful VGCS invocations.

VGCSINV This peg counts the number of VGCS invocations.

VGCSNDT This peg counts the number of times the network invokes a VGCS call.

—sheet 1 of 2—



OMSHOW example> OMSHOW MSCGCS ACTIVEMSCGCSCLASS: ACTIVESTART:1999/04/23 16:00:00 FRI; STOP: 1999/04/23 16:18:37 FRI;SLOWSAMPLES: 12 ; FASTSAMPLES: 112 ;

VGCSINV VGCSSUB VGCSDSP VGCSDSPJ VGCSNDT VGCSULGR VGCSFAIL VBSINV VBSSUB VBSDSP VBSDSPJVBSNDT VBSFAIL250 65 24 150 11 600 2270 150 30 7020 4

Group MSUPLNKThis OM group provides information about uplink channel control for a GSM VGCS group call terminating to a list of cells.

RegistersMSUPLNK registers are displayed at the MAP as follows:

UPLKREQ UPLKREQ2 UPLKREJ UPLKREJ2

VGCSSUB This peg counts the number of times a VGCS call is invoked by a service subscriber.

VGCSULGR This peg counts the number of granted uplink requests.

Table F-8Descriptions of registers in OM group MSCGCS


—sheet 2 of 2—



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.

OMSHOW example>omshow MSCUPLNKactive

MSCUPLNKCLASS: ACTIVESTART:1999/05/17 11:30:00 MON; STOP: 1999/05/17 11:50:10 MON;SLOWSAMPLES: 13 ; FASTSAMPLES: 121 ;

UPLKREQ UPLKREQ2 UPLKREJ UPLKREJ227 0 9 0

OM Logic Flow or PseudocodeFigure F-5 shows the logic flow or pseudocode for OM group MSCUPLNK.

Table F-9Descriptions of registers in OM group MSUPLNK


UPLKREQ This register increments when the MSC receives a VGCS Uplink Request from a BSC through the VGCS Call Control SCCP connection.

UPLKREQ2 This register is an extension register of UPLKREQ.

UPLKREJ This register increments when the MSC receives a VGCS Uplink Reject from a BSC through the VGCS Call Control SCCP connection.

UPLKREJ2 This register is an extension register of UPLKREJ.



Figure F-5Logic flow or pseudocode for OM group MSCUPLNK

BSCMSC

Uplink Re quest

Uplink Re quest REJ

Peg OM UPLKREQ

Peg OM UPLKREJ

Nortel Networks Confidential G-1


Glossary GAC

Account Code.

ACRJAnonymous Call Rejection.

A-MSCAnchor MSC.

AoCCAdvice of Charge (Charging).

AoCIAdvice of Charge (Information).

ASCIAdvanced Speech Call Items.

BAICBarring of All International Calls.

BAOCBarring of All Outgoing Calls.

BHCABusy Hour Completed Attempts.

BIC-RoamBarring of Incoming Calls when Roaming outside the Home PLMN country.

Bearer servicesServices providing the lower layer communication functions according to layers 1 to 3 of those reference model.

G-2 Glossary Nortel Networks Confidential


BOIC-exHCBarring of Outgoing International Calls Except those directed to the home PLMN Country.

Breakout codeAllow 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 callA call made to all members of a pre-defined group within a local geographical area.

BSBasic Service.

BSCBase Station Controller.

BSSBase Station Subsystem.

Call typeA prefix used to identify the user number dialed.

Calling subscriberIn 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.

CCCountry Code.

CDNCalled Number.

CFBCall Forward Busy.

CFNCall Forwarding Number.

CFUCall Forward Unconditional.

CFNRcCall Forward on Mobile Subscriber Not Reached.

Nortel Networks Confidential Glossary G-3


CFNRyCall Forward No Reply.

CGNCalling Number.

Class of registrationThe class of registration (CoR) defines a mobile’s 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.

CLIPCalling Line Identification Presentation.

CLIRCalling Line Identification Restriction.

CNAMCalling Name Display.

COLPConnected Line Identification Presentation.

COLRConnected Line Identification Restriction.

COOCell of Origin.

CoRClass of Registration.

COSClass of Service.

CTCall 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.

CUGClosed User Group.



CWCall Waiting.

DBQDatabase Query.

Destination subscriberIn context of VBS and VGCS, a destination subscriber is a subscriber or dispatcher that receives a VBS or VGCS call.

DispatcherA 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-HLRDigital 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 subscriber’s current location.

DMS-MSCDigital Multiplex System - Mobile Services-switching Center. The DMS-MSC is a member of the DMS family of switching systems.

DTAPDirect 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.

DTMFDual-tone Multifrequency.

E.164A standard numbering plan for ISDN numbers that are of the format CC + NDC + SN. The number is at most 15 digits in length.

ECEuropean Commission.

ECTExplicit Call Transfer.



EFNEngine Function Number.

EIRENEEuropean Integrated Railway Radio Enhanced Network. A specification that defines the requirements for the GSM-R network.

eMLPPEnhanced 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 CommissionA group responsible for proposing and implementing the European Union’s legislation.

EXTExtension Service.

FAFunctional Addressing. For definition, see Functional Addressing.

FANCFunctional Address Network Code.

FCFunction Code.

Function codeUsed within the functional addressing scheme. The FC identifies a user by the function the user performs rather than the public number of the user’s terminal.

Functional AddressingA 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 user’s terminal equipment.

Functional identityThe 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 numberThe full number used within the functional addressing scheme to identify an end



user or system by function rather than by a specific item of radio equipment or user subscription.

FSNFunctionally 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.

FTNForward-to Number.

GCAGroup Call Area. A group of cells in a particular DMS-MSC to which a VBS or VGCS call can be established.

GCNGroup Call Number.

GCRGroup Call Register. A database of al group call attributes. The GCR is indexed by the GCRef.

GCRefGroup Call Reference. The GCRef uniquely identifies a group of cells and the dispatchers to which a VBS or VGCS call can be established.

GCQGroup Call Query.

GHOTGSM Hot Billing Stream.

GIDGroup Identity. The GID uniquely identifies a particular group of cells. The GID can be a maximum of 6 BCD digits (3 octets).

Group callA 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 digitsGroup call digits contain group call area digits and group IDs. The group call digits



identify the cells and subscribers/dispatchers setup for the requested group call service.

GSMGlobal System for Mobile Communications. An ETSI (European Telecommunication Standards Institute) driven standard for mobile communications.

GSM-RGSM-Railways is a pan-European radio system that provides digital communications for multiple railway operations.

HandoverThe 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.

HLRHome Location Register. A database that stores permanent data (identity information, authentication information, supplementary services etc.) of subscribers of the home network.

HLRfOne 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).

HLRmOne of the two logical parts of the DMS-HLR. 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 HLRm verifies the request based on the subscriber’s subscription data.

HOHandover.

HPLMNHome Public Land Mobile Network.

IACIntegrated Acknowledgement Center.



IAMIncoming Acknowledgement Message.

IEInformation Elements.

IMSIInternational 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 VLRIntelligent VLR

International callsThe 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.

ISDNIntegrated Services Digital Network.

ISUPISDN User Part. Q.730, Q.761-Q.764.

LCOLocal Calls Only.

Location dependent addressingA 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).

MCTMalicious Call Trace.

MHzMegahertz.

MLPPMulti-level Precedence and Pre-emption.

MORANEMObile 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



railways.

MPTYMulti-party service. For definition, see Multi-party call.

MSCMobile Switching Center. The network entity that performs the calling processing and all its related functions.

MSISDNMobile Station International ISDN Number. An ISDN number (E.164) for routing to a gateway DMS-MSC.

MSRNMobile 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 callsIn the GSM-R network, national calls are those calls that route within the same GSM-R network.

National destination codePart of the set of public numbers (MSISDNs) for GSM-R subscribers. Each GSM-R 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.

NDCNational Destination Code.

NOANature of Address.

NSSNetwork 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).

NUSNetwork Unstructured.



ODBOperator Determined Barring.

PLMNPublic 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.

PRIPrimary Rate Interface.

Private callsIn the GSM-R network, private calls are those calls that stay within the GSM-R network or go between GSM-R networks.

ProtocolA set of rules that control the operation of a communication system.

PSTNPublic Switched Telephone Network. A telephony switching system that provides switching transmission facilities to many customers.

Public callsIn the GSM-R network, public calls are calls to subscriber numbers that begin with “8” or “55” through “59.”

PUSSRProcess Unstructured Supplementary Service Request

RACRailway Access Code.

Railway access codeA prefix used to identify an EIRENE network outside the network in which the calling party is operating.

R-MSCRemote MSC.

RoamingThe use of a mobile on any communications network other than the user’s home network.

Running numberAn identity assigned to a train for a particular journey. The identity is assigned by



the operational staff. A running number may form a component of a functional number used to address users or systems on a train.

SASubaddress.

SCPService Control Point.

SDRSource Directed Routing.

Service subscriberIn 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 digitsShort code digits allow a user to speed dial a number. Short codes are dialed only by mobile stations.

Shunting teamA 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.

SMSShort Message Service.

SOCSoftware Optionality Code.

SSNSubsystem Number.

TeleservicesServices providing the complete user-user communication capabilities including terminal functions according to layers 1 to 7 of the OSI reference model.

TFNTrain Functional Number.

TMSITemporary Mobile Subscriber Identity. A 4 octet temporary subscriber identity having only local significance to the VLR. Used to support subscriber identity



confidentiality.

UICUnion Internationale des Chemins de Fer.

UplinkThe one-way speech path from the mobile to the network.

USSDUnstructured Supplementary Service Data

USSNUnstructured Supplementary Service Number.

USSRUnstructured Supplementary Service Request.

User numberThe entry in a routing database. It consists of the user identity number and the functional number.

UUIUser-to-user Information.

UUS1User-to-user Supplementary Service 1. UUS1 presents the calling functional number to the users. UUS1 transfers the information transparently across the network.

VBSVoice 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.

VGCSVoice Group Call Service. Enables a pre-defined set of destination subscribers in a pre-defined geographical area and entitled dispatchers to hold speech conversations.

VLRVisitor 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 GSM-R 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



number and it supports supplementary services and Short Message Service.

TermDefinition



Family Product Manual Contacts Copyright Confidentiality Legal

GSM


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-5669or send e-mail from the Nortel Networks Customer Training & Documentation World Wide Web site athttp://www.nortelnetworks.com/td

Copyright 1999–2001 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-827Product release: GSMR02Document version: Standard 02.05Date: September 2001Printed in the United States of America