cug

GSM NSS/UMTS CCN

HLR200Subscriber Data Model

411-2831-332

GSM18/UMTS04 Preliminary 01.02 March 2005

What’s inside...

You will find a comprehensive reference to the HLR Subscriber Data Model, its components and their validations.

You will be able to see an overview of the HLR subscriber profile and its components, and look up details of all the components, their dataitem syntax and validations, and also details of all the items in the Oracle subscriber profile database.

Preliminary

test

GSM NSS/UMTS CCN


Document number: 411-2831-332Product release: GSM18/UMTS04Document version: Preliminary 01.02 Date: March 2005

Copyright Country of printing Confidentiality Legal statements Trademarks

Copyright © 1996–2005 Nortel, All Rights Reserved

Printed in the United States of America/Canada

NORTEL CONFIDENTIAL

The information contained herein is the property of Nortel and is strictly confidential. Except as expressly authorized in writing by Nortel, 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, the holder is granted no rights to use the information contained herein.

Information is subject to change without notice. Nortel reserves the right to make changes in design or components as progress in engineering and manufacturing may warrant.

* Nortel, the Nortel logo, the Globemark, and Unified Networks are trademarks of Nortel. 3rd Party Trademark A-N Additional 3rd party trademark A-N 3rd Party Trademark O-Z Additional 3rd party trademark O-Z Trademarks are acknowledged with an asterisk (*) at their first appearance in the document.

iv Nortel Confidential Copyright © 1996–2005 Nortel

The following apply to components or elements used in the GEM load and are used by permission of the respective owners.

Copyright notice/license for Perl

Preamble

The intent of this document is to state the conditions under which a Package may be copied, such that the Copyright Holder maintains some semblance of artistic control over the development of the package, while giving the users of the package the right to use and distribute the Package in a more-or-less customary fashion, plus the right to make reasonable modifications.

Definitions:

“Package” refers to the collection of files distributed by the Copyright Holder, and derivatives of that collection of files created through textual modification.

“Standard Version” refers to such a Package if it has not been modified, or has been modified in accordance with the wishes of the Copyright Holder as specified below.

“Copyright Holder” is whoever is named in the copyright or copyrights for the package.

“You” is you, if you're thinking about copying or distributing this Package.

“Reasonable copying fee” is whatever you can justify on the basis of media cost, duplication charges, time of people involved, and so on. (You will not be required to justify it to the Copyright Holder, but only to the computing community at large as a market that must bear the fee.)

“Freely Available” means that no fee is charged for the item itself, though there may be fees involved in handling the item. It also means that recipients of the item may redistribute it under the same conditions they received it.

1. You may make and give away verbatim copies of the source form of the Standard Version of this Package without restriction, provided that you duplicate all of the original copyright notices and associated disclaimers.

2. You may apply bug fixes, portability fixes and other modifications derived from the Public Domain or from the Copyright Holder. A Package modified in such a way shall still be considered the Standard Version.

411-2831-332 Preliminary 01.02 March 2005

vNortel Confidential Copyright © 1996–2005 Nortel

3. You may otherwise modify your copy of this Package in any way, provided that you insert a prominent notice in each changed file stating how and when you changed that file, and provided that you do at least ONE of the following:

a. place your modifications in the Public Domain or otherwise make them Freely Available, such as by posting said modifications to Usenet or an equivalent medium, or placing the modifications on a major archive site such as uunet.uu.net, or by allowing the Copyright Holder to include your modifications in the Standard Version of the Package.

b. use the modified Package only within your corporation or organization.

c. rename any non-standard executables so the names do not conflict with standard executables, which must also be provided, and provide a separate manual page for each non-standard executable that clearly documents how it differs from the Standard Version.

d. make other distribution arrangements with the Copyright Holder.

4. You may distribute the programs of this Package in object code or executable form, provided that you do at least ONE of the following:

a. distribute a Standard Version of the executables and library files, together with instructions (in the manual page or equivalent) on where to get the Standard Version.

b. accompany the distribution with the machine-readable source of the Package with your modifications.

c. give non-standard executables non-standard names, and clearly document the differences in manual pages (or equivalent), together with instructions on where to get the Standard Version.

d. make other distribution arrangements with the Copyright Holder.

5. You may charge a reasonable copying fee for any distribution of this Package. You may charge any fee you choose for support of this Package. You may not charge a fee for this Package itself. However, you may distribute this Package in aggregate with other (possibly commercial) programs as part of a larger (possibly commercial) software distribution provided that you do not advertise this Package as a product of your own. You may embed this Package's interpreter within an executable of yours (by linking); this shall be construed as a mere form of aggregation, provided that the complete Standard Version of the interpreter is so embedded.

GSM NSS/UMTS CCN HLR200 Subscriber Data Model GSM18/UMTS04

vi Nortel Confidential Copyright © 1996–2005 Nortel

6. The scripts and library files supplied as input to or produced as output from the programs of this Package do not automatically fall under the copyright of this Package, but belong to whoever generated them, and may be sold commercially, and may be aggregated with this Package. If such scripts or library files are aggregated with this Package via the so-called "undump" or "unexec" methods of producing a binary executable image, then distribution of such an image shall neither be construed as a distribution of this Package nor shall it fall under the restrictions of Paragraphs 3 and 4, provided that you do not represent such an executable image as a Standard Version of this Package.

7. C subroutines (or comparably compiled subroutines in other languages) supplied by you and linked into this Package in order to emulate subroutines and variables of the language defined by this Package shall not be considered part of this Package, but are the equivalent of input as in Paragraph 6, provided these subroutines do not change the language in any way that would cause it to fail the regression tests for the language.

8. Aggregation of this Package with a commercial distribution is always permitted provided that the use of this Package is embedded; that is, when no overt attempt is made to make this Package's interfaces visible to the end user of the commercial distribution. Such use shall not be construed as a distribution of this Package.

9. The name of the Copyright Holder may not be used to endorse or promote products derived from this software without specific prior written permission.

10. This package is provided ‘as is’ and without any express or implied warranties, including, without limitation, the implied warranties of merchantability and fitness for a particular purpose.

The standard version of the Perl interpreter is obtained from the following link:

http://www.perl.com/pub/a/language/info/software.html

Copyright notice/license for Zlib library for data compression

(C) 1995-1998 Jean-loup Gailly and Mark Adler

This software is provided ‘as-is’, without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software.


viiNortel Confidential Copyright © 1996–2005 Nortel

Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required.

2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.

3. This notice may not be removed or altered from any source distribution.

Jean-loup Gailly: [email protected]

Mark Adler: [email protected]


viii Publication historyNortel Confidential Copyright © 1996–2005 Nortel


Publication historyMarch 2005

GSM18.0/UMTS04, 01.02. This is the first published version of this document for the preliminary release of Nortel HLR200 solution (NSS18).

November 2004

GSM18.0/UMTS04, 01.01. This is the first draft of this document for the preliminary release of the Nortel HLR200 solution (NSS18).

ixNortel Confidential Copyright © 1996–2005 Nortel

Contents 1

About this document xiiiDefinition of audience xiiiDocument structure xiiiHow to use this document xivKey concepts xvMated pair xvRelated documents & references xv

Chapter 1: Introduction 17 17Profile graphical representation 20Data model and validations 31

Chapter 2: Component descriptions 41Authentication data 41Profile control data introduction 44Barring control 45Category 46IMSI Status 49LMU (Location Measurement Unit) 51NAM (Network Access Mode) 52Password 53Roaming Entitlement 54SOAPROV 55Basic Services Introduction 56ALTSPCDA (Alternate Speech / CDA Data) 59ALTSPCDS (Alternate Speech / CDS Data) 61ALTSPFAX (Alternate Speech / Fax Group 3) 63AUXTPHNY (Auxiliary Telephony) 65CDA (Circuit Duplex Asynchronous Data) 67CDA300 (Circuit Duplex Asynchronous Data 300) 68CDA1200 (Circuit Duplex Asynchronous Data 1200) 70CDA1275 (Circuit Duplex Asynchronous Data 1275) 72CDA2400 (Circuit Duplex Asynchronous Data 2400) 74CDA4800 (Circuit Duplex Asynchronous Data 4800) 76


CDA9600 (Circuit Duplex Asynchronous Data 9600) 78CDAGBS (Circuit Duplex Asynchronous Data General Bearer Service) 80

x ContentsNortel Confidential Copyright © 1996–2005 Nortel

CDS (Circuit Duplex Synchronous Data) 82CDS1200 (Circuit Duplex Synchronous Data 1200) 83CDS2400 (Circuit Duplex Synchronous Data 2400) 85CDS4800 (Circuit Duplex Synchronous Data 4800) 87CDS9600 (Circuit Duplex Synchronous Data 9600) 89CDSGBS (Circuit Duplex Synchronous Data General Bearer Service) 91FAX3 (Facsimile Group 3) 93SMMO (Short Message Mobile Originating) 95SMMT (Short Message Mobile Originating) 97SPCHCDA (Speech followed by CDA Data) 99SPCHCDS (Speech followed by CDS Data) 101TPHNY (Telephony) 103VBS (Voice Broadcast Service) 105VGCS (Voice Group Call Service) 106Supplementary Services introduction 107ACC (Accounting Codes) 109ACRJ (Anonymous Call Rejection) 110AOCC (Advice of Charge Charging) 111AOCI (Advice of Charge Information) 112BAIC (Barring of All Incoming Calls) 113BAOC (Barring of All Outgoing Calls) 115BICRoam (Barring of Incoming Calls when Roaming outside HPLMN country) 117BOIC (Barring of Outgoing International Calls) 119BOICexHC (Barring of Outgoing International Calls except to HPLMN Country) 121CFB (Call Forward when Busy) 123CFNRc (Call Forward when Not Reachable) 130CFNRy (Call Forward when No Reply) 136CFU (Call Forward Unconditionally) 143CLIP (Calling Line ID Presentation) 150CLIR (Calling Line ID Restriction) 151CNAM (Calling Name Delivery) 152COLP (Connected Line ID Presentation) 153COLR (Connected Line ID Restriction) 154COS (Class of Service) 155CUG (Closed User Groups) 158CUG Subscription (Closed User Groups Subscription) 159CUG Feature (Closed User Groups Feature) 161CW (Call Waiting) 164ECT (Explicit Call Transfer) 166EMLPP (Enhanced Multi Level Precedence & Pre-emption) 167EXT (Extension Services) 168FM (Follow Me) 175HOLD (Call Hold) 177HOTBILL (Hot Billing) 178LCO (Local Calls Only) 179MCT (Malicious Call Trace) 180MPTY (Multiparty) 181UUS1 (User to User Signalling stage 1) 182WPS (Wireless Priority Service) 183ODBs (Operator Determined Barrings) 184


CAMEL services introduction 186

Contents xiNortel Confidential Copyright © 1996–2005 Nortel

D-CSI (Dialled CSI) 187GPRS-CSI (General Packet Radio Service CSI) 189M-CSI (Mobility Management CSI) 192O-CSI (Originating CSI) 193SMS-CSI (Short Message Service CSI) 201SS-CSI (Supplementary Service CSI) 203T-CSI (Terminating CSI) 204TIF-CSI (Translations Information Flag CSI) 209USSD-CSI (Unstructured Supplementary Service Data CSI) 210Location Services (LCS) Introduction 211LCS Autonomous Self Location 212LCS Basic Self Location 213LCS Call Related 214LCS Call Unrelated 216LCS GMLCs 218LCS PLMN Operator 219LCS Transfer to Third Party 221LCS Universal 222GPRS (General Packet Radio Service) 223Other Services introduction 229CLIN (Calling Line Identification Replacement Number) 230EA (Equal Access) 231Proprietary IN (Proprietary Intelligent Network service) 232Other components introduction 233HST (Home Subscriber Trace) 234SIMR (SIM Replacement) 235

Chapter 3: Suppression States 239BICRoam suppression state determination 241CFB suppression state determination 241CFNRc suppression state determination 242CFNRy suppression state determination 242CFU suppression state determination 243EXT suppression state determination 244ODB BICRoam suppression state determination 244ODB BAOCRoam suppression state determination 245ODB HPLMN specific sategories suppression state determination 245 246

Appendix A: Oracle implementation 247Datatypes in Oracle 247Section Structure 251Schema tables listing and diagram 252Guide to table sections 256Table SUB_AUTH 258Table SUB_GENERAL 259Table SUB_ODBS 262Table SUB_BASIC_SERVICES 264Table SUB_BAIC 265


Table SUB_BAOC 267

xii ContentsNortel Confidential Copyright © 1996–2005 Nortel

Table SUB_BICROAM 269Table SUB_BOIC 271Table SUB_BOICEXHC 273Table SUB_CFB 275Table SUB_CFNRC 277Table SUB_CFNRY 279Table SUB_CFU 281Table SUB_COS 283Table SUB_CUG_FEATURE 285Table SUB_CUG_SUBSCRIPTION 287Table SUB_CW 289Table SUB_EXT 291Table SUB_IMSI_SS 294Table SUB_DCSI 297Table SUB_GPRS_CSI 299Table SUB_MCSI 301Table SUB_OCSI 302Table SUB_SMS_CSI 309Table SUB_SS_CSI 310Table SUB_TCSI 311Table SUB_USSD_CSI 315Table SUB_CLIN 317Table SUB_EA 318Table SUB_GPRS_PROV 319Table SUB_GPRS_PDPS 320Table SUB_LCS_CALL_RELATED 321Table SUB_LCS_CALL_UNRELATED 324Table SUB_LCS_GMLCS 327Table SUB_LCS_MOBILE_ORIGINATING 329Table SUB_LCS_PLMN_OPERATOR 331Table SUB_LCS_UNIVERSAL 333Table SUB_VBS 334Table SUB_VGCS 339Table SUB_SIMR 342Routing Schema 343

Glossary of terms 347


xiiiNortel Confidential Copyright © 1996–2005 Nortel

About this document 1This document details the HLR subscriber data model, specifically provisionable permanent profile data. The profile is made up of a primary ID and profile components, which may or may not have dataitems. Every dataitem has syntax rules, which must be adhered to. Dataitems within a component may interact with each other, often referred to as intra-component or intra-service validations (the vast majority of components are services). Components or their dataitems may interact with other components or their dataitems; these are often referred to as inter-component or inter-service validations. Some components also interact with system data. Some components also have provisioning side-effects. This document details all of these data model characteristics.

Audience 1This publication is written as a detailed guide to the HLR subcriber data model and its validation, including a detailed reference of the Oracle database implementation. It is intended for any person involved in the planning, engineering, administration or maintenance of the HLR.

Document structure 1“Chapter 1: Introduction”, gives a brief introduction to the profile and the section “Profile graphical representation” on page 1-20 shows the profile components in several figures. The concept of data sets is introduced. The section “Data model and validations” on page 1-31 introduces the data model and its components. The profile components are listed in full (Table 1-1) and introductions are given to the datatypes and validations.

“Chapter 2: Component descriptions” is the main section in the document, and describes in detail the data model and its validations. It contains a section by section description of the components, including introduction to various component groups (e.g. basic services). Datafill subsections give each component’s dataitems, their syntax rules and their intra-service interactions. Interactions subsections give system data interactions, service-service interactions and provisioning side-effects.


xiv About this documentNortel Confidential Copyright © 1996–2005 Nortel

“Chapter 3: Suppression States” details suppression state determination for those services that have a suppression state. Such states are not part of the profile, but are determined in part by the profile, so are given here.

“Appendix A: Oracle implementation” is the detailed reference of the Oracle implementation of the subscriber profile. The Oracle schema is introduced, including the implementation of vectors and sets in the relational database. The schema tables are both listed (Table A-4 on page A-252) and given in a diagram (Figure A-1 on page A-255), followed by sections detailing each table in the schema. A guide to these sections is included (section “Guide to table sections” on page A-256). General table information is given (such as what the primary key is), along with syntax descriptions of each column, with examples.

“Glossary of terms” is a comprehensive glossary of all acronyms and abbreviations used in the profile.

How to use this document 1This document is primarily a reference of the data model and its validations, hence is useful for looking up services, their dataitem syntax, validations etc. -- use Chapter 1, “Data model and validations”starting on page 1-31 and then “Chapter 2: Component descriptions”. The profile components are listed in Table 1-1 on page 1-31.

A reference of the Oracle schema is given in “Appendix A: Oracle implementation”starting on page A-247, with a schema table listing in Table A-4 on page A-252. A guide to the schema descriptions is given in “Guide to table sections” on page A-256 using an example table. The routing schema is given in “Routing Schema” on page A-343.

A graphical representation of the profile is given in Chapter 1, “Profile graphical representation” starting on page 1-20. This is useful to get an overview of what the profile is; what types of profile components exist, and what they all are.

A good starting point is the introduction to profiles in Chapter 1. Various component groups are introduced in Chapter 2: profile control data on page 2-44, basic services on page 2-56, supplementary services on page 2-107, CAMEL services on page 2-186, location services on page 2-211, other services on page 2-229 and other components on page 2-233.


About this document xvNortel Confidential Copyright © 1996–2005 Nortel

Key concepts 1The following definitions are useful to help read the rest of the document.

• HLR Subscriber Profile: provisionable permanent subscriber data, encompassing profile components such as authentication data and various services. It does not include temporary data such as location data and service suppression states.

• Profile Components: various components make up the subscriber profile. A profile component is a generic term to describe a logical unit of subscriber data. An example component is authentication data. Many components can be subcategorised; for example, many components are services, which themselves can be subcategorised, into basic services for example. Components are units that are explicitly provisioned, for example the provisioning protocol allow you to provision Service X (you do not provision “dataitem Y and dataitem Z”).

• Dataitem: a single piece of data: a text string, a boolean etc.

• Provisioning: the ability to manage HLR data in terms of adding data, modifying data and deleting data. In the context of this document, provisioning refers to management of subscriber profile data.

• System Data: that data that is keyed by some entity other than a subscriber ID. For example, the algorithms system table is keyed by an algorithm centre node number.

Mated pair 1This document does not contain any information relating to HLR mated pair functionality. Note that this functionality adds dataitems to the data model and enforces additional validations. Please refer to the mated pair documentation for details on this functionality.

Related documents & references 1The following documents are useful to read or reference in conjunction with this document.

• GSM18 HLR Customer Data Schema NTP, 411-2831-451 (for reference of system tables only)

• GSM18 HLR Office Parameters Reference Manual NTP, 411-2831-510


xvi About this documentNortel Confidential Copyright © 1996–2005 Nortel


1-17Nortel Confidential Copyright © 1996–2005 Nortel

Chapter 1: Introduction 11

The subscriber profile is essentially composed of a primary ID and a collection of profile components. A component is a logical group of data/functionality. Components may be mandatory or optional, may or may not have datafill, and may be a distinct are of functionality or relate to the profile as a whole (these latter items are called profile control components). A group of optional components called basic services have a secondary ID as one of their dataitems. These IDs can be shared across a subscriber’s basic services, but cannot be shared across subscribers.

A high level view of the profile is given in Figure 1-1 on page 1-18. The top box shows a very general view of the subscriber profile. The second box expands on the type of components that exist. Some components are mandatory, namely Authentication data and Profile Control components. The primary ID is also mandatory, although secondary IDs are optional. All optional components have a provisioned state, to indicate whether they are present or not. This state is not explicitly included in the data syntax tables in “Chapter 2: Component descriptions” of this document, as this state exists even if the subscriber does not have the component (i.e. it is set to false).


1-18 Chapter 1: IntroductionNortel Confidential Copyright © 1996–2005 Nortel

The profile components are further detailed in Figure 1-2 on page 1-19. For service data, the different service classifications are given, rather than the individual services. The profile is further described in several figures in the next section. The data model and its validations are given in full detail in “Data model and validations” starting on page 1-31.

Figure 1-1 Subscriber Profile high level view

SUBSCRIBERID

PROFILE COMPONENTS

COMPONENT

DATAFILL

SUBSCRIBERIMSI

Authentication Data

PROFILE COMPONENTS

Other Component

A component that doesn’t fit into

Profile Control Data

Service Data

Profile Control or Service categories.

Authentication data is the primarycomponent and defines theexistence of a subscriber

The primary ID

The subscriber profile is a collection ofmandatory and optional components,many have datafill, although not all.

Profile Control data are distinctmandatory components thathelp define the subscriber’s profile.e.g. IMSI Status

e.g. SIMR and HST

Service data components are theindividual services which have beenprovisioned to the subscriber.They are all optional. e.g. BAOC


Chapter 1: Introduction 1-19Nortel Confidential Copyright © 1996–2005 Nortel

Figure 1-2 Subscriber Profile components

Authentication Data

Barring Control

AUTHENTICATION DATA

PROFILE CONTROL DATA

Category

IMSI Status

LMU

NAM

Password

Roaming Entitlement

SOAPROV

SERVICE DATA

ODBs

Basic Services

Supplementary Services

CAMEL Services

Location Services

GPRS

Other Services

OTHER COMPONENTS

SIMR

HST



Profile graphical representation 1The subscriber profile encompasses a large number of components. These components are described in detail (see “Data model and validations” on page 1-31 and “Chapter 2: Component descriptions”). However, this section provides a graphical representation of the profile components.

Each component is given, together with an indication of whether the component is mandatory or optional, and a high-level view of its dataitems. Individual dataitems are not indicated, but instead are grouped into set data and other data (“non-set data”). Where a component has no dataitems this is indicated.

An introduction to the graphical representation is given in Figure 1-4 on page 1-22, with the components illustrated from Figure 1-5 to Figure 1-12. More information on sets is given in “Data sets” below.

Data setsA component is essentially a logical group of dataitems. Within a component there are often further logical groups of data -- these are called sets. A set is usually optional, having a “provisioned” state much like that of optional components. Not all dataitems belong to a set, these are given the awkward description of “non-set” data.

The syntax tables in “Data model and validations” on page 1-31 and in “Chapter 2: Component descriptions” indicate components’ sets, and the dataitems they contain (sets are named). Note that the “optional” column has a slightly different meaning for those dataitems in a set. It indicates that the dataitem is optional if the set is provisioned. If the set is not provisioned, then none of the dataitems will be datafilled, so they are all optional in a wider sense. A set’s provisioning state is not included in the syntax tables.

If a component has a set, it usually has multiple sets. A component with two sets is illustrated in Figure 1-3 on page 1-21. It is quite common for these sets to contain a similar group of dataitems (if not identical).



.

Figure 1-3 Sets illustrated

Some Component

Dataitem A

Dataitem B

Dataitem D

Dataitem E

Dataitem F

Dataitem G

Dataitem H

Dataitem C

Dataitem A and Dataitem B are notpart of a set (they are “non-set” data)

Dataitem C, Dataitem D and Dataitem Elogically group to form a set. The sethas a name, e.g. SPCH Registration set

Dataitem F, Dataitem G and Dataitem Halso logically group to form a set.e.g. AUXPSCH Registration set



Figure 1-4 Subscriber Profile diagram examples

Service X M

Profile Component Name

Indicates whether the component ismandatory (‘M’) or optional (‘O’)

Means the profile component has

Means the profile component hasa data set (its name is given, here is it

EXAMPLES

Telephony has datafill but no sets

CFU has non-set data and also fivesets of registration data. Note that

Data

SPCH Reg

TPHNY O

CFU O

SPCH Reg AUXS Reg

CDA Reg CDS Reg FAX Reg

Data

Data

dataitems that are not part of aset (“non-set data”)

“SPCH Reg”). There may be multiple sets.

ODB BAOC O

No data

BOIC O

SPCH Reg AUXS Reg


SMS Reg

for supplementary services theindividual sets are always displayedin the same position (hence the space

ODB BAOC has no datafill, it is

BOIC just has six sets, and no other

simply provisioned or not provisioned

datafill outside of these sets.

left where “SMS Reg” is for BOIC).

(“non-set data” only)



Figure 1-5 Subscriber Profile diagram part I (Auth, Profile Control) )

AUTHENTICATIONDATA

AUTH M

Category M

Data

Data

IMSI Status M

Data

PROFILECONTROL DATA

Password M

Data

LMU M

Data

NAM M

Data

Roaming Entitlement M

Data

Barring Control M

Data

SOAPROV M

Data



Figure 1-6 Subscriber Profile diagram part II (ODBs)

ODB BAOC O

No data

ODB BOIC O

No data

ODB BAIC O

No data

ODB PremRate Info O

No data

ODB HPLMNSpec 1 O

No data

ODB HPLMNSpec 3 O

No data

ODB CISSMGT O

No data

ODB BAOCRoam O

No data

ODB BOICexHC O

No data

ODB BICRoam O

No data

ODB PremRate Ent O

No data

ODB HPLMNSpec 2 O

No data

ODB HPLMNSpec 4 O

No data

ODB CCFMGT O

No data

ODB BAECT O

No data

ODB BINTECT O

No data

ODB BCHDECT O

No data

ODB BDBCECT O

No data

OPERATOR DETERMINED BARRING SERVICES



Figure 1-7 Subscriber Profile part III (BSs)

SPCH BSG

CDA2400 O

CDA300 O CDA1200 O

CDA1275 O

CDA O

CDA4800 O

CDA9600 O CDAGBS O

CDS O CDS1200 O CDS2400 O

CDS4800 O CDS9600 O CDSGBS O

TPHNY O AUXSPCH BSG

SMMO O SMMT OSMS BSG

FAX3 OFAX BSG

CDA BSG

CDS BSG

AUXSPCH O

ALTSPFAX O

SPCHCDA O

ALTSPCDA O

SPCHCDS O ALTSPCDS O

Data Data

Data Data

Data Data

Data Data Data

Data Data Data

Data Data Data

Data

Data Data Data

DataDataData

Data Data

BASIC SERVICES

VBS O VGCS OVGS BSG

Data Data



Figure 1-8 Subscriber Profile part IV (SSs 1)

SUPPLEMENTARY

ACC O

SERVICES Part 1

ACRJ O

No data

AOCC O

No data

AOCI O

No data

CNAM O

No data

COLR O

No data

ECT O

No data

HOLD O

No data

HOTBILL O

No data

LCO O

No data

MCT O

No data

UUS1 O

No data

CLIP O CLIR O

COLP O EMLPP O FM O

MPTY O

CUG O

SPCH Reg AUXS Reg


AllBSGReg

EXT O

SPCH Reg AUXS Reg

Data Data Data

Data Data Data

Data

COS O

SPCH Reg AUXS Reg


CW O

SPCH Reg AUXS Reg


Data



Figure 1-9 Subscriber Profile part V (SSs 2)

SUPPLEMENTARYSERVICES Part 2

BAIC O

SPCH Reg AUXS Reg


SMS Reg

BICRoam O

SPCH Reg AUXS Reg


SMS Reg

BAOC O

SPCH Reg AUXS Reg


SMS Reg

VGS Reg

BOIC O

SPCH Reg AUXS Reg


SMS Reg

BOICexHC O

SPCH Reg AUXS Reg


SMS Reg

CFB O

SPCH Reg AUXS Reg


CFNRy O

SPCH Reg AUXS Reg


CFNRc O

SPCH Reg AUXS Reg


CFU O

SPCH Reg AUXS Reg


DataData

Data Data



Figure 1-10 Subscriber Profile part VI (CAMEL)

GPRS-CSI O

TDP1 TDP2

TDP4 TDP5

TDP3

D-CSI O M-CSI O

SMS-CSI O

TDP1

O-CSI O

TDP2 Ph1

CAMEL SERVICES

Data Data

Data

Data Data

SS-CSI O

Data

USSD-CSI O

Data

TDP2 Ph2

TDP4 Ph3

TDP2 Ph3

T-CSI O

TDP12 Ph1

Data

TDP12 Ph2

TDP13 Ph3

TDP12 Ph3

TDP14 Ph3



Figure 1-11 Subscriber Profile part VII (LCS)

LOCATION SERVICES

Call Related Privacy Class O

Call Unrelated Privacy Class O

Basic Self Location Class O

Autonomous Self Location Class O

Transfer to Third Party Class O

Universal Privacy Class O

GMLCs List O

PLMN Operator Privacy Class O

Data

Data

Data

Data

Data

Data

Data

Data



Figure 1-12 Subscriber Profile part VIII (Misc.)

GPRS O

PDP 1 PDP 2 PDP 3 PDP 4

CLIN O

HST O

EA O

Data

Data

Data

SIMR O

Data

GPRS, OTHER SERVICES

PDP 5

PDP 6 PDP 7 PDP 8 PDP 9 PDP 10



Proprietary IN O

Data

AND OTHER COMPONENTS



Data model and validations 1This section outlines the data model and the validations associated with provisioning each profile component. Profile components are listed below. Datatypes are introduced on page 1-36, vectors on page 1-36 and the validations on page 1-37. The data model and validations then follow.

Profile componentsThe profile components are listed in Table 1-1. They are ordered primarily by component type, and then alphabetically. Each component is described in detail in “Chapter 2: Component descriptions”. For an example, see “Example component (guide to the following sections)” on page 1-38 of this chapter. There are also introductory sections for many of the component types.

Table 1-1 Profile components (5 pages)

Short Name Expanded Name See Chapter 2

Primary Component

Auth Data Authentication Data on page 2-41

Profile Control on page 2-44

Barring Control n/a on page 2-45

Category n/a on page 2-46

IMSI Status n/a on page 2-49

LMU Location Measurement Unit on page 2-51

NAM Network Access Mode on page 2-52

Password n/a on page 2-53

Roaming Entitlement n/a on page 2-54

SOAPROV Suppression of Announcements provisioning on page 2-55

Basic Services on page 2-56

ALTSPCDA Alternate Speech / CDA Data on page 2-59

ALTSPCDS Alternate Speech / CDS Data on page 2-61

ALTSPFAX Alternate Speech / Fax Group 3 on page 2-63

AUXTPHY Auxiliary Telephony on page 2-65


CDA Circuit Duplex Asynchronous Data on page 2-67


CDA 300 Circuit Duplex Asynchronous Data 300 on page 2-68






CDAGBS Circuit Duplex Asynchronous Data General Bearer Service

on page 2-80

CDS Circuit Duplex Synchronous on page 2-82

CDS 1200 Circuit Duplex Synchronous Data 1200 on page 2-83




CDSGBS Circuit Duplex Synchronous Data General Bearer Service

on page 2-91

FAX3 Facsimile Group 3 on page 2-93

SMMO Short Message Mobile Originating on page 2-95

SMMT Short Message Mobile Terminating on page 2-97

SPCHCDA Speech followed by CDA Data on page 2-99

SPCHCDS Speech followed by CDS Data on page 2-101

TPHY Telephony on page 2-103

VBS Voice Broadcast Service on page 2-105

VGCS Voice Group Call Service on page 2-106

Supplementary Services on page 2-107

ACC Accounting Codes on page 2-109

ACRJ Anonymous Call Reject on page 2-110





AOCC Advice of Charge Charging on page 2-111

AOCI Advice of Charge Information on page 2-112

BAIC Bar All Incoming Calls on page 2-113

BAOC Bar All Outgoing Calls on page 2-115

BICRoam Bar Incoming Calls while Roaming on page 2-117

BOIC Bar Outgoing International Calls on page 2-119

BOICexHC Bar Outgoing International Call Except to Home Country

on page 2-121

CFB Call Forward Busy on page 2-123

CFNRC Call Forward Not Reachable on page 2-130

CFNRY Call Forward No Reply on page 2-136

CFU Call Forward Unconditional on page 2-143

CLIP Calling Line Id Presentation Restriction on page 2-150

CLIR Calling Line Id Restriction on page 2-151

CNAM Calling Name Delivery on page 2-152

COLP Connected Line Id Presentation on page 2-153

COLR Connected Line Id Restriction on page 2-154

COS Class Of Service on page 2-155

CUG Closed User Groups on page 2-158

CW Call Waiting on page 2-164

ECT Explicit Call Transfer on page 2-166

EMLPP Enhanced Multi Level Precedence & Pre-emption on page 2-167

EXT Extension Services on page 2-168

FM Follow Me on page 2-175

HOLD Call Hold on page 2-177




HOTBILL Hot billing on page 2-178


LCO Local Calls Only on page 2-179

MCT Malicious Call Trace on page 2-180

MPTY Multiparty on page 2-181

UUS1 User to User Signalling stage 1 on page 2-182

WPS Wireless Priority Service on page 2-183

Operator Determined Barrings

All ODBs (incoming, outgoing, ECT, misc)

refer to the ODBs section on page 2-184

CAMEL Services on page 2-186

D-CSI Dialled CAMEL Subscription Information on page 2-187

GPRS-CSI General Packet Radio Service CAMEL Subscription Information

on page 2-189

M-CSI Mobility Management CAMEL Subscription Information

on page 2-192

O-CSI Originating CAMEL Subscription Information on page 2-193

SMS-CSI Short Message Service CAMEL Subscription Information

on page 2-201

SS-CSI Supplementary Service CAMEL Subscription Information

on page 2-203

T-CSI Terminating CAMEL Subscription Information on page 2-204

TIF-CSI Translations Information Flag CAMEL Subscription Information

on page 2-209

USSD-CSI Unstructured Supplementary Service Data CAMEL Subscription Information

on page 2-210

Location Services (LCS) on page 2-211

LCS Autonomous Self Location

n/a on page 2-212

LCS Basic Self Location n/a on page 2-213




LCS Call Related n/a on page 2-214


Proprietary servicesThe following services are Nortel proprietary services.

• ACC, ACRJ, AUXTPHNY, CLIN, CNAM, COS, EA, EXT, HOTBILL, LCO, MCT, Proprietary IN

LCS Call Unrelated n/a on page 2-216

LCS GMLCs LCS Gateway Mobile Location Centres on page 2-218

LCS PLMN Operator n/a on page 2-219

LCS Transfer to Third Party

n/a on page 2-221

LCS Universal n/a on page 2-222

GPRS

GPRS General Packet Radio Service on page 2-223

Other Services on page 2-229

CLIN Calling Line Identification Replacement Number on page 2-230

EA Equal Access on page 2-231

Proprietary IN Proprietary Intelligent Network service on page 2-232

Other Components on page 2-233

HST Home Subscriber Trace on page 2-234

SIMR SIM Replacement on page 2-235





DatatypesThe subscriber profile database is composed of a finite number of datatypes, summarised in Table 1-2. There are three broad types: number, string and enum. Strings can be composed of characters, digits or hex digits. Character strings are usually limited in the particular characters they can use, typically to alphanumeric characters and underscores. Digits strings use (0..9), whereas hex strings use (0..9) and (A..F). Booleans can be viewed as a special type of enum. The “Example(s) in Data Syntax Tables” column indicates the conventions used in the Data Syntax tables in this document (see “Chapter 2: Component descriptions”). Note that some dataitems in the database are optional, so null (a blank) would be a valid value, whatever their datatype actually is.

Data vectorsA vector is a collection of elements of the same type, where a variable number of elements can exist and elements may be added or removed. An abstract example is a names vector; if the vector is datafilled it will contain one or more individual name elements, with a limit being imposed on the maximum number of elements. Elements in vectors are not ordered, and there is no concept of indexes within the vector. Elements are simply added, removed or read from the vector.

The database contains two broad types of vector: simple and complex. Simple vectors are a collection containing just one datatype. An example is the names vector mentioned above. A complex vector is different, in that rather than containing a collection of elements, it holds a collection of structures. A structure is composed of two or more elements. An abstract example is a people vector; each item in the vector is a structure of name, age

Table 1-2 Primitive datatypes

Datatype Format Example(s) in Data Syntax Tables

Number m - n range number: 0 - 255

String m - n characters (alphanumeric and underscores unless stated otherwise)

1 - 20 characters

1 - 20 characters (alphanumeric, underscores, ‘*’, ‘#’)

Digit String m - n digits (0..9) 6 - 15 digits

Hex String m hex digits (0..9, A..Z) 32 hex digits

Enumerated {FIRST, SECOND, THIRD, ...} {OPERATOR, USER}

Boolean Boolean (i.e. true or false) Boolean


and gender elements.


In the example in Table 1-3, the simple vector is mandatory, as indicated by the number of elements (1 - 3). The complex vector is optional.

Validations introductionSubsequent “component data model” sections detail datafill and provisioning validations for each component in the subscriber profile. Operator mode validations are detailed -- i.e. those applicable to operator provisioning updates (validations for network profile updates are not covered by this document). There are three very broad validations areas, given in Table 1-4 below. A profile may be created via provisioning and subsequently deleted via provisioning. Profile modifications are made via provisioning transactions. Such a transaction may add/modify/delete multiple components.

A guide to the “component data model” sections is given in “Example component (guide to the following sections)” on page 1-38.

Table 1-3 Vector examples

Type Element(s) Examples

Simple 1 - 3 strings, each 1 - 20 characters {“APPLE”}

{“PEAR”, “APPLE”, “PEACH”}

Complex 0 - 3 structures of

-string, 1 - 20 characters

-number, 0 - 255 range

{{“RED”, 123}}

{{“RED”, 98}, {“GREEN”, 240}}

Table 1-4 Validation areas

Validation Area See Section(s)

Profile Creation on page 1-38

Profile Deletion on page 1-38

Profile Modification Transaction validations on page 1-38

Per-Profile Component validations in “Chapter 2: Component descriptions”



Profile creationA profile is created by datafilling authentication data. The current Nortel HLR implementation auto-provisions Profile Control Data with default values (see Chapter 2, “Profile control data introduction” on page 2-44). The following checks are done:

• the IMSI must be available for use (i.e. not already in use)

• the authentication data must be valid (see Chapter 2, “Authentication data” on page 2-41)

Profile deletionTo delete a subscriber profile the following conditions must be met:

• IMSI Status must be ‘DEACTIVATED’

• no services must be provisioned

• subscriber must not be involved in a SIMR relationship

Note that a profile with HST can be deleted.

Transactional validationsThese validations apply for all profile modification provisioning actions.

• if the IMSI Status is set to ‘REPLACEMENT’ then no updates at all are permitted to the profile

Example component (guide to the following sections)Sections start with a sentence or two to outline the function of the datafill for this component. Please refer to the service’s documentation for details on functionality.

DatafillThis subsection details the component’s datafill. The dataitems and their syntax are detailed in the Data Syntax table, see Table 1-5 on page 1-39 for an example. The example shows one dataitem that is not part of a set, and then two sets, each with two dataitems.

Syntax checks describe the format of the dataitem, and do not include any checks resulting from interactions with other dataitems. They describe the checks for validating the dataitem in isolation. Example syntax are checking the dataitem in a string (and of the correct length) or a number (in the correct range) or a boolean.

This subsection also includes the intra-component validations in a bullet list. These are validations arising from interactions between the dataitems of this component. An example intra-component interaction is that dataitem X must be greater than dataitem Y.



A glossary of shortened/acronym dataitems is given in “Glossary of terms” on page B-347..

Descriptions for the dataitems, which are also known as fields, are given in the “Field Descriptions” table (see Table 1-6 for an example).

InteractionsThis subsection details the interactions with other components and system data. Provisioning side-effects are also included. An example interaction with system data is:

• dataitem X must exist in the YYY field of system table ZZZ

Example interactions with other services are:

• service A can only be provisioned if service B is also provisioned

• the syntax of dataitem X of service A depends on dataitem M of service B

Table 1-5 Example data syntax

Dataitem Syntax Optional

Dataitem name the syntax is described here for each dataitem; see “Datatypes” on page 1-36 for examples and help

some components have vectors; these will be indicated in this table; see “Data vectors” on page 1-36 for more help

indicates whether each dataitem is optional, including how many entries are optional for vectors

Set name Dataitem name

Dataitem name


Dataitem name

Table 1-6 Example field descriptions

Dataitem Description

Dataitem name a concise description is given for each dataitem, including expansion of shortened/acronym enum options


Dataitem name


Dataitem name



HLR-wide validationsThis subsection gives those validations that interact with other subscribers and their data. If none exist then this subsection is not included. Some examples of these validations are:

• the value for a particular dataitem cannot be used by more than one subscriber, i.e. its value must be unique HLR-wide

• a limit is placed on the number of subscribers that can have a particular service provisioned



Chapter 2: Component descriptions 2Authentication data 2

Authentication data is mandatory datafill for all subscribers. The Nortel HLR includes authentication centre (AUC) functionality.

DatafillAuthentication data syntax is detailed in Table 2-1. A 2G subscriber has a GSM algorithm and hence a Ki, whereas a 3G subscriber has a UMTS algorithm and hence a K. The algorithm indirectly indicates whether the subscriber is 2G or 3G (see section for more details). The IMSI is actually composed of three parts: MCC, MNC and MSIN.

Authentication data descriptions are given in Table 2-2.

Table 2-1 Authentication data syntax

Dataitem syntax Optional

IMSI 6 - 15 digits

Ki (2G) or K (3G) 32 hex digits

Algorithm number: 0 - 255

OPC 32 hex digits Yes

Table 2-2 Authentication data field descriptions


IMSI International Mobile Subscriber Identity, a unique ID specified by a SIM card

Ki (2G) or K (3G) key used in authentication; 2G subscribers have a Ki whereas 3G subscribers have a K


2-42 Chapter 2: Component descriptionsNortel Confidential Copyright © 1996–2005 Nortel

InteractionsAuthentication data interacts with IMSI Status, GPRS, system tables GHLRALG and GHLRPDP and office parameter GHLR_IMSI_MNC.

• the MNC portion of the IMSI must be valid according to office parameter GHLR_IMSI_MNC (table OFCSTD). The MNC is the 4th, 5th and possibly the 6th digits of the IMSI. If the parameter’s MNC_SELECTOR is set to ‘SINGLE’ then the MNC must match the parameter’s SINGLE_MNC_VALUE (if SINGLE_MNC_VALUE has 2 digits then the MNC is taken to be the IMSI’s 4th and 5th digits, whereas if SINGLE_MNC_VALUE has 3 digits then the MNC is taken to be the IMSI’s 4th, 5th and 6th digits). If it is set to ‘MULTIPLE’ then the IMSI’s length must be a minimum of (4 +MULTIPLE_MNC_LENGTH); the 4 originates from the length of the IMSI MCC (3 digits) added to the minimum length of the IMSI MSIN (1 digit min.)

• the algorithm should map to an entry in the ALGSEL column of system table GHLRALG, but note that this relationship is not enforced

• if the subscriber’s IMSI Status is set to ‘REPLACEMENT’, the algorithm cannot change from a 2G to a 3G type, or from a 3G to a 2G type. The determination of 2G/3G requires system table GHLRALG as explained in “Determination of 2G/3G algorithm” on page 2-43

• if the algorithm is 3G, then all of the subscriber’s PDPs (GPRS) must have ExtQoS. A PDP has ExtQoS if its entry in system table GHLRPDP (PDPNAME field) has the EXTQOS field datafilled. The determination of 2G/3G requires system table GHLRALG as explained in “Determination of 2G/3G algorithm” on page 2-43

• the OPC is only datafilled if the algorithm maps to the milenage UMTS algorithm, for all other algorithms the OPC must not be datafilled. The algorithm is milenage if it maps to an entry in system table GHLRALG (ALGSEL field) whose FLAVOUR.BASE_ALG is set to ‘UMTS_MILENAGE’

Algorithm this number maps to a 2G/3G authentication algorithm in system table GHLRALG (the relationship is not enforced) also known as AlgSel and algorithm selection

OPC Operator variant algorithm Configuration, used by the UMTS milenage algorithm also known as OPc Algorithm Parameter

Table 2-2 Authentication data field descriptions



Chapter 2: Component descriptions 2-43Nortel Confidential Copyright © 1996–2005 Nortel

Additional information

Determination of 2G/3G algorithmAn algorithm is 3G if it maps to an entry in system table GHLRALG (ALGSEL field) whose FLAVOUR.BASE_ALG is ‘UMTS_XOR’ or ‘UMTS_MILENAGE’. All other algorithms (whether they exist in GHLRALG or not) are 2G.



Profile control data introduction 2Profile control data are mandatory components which help define the subscriber’s profile, they relate to the profile as a whole. For instance, the IMSI Status defines the status of the subscriber in the network (e.g. activated). Profile control data components are listed in Table 2-3, along with their default values, which are used for ‘blank’ subscribers (essentially subscribers that only have authentication datafill).

Table 2-3 Profile control data

Component Dataitem(s) Default Values See section

Barring Control BICCTRL OPERATOR on page 2-45

BOCCTRL OPERATOR

Category Category ORDINARY on page 2-46

IMSI Status IMSI Status DEACTIVATED on page 2-49

Cust Group null

NCOS null

LMU (Location Measurement Unit) LMU FALSE on page 2-51

NAM (Network Access Mode) NAM office parameter NAM_DFLT from table GHLRPARM

on page 2-52

Password Password office parameter PASSDFLT from table GHLRPARM

on page 2-53

Roaming Entitlement Roaming Entitlement UNKW on page 2-54

SOAPROV SOAPROV FALSE on page 2-55



Barring control 2The Barring Control component is profile control data and is therefore mandatory datafill. It is used to indicate whether the operator or user has control over incoming/outgoing barrings.

DatafillBarring Control data syntax is detailed in Table 2-4.

Barring Control field descriptions are given in Table 2-5.

InteractionsNone

Table 2-4 Barring Control data syntax


BICCTRL {OPERATOR, USER}

BOCCTRL {OPERATOR, USER]

Table 2-5 Barring Control field descriptions


BICCTRL control of barring incoming calls: operator or user

BOCCTRL control of barring outgoing calls: operator or user



Category 2The Category component is profile control data and is therefore mandatory datafill. It is used to indicate the subscriber category, which is used for signalling and billing.

DatafillCategory data syntax is detailed in Table 2-6.

Table 2-6 Category control data syntax (3 pages)


Category (continued on next page)

{ORDINARY, PRIORITY, TEST, PAYPHONE, DATA,ORDNCHRG, PRINCHRG, UNKNOWN, FRENCH,ENGLISH, GERMAN, RUSSIAN, SPANISH,RESERVED, SPARLANG1, SPARLANG2,SPARLANG3, FIXEDACCESS, CHINAIP,CATEGORY14, CATEGORY17, CATEGORY18CATEGORY19, CATEGORY20, CATEGORY21,CATEGORY22, CATEGORY23, CATEGORY24,CATEGORY25, CATEGORY26, CATEGORY27,CATEGORY28, CATEGORY29, CATEGORY30,CATEGORY31, CATEGORY32, CATEGORY33,CATEGORY34, CATEGORY35, CATEGORY36,CATEGORY37, CATEGORY38, CATEGORY39,CATEGORY40, CATEGORY41, CATEGORY42,CATEGORY43, CATEGORY44, CATEGORY45,CATEGORY46, CATEGORY47, CATEGORY48,CATEGORY49, CATEGORY50, CATEGORY51,CATEGORY52, CATEGORY53, CATEGORY54,CATEGORY55, CATEGORY56, CATEGORY57,CATEGORY58, CATEGORY59, CATEGORY60,CATEGORY61, CATEGORY62, CATEGORY63,CATEGORY64, CATEGORY65, CATEGORY66,CATEGORY67, CATEGORY68, CATEGORY69,CATEGORY70, CATEGORY71, CATEGORY72,CATEGORY73, CATEGORY74, CATEGORY75,CATEGORY76, CATEGORY77, CATEGORY78,CATEGORY79, CATEGORY80, CATEGORY81,CATEGORY82, CATEGORY83, CATEGORY84,CATEGORY85, CATEGORY86, CATEGORY87,CATEGORY88, CATEGORY89, CATEGORY90,CATEGORY91, CATEGORY92, CATEGORY93,CATEGORY94, CATEGORY95, CATEGORY96,CATEGORY97, CATEGORY98, CATEGORY99,CATEGORY100, CATEGORY101, CATEGORY102,CATEGORY103, CATEGORY104, CATEGORY105,



Category (continued)

CATEGORY106, CATEGORY107, CATEGORY108,CATEGORY109, CATEGORY110, CATEGORY111,CATEGORY112, CATEGORY113, CATEGORY114CATEGORY115, CATEGORY116, CATEGORY117,CATEGORY118, CATEGORY119, CATEGORY120,CATEGORY121, CATEGORY122, CATEGORY123,CATEGORY124, CATEGORY125, CATEGORY126,CATEGORY127, CATEGORY128, CATEGORY129,CATEGORY130, CATEGORY131, CATEGORY132,CATEGORY133, CATEGORY134, CATEGORY135,CATEGORY136, CATEGORY137, CATEGORY138,CATEGORY139, CATEGORY140, CATEGORY141,CATEGORY142, CATEGORY143, CATEGORY144,CATEGORY145, CATEGORY146, CATEGORY147,CATEGORY148, CATEGORY149, CATEGORY150,CATEGORY151, CATEGORY152, CATEGORY153,CATEGORY154, CATEGORY155, CATEGORY156,CATEGORY157, CATEGORY158, CATEGORY159,CATEGORY160, CATEGORY161, CATEGORY162,CATEGORY163, CATEGORY164, CATEGORY165,CATEGORY166, CATEGORY167, CATEGORY168,CATEGORY169, CATEGORY170, CATEGORY171,CATEGORY172, CATEGORY173, CATEGORY174,CATEGORY175, CATEGORY176, CATEGORY177,CATEGORY178, CATEGORY179, CATEGORY180,CATEGORY181, CATEGORY182, CATEGORY183,CATEGORY184, CATEGORY185, CATEGORY186,CATEGORY187, CATEGORY188, CATEGORY189,CATEGORY190, CATEGORY191, CATEGORY192,CATEGORY193, CATEGORY194, CATEGORY195,CATEGORY196, CATEGORY197, CATEGORY198,CATEGORY199, CATEGORY200, CATEGORY201,CATEGORY202, CATEGORY203, CATEGORY204,CATEGORY205, CATEGORY206, CATEGORY207,CATEGORY208, CATEGORY209, CATEGORY210,CATEGORY211, CATEGORY212, CATEGORY213,CATEGORY214, CATEGORY215, CATEGORY216,CATEGORY217, CATEGORY218, CATEGORY219,CATEGORY220, CATEGORY221, CATEGORY222,CATEGORY223, CATEGORY224, CATEGORY225,CATEGORY226, CATEGORY227, CATEGORY228,CATEGORY229, CATEGORY230, CATEGORY231,CATEGORY232, CATEGORY233, CATEGORY234,CATEGORY235, CATEGORY236, CATEGORY237,CATEGORY238, CATEGORY239, CATEGORY241,





Category field descriptions are given in Table 2-7.

InteractionsNone

Category (continued)

CATEGORY242, CATEGORY243, CATEGORY245,CATEGORY246, CATEGOTY247, CATEGORY248,CATEGORY249, CATEGORY250, CATEGORY 251,CATEGORY252, CATEGORY253, CATEGORY254}

Table 2-7 Category field descriptions


Category the subscriber category, used for signalling and billing





IMSI Status 2The IMSI Status component is profile control data and is therefore mandatory datafill. It defines the status of the subscriber within the network and hot-line routing (HLR) class of service (COS) information for ‘NEW’ subscribers (as defined by their IMSI Status dataitem).

DatafillIMSI Status data syntax is detailed in Table 2-8. The following intra-service interactions apply.

• the IMSI Status cannot be manually set to ‘REPLACEMENT’; the IMSI Status is automatically changed to ‘REPLACEMENT’ when the IMSI is assigned to be the ‘new’ IMSI in a SIM Replacement (SIMR) relationship

• if IMSI Status is not ‘NEW’ then Cust Group and NCOS must not be datafilled

• if IMSI Status is ‘NEW’ then Cust Group must be datafilled (NCOS may optionally be datafilled too)

IMSI Status field descriptions are given in Table 2-9.

Table 2-8 IMSI status data syntax


IMSI Status {ACTIVATED, DEACTIVATED, NEW, REPLACEMENT}

Cust Group number: 0 - 4095 Optional

NCOS number: 0 - 255 Optional

Table 2-9 IMSI Status field descriptions


IMSI Status the status of the subscriber within the network: Activated, Deactivated, New or Replacement (the Replacement state is only valid for “new” IMSIs in a SIMR relationship) also known as IStatus

Cust Group hot line routing customer group for new subscribers defined in system tables GSMCUST and GSMNCOS

NCOS hot line routing network class of service for new subscribers defined in system table GSMNCOS



InteractionsIMSI Status interacts with all ODBs and system tables GSMCUST and GSMNCOS.

• if IMSI Status is ‘NEW’ then no ODBs may be provisioned

• if IMSI Status is ‘NEW’ and NCOS has not been datafilled then the Cust Group must be an entry from the GSM_CUSTGRP_KEY field of system table GSMCUST, and this entry must have the USERTYPE and XLT fields datafilled with the USERTYPE option set to ‘HTL

• if IMSI Status is ‘NEW’ and NCOS has been datafilled then the Cust Group and NCOS combined must be an entry from the GSM_NCOS_KEY field of system table GSMNCOS, and this entry must have the USERTYPE and XLT fields datafilled with the USERTYPE option set to ‘HTL’

’



LMU (Location Measurement Unit) 2The LMU component is profile control data and is therefore mandatory datafill. It is used in E911.

DatafillLMU data syntax is detailed in Table 2-10.

LMU field descriptions are given in Table 2-11.

InteractionsNone

Table 2-10 LMU control data syntax


LMU Boolean

Table 2-11 LMU field descriptions


LMU location measurement unit, used in E911



NAM (Network Access Mode) 2The NAM component is profile control data and is therefore mandatory datafill. It is used to indicate whether the subscriber is entitled to GSM and/or GPRS service.

DatafillNAM data syntax is detailed in Table 2-12.

NAM field descriptions are given in Table 2-13.

InteractionsNone

Table 2-12 NAM control data syntax


NAM {MSC_ONLY, SGSN_ONLY, SGSN_AND_MSC}

Table 2-13 NAM field descriptions


NAM network access mode, indicates whether the subscriber is entitled to only GSM service (MSC_ONLY), only GPRS (SGSN_ONLY) service or both (SGSN_AND_MSC)



Password 2The Password component is profile control data and is therefore mandatory datafill. It gives the password for barring supplementary services.

DatafillPassword data syntax is detailed in Table 2-14.

Password field descriptions are given in Table 2-15.

InteractionsNone

Table 2-14 Password control data syntax


Password 4 digits

Table 2-15 Password field descriptions


Password password for barring supplementary services



Roaming Entitlement 2The Roaming Entitlement component is profile control data and is therefore mandatory datafill.

DatafillRoaming Entitlement data syntax is detailed in Table 2-16.

Roaming Entitlement field descriptions are given in Table 2-17.

InteractionsRoaming Entitlement interacts with system table GHLRRMZN.

• the Roaming Entitlement must either be ‘UNKW’ or an entry from the ROAM column of system table GHLRRMZN

Table 2-16 Roaming Entitlement data syntax


Roaming Entitlement 1 - 16 characters

Table 2-17 Roaming Entitlement field descriptions


Roaming Entitlement the subscribers roaming entitlement (can be set to unknown)



SOAPROV 2The SOAPROV component is profile control data and is therefore mandatory datafill. It indicates whether the suppression of announcements (to called party) parameter is sent in PRN v3 message. SOAPROV stands for suppression of announcements provisioning.

DatafillSOAPROV data syntax is detailed in Table 2-18.

SOAPROV field descriptions are given in Table 2-19.

InteractionsNone

Table 2-18 SOAPROV data syntax


SOAPROV Boolean

Table 2-19 SOAPROV field descriptions


SOAPROV indicates whether the suppression of announcements (to called party) parameter is sent in PRN v3 message



Basic Services Introduction 2Basic services are teleservices/bearer services in the telecommunications network. Teleservices are end-to-end services between MS handsets or other terminal devices. Service definitions cover all seven layers of the OSI (Open Systems Interconnection) model. Bearer services are point-to-point services between access points. Service definitions only cover layers one to three of the OSI model. Actions at layers four to seven must be specified by user applications; they are not part of the bearer service.

The HLR supports the basic services given in Table 2-20. Note that the Emergency Calls service is implicitly provisioned to all subscribers, there is no specific datafill or validations.

Table 2-20 Basic Services (2 pages)

Short Name Expanded Name Type See Section

ALTSPCDA Alternate Speech / CDA Data Bearer Service on page 2-59

ALTSPCDS Alternate Speech / CDS Data Bearer Service on page 2-61

ALTSPFAX Alternate Speech / Fax Group 3 Teleservice on page 2-63

AUXTPHNY Auxiliary Telephony Teleservice on page 2-65

CDA Circuit Duplex Asynchronous Data Bearer Service on page 2-67

CDA300 Circuit Duplex Asynchronous Data 300 Bearer Service on page 2-68






CDAGBS Circuit Duplex Asynchronous Data General Bearer Service

Bearer Service on page 2-80

CDS Circuit Duplex Synchronous Data Bearer Service on page 2-82

CDS1200 Circuit Duplex Synchronous Data 1200 Bearer Service on page 2-83






Each basic service belongs to a basic service group (BSG); these are given in Table 2-21. Note that Emergency Calls is a speech service, although the data model only places TPHNY in the SPCH basic service group.

CDSGBS Circuit Duplex Synchronous Data General Bearer Service

Bearer Service on page 2-91

Emergency Calls

Emergency Calls Teleservice see note above

FAX3 Facsimile Group 3 Teleservice on page 2-93

SMMO Short Message Mobile Originating Teleservice on page 2-95

SMMT Short Message Mobile Terminating Teleservice on page 2-97

SPCHCDA Speech followed by CDA Data Bearer Service on page 2-99

SPCHCDS Speech followed by CDS Data Bearer Service on page 2-101

TPHNY Telephony Teleservice on page 2-103

VBS Voice Broadcast Service Teleservice on page 2-105

VGCS Voice Group Call Service Teleservice on page 2-106

Table 2-21 Basic Service Groups

Basic Service Group Basic Services

SPCH TPHNY

AUXSPCH AUXTPHNY

SMS SMMO, SMMT

CDA ALTSPCDA, CDA, CDA300, CDA1200, CDA1275, CDA2400, CDA4800, CDA9600, CDAGBS, SPCHCDA

CDS ALTSPCDS, CDS, CDS1200, CDS2400, CDS4800, CDS9600, CDSGBS, SPCHCDS

FAX ALTSPFAX, FAX3

VGS VBS, VGCS

Table 2-20 Basic Services (2 pages)

Short Name Expanded Name Type See Section



Notes on Basic Service datafillBasic service datafill is composed of an MSISDN and bearer capability index (BCI), with the following exceptions:

• CDA1275, SMMO and SMMT do not have a BCI

• VBS and VGCS have entirely different datafill (these two services are GSM Railways (GSMR) specific)

BCI validationBCI validation is rather complex but can be summarised by the following rule, with the given exceptions.

• If more than one service shares an MSISDN, then all of their BCIs must be null. There are three exceptions:

— if a service “X” shares an MSISDN with only SMMO/SMMT/CDA1275, then “X” may have a BCI

— FAX3/CDA/CDS may share an MSISDN, and one of them may have a BCI

— sister basic services always share an MSISDN, and one of them must have a BCI, the other must not

There are two pairs of sister basic services, ALTSPCDA & ALTSPCDS and SPCHCDA & SPCHCDS.



ALTSPCDA (Alternate Speech / CDA Data) 2ALTSPCDA datafill defines the MSISDN and bearer capability for alternate speech/CDA data. ALTSPCDA belongs to the CDA basic service group (BSG).

DatafillALTSPCDA data syntax is detailed in Table 2-22. The three MSISDN fields are combined to give the complete MSISDN (i.e. CC + NDC + SN). The following intra-service validation applies.

• the length of the complete MSISDN (i.e. CC + NDC + SN) must be 3 to 15 digits

ALTSPCDA field descriptions are given in Table 2-23.

Table 2-22 ALTSPCDA data syntax


MSISDN CC 1 to 3 digits, first digit cannot be zero

MSISDN NDC 1 to 13 digits

MSISDN SN 1 to 13 digits

BCI number: 0 - 255 Optional

Table 2-23 ALTSPCDA field descriptions


MSISDN CC Mobile Subscriber ISDN, Country Code component

MSISDN NDC Mobile Subscriber ISDN, National Destination Code component

MSISDN SN Mobile Subscriber ISDN, subscriber number

BCI Bearer Capability Index, defined in system table GHLRBCA



InteractionsALTSPCDA interacts with all other basic services, all BSG supplementary services and system table GHLRBCA.

• the MSISDN CC must match all other basic service MSISDN CCs

• if the MSISDN matches the MSISDN of any other basic service except SMMO/SMMT/CDA1275/ALTSPCDS then ALTSPCDA’s BCI must not be datafilled

• if datafilled, the BCI must be an entry from the BCAKEY column of system table GHLRBCA, and the value in the system table’s BSVC field must be ‘ALTSPCDA’

• ALTSPCDA belongs to the CDA BSG; at least one basic service from the CDA BSG must be provisioned if any BSG-SS is registered against CDA (services BAIC, BICRoam, BAOC, BOIC, BOICexHC, CFB, CFNRc, CFNRy, CFU, COS, CUG, CW and EXT)

• the MSISDN must not match any FTN of CFB, CFNRc, CFNRy or CFU

• when provisioning ALTSPCDA, a BCI must be supplied unless ALTSPCDS is concurrently provisioned with a BCI

• upon provisioning ALTSPCDA, ALTSPCDS is automatically provisioned with the same MSISDN and a null BCI (unless explicitly provisioned also)

• ALTSPCDA and ALTSPCDS must have the same MSISDN. Upon changing the MSISDN of one service, the other service’s MSISDN is automatically updated to match

• one of ALTSPCDA/ALTSPCDS must have a BCI, the other must have a null BCI. Upon changing the null BCI to a value, the other service’s BCI is automatically updated to have a null BCI. It is not valid to change the service with the BCI so that it has a null BCI (as then both services would have a null BCI)

• upon deprovisioning ALTSPCDA, ALTSPCDS is automatically deprovisioned too

HLR-wide validations• the MSISDN cannot be used by any other subscriber (interacts with all

basic services (except VBS/VGCS) for all subscribers)



ALTSPCDS (Alternate Speech / CDS Data) 2ALTSPCDS datafill defines the MSISDN and bearer capability for alternate speech/CDS data. ALTSPCDS belongs to the CDS basic service group (BSG).

DatafillALTSPCDS data syntax is detailed in Table 2-24. The three MSISDN fields are combined to give the complete MSISDN (i.e. CC + NDC + SN). The following intra-service validation applies.


ALTSPCDS field descriptions are given in Table 2-25.

Table 2-24 ALTSPCDS data syntax






Table 2-25 ALTSPCDS field descriptions








InteractionsALTSPCDS interacts with all other basic services, all BSG supplementary services and system table GHLRBCA.


• if the MSISDN matches the MSISDN of any other basic service except SMMO/SMMT/CDA1275/ALTSPCDA then ALTSPCDS’s BCI must not be datafilled

• if datafilled, the BCI must be an entry from the BCAKEY column of system table GHLRBCA, and the value in the system table’s BSVC field must be ‘ALTSPCDS’

• ALTSPCDS belongs to the CDS BSG; at least one basic service from the CDS BSG must be provisioned if any BSG-SS is registered against CDS (services BAIC, BICRoam, BAOC, BOIC, BOICexHC, CFB, CFNRc, CFNRy, CFU, COS, CUG, CW and EXT)


• when provisioning ALTSPCDS, a BCI must be supplied unless ALTSPCDA is concurrently provisioned with a BCI

• upon provisioning ALTSPCDS, ALTSPCDA is automatically provisioned with the same MSISDN and a null BCI (unless explicitly provisioned also)

• ALTSPCDS and ALTSPCDA must have the same MSISDN. Upon changing the MSISDN of one service, the other service’s MSISDN is automatically updated to match

• one of ALTSPCDS/ALTSPCDA must have a BCI, the other must have a null BCI. Upon changing the null BCI to a value, the other service’s BCI is automatically updated to have a null BCI. It is not valid to change the service with the BCI so that it has a null BCI (as then both services would have a null BCI)

• upon deprovisioning ALTSPCDS, ALTSPCDA is automatically deprovisioned too





ALTSPFAX (Alternate Speech / Fax Group 3) 2ALTSPFAX datafill defines the MSISDN and bearer capability for alternate speech/fax group 3. ALTSPFAX belongs to the FAX basic service group (BSG).

DatafillALTSPFAX data syntax is detailed in Table 2-26. The three MSISDN fields are combined to give the complete MSISDN (i.e. CC + NDC + SN). The following intra-service validation applies.


ALTSPFAX field descriptions are given in Table 2-27.

Table 2-26 ALTSPFAX data syntax






Table 2-27 ALTSPFAX field descriptions








InteractionsALTSPFAX interacts with all other basic services, all BSG supplementary services and system table GHLRBCA.

• ALTSPFAX is mutually exclusive with FAX3


• if the MSISDN matches the MSISDN of any other basic service except SMMO/SMMT/CDA1275 then ALTSPFAX’s BCI must not be datafilled

• if datafilled, the BCI must be an entry from the BCAKEY column of system table GHLRBCA, and the value in the system table’s BSVC field must be ‘ALTSPFAX’

• ALTSPFAX belongs to the FAX BSG; at least one basic service from the FAX BSG must be provisioned if any BSG-SS is registered against FAX (services BAIC, BICRoam, BAOC, BOIC, BOICexHC, CFB, CFNRc, CFNRy, CFU, COS, CUG, CW and EXT)






AUXTPHNY (Auxiliary Telephony) 2AUXTPHNY datafill defines the MSISDN and bearer capability for voice calls on an alternate line. AUXTPHNY is a Nortel proprietary service and belongs to the AUXSPCH basic service group (BSG).

DatafillAUXTPHNY data syntax is detailed in Table 2-28. The three MSISDN fields are combined to give the complete MSISDN (i.e. CC + NDC + SN). The following intra-service validation applies.


AUXTPHNY field descriptions are given in Table 2-29.

Table 2-28 AUXTPHNY data syntax






Table 2-29 AUXTPHNY field descriptions








InteractionsAUXTPHNY interacts with all other basic services, all BSG supplementary services and system table GHLRBCA.

• TPHNY must be provisioned for AUXTPHNY to be provisioned


• if the MSISDN matches the MSISDN of any other basic service except SMMO/SMMT/CDA1275 then AUXTPHNY’s BCI must not be datafilled

• if datafilled, the BCI must be an entry from the BCAKEY column of system table GHLRBCA, and the value in the system table’s BSVC field must be ‘AUXTPHNY’

• AUXTPHNY must be provisioned if any BSG-SS is registered against AUXSPCH (services BAIC, BICRoam, BAOC, BOIC, BOICexHC, CFB, CFNRc, CFNRy, CFU, COS, CUG, CW and EXT)






CDA (Circuit Duplex Asynchronous Data) 2CDA is a special case basic service as provisioning this “service” is equivalent to provisioning CDA300, CDA1200, CDA1275, CDA2400, CDA4800 and CDA9600, using the datafill specified for CDA. Note that the individual CDAxxx services can be provisioned alongside CDA.

For example, a subscriber may have both CDA and CDA300 provisioned. The subscriber profile will actually have all CDAxxx services. The datafill used for CDA300 will be equal to that specified for CDA300, and not equal to the CDA datafill (i.e. the CDA300 datafill takes precedence) If CDA is subsequently deprovisioned, then all CDAxxx services are removed except CDA300, as this is still explicitly provisioned.

Please refer to the individual service sections for datafill/interactions details. CDA does have a special case for BCI validation, however:

• if the MSISDN matches the MSISDN of any other basic service except SMMO/SMMT/CDA1275 then CDA’s BCI must not be datafilled but there is an exception:


• if datafilled, the BCI must be an entry from the BCAKEY column of system table GHLRBCA, and the value in the system table’s BSVC field must be ‘CDA9600’

Note that CDA is also the name of a basic service group (BSG). When ‘CDA’ is used, it typically refers to the BSG, rather than this basic service.



CDA300 (Circuit Duplex Asynchronous Data 300) 2CDA300 datafill defines the MSISDN and bearer capability for 300 bits/second CDA. CDA300 belongs to the CDA basic service group (BSG).

DatafillCDA300 data syntax is detailed in Table 2-30. The three MSISDN fields are combined to give the complete MSISDN (i.e. CC + NDC + SN). The following intra-service validation applies.


CDA300 field descriptions are given in Table 2-31.

Table 2-30 CDA300 data syntax






Table 2-31 CDA300 field descriptions








InteractionsCDA300 interacts with all other basic services, all BSG supplementary services and system table GHLRBCA.

• CDA300 is mutually exclusive with CDAGBS


• if the MSISDN matches the MSISDN of any other basic service except SMMO/SMMT/CDA1275 then CDA300’s BCI must not be datafilled


• CDA300 belongs to the CDA BSG; at least one basic service from the CDA BSG must be provisioned if any BSG-SS is registered against CDA (services BAIC, BICRoam, BAOC, BOIC, BOICexHC, CFB, CFNRc, CFNRy, CFU, COS, CUG, CW and EXT)



















































InteractionsCDA1275 interacts with all other basic services and all BSG supplementary services.
































































































CDAGBS (Circuit Duplex Asynchronous Data General Bearer Service) 2

CDAGBS datafill defines the MSISDN and bearer capability for CDA General Bearer Service, which allows support for all data rates up to and including 64 kbit/second. CDAGBS belongs to the CDA basic service group (BSG).

DatafillCDAGBS data syntax is detailed in Table 2-42. The three MSISDN fields are combined to give the complete MSISDN (i.e. CC + NDC + SN). The following intra-service validation applies.


CDAGBS field descriptions are given in Table 2-43.

Table 2-42 CDAGBS data syntax






Table 2-43 CDAGBS field descriptions








InteractionsCDAGBS interacts with all other basic services, all BSG supplementary services and system table GHLRBCA.

• CDAGBS is mutually exclusive with CDA (basic service), CDA300, CDA1200, CDA1275, CDA2400, CDA4800 and CDA9600


• if the MSISDN matches the MSISDN of any other basic service except SMMO/SMMT/CDA1275 then CDAGBS’s BCI must not be datafilled

• if datafilled, the BCI must be an entry from the BCAKEY column of system table GHLRBCA, and the value in the system table’s BSVC field must be ‘CDAGBS’

• CDAGBS belongs to the CDA BSG; at least one basic service from the CDA BSG must be provisioned if any BSG-SS is registered against CDA (services BAIC, BICRoam, BAOC, BOIC, BOICexHC, CFB, CFNRc, CFNRy, CFU, COS, CUG, CW and EXT)






CDS (Circuit Duplex Synchronous Data) 2CDS is a special case basic service as provisioning this “service” is equivalent to provisioning CDS1200, CDS2400, CDS4800 and CDS9600, using the datafill specified for CDS. Note that the individual CDSxxx services can be provisioned alongside CDS.

For example, a subscriber may have both CDS and CDS1200 provisioned. The subscriber profile will actually have all CDSxxx services. The datafill used for CDS1200 will be equal to that specified for CDS1200, and not equal to the CDS datafill (i.e. the CDS1200 datafill takes precedence) If CDS is subsequently deprovisioned, then all CDSxxx services are removed except CDS1200, as this is still explicitly provisioned.

Please refer to the individual service sections for datafill/interactions details. CDS does have a special case for BCI validation, however:

• if the MSISDN matches the MSISDN of any other basic service except SMMO/SMMT/CDA1275 then CDS’s BCI must not be datafilled but there is an exception:


• if datafilled, the BCI must be an entry from the BCAKEY column of system table GHLRBCA, and the value in the system table’s BSVC field must be ‘CDS9600’

Note that CDS is also the name of a basic service group (BSG). When ‘CDS’ is used, it typically refers to the BSG, rather than this basic service.



CDS1200 (Circuit Duplex Synchronous Data 1200) 2CDS1200 datafill defines the MSISDN and bearer capability for 1200 bits/second CDS. CDS1200 belongs to the CDS basic service group (BSG).

DatafillCDS1200 data syntax is detailed in Table 2-44. The three MSISDN fields are combined to give the complete MSISDN (i.e. CC + NDC + SN). The following intra-service validation applies.


CDS1200 field descriptions are given in Table 2-45.

Table 2-44 CDS1200 data syntax






Table 2-45 CDS1200 field descriptions








InteractionsCDS1200 interacts with all other basic services, all BSG supplementary services and system table GHLRBCA.

• CDS1200 is mutually exclusive with CDSGBS


• if the MSISDN matches the MSISDN of any other basic service except SMMO/SMMT/CDA1275 then CDS1200’s BCI must not be datafilled


• CDS1200 belongs to the CDS BSG; at least one basic service from the CDS BSG must be provisioned if any BSG-SS is registered against CDS (services BAIC, BICRoam, BAOC, BOIC, BOICexHC, CFB, CFNRc, CFNRy, CFU, COS, CUG, CW and EXT)





























































































CDSGBS (Circuit Duplex Synchronous Data General Bearer Service) 2

CDSGBS datafill defines the MSISDN and bearer capability for CDS General Bearer Service, which allows support for all data rates up to and including 64 kbit/second. An example use of this service is for support of H.324-M (circuit video calls). CDSGBS belongs to the CDS basic service group (BSG).

DatafillCDSGBS data syntax is detailed in Table 2-52. The three MSISDN fields are combined to give the complete MSISDN (i.e. CC + NDC + SN). The following intra-service validation applies.


CDSGBS field descriptions are given in Table 2-53.

Table 2-52 CDSGBS data syntax






Table 2-53 CDSGBS field descriptions








InteractionsCDSGBS interacts with all other basic services, all BSG supplementary services and system table GHLRBCA.

• CDSGBS is mutually exclusive with CDS (basic service), CDS1200, CDS2400, CDS4800 and CDS9600


• if the MSISDN matches the MSISDN of any other basic service except SMMO/SMMT/CDA1275 then CDSGBS’s BCI must not be datafilled

• if datafilled, the BCI must be an entry from the BCAKEY column of system table GHLRBCA, and the value in the system table’s BSVC field must be ‘CDSGBS’

• CDSGBS belongs to the CDS BSG; at least one basic service from the CDS BSG must be provisioned if any BSG-SS is registered against CDS (services BAIC, BICRoam, BAOC, BOIC, BOICexHC, CFB, CFNRc, CFNRy, CFU, COS, CUG, CW and EXT)






FAX3 (Facsimile Group 3) 2FAX3 datafill defines the MSISDN and bearer capability for fax3. FAX3 belongs to the FAX basic service group (BSG).

DatafillFAX3 data syntax is detailed in Table 2-54. The three MSISDN fields are combined to give the complete MSISDN (i.e. CC + NDC + SN). The following intra-service validation applies.


FAX3 field descriptions are given in Table 2-55.

Table 2-54 FAX3 data syntax






Table 2-55 FAX3 field descriptions








InteractionsFAX3 interacts with all other basic services, all BSG supplementary services and system table GHLRBCA.

• ALTSPFAX is mutually exclusive with FAX3


• if the MSISDN matches the MSISDN of any other basic service except SMMO/SMMT/CDA1275 then FAX3’s BCI must not be datafilled but there is an exception:

— FAX3/CDA/CDS may share an MSISDN, and one of them may have a BCI (refers to CDA/CDS basic services, not BSGs)

• if datafilled, the BCI must be an entry from the BCAKEY column of system table GHLRBCA, and the value in the system table’s BSVC field must be ‘FAX3’

• FAX3 belongs to the FAX BSG; at least one basic service from the FAX BSG must be provisioned if any BSG-SS is registered against FAX (services BAIC, BICRoam, BAOC, BOIC, BOICexHC, CFB, CFNRc, CFNRy, CFU, COS, CUG, CW and EXT)






SMMO (Short Message Mobile Originating) 2SMMO datafill defines the MSISDN and bearer capability for SMMO. SMMO belongs to the SMS basic service group (BSG).

DatafillSMMO data syntax is detailed in Table 2-56. The three MSISDN fields are combined to give the complete MSISDN (i.e. CC + NDC + SN). The following intra-service validation applies.


SMMO field descriptions are given in Table 2-57.

Table 2-56 SMMO data syntax





Table 2-57 SMMO field descriptions







InteractionsSMMO interacts with all other basic services and all BSG supplementary services.

• TPHNY, SMMO, and SMMT must have the same MSISDN. If the MSISDN of SMMO is changed then the other two are automatically updated to match


• SMMO belongs to the SMS BSG; at least one basic service from the SMS BSG must be provisioned if any BSG-SS is registered against SMS (services BAIC, BICRoam, BAOC, BOIC, BOICexHC, CFB, CFNRc, CFNRy, CFU, COS, CUG, CW and EXT)






SMMT (Short Message Mobile Originating) 2SMMT datafill defines the MSISDN and bearer capability for SMMT. SMMT belongs to the SMS basic service group (BSG).

DatafillSMMT data syntax is detailed in Table 2-58. The three MSISDN fields are combined to give the complete MSISDN (i.e. CC + NDC + SN). The following intra-service validation applies.


SMMT field descriptions are given in Table 2-59.

Table 2-58 SMMT data syntax





Table 2-59 SMMT field descriptions







InteractionsSMMT interacts with all other basic services and all BSG supplementary services.

• TPHNY, SMMO, and SMMT must have the same MSISDN. If the MSISDN of SMMO is changed then the other two are automatically updated to match


• SMMT belongs to the SMS BSG; at least one basic service from the SMS BSG must be provisioned if any BSG-SS is registered against SMS (services BAIC, BICRoam, BAOC, BOIC, BOICexHC, CFB, CFNRc, CFNRy, CFU, COS, CUG, CW and EXT)






SPCHCDA (Speech followed by CDA Data) 2SPCHCDA datafill defines the MSISDN and bearer capability for speech followed by CDA data. SPCHCDA belongs to the CDA basic service group (BSG).

DatafillSPCHCDA data syntax is detailed in Table 2-60. The three MSISDN fields are combined to give the complete MSISDN (i.e. CC + NDC + SN). The following intra-service validation applies.


SPCHCDA field descriptions are given in Table 2-61.

Table 2-60 SPCHCDA data syntax






Table 2-61 SPCHCDA field descriptions








InteractionsSPCHCDA interacts with all other basic services, all BSG supplementary services and system table GHLRBCA.


• if the MSISDN matches the MSISDN of any other basic service except SMMO/SMMT/CDA1275/SPCHCDS then SPCHCDA’s BCI must not be datafilled

• if datafilled, the BCI must be an entry from the BCAKEY column of system table GHLRBCA, and the value in the system table’s BSVC field must be ‘SPCHCDA’

• SPCHCDA belongs to the CDA BSG; at least one basic service from the CDA BSG must be provisioned if any BSG-SS is registered against CDA (services BAIC, BICRoam, BAOC, BOIC, BOICexHC, CFB, CFNRc, CFNRy, CFU, COS, CUG, CW and EXT)


• when provisioning SPCHCDA, a BCI must be supplied unless SPCHCDS is concurrently provisioned with a BCI

• upon provisioning SPCHCDA, SPCHCDS is automatically provisioned with the same MSISDN and a null BCI (unless explicitly provisioned also)

• SPCHCDA and SPCHCDS must have the same MSISDN. Upon changing the MSISDN of one service, the other service’s MSISDN is automatically updated to match

• one of SPCHCDA/SPCHCDS must have a BCI, the other must have a null BCI. Upon changing the null BCI to a value, the other service’s BCI is automatically updated to have a null BCI. It is not valid to change the service with the BCI so that it has a null BCI (as then both services would have a null BCI)

• upon deprovisioning SPCHCDA, SPCHCDS is automatically deprovisioned too





SPCHCDS (Speech followed by CDS Data) 2SPCHCDS datafill defines the MSISDN and bearer capability for speech followed by CDS data. SPCHCDS belongs to the CDS basic service group (BSG).

DatafillSPCHCDS data syntax is detailed in Table 2-62. The three MSISDN fields are combined to give the complete MSISDN (i.e. CC + NDC + SN). The following intra-service validation applies.


SPCHCDS field descriptions are given in Table 2-63.

Table 2-62 SPCHCDS data syntax






Table 2-63 SPCHCDS field descriptions








InteractionsSPCHCDS interacts with all other basic services, all BSG supplementary services and system table GHLRBCA.


• if the MSISDN matches the MSISDN of any other basic service except SMMO/SMMT/CDA1275/SPCHCDA then SPCHCDS’s BCI must not be datafilled

• if datafilled, the BCI must be an entry from the BCAKEY column of system table GHLRBCA, and the value in the system table’s BSVC field must be ‘SPCHCDS’

• SPCHCDS belongs to the CDA BSG; at least one basic service from the CDA BSG must be provisioned if any BSG-SS is registered against CDA (services BAIC, BICRoam, BAOC, BOIC, BOICexHC, CFB, CFNRc, CFNRy, CFU, COS, CUG, CW and EXT)


• when provisioning SPCHCDS, a BCI must be supplied unless SPCHCDA is concurrently provisioned with a BCI

• upon provisioning SPCHCDS, SPCHCDA is automatically provisioned with the same MSISDN and a null BCI (unless explicitly provisioned also)

• SPCHCDS and SPCHCDA must have the same MSISDN. Upon changing the MSISDN of one service, the other service’s MSISDN is automatically updated to match

• one of SPCHCDS/SPCHCDA must have a BCI, the other must have a null BCI. Upon changing the null BCI to a value, the other service’s BCI is automatically updated to have a null BCI. It is not valid to change the service with the BCI so that it has a null BCI (as then both services would have a null BCI)

• upon deprovisioning SPCHCDS, SPCHCDA is automatically deprovisioned too





TPHNY (Telephony) 2TPHNY datafill defines the MSISDN and bearer capability for voice calls. TPHNY belongs to the SPCH basic service group (BSG).

DatafillTPHNY data syntax is detailed in Table 2-64. The three MSISDN fields are combined to give the complete MSISDN (i.e. CC + NDC + SN). The following intra-service validation applies.


TPHNY field descriptions are given in Table 2-65.

Table 2-64 TPHNY data syntax






Table 2-65 TPHNY field descriptions








InteractionsTPHNY interacts with all other basic services, all BSG supplementary services and system table GHLRBCA.

• TPHNY must be provisioned for AUXTPHNY to be provisioned

• TPHNY, SMMO, and SMMT must have the same MSISDN. If the MSISDN of TPHNY is changed then the other two are automatically updated to match.


• if the MSISDN matches the MSISDN for any other basic service except SMMO/SMMT/CDA1275 then TPHNY’s BCI must not be datafilled

• if datafilled, the BCI must be an entry from the BCAKEY field of system table GHLRBCA, and the value in the system table’s BSVC field must be ‘TPHNY’

• TPHNY must be provisioned if any BSG-SS is registered against SPCH (services BAIC, BICRoam, BAOC, BOIC, BOICexHC, CFB, CFNRc, CFNRy, CFU, COS, CUG, CW and EXT)






VBS (Voice Broadcast Service) 2VBS belongs to the voice group services (VGS) basic service group (BSG). VGS basic services have different datafill to all other basic services. VBS datafill defines groups that the subscriber belongs to for VBS functionality.

DatafillVBS data syntax is detailed in Table 2-66. The following intra-service validations apply.

• all datafill is optional; however, if Functions outside HPLMN is datafilled then at least one Group must be datafilled (similarly, if at least one Group is datafilled then Functions outside HPLMN must be datafilled)

• within the Groups vector, duplicate IDs are not permitted

VBS field descriptions are given in Table 2-67.

InteractionsNone

Table 2-66 VBS data syntax


Functions outside HPLMN Boolean Optional

Groups Vector (0 - 50) composed of the two dataitems below All 50 are Optional

- ID 3 digits as above

- Origination Entitlement Boolean as above

Table 2-67 VBS field descriptions


Functions outside HPLMN indicates whether subscriber can use VBS when roaming out of the HPLMN

Groups Vector (0 - 50) vector of groups

- ID a group ID

- Origination Entitlement indicates whether the subscriber can originate calls to this group



VGCS (Voice Group Call Service) 2VGCS belongs to the voice group services (VGS) basic service group (BSG). VGS basic services have different datafill to all other basic services. VGCS datafill defines groups that the subscriber belongs to for VBS functionality.

DatafillVGCS data syntax is detailed in Table 2-68. The following intra-service validations apply.

• all datafill is optional; however, if Functions outside HPLMN is datafilled then at least one Group must be datafilled (similarly, if at least one Group is datafilled then Functions outside HPLMN must be datafilled)

• within the Groups vector, duplicate IDs are not permitted

VGCS field descriptions are given in Table 2-69.

InteractionsNone

Table 2-68 VGCS data syntax


Functions outside HPLMN Boolean Optional

Group IDs Vector (0 - 50) 3 digits All 50 are Optional

Table 2-69 VGCS field descriptions


Functions outside HPLMN indicates whether subscriber can use VBS when roaming out of the HPLMN

Group ID a group ID



Supplementary Services introduction 2Supplementary Services (SSs) modify or enhance basic services. Each SS only applies to certain basic service groups (BSGs). There are two major SS groups: IMSI-based and BSG-based. IMSI-based services have datafill that applies to all the basic service groups they apply to. BSG-based services have datafill specific to each basic service group they apply to.

BSG-SSs have registration sets, with each set having registered/activated/suppression states (suppression states are temporary/changeable data that are a result of interactions between the subscribers services and location and are therefore not part of the subscriber profile). IMSI-SSs do not have registration sets, hence simply have a provisioned state.

The HLR supports the supplementary services given in Table 2-70. The Group column gives the SS group type as used in the specifications (a proprietary service does not belong to one of these groups and is marked as such). Note that CUG has two separate lots of datafill: CUG Feature data and CUG Subscription data.

Table 2-70 Supplementary Services (2 pages)

Short Name

Expanded Name Group Type See Section

ACC Accounting Codes Proprietary IMSI on page 2-109

ACRJ Anonymous Call Rejection Proprietary IMSI on page 2-110

AOCC Advice of Charge Charging Charging IMSI on page 2-111

AOCI Advice of Charge Information Charging IMSI on page 2-112

BAIC Barring of all Incoming Calls Barring BSG on page 2-113

BAOC Barring of all Outgoing Calls Barring BSG on page 2-115

BICRoam Barring of all Incoming Calls when Roaming outside HPLMN country

Barring BSG on page 2-117

BOIC Barring of Outgoing International Calls


BOICexHC Barring of Outgoing International Calls except to HPLMN Country


CFB Call Forward when Busy Forwarding BSG on page 2-123



CFNRc Call Forward when Not Reachable

Forwarding BSG on page 2-130

CFNRy Call Forward when No Reply Forwarding BSG on page 2-136

CFU Call Forward Unconditionally Forwarding BSG on page 2-143

CLIP Calling Line ID Presentation Line Identification IMSI on page 2-150

CLIR Calling Line ID Restriction Line Identification IMSI on page 2-151

CNAM Calling Name Delivery Proprietary IMSI on page 2-152

COLP Connected Line ID Presentation Line Identification IMSI on page 2-153

COLR Connected Line ID Restriction Line Identification IMSI on page 2-154

COS Class Of Service Proprietary BSG on page 2-155

CUG Closed User Groups Community of Interest

BSG on page 2-158

CW Call Waiting Call Completion BSG on page 2-164

ECT Explicit Call Transfer Call Offering IMSI on page 2-166

EMLPP Enhanced Multi Level Precedence & Pre-emption

Call Priority IMSI on page 2-167

EXT Extension Services Proprietary BSG on page 2-168

FM Follow Me Follow Me IMSI on page 2-175

HOLD Call Hold Call Completion IMSI on page 2-177

HOTBILL Hot Billing Proprietary IMSI on page 2-178

LCO Local Calls Only Proprietary IMSI on page 2-179

MCT Malicious Call Trace Proprietary IMSI on page 2-180

MPTY Multi-Party MultiParty IMSI on page 2-181

UUS1 User to User Signalling stage 1 Additional Info Transfer

IMSI on page 2-182

WPS Wireless Priority Service Call Priority IMSI on page 2-183

Table 2-70 Supplementary Services (2 pages)

Short Name

Expanded Name Group Type See Section



ACC (Accounting Codes) 2ACC datafill defines the verification of the account code entered by the subscriber when originating a call. ACC is a Nortel proprietary IMSI-SS and applies to all BSGs except VGS.

DatafillACC data syntax is detailed in Table 2-71. The following intra-service interactions apply.

• Verification Length must be datafilled if the Option is set to ‘VER’; Verification Length must not be datafilled for other Options

ACC field descriptions are given in Table 2-72.

InteractionsNone

Table 2-71 ACC data syntax


Option {VER, NONVER, VOL}

Verification Length number: 1 - 16 Optional

Table 2-72 ACC field descriptions


Option verification of the account code option: verified (VER), non-verified (NONVER), voluntary (VOL)

Verification Length the valid length of the account code (only used with the verified option)



ACRJ (Anonymous Call Rejection) 2Provisioning ACRJ enables anonymous call reject functionality for the subscriber (ACRJ rejects anonymous calls, i.e. those where its calling line identification number presentation is set to restricted). ACRJ is a Nortel proprietary IMSI-SS and applies to all BSGs except SMS and VGS.

DatafillACRJ has no dataitems, it is simply provisioned or deprovisioned.

InteractionsACRJ interacts with CLIP.

• for ACRJ to be provisioned, CLIP must be provisioned and have its Override dataitem set to ‘FALSE’



AOCC (Advice of Charge Charging) 2Provisioning AOCC enables advice of charge charging functionality for the subscriber (AOCC allows a subscriber to request charging information; calls are not allowed if this information is not available). AOCC is an IMSI-SS and applies to all BSGs except SMS and VGS.

DatafillAOCC has no dataitems, it is simply provisioned or deprovisioned.

InteractionsAOCC interacts with AOCI.

• AOCC and AOCI are mutually exclusive



AOCI (Advice of Charge Information) 2Provisioning AOCI enables advice of charge information functionality for the subscriber (AOCI allows a subscriber to request charging information; calls are allowed if this information is not available). AOCI is an IMSI-SS and applies to all BSGs except SMS and VGS.

DatafillAOCI has no dataitems, it is simply provisioned or deprovisioned.

InteractionsAOCI interacts with AOCC.

• AOCI and AOCC are mutually exclusive



BAIC (Barring of All Incoming Calls) 2BAIC is a basic service group based supplementary service (BSG-SS), with its datafill defining which BSGs (supported by the service) are barred for incoming calls.

DatafillBAIC data syntax is detailed in Table 2-73. Each of the registration sets is optional.

BAIC field descriptions are given in Table 2-74.

Table 2-73 BAIC data syntax


SPCH Reg Set Activated Boolean

AUXSPCH Reg Set Activated Boolean

SMS Reg Set Activated Boolean

CDA Reg Set Activated Boolean

CDS Reg Set Activated Boolean

FAX Reg Set Activated Boolean

Table 2-74 BAIC field descriptions


SPCH Reg Set Activated indicates whether the SPCH registration is activated

AUXSPCH Reg Set Activated indicates whether the AUXSPCH registration is activated

SMS Reg Set Activated indicates whether the SMS registration is activated

CDA Reg Set Activated indicates whether the CDA registration is activated

CDS Reg Set Activated indicates whether the CDS registration is activated

FAX Reg Set Activated indicates whether the FAX registration is activated



InteractionsBAIC interacts with all basic services (except VBS and VGCS), all call forwards (CFB, CFNRc, CFNRy, CFU) and BICRoam.

• for each registration set provisioned, the BSG must be provisioned (interacts with all basic services except VBS and VGCS)

• interactions with BSG-SSs are given in Table 2-75 below. Note that these interactions apply to each BSG registration set (and where the interaction is with a BSG-SS, the interaction is with the corresponding BSG in the interacting service). These interactions only apply to activated BSG registrations

Table 2-75 BAIC registration set interactions

Validate Against Interaction

Service State

CFU Reg Set Activated BAIC and CFU are mutually exclusive per-reg set, unless the subscriber has TIF-FTNs (see section ) in which case there is no interaction

CFB Reg Set Activated BAIC and CFB are mutually exclusive per-reg set, unless the subscriber has TIF-FTNs (see section ) in which case there is no interaction

CFNRc Reg Set Activated BAIC and CFNRc are mutually exclusive per-reg set, unless the subscriber has TIF-FTNs (see section ) in which case there is no interaction

CFNRy Reg Set Activated BAIC and CFNRy are mutually exclusive per-reg set, unless the subscriber has TIF-FTNs (see section ) in which case there is no interaction

BICRoam Reg Set Activated the BICRoam reg set is deregistered



BAOC (Barring of All Outgoing Calls) 2BAOC is a basic service group based supplementary service (BSG-SS), with its datafill defining which BSGs (supported by the service) are barred for outgoing calls.

DatafillBAOC data syntax is detailed in Table 2-76. Each of the registration sets is optional.

BAOC field descriptions are given in Table 2-77.

Table 2-76 BAOC data syntax








VGS Reg Set Activated Boolean

Table 2-77 BAOC field descriptions








VGS Reg Set Activated indicates whether the VGS registration is activated



InteractionsBAOC interacts with all basic services, all call forwards (CFB, CFNRc, CFNRy, CFU), BOIC and BOICexHC.

• for each registration set provisioned, the BSG must be provisioned (interacts with all basic services)


Table 2-78 BAIC registration set interactions


Service State

CFU Reg Set Activated BAOC and CFU are mutually exclusive per-reg set, unless the subscriber has TIF-FTNs (see section ) in which case there is no interaction

CFB Reg Set Activated BAOC and CFB are mutually exclusive per-reg set, unless the subscriber has TIF-FTNs (see section ) in which case there is no interaction

CFNRc Reg Set Activated BAOC and CFNRc are mutually exclusive per-reg set, unless the subscriber has TIF-FTNs (see section ) in which case there is no interaction

CFNRy Reg Set Activated BAOC and CFNRy are mutually exclusive per-reg set, unless the subscriber has TIF-FTNs (see section ) in which case there is no interaction

BOIC Reg Set Activated the BOIC reg set is deregistered

BOICexHC Reg Set Activated the BOICexHC reg set is deregistered



BICRoam (Barring of Incoming Calls when Roaming outside HPLMN country) 2BICRoam is a basic service group based supplementary service (BSG-SS), with its datafill defining which BSGs (supported by the service) are barred for incoming calls when the subscriber is roaming outside the HPLMN country.

DatafillBICRoam data syntax is detailed in Table 2-79. Each of the registration sets is optional.

BICRoam field descriptions are given in Table 2-80.

Table 2-79 BICRoam data syntax








Table 2-80 BICRoam field descriptions










InteractionsBICRoam interacts with all basic services (except VBS and VGCS) and BAIC.



Table 2-81 BICRoam registration set interactions


Service State

BAIC Reg Set Activated the BAIC reg set is deregistered unless

BAIC is registered in the current transaction, in which case

the BICRoam reg set is deregistered



BOIC (Barring of Outgoing International Calls) 2BOIC is a basic service group based supplementary service (BSG-SS), with its datafill defining which BSGs (supported by the service) are barred for outgoing international calls.

DatafillBOIC data syntax is detailed in Table 2-82. Each of the registration sets is optional.

BOIC field descriptions are given in Table 2-83.

Table 2-82 BOIC data syntax








Table 2-83 BOIC field descriptions










InteractionsBOIC interacts with all basic services (except VBS and VGCS), CFU, BAOC, BOICexHC and system table GHLRPCC.



Table 2-84 BOIC registration set interactions


Service State

CFU Reg Set Activated BOIC and CFU are mutually exclusive per-reg set if the subscriber has GSM-FTNs (see section ) and the CFU FTN is international w.r.t. the HPLMN Country (see section , requires system table GHLRPCC)

BAOC Reg Set Activated the BAOC reg set is deregistered unless

BAOC is registered in the current transaction, in which case

the BOIC reg set is deregistered

BOICexHC Reg Set Activated the BOICexHC reg set is deregistered



BOICexHC (Barring of Outgoing International Calls except to HPLMN Country) 2BOICexHC is a basic service group based supplementary service (BSG-SS), with its datafill defining which BSGs (supported by the service) are barred for outgoing international calls, except those to the HPLMN country.

DatafillBOICexHC data syntax is detailed in Table 2-85. Each of the registration sets is optional.

BOICexHC field descriptions are given in Table 2-86.

Table 2-85 BOICexHC data syntax








Table 2-86 BOICexHC field descriptions










InteractionsBOICexHC interacts with all basic services (except VBS and VGCS), CFU, BAOC, BOIC and system table GHLRPCC.


• interactions with BSG-SSs are given in Table 2-87. Note that these interactions apply to each BSG registration set (and where the interaction is with a BSG-SS, the interaction is with the corresponding BSG in the interacting service). These interactions only apply to activated BSG registrations

Table 2-87 BOICexHC registration set interactions


Service State

CFU Reg Set Activated BOICexHC and CFU are mutually exclusive per-reg set if the subscriber has GSM-FTNs (see section ) and the CFU FTN is international w.r.t. the HPLMN Country (see section , requires system table GHLRPCC)

BAOC Reg Set Activated the BAOC reg set is deregistered unless

BAOC is registered in the current transaction, in which case

the BOIC reg set is deregistered

BOIC Reg Set Activated the BOIC reg set is deregistered unless

BOIC is registered in the current transaction, in which case

the BOICexHC reg set is deregistered



CFB (Call Forward when Busy) 2CFB is a basic service group based supplementary service (BSG-SS), allowing forward to numbers (FTNs) to be datafilled for call forwarding when busy against the BSGs the service supports.

DatafillCFB data syntax is detailed in Table 2-88. Each of the registration sets is optional.

The validation of CFB is complicated by its interaction with ESMR LCO Translations. If these translations are enabled then CFB’s FTNs are passed through these translations to normalise the number (i.e convert it to international E164 format) and to determine whether the number is “local”. The syntax checks in apply to the post-translated number. The syntax check for pre-translated FTNs is that they contain 1 - 15 digits (with no restriction on the first digit). The “local” indication is required in CFB’s interaction with LCO service.

Note that if ESMR LCO translations are not enabled, then no translations occur and the FTN defaults to being “not local”.

Meaning of ESMR LCOThese are a particular type of translations used to normalise DNs and determine their localness. They are enabled on the HLR if key ‘1021’ is datafilled in system table XLAENTRY and there is associated translations tables datafill. The term “ESMR” is used due to these translations being particularly used in the north American market.



.

Table 2-88 CFB data syntax


NCP {NONF, NF, NFWN}

NFP {NONF, NF, NFWN}

DCF ID 1 - 20 characters Optional


NOA {UNKN, INTL, NTL, NTWK, SUBS, ABBR}

NPI {UNKN, E164, X121, F69, E212, NATL, PRIV}

FTN 1 - 15 digits




FTN 1 - 15 digits




FTN 1 - 15 digits




FTN 1 - 15 digits




FTN 1 - 15 digits



CFB field descriptions are given in Table 2-89.

Table 2-89 CFB field descriptions


NCP Notify Calling Party option: No-notification (NONF), Notification (NF), Notification-with-number (NFWN)

NFP Notify Forwarding Party option: No-notification (NONF), Notification (NF), Notification-with-number (NFWN)

DCF ID Default Call Forwarding ID, defined in system table GHLRDCF


NOA the FTN Nature Of Address for the SPCH registration; options are Unknown (UNKN), International-number (INTL), National-significant-number (NTL), Network-specific-number (NTWK), Subscriber-number (SUBS) and Abbreviated-number (ABBR)

NPI the FTN Number Plan Indicator for the SPCH registration; options are Unknown (UNKN), ISDN/telephony-numbering-plan (E164), Data-numbering-plan (X121), Telex-numbering-plan (F69), Land-mobile-numbering-plan (E212), National-numbering-plan (NATL) and Private-numbering-plan (PRIV)

FTN the Forward To Number for the SPCH registration

also known as the call forward number


NOA the FTN Nature Of Address for the AUXSPCH registration; for options see SPCH Reg Set

NPI the FTN Number Plan Indicator for the AUXSPCH registration; for options see SPCH Reg Set

FTN the Forward To Number for the AUXSPCH registration





NOA the FTN Nature Of Address for the CDA registration; for options see SPCH Reg Set

NPI the FTN Number Plan Indicator for the CDA registration; for options see SPCH Reg Set

FTN the Forward To Number for the CDA registration



NOA the FTN Nature Of Address for the CDS registration; for options see SPCH Reg Set

NPI the FTN Number Plan Indicator for the CDS registration; for options see SPCH Reg Set

FTN the Forward To Number for the CDS registration



NOA the FTN Nature Of Address for the FAX registration; for options see SPCH Reg Set

NPI the FTN Number Plan Indicator for the FAX registration; for options see SPCH Reg Set

FTN the Forward To Number for the FAX registration


Table 2-89 CFB field descriptions




InteractionsCFB interacts with all basic services (except VBS and VGCS), BAOC, BAIC, CFU, LCO, ODB BAIC, ODB BAOC, ODB PremRate categories, O-CSI and system tables GHLRDCF and GHLRODB. Note that CFB’s interactions are identical to that of CFNRc and CFNRy.

• if the DCF ID is datafilled, it must be an entry from the DCFID field of system table GHLRDCF, and the FTNCHECK field must match the subscriber’s FTN type (depends on O-CSI, see “Determining FTN type” on page 2-129)

• for each registration set provisioned, the BSG must be provisioned (interacts with all basic services except SMMO, SMMT, VBS and VGCS)

• none of the FTNs must match any of the subscriber’s basic service MSISDNs (interacts with all basic services except VBS and VGCS)

• the FTN format and NOA/NPI combination is checked against the subscriber’s FTN-type (interacts with O-CSI (see “Determining FTN type” on page 2-129):

— GSM-FTNs: length must have 4 - 15 digits, first digit must not be zero; NOA must be ‘INTL’, NPI must be ‘E164’

— Custom-FTNs: length must have 1 - 15 digits; NOA must be ‘UNKN’, NPI must be ‘UNKN’

— TIF-FTNs: length must have 1 - 15 digits; NOA and NPI can take any values, however if NOA/NPI is ‘INTL’/’E164’ then additional checks apply to the FTN format: must be 4 - 15 digits and first digit must not be zero

• interactions with BSG-SSs and ODBs are given in Table 2-90 on page 2-128. Note that these interactions apply to each BSG registration set (and where the interaction is with a BSG-SS, the interaction is with the corresponding BSG in the interacting service). These interactions only apply to activated BSG registrations



.

* FTN type determination is discussed in “Determining FTN type” on page 2-129

Table 2-90 CFB registration set interactions


Service State

BAIC Reg Set Activated CFB and BAIC are mutually exclusive per-reg set, unless the subscriber has TIF FTNs*, in which case there is no interaction

BAOC Reg Set Activated CFB and BAOC are mutually exclusive per-reg set, unless the subscriber has TIF FTNs*, in which case there is no interaction

CFU Reg Set Activated CFB cannot be newly registered after CFU has been registered

LCO Provisioned CFB and LCO are mutually exclusive if (1) the subscriber has GSM FTNs* and (2) any CFB FTN is not local

ODB BAIC Provisioned CFB cannot be newly registered after ODB BAIC has been provisioned, unless the subscriber has TIF FTNs*, in which case there is no interaction

ODB BAOC Provisioned CFB cannot be newly registered after ODB BAOC has been provisioned, unless the subscriber has TIF FTNs*, in which case there is no interaction

ODB Prem Rate categories

Provisioned CFB cannot be newly registered after ODB Prem Rate (Ent or Info) is provisioned if (1) the subscriber has GSM FTNs AND (2) the FTN is barred according to its lookup in system table GHRLODB.




Determining FTN typeA subscriber may have GSM-FTNs, TIF-FTNs or Custom-FTNs. If the subscriber does not have O-CSI provisioned then they have GSM-FTNs. If the subscriber does have O-CSI provisioned, then their FTN type is determined by the FTN Checks field -- the field can be set to GSM, TIF or Custom. Therefore for instance, a TIF-FTNs subscriber has O-CSI provisioned, with FTN Checks set to TIF.

Determining if an FTN is international w.r.t. HPLMN countryWhether an FTN is international with respect to the HPLMN Country is important in some interactions with CFB. The following steps are taken in this determination:

• the subscriber’s primary MSISDN is determined (requires all basic services except VBS and VGCS)

• the primary MSISDN CC is mapped to a Pseudo Country Code (PCC) by doing a lookup in the TO/FROM fields of system table GHLRPCC

• the CFB FTN is also mapped to a PCC by doing a lookup in the TO/FROM fields of system table GHLRPCC

• if either number does not map to a PCC then it is a translations error, and the datafill is not valid

• the two PCCs are compared -- the FTN is international w.r.t. the HPLMN Country if they differ

DCF ID activation state determinationThe DCF ID does have an “activation” state, but it is not provisionable and is only determined on demand (e.g. when a MAP message to the HLR requests it). It is therefore, strictly speaking, not part of the subscriber profile. For information only, here are details regarding the DCF activation state:

• For non-TIF-FTN subscribers: DCF is deactivated if the subscriber has BAOC or BAIC. DCF is suppressed if the subscriber has BICRoam (act/not sup), ODB BAOC, ODB BAOCRoam (act), ODB BAIC or ODB BICRoam (act)

• If the subscriber has CFU then DCF is always deactivated

• For GSM-FTN subscribers: DCF is suppressed if the subscriber has LCO (ESMR or non-ESMR), BOIC (act, number intl), BOICexHC (act, number intlexHC), ODB BOIC (number intl), ODB BOICexHC (number intlexHC), ODB PremRate (number barred) or ODB HPLMN Spec (act, number barred)



CFNRc (Call Forward when Not Reachable) 2CFNRc is a basic service group based supplementary service (BSG-SS), allowing forward to numbers (FTNs) to be datafilled for call forwarding when not reachable (i.e. the MS is detached, there is radio congestion or there is no page response/temporarily unavailable) against the BSGs the service supports.

DatafillCFNRc data syntax is detailed in Table 2-91 on page 2-131. Each of the registration sets is optional.

The validation of CFNRc is complicated by its interaction with ESMR LCO Translations. If these translations are enabled then CFNRc’s FTNs are passed through these translations to normalise the number (i.e convert it to international E164 format) and to determine whether the number is “local”. The syntax checks in apply to the post-translated number. The syntax check for pre-translated FTNs is that they contain 1 - 15 digits (with no restriction on the first digit). The “local” indication is required in CFNRc’s interaction with LCO service.





.

Table 2-91 CFNRc data syntax







FTN 1 - 15 digits




FTN 1 - 15 digits




FTN 1 - 15 digits




FTN 1 - 15 digits




FTN 1 - 15 digits



CFNRc field descriptions are given in Table 2-92.

Table 2-92 CFNRc field descriptions (2 pages)





















InteractionsCFNRc interacts with all basic services (except VBS and VGCS), BAOC, BAIC, CFU, LCO, ODB BAIC, ODB BAOC, ODB PremRate categories, O-CSI and system tables GHLRDCF and GHLRODB. Note that CFNRc’s interactions are identical to that of CFB and CFNRy.















Table 2-92 CFNRc field descriptions (2 pages)







• interactions with BSG-SSs and ODBs are given in Table 2-93 below. Note that these interactions apply to each BSG registration set (and where the interaction is with a BSG-SS, the interaction is with the corresponding BSG in the interacting service). These interactions only apply to activated BSG registrations

Table 2-93 CFNRc registration set interactions


Service State






















• If the subscriber has CFU then DCF is always deactivated.




CFNRy (Call Forward when No Reply) 2CFNRy is a basic service group based supplementary service (BSG-SS), allowing forward to numbers (FTNs) to be datafilled for call forwarding when no reply within a specified time against the BSGs the service supports.

DatafillCFNRy data syntax is detailed in Table 2-94. Each of the registration sets is optional.

The validation of CFNRy is complicated by its interaction with ESMR LCO Translations. If these translations are enabled then CFNRy’s FTNs are passed through these translations to normalise the number (i.e convert it to international E164 format) and to determine whether the number is “local”. The syntax checks in apply to the post-translated number. The syntax check for pre-translated FTNs is that they contain 1 - 15 digits (with no restriction on the first digit). The “local” indication is required in CFNRy’s interaction with LCO service.



Table 2-94 CFNRy data syntax (2 pages)



NFP {NONF, NF, NFWN}





FTN 1 - 15 digits

No Reply Time number: 5 - 30 (must be a multiple of 5)






FTN 1 - 15 digits





FTN 1 - 15 digits





FTN 1 - 15 digits





FTN 1 - 15 digits


Table 2-94 CFNRy data syntax (2 pages)




CFNRy field descriptions are given in Table 2-95.

Table 2-95 CFNRy field descriptions (2 pages)



NFP Notify Forwarding Party option: No-notification (NONF), Notification (NF), Notification-with-number (NFWN)







No Reply Time the no-reply time for the SPCH registration



























Table 2-95 CFNRy field descriptions (2 pages)




InteractionsCFNRy interacts with all basic services (except VBS and VGCS), BAOC, BAIC, CFU, LCO, ODB BAIC, ODB BAOC, ODB PremRate categories, O-CSI and system tables GHLRDCF and GHLRODB. Note that CFNRy’s interactions are identical to that of CFB and CFNRc.








• interactions with BSG-SSs and ODBs are given in Table 2-96 on page 2-141. Note that these interactions apply to each BSG registration set (and where the interaction is with a BSG-SS, the interaction is with the corresponding BSG in the interacting service). These interactions only apply to activated BSG registrations




Table 2-96 CFNRy registration set interactions


Service State





















• If the subscriber has CFU then DCF is always deactivated




CFU (Call Forward Unconditionally) 2CFU is a basic service group based supplementary service (BSG-SS), allowing forward to numbers (FTNs) to be datafilled for call forwarding unconditionally against the BSGs the service supports.

DatafillCFU data syntax is detailed in Table 2-97 on page 2-144. Each of the registration sets is optional.

The validation of CFU is complicated by its interaction with ESMR LCO Translations. If these translations are enabled then CFU’s FTNs are passed through these translations to normalise the number (i.e convert it to international E164 format) and to determine whether the number is “local”. The syntax checks in apply to the post-translated number. The syntax check for pre-translated FTNs is that they contain 1 - 15 digits (with no restriction on the first digit). The “local” indication is required in CFU’s interaction with LCO service.





Table 2-97 CFU data syntax






FTN 1 - 15 digits




FTN 1 - 15 digits




FTN 1 - 15 digits




FTN 1 - 15 digits




FTN 1 - 15 digits



CFU field descriptions are given in Table 2-98.

Table 2-98 CFU field descriptions (2 pages)




















InteractionsCFU interacts with all basic services (except VBS and VGCS), BAOC, BOIC, BOICexHC, BAIC, LCO, ODB BAIC, ODB BAOC, ODB BOIC, ODB BOICexHC, ODB PremRate categories, ODB HPLMN Specific categories, O-CSI and system table GHLRODB.
















Table 2-98 CFU field descriptions (2 pages)





• interactions with BSG-SSs and ODBs are given in Table 2-99 below. Note that these interactions apply to each BSG registration set (and where the interaction is with a BSG-SS, the interaction is with the corresponding BSG in the interacting service). These interactions only apply to activated BSG registrations

Table 2-99 CFU registration set interactions (2 pages)


Service State

BAIC Reg Set Activated CFU and BAIC are mutually exclusive per-reg set, unless the subscriber has TIF FTNs*, in which case there is no interaction

BAOC Reg Set Activated CFU and BAOC are mutually exclusive per-reg set, unless the subscriber has TIF FTNs*, in which case there is no interaction

BOIC Reg Set Activated CFU and BOIC are mutually exclusive per-reg set if (1) the subscriber has GSM FTNs* and (2) the FTN is international with respect to HPLMN country**

BOICexHC Reg Set Activated CFU and BOICexHC are mutually exclusive per-reg set if (1) the subscriber has GSM FTNs* and (2) the FTN is international with respect to HPLMN country**

LCO Provisioned CFU and LCO are mutually exclusive if (1) the subscriber has GSM FTNs* and (2) any CFU FTN is not local

ODB BAIC Provisioned CFU cannot be newly registered after ODB BAIC has been provisioned, unless the subscriber has TIF FTNs*, in which case there is no interaction

ODB BAOC Provisioned CFU cannot be newly registered after ODB BAOC has been provisioned, unless the subscriber has TIF FTNs*, in which case there is no interaction

ODB BOIC Provisioned CFU cannot be newly registered after ODB BOIC has been provisioned

if (1) the subscriber has GSM FTNs* and (2) the FTN is international with respect to HPLMN country**



* FTN type determination is discussed in “Determining FTN type” on page 2-149** determination if FTN is international with respect to HPLMN country is discussed in “Determining if an FTN is international w.r.t. HPLMN country” on page 2-149# determining whether an FTN is barred for an ODB Premium Rate/ODB HPLMN Specific categories is done via a lookup in digilator system table GHLRODB

ODB BOICexHC Provisioned CFU cannot be newly registered after ODB BOIC has been provisioned

if (1) the subscriber has GSM FTNs* and (2) the FTN is international with respect to HPLMN country**


Provisioned CFU cannot be newly registered after an ODB Premium Rate category has been provisioned if (1) the subscriber has GSM FTNs* and (2) the FTN is barred for that category#

ODB HPLMN Specific categories

Provisioned CFU cannot be newly registered after an ODB HPLMN Specific category has been provisioned if (1) the subscriber has GSM FTNs* and (2) the FTN is barred for that category#

Table 2-99 CFU registration set interactions (2 pages)


Service State













CLIP (Calling Line ID Presentation) 2CLIP datafill defines whether a Calling Line Identity Restriction (CLIR) of the calling party is overridden. CLIP is an IMSI-SS and applies to all BSGs except SMS.

DatafillCLIP data syntax is detailed in Table 2-100.

CLIP field descriptions are given in Table 2-101.

InteractionsCLIP interacts with ACRJ and office parameters GSM_CLIP_SUPPORTED and GSM_CLIP_OVR_SUPPORTED.

• for ACRJ to be provisioned, CLIP must be provisioned and have Override set to ‘FALSE’

• CLIP can only be provisioned if office parameter GSM_CLIP_SUPPORTED (table OFCSTD) is ‘TRUE’

• Override can only be set to ‘TRUE’ if office parameter GSM_CLIP_OVR_SUPPORTED (table OFCSTD) is ‘TRUE’

Table 2-100 CLIP data syntax


Override Boolean

Table 2-101 CLIP field descriptions


Override indicates whether CLIP override is in effect



CLIR (Calling Line ID Restriction) 2CLIR datafill defines the presentation mode to be used for CLI restriction. CLIR is an IMSI-SS and applies to all BSGs except SMS.

DatafillCLIR data syntax is detailed in Table 2-102.

CLIR field descriptions are given in Table 2-103.

InteractionsCLIR interacts with office parameter GSM_CLIR_SUPPORTED.

• CLIR can only be provisioned if office parameter GSM_CLIR_SUPPORTED (table OFCSTD) is ‘TRUE’

Table 2-102 CLIR data syntax


Presentation Mode {P, TRES, TNRES}

Table 2-103 CLIR field descriptions


Presentation Mode presentation mode option: permanent-CLI-presentation-restricted (P), temporary-CLI-presentation-restricted (TRES), temporary-CLI-presentation-not-restricted (TNRES)



CNAM (Calling Name Delivery) 2Provisioning CNAM enables Calling Name Delivery functionality for the subscriber (CNAM allows the calling party’s name to be displayed on the terminator’s MS). CNAM is a Nortel proprietary IMSI-SS and applies to all BSGs except SMS and VGS.

DatafillCNAM has no dataitems, it is simply provisioned or deprovisioned.

InteractionsNone



COLP (Connected Line ID Presentation) 2COLP datafill specifies whether service COLR on the connected party is overridden. COLP is an IMSI-SS and applies to all BSGs except SMS.

DatafillCOLP data syntax is detailed in Table 2-104.

COLP field descriptions are given in Table 2-105.

InteractionsNone

Table 2-104 COLP data syntax


Override Boolean

Table 2-105 COLP field descriptions


Override indicates whether COLP override is in effect



COLR (Connected Line ID Restriction) 2Provisioning COLR enables explicit connected line ID restriction functionality for the subscriber. COLR is an IMSI-SS and applies to all BSGs except SMS.

DatafillCOLR has no dataitems, it is simply provisioned or deprovisioned.

InteractionsNone



COS (Class of Service) 2COS is a basic service group based supplementary service (BSG-SS), allowing class of service information to be datafilled against each BSG that is supported by the service. COS is a Nortel proprietary service.

DatafillCOS data syntax is detailed in Table 2-106. Each of the registration sets is optional.

Table 2-106 COS data syntax



Customer Group number: 0 - 4095
















COS field descriptions are given in Table 2-107.

Table 2-107 COS field descriptions



Customer Group the customer group for the SPCH registration, defined in system table GSMCUST or GSMNCOS

NCOS the network class of service for the SPCH registration, defined in system table GSMNCOS


Customer Group the customer group for the AUXSPCH registration, defined in system table GSMCUST or GSMNCOS

NCOS the network class of service for the AUXSPCH registration, defined in system table GSMNCOS


Customer Group the customer group for the CDA registration, defined in system table GSMCUST or GSMNCOS

NCOS the network class of service for the CDA registration, defined in system table GSMNCOS


Customer Group the customer group for the CDS registration, defined in system table GSMCUST or GSMNCOS

NCOS the network class of service for the CDS registration, defined in system table GSMNCOS


Customer Group the customer group for the FAX registration, defined in system table GSMCUST or GSMNCOS

NCOS the network class of service for the FAX registration, defined in system table GSMNCOS



InteractionsCOS interacts with all basic services (except SMMO, SMMT, VBS and VGCS) and system tables GSMCUST and GSMNCOS.


• for each registration set, if NCOS is datafilled, then Customer Group and NCOS combined must be an entry from column GSM_NCOS_KEY of system table GSMNCOS

• for each registration set, if NCOS is not datafilled, then Customer Group must be an entry from the GSMCUST_GRP_KEY column of system table GSMCUST



CUG (Closed User Groups) 2CUG is a basic service group based supplementary service (BSG-SS), allowing closed user groups information to be datafilled against the BSGs that are supported by the service.

CUG is unusual in that it has two separate groups of datafill. One group is mandatory, called CUG Subscription, and the other is optional, called CUG Feature.

CUG Subscription is detailed on page 2-159.

CUG Feature is detailed on page 2-161.



CUG Subscription (Closed User Groups Subscription) 2CUG is a basic service group based supplementary service (BSG-SS), allowing closed user groups information to be datafilled against the BSGs that are supported by the service.

CUG Subscription is mandatory CUG data, whereas CUG Feature (on page 2-161) is optional CUG data.

DatafillCUG Subscription data syntax is detailed in Table 2-108. The following intra-service validations apply.

• each Interlocks must be unique per subscriber

• each CUG Index must be unique per subscriber

Table 2-108 CUG Subscription data syntax


Subscription Dataset vector (1 - 10) composed of the following ten dataitems 9 are Optional

- Network ID number: 0 - 9999

- Interlock number: 0 - 65535

- CUG Index number: 0 - 32767

- IntraCUG Restrictions {ICB,OCB} Optional

- SPCH Reg Boolean

- AUXSPCH Reg Boolean

- FAX Reg Boolean

- CDA Reg Boolean

- CDS Reg Boolean

- All BSG Reg Boolean



CUG Subscription field descriptions are given in Table 2-109.

Interactions• CUG Subscription interacts with all basic services (except SMMO,

SMMT, VBS and VGCS) and CUG Feature

• CUG Subscription must be provisioned for CUG Feature to be provisioned

• for each <bsg> Reg set to ‘TRUE’, the corresponding BSG must be provisioned (interacts with all basic services except SMMO, SMMT, VBS and VGCS)

• there are complex interactions with CUG Feature -- see the CUG Feature interactions in section on page 2-163

Table 2-109 CUG Subscription field descriptions


Subscription Dataset a CUG subscription dataset, composed of the dataitems below

- Network ID network identity

- Interlock interlock code

- CUG Index CUG index

- IntraCUG Restrictions intra-CUG restrictions; options are incoming-call-barred (ICB) and outgoing-call-barred (OCB)

- SPCH Reg whether this subscription applies to SPCH

- AUXSPCH Reg whether this subscription applies to AUXSPCH

- FAX Reg whether this subscription applies to FAX

- CDA Reg whether this subscription applies to CDA

- CDS Reg whether this subscription applies to CDS

- All BSG Reg whether this subscription applies to all BSGs



CUG Feature (Closed User Groups Feature) 2CUG is a basic service group based supplementary service (BSG-SS), allowing closed user groups information to be datafilled against each BSG that is supported by the service.

CUG Feature is optional CUG data, whereas CUG Subscription (on page 2-159) is mandatory CUG data.

DatafillCUG Feature data syntax is detailed in Table 2-110. Each of the registration sets is optional.

Table 2-110 CUG Feature data syntax



ICA {OA, IA, ALL} Optional

PrefCUG Index number: 0 - 32767 Optional













All BSG Reg Set Activated Boolean





CUG Feature field descriptions are given in Table 2-111.

Table 2-111 CUG Feature field descriptions


SPCH Reg Set Activated indicates whether the registration is activated

ICA inter-CUG accessibility; options are outgoing-access, incoming-access or all

PrefCUG Index preferred CUG index

AUXSPCH Reg Set Activated indicates whether the registration is activated



FAX Reg Set Activated indicates whether the registration is activated



CDA Reg Set Activated indicates whether the registration is activated



CDS Reg Set Activated indicates whether the registration is activated



All BSG Reg Set Activated indicates whether the registration is activated





Interactions• CUG Feature interacts with all basic services (except SMMO, SMMT,

VBS and VGCS) and CUG Subscription.

• CUG Subscription must be provisioned for CUG Feature to be provisioned.

• for each Reg Set, if a PrefCUG Index is datafilled:

— the PrefCUG Index must exist at least once in a CUG Subscription as a CUG Index

— any CUG Subscription dataset whose CUG Index matches the PrefCUG Index must have its <bsg> Reg dataitem set to ‘TRUE’ (where <bsg> corresponds to the particular CUG Feature Reg Set) and its IntraCUG Restrictions dataitem must not be set to ‘OCB’

• for each Reg Set provisioned except All BSG:

— the BSG must be provisioned (interacts with all basic services except SMMO, SMMT, VBS and VGCS)

— at least one <bsg> Reg dataitem of any CUG Subscription dataset must be set to ‘TRUE’ (where <bsg> corresponds to the particular CUG Feature Reg Set). Note that if any CUG Subscription dataset has its All BSG Reg dataitem set to ‘TRUE’ then this check will always pass



CW (Call Waiting) 2CW is a basic service group based supplementary service (BSG-SS), allowing call waiting to be given to the BSGs that are supported by the service.

DatafillCW data syntax is detailed in Table 2-112. Each of the registration sets is optional.

CW field descriptions are given in Table 2-113.

Table 2-112 CW data syntax







Table 2-113 CW field descriptions









InteractionsCW interacts with all basic services (except VBS and VGCS), BAIC and ODB BAIC.


• interactions with BSG-SSs and ODBs are given in Table 2-114. Note that these interactions apply to each BSG registration set (and where the interaction is with a BSG-SS, the interaction is with the corresponding BSG in the interacting service). These interactions only apply to activated BSG registrations

Table 2-114 CW registration set interactions


Service State

BAIC Reg Set Activated BAIC can be registered after CW but CW cannot be registered after BAIC; CW and BAIC can be registered together in the same transaction

ODB BAIC Provisioned ODB BAIC can be provisioned after CW but CW cannot be registered after ODB BAIC; CW can be registered plus ODB BAIC provisioned in the same transaction



ECT (Explicit Call Transfer) 2Provisioning ECT enables explicit call transfer functionality for the subscriber. ECT is an IMSI-SS and applies to SPCH and AUXPSCH BSGs only.

DatafillECT has no dataitems, it is simply provisioned or deprovisioned.

InteractionsECT interacts with HOLD.

• HOLD must be provisioned for ECT to be provisioned



EMLPP (Enhanced Multi Level Precedence & Pre-emption) 2EMLPP datafill defines priorities for the subscriber, and can be used to set a priority for Wireless Priority Service (WPS). EMLPP is an IMSI-SS and applies to all BSGs except SMS.

DatafillEMLPP data syntax is detailed in Table 2-115.

EMLPP field descriptions are given in Table 2-116.

InteractionsEMLPP interacts with office parameter CPS_MODE (table GHLRPARM).

• if office parameter CPS_MODE is ‘EMLPP’ then the Default Priority must not be greater than the Maximum Priority (A is highest, 4 is lowest)

• if office parameter CPS_MODE is ‘WPS’ then the Default Priority and the Maximum Priority must match, and their range is restricted to {B, 1, 2, 3}

• if office parameter CPS_MODE is ‘HYBRID’ then the Maximum Priority range is restricted to {B, 1, 2, 3, 4}. Note that the Maximum Priority represents the WPS setting, while the Default Priority represents the EMLPP setting

Table 2-115 EMLPP data syntax


Maximum Priority {A, B, 1, 2, 3, 4}

Default Priority {A, B, 1, 2, 3, 4}

Table 2-116 EMLPP field descriptions


Maximum Priority the maximum priority for EMLPP or WPS

Default Priority the default priority for EMLPP or WPS, depending on office parameter CPS_MODE



EXT (Extension Services) 2EXT is a basic service group based supplementary service (BSG-SS), allowing MSISDN groups and timers to be datafilled for simultaneous and sequential altering (also known as flexible altering and mobile hunting respectively) for the BSGs supported by the service. EXT is a Nortel proprietary service.

DatafillEXT data syntax is detailed in Table 2-117 on page 2-169. Each registration set data consists of one to three groups and also an overall registration set. Each group consists of one to three MSISDNs and a timer.

For each registration set, only certain combinations of MSISDNs, Timers and Groups are valid; these are given in Table 2-118 on page 2-171. Note that combinations contain a maximum of five MSISDNs.

The validation of EXT is complicated by its interaction with ESMR LCO Translations. If these translations are enabled then EXT’s MSISDNs are passed through these translations to normalise the number (i.e convert it to international E164 format) and to determine whether the number is “local”. The syntax checks in apply to the post-translated number. The syntax check for pre-translated MSISDNs is that they contain 1 - 15 digits (with no restriction on the first digit). The “local” indication is required in EXT’s interaction with LCO service.

Note that if ESMR LCO translations are not enabled, then no translations occur and the MSISDN defaults to being “not local”.




.

Table 2-117 EXT data syntax (2 pages)



MSISDN 1.1 4 - 15 digits, cannot start with zero

MSISDN 1.2 4 - 15 digits, cannot start with zero Optional


Timer 1 number: 5 - 90 (multiple of 5)

Group 1 {SINGLE, MULTIPLE} Optional




Timer 2 number: 5 - 90 (multiple of 5) Optional







Overall Group {SINGLE, MULTIPLE} Optional




MSISDN 1.1 4 - 15 digits, cannot start with zero



Timer 1 number: 5 - 90 (multiple of 5)












Overall Group {SINGLE, MULTIPLE} Optional

Table 2-117 EXT data syntax (2 pages)




Table 2-118 Valid MSISDN/Timer/Group Combinations

Combination Type Sequence

Simultaneous M M T G

M M M T G

Sequential M T M T G

M T M T M T G

Mix using 5 MSISDNs M M M T G M M T G G

M M T G M M M T G G

M M M T G M T M T G

M T M T M M M T G G

M T M M M T G M T G

M M T G M M T G M T G

M M T G M T M M T G G

M T M M T G M M T G G

Mix using 4 MSISDNs M M T G M T M T G

M T M M T G M T G

M T M T M M T G G

M M M T G M T G

M T M M M T G G

M M T G M M T G G

Mix using 3 MSISDNs M M T G M T G

M T M M T G G

Other M T



EXT field descriptions are given in Table 2-119.

Table 2-119 EXT field descriptions (2 pages)



MSISDN 1.1 first MSISDN of first group for SPCH registration

MSISDN 1.2 second MSISDN of first group for SPCH registration

MSISDN 1.3 third MSISDN of first group for SPCH registration

Timer 1 timer for first group for SPCH registration

Group 1 first group type for SPCH registration; options are multiple or single user

MSISDN 2.1 first MSISDN of second group for SPCH registration

MSISDN 2.2 second MSISDN of second group for SPCH registration

MSISDN 2.3 third MSISDN of second group for SPCH registration

Timer 2 timer for second group for SPCH registration

Group 2 second group type for SPCH registration; options are multiple or single user

MSISDN 3.1 first MSISDN of third group for SPCH registration

MSISDN 3.2 second MSISDN of third group for SPCH registration

MSISDN 3.3 third MSISDN of third group for SPCH registration

Timer 3 timer for third group for SPCH registration

Group 3 third group type for SPCH registration; options are multiple or single user

Overall Group overall group type for SPCH registration; options are multiple or single user

(applies to the three other groups)




MSISDN 1.1 first MSISDN of first group for AUXSPCH registration

MSISDN 1.2 second MSISDN of first group for AUXSPCH registration

MSISDN 1.3 third MSISDN of first group for AUXSPCH registration

Timer 1 timer for first group for AUXSPCH registration

Group 1 first group type for AUXSPCH registration; options are multiple or single user

MSISDN 2.1 first MSISDN of second group for AUXSPCH registration

MSISDN 2.2 second MSISDN of second group for AUXSPCH registration

MSISDN 2.3 third MSISDN of second group for AUXSPCH registration

Timer 2 timer for second group for AUXSPCH registration

Group 2 second group type for AUXSPCH registration; options are multiple or single user

MSISDN 3.1 first MSISDN of third group for AUXSPCH registration

MSISDN 3.2 second MSISDN of third group for AUXSPCH registration

MSISDN 3.3 third MSISDN of third group for AUXSPCH registration

Timer 3 timer for third group for AUXSPCH registration

Group 3 third group type for AUXSPCH registration; options are multiple or single user

Overall Group overall group type for AUXSPCH registration; options are multiple or single user

(applies to the three other groups)

Table 2-119 EXT field descriptions (2 pages)




Service InteractionsEXT interacts with TPHNY, AUXTPHNY and LCO.

• for each registration set provisioned, the BSG must be provisioned (interacts with TPHNY and AUXTPHNY)

• the interactions with LCO is given in Table 2-120. Note that this interactions apply to both BSG registration sets. These interactions only apply to activated BSG registrations

Table 2-120 EXT registration set interactions


Service State

LCO Provisioned LCO and EXT registration sets can only co-exist if each MSISDN in the registration set is “local”



FM (Follow Me) 2FM datafill allows FM class of registrations to be specified. FM in an IMSI-SS and applies to all BSGs except VGS.

Note that this service is also known as Functional Addressing (FA).

DatafillFM data syntax is detailed in Table 2-121. The following intra-service interactions apply.

• at least one COR value (COR x or Supervisor COR x) must be set to ‘TRUE’

Table 2-121 FM data syntax


COR A Boolean

COR B Boolean

COR C Boolean

COR D Boolean

Supervisor COR A Boolean

Supervisor COR B Boolean

Supervisor COR C Boolean

Supervisor COR D Boolean



FM field descriptions are given in Table 2-122.

InteractionsNone

Table 2-122 FM field descriptions


COR A indicates whether FM Class of Registration A is provisioned

COR B indicates whether FM Class of Registration B is provisioned

COR C indicates whether FM Class of Registration C is provisioned

COR D indicates whether FM Class of Registration D is provisioned

Supervisor COR A indicates whether FM Supervisor Class of Registration A is provisioned

Supervisor COR B indicates whether FM Supervisor Class of Registration B is provisioned

Supervisor COR C indicates whether FM Supervisor Class of Registration C is provisioned

Supervisor COR D indicates whether FM Supervisor Class of Registration D is provisioned



HOLD (Call Hold) 2Provisioning HOLD enables call hold functionality for the subscriber. HOLD is an IMSI-SS and applies to SPCH and AUXSPCH BSGs only.

DatafillHOLD has no dataitems, it is simply provisioned or deprovisioned.

InteractionsHOLD interacts with MPTY and ECT.

• HOLD must be provisioned for MPTY to be provisioned

• HOLD must be provisioned for ECT to be provisioned



HOTBILL (Hot Billing) 2Provisioning HOTBILL enables hot billing functionality for the subscriber. HOTBILL is an Nortel proprietary IMSI-SS.

DatafillHOTBILL has no dataitems, it is simply provisioned or deprovisioned.

InteractionsNone



LCO (Local Calls Only) 2Provisioning LCO enables local calls only functionality for the subscriber. LCO is an Nortel proprietary IMSI-SS.

DatafillLCO has no dataitems, it is simply provisioned or deprovisioned.

InteractionsLCO interacts with all call forwards and EXT.

• interactions with BSG-SSs are given in Table 2-123. This interactions apply to every registration set of each BSG-SS listed

* for determination of subscriber FTN type see “Determining FTN type” on page 2-129** for more information on CF FTNs/EXT MSISDNs “localness” see “Datafill” on page 2-123 / on page 2-168 respectively. Note that if ESMR LCO Translations are not enabled then all FTNs/MSISDNs default to “not local”, meaning that in this scenario LCO is always mutually exclusive with all call forwards and EXT.

Table 2-123 LCO Interactions


Service State

CFU Reg Set Activated LCO and CFU are mutually exclusive unless (1) subscriber does not have GSM FTNs* OR (2) subscriber has GSM FTNs but FTN is “local”**

CFB Reg Set Activated LCO and CFB are mutually exclusive unless (1) subscriber does not have GSM FTNs* OR (2) subscriber has GSM FTNs but FTN is “local”**

CFNRc Reg Set Activated LCO and CFNRc are mutually exclusive unless (1) subscriber does not have GSM FTNs* OR (2) subscriber has GSM FTNs but FTN is “local”**

CFNRy Reg Set Activated LCO and CFNRy are mutually exclusive unless (1) subscriber does not have GSM FTNs* OR (2) subscriber has GSM FTNs but FTN is “local”**

EXT Reg Set Activated LCO and EXT are mutually exclusive unless all EXT MSISDNs are “local”**



MCT (Malicious Call Trace) 2Provisioning MCT enables malicious call trace functionality for the subscriber. MCT is an Nortel proprietary IMSI-SS and applies to all BSGs except SMS and VGS.

DatafillMCT has no dataitems, it is simply provisioned or deprovisioned.

InteractionsNone



MPTY (Multiparty) 2MPTY datafill defines the maximum number of ports allowed on a multi-party call. MPTY is an IMSI-SS and applies to SPCH and AUXSPCH BSGs only.

DatafillMPTY data syntax is detailed in Table 2-124.

MPTY field descriptions are given in Table 2-125.

InteractionsMPTY interacts with HOLD.

• HOLD must be provisioned for MPTY to be provisioned

Table 2-124 MPTY data syntax


Option {M3PORT, M6PORT]

Table 2-125 MPTY field descriptions


Option multiparty option: 3-ports or 6-port



UUS1 (User to User Signalling stage 1) 2Provisioning UUS1 enables user to user signalling stage 1 functionality for the subscriber. UUS1 is an IMSI-SS and applies to all BSGs except SMS and VGS.

DatafillUUS1 has no dataitems, it is simply provisioned or deprovisioned.

InteractionsNone



WPS (Wireless Priority Service) 2On the Nortel HLR, service EMLPP is used to provision/datafill WPS (see “EMLPP (Enhanced Multi Level Precedence & Pre-emption)” on page 2-167).



ODBs (Operator Determined Barrings) 2ODBs define barrings put in place by the operator. They apply to all basic service groups except VGS (ODB BAOC is an exception in that it applies to VGS too). There are four categories of ODB: incoming, outgoing, ECT and miscellaneous.

Incoming ODBs are:

• ODB BAIC (Barring of All Incoming Calls)

• ODB BICRoam (Barring of Incoming Calls when Roaming outside HPLMN country)

Outgoing ODBs are:

• ODB BAOC (Barring of All Outgoing Calls)

• ODB BAOCRoam (Barring of (All) Outgoing Calls when Roaming outside HPLMN country)

• ODB BOIC (Barring of Outgoing International Calls)

• ODB BOICexHC (Barring of Outgoing International Calls except those to HPLMN Country

ECT ODBs are:

• ODB BAECT (Barring of All Explicit Call Transfer)

• ODB BCHDECT (Barring of Chargeable Explicit Call Transfer, i.e. when at least one of the calls is charged to the served subscriber)

• ODB BINTECT (Barring of International Explicit Call Transfer, i.e. when at least one of the calls is charge to the served subscriber at international rates)

• ODB BDBCECT (Barring of Doubly Chargeable Explicit Call Transfer, i.e. when both of the calls are charged to the served subscriber)

Miscellaneous ODBs are:

• ODB HPLMN Specific 1




• ODB Premium Rate Entertainment

• ODB Premium Rate Information

• ODB CCFMGT (Barring of Conditional Call Forwarding Subscriber


Management)


• ODB CISSMGT (Barring of Call Independent Supplementary Services Management)

DatafillEach ODB is identical is that they have no dataitems, they are simply provisioned or deprovisioned.

InteractionsThe ECT ODBs interact with each other.

• ODB BAECT and ODB BCHDECT are mutually exclusive

• ODB BCHDECT and ODB BINTEXT are mutually exclusive

• ODB BAECT and ODB BINTECT are mutually exclusive



CAMEL services introduction 2CAMEL (Customised Applications for Mobile Enhanced network Logic) services are intelligent network (IN) services for the GSM network. The HLR supports several individual CAMEL subscription information (CSI) services as given in Table 2-126.

CAMEL is a network feature that enables the HPLMN operator to offer some of its Operator Specific Services (OSSs) that are not standardized by GSM specifications, to some or all of its subscribers when roaming to a different PLMN. The feature can also be used to offer these services while the subscriber is in their HPLMN.

Normally, when a subscriber roams to a different PLMN, all OSSs are lost, since the services are not GSM defined and therefore not supported by the VPLMN. However, CAMEL is GSM defined, which means that OSSs provided through CAMEL are available when the subscriber roams to a VPLMN that supports CAMEL.

Table 2-126 CAMEL Services

Short Name Expanded Name See Section

D-CSI Dialled CSI on page 2-187

GPRS-CSI GPRS CSI on page 2-189

M-CSI Mobility Management CSI on page 2-192

O-CSI Originating CSI on page 2-193

SMS-CSI Short Message Service CSI on page 2-201

SS-CSI Supplementary Service CSI on page 2-203

T-CSI Terminating CSI on page 2-204

USSD-CSI Unstructured Supplementary Service Data CSI on page 2-210



D-CSI (Dialled CSI) 2D-CSI datafill defines criteria for the Analysed Information detection point (DP) in the originating Basic Call State Machine (BCSM) for mobile originating and forwarded calls.

DatafillD-CSI data syntax is detailed in Table 2-127. The Criteria Names are a vector; at least one Criteria Name must be datafilled (see Chapter 1, “Data vectors”, on page 1-36 for more information on vectors). The following intra-service interactions apply.

• duplicate Criteria Names are not permitted

D-CSI field descriptions are given in Table 2-128.

Table 2-127 D-CSI data syntax


Active Boolean

Phase {CAP3}

UNSPVMSC {RELEASE, CONTINUE, CONT_HPLMN}

UNSPGMSC {RELEASE, CONTINUE}

Criteria Names vector (1 - 10) 1 - 20 characters 9 are Optional

Table 2-128 D-CSI field descriptions


Active indicates whether the CSI is active

Phase the CAMEL Phase which is required at the gsmSCF for the service -- this has to be datafilled as Phase 3 (‘CAP3’)

also know as the CAMEL Capability Handler (CCH)

UNSPVMSC behaviour if the VLR/MSC does not support Phase 3: release-call, continue-call or continue-call-if-in-HPLMN

UNSPGMSC behaviour if the GMSC does not support Phase 3: release-call or continue-call

Criteria Name(s) a criteria name, defined in system table GHLRDSCR



InteractionsD-CSI interacts with system table GHLRDCSR.

• each Criteria Name must be an entry from column DPCRNAME of system table GHLRDCSR



GPRS-CSI (General Packet Radio Service CSI) 2GPRS-CSI datafill defines trigger information that is required to invoke a CAMEL service for GPRS Sessions and PDP Contexts.

DatafillGPRS-CSI data syntax is detailed in Table 2-129. Each of the Trigger DP sets is optional, although at least one must be provisioned. The following intra-service interactions apply.

• at least one Trigger DP set must be provisioned

Table 2-129 GPRS-CSI data syntax (2 pages)


Active Boolean

Phase {CAP3}

UNSPSGSN {RELEASE, CONTINUE, CONT_HPLMN}

Trigger DP1 Set SCF Name 1 - 20 characters

Service Key number: 1 - 2147483647

SCF Unavailable Treatment

{RELEASE, CONTINUE}




{RELEASE, CONTINUE}




{RELEASE, CONTINUE}




{RELEASE, CONTINUE}



GPRS-CSI field descriptions are given in Table 2-130.




{RELEASE, CONTINUE}

Table 2-130 GPRS-CSI field descriptions (2 pages)





UNSPSGSN behaviour if the SGSN does not support Phase 3: release-call, continue-call or continue-call-if-in-HPLMN

Trigger DP1 Set SCF Name the DP SCF name, defined in system table GHLRSCF

Service Key the DP service key


the behaviour for this DP if the SCF is unavailable: release or continue the GPRS session/PDP context









Table 2-129 GPRS-CSI data syntax (2 pages)




InteractionsGPRS-CSI interacts with GPRS and system table GHLRSCF.

• GPRS must be provisioned for GPRS-CSI to be provisioned

• each SCF Name must be an entry from the SCF_NAME column of system table GHLRSCF









Table 2-130 GPRS-CSI field descriptions (2 pages)




M-CSI (Mobility Management CSI) 2M-CSI datafill defines which mobility events trigger a message to be sent to the GSM Service control Function (gsmSCF).

DatafillM-CSI data syntax is detailed in Table 2-131.

M-CSI field descriptions are given in Table 2-132.

InteractionsM-CSI interacts with system table GHMTRIG.

• the Mobility Trigger Name must be an entry from the MTNAME field of system table GHMTRIG

Table 2-131 M-CSI data syntax


Active Boolean

Mobility Trigger Name 1 - 20 characters

Suppress M-CSI {HC, HPLMN, INTL} Optional

Table 2-132 M-CSI field descriptions



Mobility Trigger Name the mobility trigger name, defined in system table GHMTRIG

Suppress M-CSI indicates when to suppress M-CSI: when located in HPLMN country, in HPLMN, or when international



O-CSI (Originating CSI) 2O-CSI datafill defines subscriber originating trigger information which is used by GSM nodes to determine when to contact the GSM Service Control Function (gsmSCF), which in turn decides how a call proceeds.

O-CSI datafill also encompasses TIF-CSI provisioning.

DatafillO-CSI data syntax is detailed in Table 2-133 on page 2-194. Each of the Trigger DP sets is optional, although at least one must be provisioned. TIF-CSI is provisioned via the FTN Checks dataitem. The following intra-service interactions apply.


• if FTN Checks is ‘CUSTOM’ then Active must be ‘TRUE’, UNSPVMSC must be ‘RELEASE’, UNSPGMSC must be ‘RELEASE’ and QSCFWIHP must be ‘TRUE’

• if FTN Checks is ‘TIF’ then Active must be ‘TRUE’, QSCFWIHP must be ‘TRUE’ and at least one of these sets must be provisioned: TDP2 Phase2, TDP2 Phase3, TDP4 Phase3

• for both the TDP2 Phase2 and TDP2 Phase3 sets: if DNC Matchtype is not datafilled, then no DNC DNs should be datafilled, and no DNC Lengths should be datafilled either

• for both the TDP2 Phase2 and TDP2 Phase3 sets: if DNC Matchtype is datafilled, then at least one DNC DN or one DNC Length must be datafilled (e.g. it is valid to have just one DNC DN, or just one DNC Length)

• DNC DNs (i.e. NOA + NPI + DN combined) must be unique per-subscriber (includes both vectors)

• DNC Lengths must be unique per-subscriber (includes both vectors)

• BS Codes Criteria must be unique per-subscriber (include both vectors)

• for BS Codes Criteria, if a BSG is datafilled then no BSs belonging to that BSG may also be datafilled

• Cause Values Criteria must be unique per-subscriber



Table 2-133 O-CSI data syntax (3 pages)


Active Boolean

FTN Checks {GSM, CUSTOM, TIF}

UNSPVMSC {RELEASE, CONTINUE, CONT_HPLMN}


QSCFWIHP Boolean

Trigger DP2 Phase1 Set

SCF Name 1 - 20 characters



{RELEASE, CONTINUE}

Send CCH Boolean







{RELEASE, CONTINUE}

DNC Matchtype {ENABLING, INHIBITING} Optional

DNC DNs vector (0 - 10)

composed of the three dataitems below All 10 are Optional

- NOA {INTL, UNKN} as above

- NPI {E164, E212, F69, NATL, PRIV, UNKN, X121} as above

- DN 1 - 15 characters (0..9, *, #, A, B, C) as above

DNC Lengths vector (0 - 3)

number: 1 - 15 All 3 are Optional

BS Codes Criteria vector (0 - 5)

{CDA, CDA300, CDA1200, CDA2400, CDA4800, CDA9600, CDAGBS, ALTSPCDA, SPCHCDA, CDS, CDS1200, CDS2400, CDS4800, CDS9600, CDSGBS, ALTSPCDS, SPCHCDS, SPCH, TPHNY, AUXSPCH, AUXTPHNY, FAX, FAX3, ALTSPFAX}

All 5 are Optional

Call Type Criteria {FWD, NOT_FWD} Optional









{RELEASE, CONTINUE}

DNC Matchtype {ENABLING, INHIBITING} Optional


composed of the three dataitems below All 10 are Optional

- NOA {ABBR, INTL, NATL, NTWK, SUBS, UNKN} as above

- NPI {E164, E212, F69, NATL, PRIV, UNKN, X121} as above

- DN 1 - 15 characters (0..9, *, #, A, B, C) as above





All 5 are Optional

Call Type Criteria {FWD, NOT_FWD} Optional





{RELEASE, CONTINUE}

Cause Values Criteria vector (0 - 5)






O-CSI field descriptions are given in Table 2-134.

Table 2-134 O-CSI field descriptions (3 pages)



FTN Checks whether the subscriber has GSM FTNs, TIF-CSI FTNs (aka TIF FTNs) or custom FTNs; relates to valid NOA/NPI formats. TIF-CSI is provisioned by setting this dataitem to ‘TIF’.

UNSPVMSC unsupported VLR/MSC behaviour: release-call, continue-call or continue-call-if-in-HPLMN

UNSPGMSC behaviour if the GMSC does not support the O-CSI phase: release-call or continue-call

QSCFWIHP indicates whether to query the SCF when in HPLMN


SCF Name the DP SCF name, defined in system table GHLRSCF



the behaviour for this DP if the SCF is unavailable: release or continue the call

Send CCH indicates whether to send the CCH (CAP1) to the VLR








DNC Matchtype indicates whether the Destination Number Criteria is enabling or inhibiting


destination-number-criteria destination numbers, each composed of NOA, NPI and DN

- NOA the DN Nature Of Address; options are International-number (INTL) and Unknown (UNKN)

- NPI the DN Number Plan Indicator; options are ISDN/telephony-numbering-plan (E164), Land-mobile-numbering-plan (E212), Telex-numbering-plan (F69), National-numbering-plan (NATL), Private-numbering-plan (PRIV), Unknown (UNKN), Data-numbering-plan (X121)

- DN the destination number itself


destination-number-criteria destination number lengths


basic service codes criteria

Call Type Criteria

indicates whether call type criteria is forwarding or not forwarding










DNC Matchtype indicates whether the Destination Number Criteria is enabling or inhibiting


destination-number-criteria destination numbers, each composed of NOA, NPI and DN

- NOA the DN Nature Of Address; options are Abbreviated-number (ABBR), International-number (INTL), National-significant-number (NATL), Network-specific-number (NTWK), Subscriber-number (SUBS), Unknown (UNKN)

- NPI the DN Number Plan Indicator; options are ISDN/telephony-numbering-plan (E164), Land-mobile-numbering-plan (E212), Telex-numbering-plan (F69), National-numbering-plan (NATL), Private-numbering-plan (PRIV), Unknown (UNKN), Data-numbering-plan (X121)

- DN the destination number itself


destination-number-criteria destination number lengths


basic service codes criteria

Call Type Criteria

indicates whether call type criteria is forwarding or not forwarding







cause values criteria





InteractionsO-CSI interacts with all call forwards (CFB, CFNRc, CFNRy, CFU) and system table GHLRSCF. Note that the vast majority of interactions relate (directly or indirectly) to TIF-CSI.

• O-CSI cannot be newly provisioned with FTN Checks as ‘CUSTOM’ if the subscriber has any call forward FTNs (i.e. any CF registration data)

• O-CSI cannot be newly provisioned with FTN Checks as ‘TIF’ if the subscriber has any call forward FTNs (i.e. any CF registration data)

• O-CSI cannot be deprovisioned if FTN Checks is ‘CUSTOM’ and the subscriber has any call forward FTNs (i.e. any CF registration data)

• O-CSI cannot be deprovisioned if FTN Checks is ‘TIF’ and the subscriber has any call forward FTNs (i.e. any CF registration data)

• O-CSI cannot be deprovisioned if the subscriber has any call forwards with a DCF ID datafilled

• FTN Checks cannot be changed if the subscriber has any call forward FTNs (i.e. any CF registration data)

• FTN Checks cannot be changed if the subscriber has any call forwards with a DCF ID datafilled




SMS-CSI (Short Message Service CSI) 2SMS-CSI datafill defines trigger information required to invoke CAMEL service logic for mobile originating short message (SMMO) submissions.

DatafillSMS-CSI data syntax is detailed in Table 2-135. As there is only one Trigger DP set (i.e. DP1), it must be provisioned. The intra-service validations therefore are:

• the Trigger DP1 Set must be provisioned

Table 2-135 SMS-CSI data syntax


Active Boolean

Phase {CAP3}

UNSPNODE {RELEASE, CONTINUE, CONT_HPLMN}




{RELEASE, CONTINUE}



SMS-CSI field descriptions are given in Table 2-136.

InteractionsSMS-CSI interacts with system table GHLRSCF.

• the SCF Name must be an entry from the SCF_NAME column of system table GHLRSCF

Table 2-136 SMS-CSI field descriptions





UNSPNODE behaviour if the VLR/MSC or SGSN does not support Phase 3: release-call, continue-call or continue-call-if-in-HPLMN




the behaviour for this DP if the SCF in unavailable: release or continue the GPRS session/PDP context



SS-CSI (Supplementary Service CSI) 2SS-CSI datafill defines supplementary service notification criteria.

DatafillSS-CSI data syntax is detailed in Table 2-137. The following intra-service validations apply.

• at least one of ECT Option and MPTY Option must be set to ‘TRUE’

SS-CSI field descriptions are given in Table 2-138.

InteractionsSS-CSI interacts with system table GHLRSCF.

• the SCF Name must be an entry from the SCF_NAME column of system table GHLRSCF

Table 2-137 SS-CSI data syntax


Active Boolean

ECT Option Boolean

MPTY Option Boolean


Table 2-138 SS-CSI field descriptions



ECT Option indicates whether notifications are sent for ECT

MPTY Option indicates whether notifications are sent for MPTY

SCF Name the SCF name, defined in system table GHLRSCF



T-CSI (Terminating CSI) 2T-CSI datafill defines subscriber terminating trigger information which is used by GSM nodes to determine when to contact the GSM Service Control Function (gsmSCF), which in turn decides how a call proceeds.

DatafillT-CSI data syntax is detailed in Table 2-139 on page 2-205. Each of the Trigger DP sets is optional, although at least one must be provisioned. The following intra-service validations apply.


• a particular BS Code can only be datafilled once across both the TDP12 Phase2 and Phase3 sets

• for each BS Codes vector, if a BSG code is datafilled then a BS belonging to that BSG cannot also be datafilled

• a particular Cause Value can only be datafilled once across both the TDP13 and TDP14 sets

Note that in the original Nortel HLR O-CSI/T-CSI implementation, QSCFWIHP was shared between these two services, whereas now it is seen as being specific to O-CSI. Also note that the Nortel HLR shares the UNSPGMSC across both T-CSI and O-CSI (i.e. there is a single value, used by both T-CSI and O-CSI).



.

Table 2-139 T-CSI data syntax (2 pages)


Active Boolean

Provide Location Info Boolean

Page for Cell ID Boolean

Provide Subscriber State Boolean

Provide Current Location Boolean

Suppress T-CSI {HC, HPLMN} Optional






{RELEASE, CONTINUE}

Send CCH Boolean





{RELEASE, CONTINUE}



All 5 are Optional







{RELEASE, CONTINUE}



All 5 are Optional





{RELEASE, CONTINUE}







{RELEASE, CONTINUE}



Table 2-139 T-CSI data syntax (2 pages)




T-CSI field descriptions are given in Table 2-140.

Table 2-140 T-CSI field descriptions (2 pages)



Provide Location Info indicates whether provide location info is in effect

Page for Cell ID indicates whether page for cell ID is in effect

Provide Subscriber State indicates whether provide subscriber state is in effect

Provide Current Location indicates whether provide current location is in effect

Suppress T-CSI indicates when T-CSI is to be suppressed: when-located-in-HPLMN-country or when-located-in-HPLMN

UNSPGMSC behaviour if the GMSC does not support the T-CSI phase: release-call or continue-call






Send CCH indicates whether to send the CCH (CAP1) to the VLR







basic service [group] codes criteria







basic service [group] codes criteria



InteractionsT-CSI interacts with system table GHLRSCF.
















Table 2-140 T-CSI field descriptions (2 pages)




TIF-CSI (Translations Information Flag CSI) 2TIF-CSI datafill defines that the usual GSM (conformity to E164) number checks on forwarding-to numbers are suppressed.

The Nortel HLR implements TIF-CSI as a dataitem of O-CSI (FTN Checks). Please refer to “O-CSI (Originating CSI)”on page 2-193.



USSD-CSI (Unstructured Supplementary Service Data CSI) 2USSD-CSI datafill defines how the PUSSR (Process Unstructured Supplementary Service Request) message is handled.

DatafillUSSD-CSI data syntax is detailed in Table 2-141. The IDs are a vector; at least one ID must be datafilled (see“Data vectors” on page 1-36 for more information on vectors). The following intra-service validations apply.

• duplicate IDs are not permitted

USSD-CSI field descriptions are given in Table 2-142.

InteractionsUSSD-CSI interacts with system table GHLRUSSD.

• each ID must be an entry from the USSD_STR.UCSI_ID field of system table GHLRUSSD; also each ID must be from a different USSD_STR from system table GHLRUSSD (note that each USSD_STR can multiple UCSI_IDs)

Table 2-141 USSD-CSI data syntax


IDs vector (1 - 10) 1 - 10 characters 9 are Optional

Table 2-142 USSD-CSI field descriptions


ID an ID, defined in system table GHLRUSSD



Location Services (LCS) Introduction 2Location services provide value-added, vicinity-specific services to the subscriber. They are composed of four privacy classes and three mobile originating (MO) classes, as given in Table 2-143. Privacy classes indicate what type of clients are allowed to make location requests. MO classes indicate whether/how the subscriber can make MO location requests. Each privacy/MO class is treated as a distinct service. LCS datafill is supplemented by a list of Gateway Mobile Location Centres (GMLCs); they are treated as a separate profile component -- see “LCS GMLCs” on page 2-218.

Table 2-143 Location Services classes

Class Type See Section

Autonomous Self Location MO on page 2-212

Basic Self Location MO on page 2-213

Call Related Privacy on page 2-214

Call Unrelated Privacy on page 2-216

PLMN Operator Privacy on page 2-219

Transfer to Third Party MO on page 2-221

Universal Privacy on page 2-222



LCS Autonomous Self Location 2LCS Autonomous Self Location class specifies that the subscriber does not need interact with the network for each location request. A single interaction enables the subscriber to obtain multiple location positionings during a predetermined period of time.

DatafillLCS Autonomous Self Location data syntax is detailed in Table 2-144.

LCS Autonomous Self Location field descriptions are given in Table 2-145.

InteractionsNone

Table 2-144 LCS Autonomous Self Location data syntax


Active Boolean

Table 2-145 LCS Autonomous Self Location field descriptions


Active whether this class is active



LCS Basic Self Location 2LCS Basic Self Location class specifies that the subscriber needs to interact with the network for each location request.

DatafillLCS Basic Self Location data syntax is detailed in Table 2-146.

LCS Basic Self Location field descriptions are given in Table 2-147.

InteractionsNone

Table 2-146 LCS Basic Self Location data syntax


Active Boolean

Table 2-147 LCS Basic Self Location field descriptions





LCS Call Related 2LCS Call Related class allows an LCS client to request the subscriber’s location if the subscriber originated a call to the client and the call is still established.

DatafillLCS Call Related data syntax is detailed in Table 2-148. There are two external client name vectors (see “Data vectors” on page 1-36 for more information on vectors). The following intra-service validations apply.

• duplicate external client names are not permitted (names from both vectors are pooled together for this check)

LCS Call Related field descriptions are given in Table 2-149.

Table 2-148 LCS Call Related data syntax


Active Boolean

Notification To User {LOC_NOT_ALLOW, LOC_ALLOW_WITHOUT_NOTIF, LOC_ALLOW_WITH_NOTIF, NOTIF_PRVCY_LOC_IF_NO_RSP, NOTIF_PRVCY_LOC_REST_IF_NO_RSP}

External Client Names vector (0 - 5)

1 - 8 characters All 5 are Optional

Extended External Client Names vector (0 - 35)


Table 2-149 LCS Call Related field descriptions



Notification To User the notification to the user

External Client Name external client name, defined in system table GHLRR4EC

Extended External Client Name

external client name, defined in system table GHLRR4EC

(the term ‘extended’ is simply used to identify a separate vector of names)



InteractionsLCS Call Related interacts with GMLCs and LCS Call Unrelated.

• GMLCs can only be provisioned if at least one of LCS Call Related/LCS Call Unrelated is also provisioned



LCS Call Unrelated 2LCS Call Unrelated class allows LCS client to be defined that are able to request the subscriber’s location.

DatafillLCS Call Unrelated data syntax is detailed in Table 2-150. There are two external client name vectors (see “Data vectors” on page 1-36 for more information on vectors). The following intra-service validations apply.

• duplicate external client names are not permitted (names from both vectors are pooled together for this check)

LCS Call Unrelated field descriptions are given in Table 2-151.

Table 2-150 LCS Call Unrelated data syntax


Active Boolean

Notification To User {LOC_NOT_ALLOW, LOC_ALLOW_WITH_NOTIF, NOTIF_PRVCY_LOC_IF_NO_RSP, NOTIF_PRVCY_LOC_REST_IF_NO_RSP}

External Client Names vector (0 - 5)


Extended External Client Names vector (0 - 35)


Table 2-151 LCS Call Unrelated field descriptions



Notification To User the notification to the user

External Client Name external client name, defined in system table GHLRLSEC

Extended External Client Name

external client name, defined in system table GHLRR4EC

(the term ‘extended’ is simply used to identify a separate vector of names)



InteractionsLCS Call Related interacts with GMLCs and LCS Call Related.




LCS GMLCs 2The GMLCs component gives the Gateway Mobile Location Centres used by LCS Call Related and LCS Call Unrelated.

DatafillLCS GMLCs data syntax is detailed in Table 2-152. The GMLC Names are a vector (see “Data vectors” on page 1-36 for more information on vectors). The following intra-service validations apply.

• at least one GLMC Name must be datafilled

• duplicate GLMC Names are not permitted

LCS GMLCs field descriptions are given in Table 2-153.

InteractionsLCS GMLCs interacts with LCS Call Related and LCS Call Unrelated.


Table 2-152 LCS GMLCs data syntax


GMLC Names vector (1 - 5) 1 - 20 characters 4 Are Optional

Table 2-153 LCS GMLCs field descriptions


GMLC Name a gateway mobile location centre name, an entry from system table GHLRGMLC



LCS PLMN Operator 2LCS PLMN Operator class allows positioning by specific types of clients indicated in the subscriber's privacy profile.

DatafillLCS PLMN Operator data syntax is detailed in Table 2-154. The following dataitems are known as Internal Client IDs (ICIDs): Broadcast, OMH, OMV, Anonymous, Target MS. The following intra-service validations apply.

• at least one of the ICIDs must be true: Broadcast, OMH, OMV, Anonymous, Target MS

Table 2-154 LCS PLMN Operator data syntax


Active Boolean

Broadcast Boolean

OMH Boolean

OMV Boolean

Anonymous Boolean

Target MS Boolean



LCS PLMN Operator field descriptions are given in Table 2-155.

InteractionsNone

Table 2-155 LCS PLMN Operator field descriptions



Broadcast indicates whether an LCS client broadcasting location related information is allowed to locate the MS

OMH indicates whether an O&M LCS client in the HPLMN is allowed to locate the MS

OMV indicates whether an O&M LCS client in the VPLMN is allowed to locate the MS

Anonymous indicates whether an LCS client recording anonymous location information is allowed to locate the MS

Target MS indicates whether an LCS client supporting a bearer service, teleservice or supplementary service to target the MS is allowed to locate the MS



LCS Transfer to Third Party 2LCS Transfer to Third Party class specifies that the subscriber’s location is transferred to another LCS client.

DatafillLCS Transfer to Third Party data syntax is detailed in Table 2-156.

LCS Transfer to Third Party field descriptions are given in Table 2-157.

InteractionsNone

Table 2-156 LCS Transfer to Third Party data syntax


Active Boolean

Table 2-157 LCS Transfer to Third Party field descriptions





LCS Universal 2LCS Universal class allows all LCS clients to request the subscriber’s location.

DatafillLCS Universal data syntax is detailed in Table 2-158.

LCS Universal field descriptions are given in Table 2-159.

InteractionsNone

Table 2-158 LCS Universal data syntax


Active Boolean

Table 2-159 LCS Universal field descriptions





GPRS (General Packet Radio Service) 2Provisioning GPRS makes the subscriber a GPRS network subscriber. GPRS datafill allows PDP context IDs to be specified for the subscriber.

DatafillGPRS data syntax is detailed in Table 2-160. Each of the Context ID sets is optional.

Table 2-160 GPRS data syntax (2 pages)


Context ID1 Set PDP Name 1 - 16 characters

PDP Static Address 1 - 63 characters (0..9, dot) Optional









































Table 2-160 GPRS data syntax (2 pages)




GPRS field descriptions are given in Table 2-161.

Table 2-161 GPRS field descriptions (3 pages)


Context ID1 Set PDP Name PDP name for this context ID, defined in system table GHLRPDP

PDP Static Address PDP static address for this context ID, may be IPv4, IPv6 or X25 format

















































InteractionsGPRS interacts with Auth data, GPRS-CSI and system tables GHLRPDP and GHLRALG.

• GPRS must be provisioned for GPRS-CSI to be provisioned

• for each Static Address datafilled, their format is checked against the PDP type. PDP type is determined by lookup of the PDP Name in system table GHLRPDP, and checking the PDPTYPE (FORMAT) field.

— for IPv4 types, address must be of format “x.x.x.x” where ‘x’ is (0-255)

— for IPv6 types, address must be of format “x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x” where each of the 16 ‘x’s is (0-255)

— for X25 types, address must be 1 - 14 digits

— for PPP types, address must not be datafilled

• if the subscriber is 3G then all PDP Names must have ExtQoS

— determination of 2G/3G requires Auth data and system table GHLRALG -- see “Determination of 2G/3G algorithm” on page 2-43

— determination of PDP ExtQoS requires lookup of the PDP Name in system table GHLRPDP, and checking whether the EXTQOS field is null or datafilled



Other Services introduction 2Other Services are those that do not fit within the following categories: basic services, supplementary services, CAMEL service, Location Services, GPRS. A list of these services is given in Table 2-162.

Table 2-162 Other Services


CLIN Calling Line Identification Replacement Number on page 2-230

EA Equal Access on page 2-231

Proprietary IN Proprietary Intelligent Network service on page 2-232



CLIN (Calling Line Identification Replacement Number) 2Provisioning CLIN enables CLI Replacement Number functionality for the subscriber (CLIN allows an alternative number to be used for TPHNY’s CLI, i.e. not TPHNY’s actual MSISDN). Note that CLIN service is distinct, and quite different from the common use of the word CLIN as calling line ID number. CLIN is a Nortel proprietary service.

DatafillCLIN data syntax is detailed in Table 2-163.

CLIN field descriptions are given in Table 2-164.

InteractionsCLIN interacts with TPHNY.

• TPHNY must be provisioned for CLIN to be provisioned

Table 2-163 CLIN data syntax


CLI 1 - 15 digits

Table 2-164 CLIN field descriptions


CLI the replacement calling line identity for telephony



EA (Equal Access) 2EA datafill allows a primary interexchange carrier to be given to the subscriber. EA is a Nortel proprietary service.

DatafillEA data syntax is detailed in Table 2-165.

EA field descriptions are given in Table 2-166.

InteractionsNone

Table 2-165 EA data syntax


PIC 4 digits

Table 2-166 EA field descriptions


PIC Primary Interexchange Carrier



Proprietary IN (Proprietary Intelligent Network service) 2This service provides Nortel proprietary IN, allowing an IN platform to be specified for both originating and terminating calls.

DatafillProprietary IN data syntax is detailed in Table 2-167.

Proprietary IN field descriptions are given in Table 2-168.

InteractionsNone

Table 2-167 Proprietary IN data syntax


INORIG number: 0 - 1023 Optional

INTERM number: 0 - 1023 Optional

Table 2-168 Proprietary IN field descriptions


INORIG IN index for IN platform originating calls

INTERM IN index for IN platform terminating calls



Other components introduction 2The concept of other components is introduced in Chapter 1. A list of these components is given in Table 2-169.

Table 2-169 Other Components


HST Home Subscriber Trace on page 2-234

SIMR SIM Replacement on page 2-235



HST (Home Subscriber Trace) 2Home Subscriber Trace (HST) is used to track subscribers within the HPLMN.

DatafillHST data syntax is detailed in Table 2-170. The following intra-service validations apply.

• none of the dataitems can be changed once provisioned (it is possible to deprovision HST, however)

HST field descriptions are given in Table 2-171.

InteractionsNone

HLR-wide interactions• a maximum of 1024 subscribers may be provisioned with HST at any one

time

Table 2-170 HST data syntax


Trace Reference number: 0 - 65535

OMC Destination 0 - 38 digits (0..9)

Trace Type number: 0 - 255

Table 2-171 HST field descriptions


Trace Reference trace reference (used as an identifier)

OMC Destination Operator Maintenance Centre Destination address

Trace Type identifies the trace type



SIMR (SIM Replacement) 2A SIM Replacement (SIMR) entry is used to set up a relationship between two IMSIs, whereby one IMSI will replace an old IMSI at a certain date. The Nortel HLR specifies that the New IMSI must exist in the database, thereby placing restrictions on the New IMSI’s profile.

It is strongly recommended that the SIMR documentation is used to set up SIMR relationships; the information here is provided as a guide only.

DatafillSIMR data syntax is detailed in Table 2-172. The following intra-service validations apply.

• the New IMSI must be present in the database

• the Old IMSI must be present in the database (this is the subscriber’s current profile)

• the New IMSI and Old IMSI must be different

• Activation Date must not be datafilled if Option is ‘FIXED’

• Activation Date must be datafilled if Option is ‘USER’

• if datafilled, the Activation Date must be before the Invocation Date

Table 2-172 SIMR data syntax


New IMSI 6 - 15 digits

Old IMSI 6 - 15 digits

Option {FIXED, USER}

Invocation Date Date (nearest hour)

Activation Date Date (nearest hour) Optional



SIMR field descriptions are given in Table 2-173.

InteractionsAs the Nortel HLR requires the New IMSI to be present in the database, the following restrictions have to be made to the New IMSI profile:

• the IMSI Status must not be ‘ACTIVATED’

• if the IMSI Status is ‘DEACTIVATED’ all profile control data must be set to their defaults (see “Profile control data introduction” on page 2-44)

• no services can be provisioned

• HST cannot be provisioned

• there are several interactions with mated-pair: the New IMSI must not be SIMR blocked, the acting status for both Old IMSI and New IMSI must match, the maintenance blocked status for Old IMSI and New IMSI must match and partition numbers for Old IMSI and New IMSI must match and not be equal zero

The following requires a check on the Old IMSI.

• if the New IMSI is 3G (see “Determination of 2G/3G algorithm” on page 2-43) then the Old IMSIs GPRS PDPs (if any) must all have ExtQoS (see “Interactions” on page 2-228)

Table 2-173 SIMR field descriptions


New IMSI the new International Mobile Subscriber Identity, the replacement IMSI for the subscriber

Old IMSI the old International Mobile Subscriber Identity, the current IMSI for the subscriber

Option how the swapover will occur; fixed option swaps IMSIs on a (fixed) invocation date; the user option swaps IMSIs on activation of the new IMSI (via using new SIM), or on the invocation date if activation has not yet occurred

Invocation Date the time the swapover will occur (for user option, this only applies if there was not an update location for the new SIM/IMSI)

Activation Date the time from which a subscriber may use its new SIM (and hence an update location will trigger a SIMR swap)



HLR-wide interactions• a maximum of 10,000 SIMR relationships may be set up at any one time

• the New IMSI cannot be defined as an Old IMSI in an existing SIMR relationship

• the Old IMSI cannot be defined as an Old IMSI or New IMSI in an existing SIMR relationship





Chapter 3: Suppression States 3Each BSG registration set of each BSG-Supplementary Service has a suppression state. These states are used in conjunction with registration and activation states within the network. Suppression states are not part of the subscriber profile and are given here as extra information.

Each time a BSG registration set is added or updated, its suppression state must be recalculated -- this may involve interactions with several other services. Note that a suppression state is only applicable to activated registration sets. The following supplementary services have suppression states: BICRoam, CFB, CFNRc, CFNRy and EXT.

Some ODBs also have a single suppression state, although this is sometimes called an “activation” state. Those ODBs are ODB BICRoam, ODB BAOCRoam and ODB HPLMN Specific categories.

Suppression state determination is given for each service in their own subsection; Figure 3-1 is a diagram of all suppression interactions.


3-240 Chapter 3: Suppression StatesNortel Confidential Copyright © 1996–2005 Nortel

Figure 3-1 Service suppressions

CCFs EXTCFU

ODB-BOIC[exHC]ODB-HPLMNSpec

ODB-PremRate ODB-BAOC ODB-BAIC

ODB-BICRoam

BOIC[exHC]

ODB-BAOCRoamBICRoam

In HPLMN Country

Outside HPLMN

2

1 1 1 1

1

KEY

Only applies if thesuppressing serviceis not suppressed

2 Only applies ifODB-HPLMNSpecis not suppressed


Chapter 3: Suppression States 3-241Nortel Confidential Copyright © 1996–2005 Nortel

BICRoam suppression state determination 3BICRoam suppression state determination is detailed in Table 3-1..

CFB suppression state determination 3CFB suppression state determination is detailed in Table 3-2..

Table 3-1 Determine BICRoam registration set suppression

Suppressed By Conditions

Service State

Subscriber Location

N/A location is in HPLMN Country

CFU Activated and not Suppressed

none

Table 3-2 Determine CFB registration set suppression (2 pages)


Service State

CFU Activated none (always suppressed)

BOIC Activated has GSM-FTNs and FTN is international wrt current location

BOICexHC Activated has GSM-FTNs and FTN is not in HPLMN and is international wrt current location

BICRoam Activated & Not Suppressed

does not have TIF-FTNs

ODB BAIC Provisioned does not have TIF-FTNs

ODB BICRoam Provisioned & Activated


ODB BAOC Provisioned does not have TIF-FTNs

ODB BOIC Provisioned has GSM-FTNs and FTN is international wrt current location

ODB BOICexHC Provisioned has GSM-FTNs and FTN is not in HPLMN and is international wrt current location



CFNRc suppression state determination 3CFNRc suppression state determination is identical for that of CFB -- please refer to Table 3-2.

CFNRy suppression state determination 3CFNRy suppression state determination is identical for that of CFB -- please refer to Table 3-2.

ODB BAOCRoam Provisioned & Not Suppressed


ODB Prem Rate categories Provisioned has GSM-FTNs and FTN is barred for the category in system table GHLRODB

ODB HPLMN Specific categories Provisioned & Not Suppressed

has GSM-FTNs and FTN is barred for the category in system table GHLRODB

Table 3-2 Determine CFB registration set suppression (2 pages)


Service State



CFU suppression state determination 3CFU suppression state determination is detailed in Table 3-3..

Table 3-3 Determine CFU registration set suppression


Service State

ODB BAOC Provisioned does not have TIF-FTNs

ODB BOIC Provisioned has GSM-FTNs and FTN is international wrt HPLMN Country

ODB BOICexHC Provisioned has GSM-FTNs and FTN is international wrt HPLMN Country

ODB BAIC Provisioned does not have TIF-FTNs

ODB Prem Rate categories Provisioned has GSM-FTNs and FTN is barred for the category in system table GHLRODB


Provisioned has GSM-FTNs and FTN is barred for the category in system table GHLRODB



EXT suppression state determination 3EXT suppression state determination is detailed in Table 3-4. EXT is a special case in that every MSISDN has a suppression state, rather than each registration set.

ODB BICRoam suppression state determination 3ODB BICRoam suppression state determination is detailed in Table 3-5. Note that ODB suppression states may also be called an activation state; therefore “not suppressed” is equivalent to “activated”.

Table 3-4 Determine EXT MSISDN suppression


Service State

ODB BAOC Provisioned all MSISDNs except Pilot MSISDNs are suppressed only if office parameter EXTODBON (GHLRPARM) is true

ODB BOIC Provisioned MSISDNs international wrt HPLMN Country are suppressed (note that Pilot MSISDNs will never be suppressed because they are in HPLMN)

ODB BOICexHC Provisioned MSISDNs international wrt HPLMN Country are suppressed (note that Pilot MSISDNs will never be suppressed because they are in HPLMN)

ODB BAIC Provisioned all MSISDNs are suppressed

ODB Prem Rate categories Provisioned MSISDNs that are barred for ODB Prem Rate are suppressed (using system table GHLRODB)


Provisioned MSISDNs that are barred for ODB HPLMN Specific are suppressed (using system table GHLRODB)

Table 3-5 Determine ODB BICRoam suppression


Service State

Subscriber Location N/A location is in HPLMN Country



ODB BAOCRoam suppression state determination 3ODB BAOCRoam suppression state determination is detailed in Table 3-6. Note that ODB suppression states may also be called an activation state; therefore “not suppressed” is equivalent to “activated”.

ODB HPLMN specific sategories suppression state determination 3ODB HPLMN Specific categories suppression state determination is detailed in Table 3-7. Note that ODB suppression states may also be called an activation state; therefore “not suppressed” is equivalent to “activated”.

Table 3-6 Determine ODB BAOCRoam suppression


Service State

Subscriber Location N/A location is in HPLMN Country

Table 3-7 Determine ODB HPLMN specific categories suppression

Suppressed by Conditions

Service State

Subscriber Location N/A location outside HPLMN



3


A-247Nortel Confidential Copyright © 1996–2005 Nortel

Appendix A: Oracle implementation AThe subscriber data schema comprises 40 tables and stores authentication data, profile control data, services data and SIMR data. The schema is a logical database composed of Oracle views, based on the actual physical tables. This document uses the term “table” when referring to the views. The schema tables are listed in Table A-4 on page A-252, and presented in a diagram in Figure A-1 on page A-255. Note that the routing schema is described later in “Routing Schema” on page A-343.

Most tables store just one particular service, and are named sub_<service>. Other tables store more than one service, while some services are actually datafilled across more than one table. Exceptions to the sub_<service> format are as follows:

• Three tables store more than one service. Table sub_odbs stores all ODBs. Table sub_basic_services stores all basic services. Table sub_imsi_ss stores all IMSI-SSs

• Three services are split across more than one table. CUG is datafilled in table sub_cug_subscription and table sub_cug_feature. GPRS is datafilled in table sub_gprs_prov and sub_gprs_pdps. LCS can be seen as one service, or a collection of services; it is datafilled in six tables all prefixed with sub_lcs_

Profile control data, along with some service data is grouped into one table, sub_general.

Datatypes in OracleThe subscriber profile database is composed of a finite number of datatypes. They are listed in Table A-1 below, including their mapping to Oracle types. Note that the “x” values indicate the maximum length of the particular string/enum/number. A discussion of datatypes in the data model is given in “Datatypes” on page 1-36.


A-248 Appendix A: Oracle implementationNortel Confidential Copyright © 1996–2005 Nortel

Dataitem syntax is described in the data model section of this document (see “Chapter 2: Component descriptions”). The schema description in the following sections gives the Oracle types for each dataitem (i.e. column). Note that strings and enum options are always stored in uppercase, as are booleans (‘TRUE’ and ‘FALSE’). Time dataitems can be to the nearest day or hour and hence have two format types.

Vectors in OracleOne column is assigned to each possible value, with a number appended to the column name to distinguish the different columns. For example, a nodes vector of one to four elements is represented by columns node1, node2, node3 and node4. The number is simply there to distinguish the columns, it has no other meaning as vectors are not ordered.

As elements are datafilled, they use up positions in numerical order (i.e. 1 first, then 2, then 3 and finally 4). If an element is removed, then the elements “after” that element shift down one position. See Table A-2 on page A-249 for an example of how this works. The initial state shows the vector as not being datafilled. If two elements are added in the same transaction then there is no guarantee of the order in which they are datafilled. It is not possible to provision an element at an explicit position.

Table A-1 Datatypes and their Oracle implementation

Data Model Definition Oracle Schema Definition

Datatype Format Oracle Type Syntax

Number m - n range number(x) number: m - n

String m - n characters varchar2(x) m - n characters (what chars)

Digit String m - n digits varchar2(x) m - n digits

Hex Digit String m digits varchar2(x) m hex digits

Enum {a, b, c, ..., z} varchar2(x) enum: A, B, C, Z

Boolean {true, false} varchar2(5) boolean

Time to nearest second or hour varchar2(20)

varchar2(17)

DD-Mon-YYYY 24HH:MM:SS

DD-Mon-YYYY 24HH:MM


Appendix A: Oracle implementation A-249Nortel Confidential Copyright © 1996–2005 Nortel

A small number of vectors are complex vectors, i.e. the elements are actually structures, which themselves contain two or more elements. An example of such a vector is given in Table A-3. The vector has 1 - 3 structures, with each structure being composed of elements colour and style.

A discussion of vectors in the data model is given in “Data vectors” on page 1-36.

Table A-2 Datafilling vectors example

Column Name Initial State Add ‘A’ Add ‘B’ Add ‘C’ Remove ‘A’ Remove ‘C’

node1 null A A A B B

node2 null null B B C null

node3 null null null C null null

node4 null null null null null null

Table A-3 Complex vector example

Column Name

colour1

style1

colour2

style2

colour3

style3



Sets in OracleAll sets are named, and such names are used to qualify column names belonging to a particular set. For example, a set may be named Code A, and have dataitems activated and option. The column names would be codeA_activated and codeA_option.

An additional boolean column is used to indicate whether the set is provisioned or not. It is named <setname>_prov or <setname>_reg. The _reg naming convention is used for services that have registration data (as named by GSM specifications); the _prov convention is used for all other sets. If a set-provisioned column is set to ‘FALSE’, then the set dataitems will always be all set to null.

Sets are introduced in this document in Chapter 1, “Data sets” on page 1-20.



Section StructureA schema guide is presented in “Guide to table sections” on page A-256. A sample table section is given with explanations. There is also an overview of the datatypes used in the subscriber database.

Tables are described in detail starting on page A-258. The order of tables is given below.

• Authentication Data

• General Data

• ODBs

• Basic Services

• Supplementary Services

— Barrings

– Incoming (alphabetical)

– Outgoing (alphabetical)

— Call Forwards (alphabetical)

— Other BSG-SSs (alphabetical)

— IMSI-SSs

• CAMEL Services (alphabetical)

• CLIN

• EA

• GPRS

• LCS

• GSMR Basic Services

• SIMR



Schema tables listing and diagramSubscriber profile data schema tables are listed in Table A-4. Indications of any changes in the current release, brief descriptions and page number references are given. Note that in NSS18 all tables are marked as “New”; this is because they are new to the Oracle subscriber schema, rather than being new tables to the HLR. A diagram of the schema is given in Figure A-1 on page A-255. Services that span multiple tables are indicated.

Table A-4 Subscriber data schema tables (3 pages)

Table Name New/Changed/Deleted

Description See Section

sub_auth New mandatory table storing authentication data

on page A-258

sub_general New mandatory table storing general data

on page A-259

sub_odbs New stores ODB provisioning statuses on page A-262

sub_basic_services New stores all basic service data on page A-264

sub_baic New stores BAIC data on page A-265

sub_baoc New stores BAOC data on page A-267

sub_bicroam New stores BICRoam data on page A-269

sub_boic New stores BOIC data on page A-271

sub_boicexhc New stores BOICexHC data on page A-273

sub_cfb New stores CFB data on page A-275

sub_cfnrc New stores CFNRc data on page A-277

sub_cfnry New stores CFNRy data on page A-279

sub_cfu New stores CFU data on page A-281

sub_cos New stores COS data on page A-283

sub_cug_feature New stores CUG feature data on page A-285

sub_cug_subscription New stores CUG subscription data on page A-287

sub_cw New stores CW data on page A-289

sub_ext New stores EXT data on page A-291



sub_imsi_ss New stores all IMSI-SS data on page A-294

sub_dcsi New stores D-CSI data on page A-297

sub_gprs_csi New stores GPRS-CSI data on page A-299

sub_mcsi New stores M-CSI data on page A-301

sub_ocsi New stores O-CSI data on page A-302

sub_sms_csi New stores SMS-CSI data on page A-309

sub_ss_csi New stores SS-CSI data on page A-310

sub_tcsi New stores T-CSI data on page A-311

sub_ussd_csi New stores USSD-CSI data on page A-315

sub_clin New stores CLIN data on page A-317

sub_ea New stores EA data on page A-318

sub_gprs_prov New stores GPRS provisioning indications

on page A-319

sub_gprs_pdps New stores GPRS data on page A-320

sub_lcs_call_related New stores LCS call related privacy class data

on page A-321

sub_lcs_call_unrelated New stores LCS call unrelated privacy class data

on page A-324

sub_lcs_gmlcs New stores LCS GMLCs on page A-327

sub_lcs_mobile_originating New stores LCS mobile originating data on page A-329

sub_lcs_plmn_operator New stores LCS PLMN operator privacy class data

on page A-331

sub_lcs_universal New stores LCS universal privacy class data

on page A-333

sub_vbs New stores VBS data on page A-334

sub_vgcs New stores VGCS data on page A-339






sub_simr New stores SIMR relationships data on page A-342






Figure A-1 Oracle Schema diagram

SUB_AUTH

SUB_GENERAL

SUB_CUG_SUBSCRIPTION

SUB_CUG_FEATURE

SUB_DCSI

SUB_GPRS_CSI

SUB_MCSI

SUB_OCSI

SUB_SMS_CSI

SUB_SS_CSI

SUB_TCSI

SUB_USSD_CSI

SUB_VBS

SUB_VGCS

SUB_CLIN

SUB_EA

SUB_SIMR

SUB_ODBS

SUB_BASIC_SERVICES

SUB_BAIC

SUB_BAOC

SUB_BICROAM

SUB_BOIC

SUB_BOICEXHC

SUB_CFB

SUB_CFNRC

SUB_CFNRY

SUB_CFU

SUB_GPRS_PROV

SUB_GPRS_PDPS

SUB_LCS_UNIVERSAL

SUB_LCS_CALL_RELATED

SUB_COS

SUB_CW

SUB_EXT

SUB_LCS_CALL_UNRELATED

SUB_LCS_PLMN_OPERATOR

SUB_LCS_GMLCS

SUB_LCS_MOBILE_ORIGINATING

B

E

D

C

B

C

A

Supplementary Services

Auth data, General data, ODBs

Basic Services

A

SUB_IMSI_SS

D CAMEL Services

E Other Services



Guide to table sectionsCase conventions used in this document are outlined in “Case conventions” below. An example table section with help is given in “Table EXAMPLE_TAB” on page A-257. The schema tables are each presented in their own section starting on page A-258.

Case conventionsThe table names and column names in Oracle are case-insensitive. This document uses the following conventions for these names, primarily to aid readability. Names are presented in either all uppercase or all lowercase, and never a mix of the two. Note that Oracle internally stores all names as uppercase (this affects SQL select statements for instance).

Table names in headings and paragraphs are all uppercase (SUB_GENERAL), in tables they are bold italic lowercase (sub_general).

Column names in paragraph text are italic lowercase (imsi_status), in tables they are either lowercase (imsi_status) or all uppercase (IMSI_STATUS).

System table names in paragraph text are bold small uppercase (GHLRDCFB), while system table column names in paragraph text are small uppercase (DCFID).



Table EXAMPLE_TABAn introductory paragraph (or two) gives a brief description of the table, indicating what services the table stores.

Information tables (see Table A-5 for an example) contain general information about the table, such as number of columns, rows per subscriber and primary key.

Field details tables (see Table A-6 for an example) show all column (i.e. field/dataitem) names, with their Oracle type and constraints. Two examples are also given. Note that some tables can have multiple rows per subscriber, but the examples are obviously limited to showing a single row each.

Table A-5 Table EXAMPLE_TAB information

Number of Columns the total number of columns in the table, including key columns

Rows per Subscriber the range for the number of rows any one subscriber may have, and whether they are mandatory or optional

Primary Key the primary key column(s)

Foreign Keys foreign key columns and what tables/columns they refer to

Indexes the indexes on this table

Also See Table(s) used when a service spans multiple tables; lists the other tables

Table A-6 Table EXAMPLE_TAB field details

Column Name Oracle Type Constraints Example 1 Example 2

column_a (this is the primary key - identified by the grey background; the primary key may be composed of multiple columns)

the Oracle type for this column, examples are varchar2(x), number(x) and date; x indicates the max number of digits/chars

Oracle constraints, example is "not null", which means the column must be datafilled

Example datafill

Alternative set of example datafill

column_b etc. etc. etc. etc.

column_c etc. etc. etc. etc.

column_d etc. etc. etc. etc.



Table SUB_AUTHThis table stores authentication data for both 2G and 3G subscribers. This is the primary subscriber table and denotes a subscriber’s existence. A row in this table is mandatory for all subscribers. General table information is given in Table A-7.

Field details for SUB_AUTH are given in Table A-8, along with example values. Field descriptions and validations are given in Chapter 2, “Authentication data” on page 2-41.

Table A-7 Table SUB_AUTH information

Number of Columns 3

Rows per Subscriber One Mandatory

Primary Key IMSI

Foreign Keys None

Indexes IMSI

Also See Table(s) None

Table A-8 Table SUB_AUTH field details


imsi varchar2(15) not null 456231234567890 234109920024844

algorithm number(3) not null 2 101

opc varchar2(32) null 11AB11E111CD21231E111544141132A1



Table SUB_GENERALThis table stores miscellaneous provisioning data, such as profile control data and timestamps. A row in this table is mandatory for all subscribers. General table information is given in Table A-9.

Field details for SUB_GENERAL are given in Table A-10 on page A-260, along with example values. Field descriptions and validations are given in the following sections:

• imsi_status, cust_group and ncos, “IMSI Status” on page 2-49

• roaming_ent, “Roaming Entitlement” on page 2-54

• category, “Category” on page 2-46

• bicctrl, bocctrl, “Barring control” on page 2-45

• password, “Password” on page 2-53

• inorig, interm, “Proprietary IN (Proprietary Intelligent Network service)” on page 2-232

• soa_prov, “SOAPROV” on page 2-55

• nam, “NAM (Network Access Mode)” on page 2-52

• lmu, “LMU (Location Measurement Unit)” on page 2-51

The hlr_id indicates the HLR Core the subscriber resides on (see “Table HLRS” on page A-343). Column network_active indicates whether the subscriber has had its first network activity.

Table A-9 Table SUB_GENERAL information

Number of Columns 20


Primary Key IMSI

Foreign Keys IMSI to table sub_auth, column IMSI

HLR_ID to table hlrs, column ID

Indexes IMSI




The creation_time is a timestamp for creation of the subscriber in the database. The sub_last_modified is a timestamp for the last modification made to the subscriber's profile in the Oracle database; null change provisioning requests will not update the subscriber's profile in the database and so will not update this timestamp.

The imsi_status_last_modified is a timestamp for the last modification to the imsi_status; a null change will not update the timestamp. The imsi_status_last_activated is a timestamp for when the imsi_status was last set to ‘ACTIVATED’; a null change will not update the timestamp.

Table A-10 Table SUB_GENERAL field details



imsi_status varchar2(11) not null DEACTIVATED ACTIVATED

cust_group number(4) null null

ncos number(3) null null

hlr_id varchar2(10) not null 1234567890 1231231234

roaming_ent varchar2(16) not null UNKW MYHPLMN

category varchar2(12) not null ORDINARY ORDINARY

bicctrl varchar2(8) not null OPERATOR USER

bocctrl varchar2(8) not null OPERATOR OPERATOR

password varchar2(4) not null 1234 1234

inorig number(4) null 567

interm number(4) null 567

soa_prov varchar2(5) not null FALSE TRUE

nam varchar2(12) not null MSC_ONLY SGSN_AND_MSC

lmu varchar2(5) not null FALSE TRUE

network_active varchar2(5) not null FALSE TRUE

creation_time varchar2(20) not null 25-Dec-2003 21:30:58

05-Jan-2004 21:30:58

sub_last_modified varchar2(20) not null 25-Dec-2003 29-Mar-2004


23:01:20 07:31:18


imsi_status_last_ modified

varchar2(20) not null 25-Dec-2003 21:30:58

25-Feb-2004 15:30:00

imsi_status_last_ activated

varchar2(20) null 25-Feb-2004 15:30:00

Table A-10 Table SUB_GENERAL field details




Table SUB_ODBSThis table stores Operator Determined Barrings (ODB) provisioning statuses. A row in this table is mandatory for all subscribers. General table information is given in Table A-11.

Field details for SUB_ODBS are given in Table A-12 on page A-263, along with example values. ODB validations are discussed in “ODBs (Operator Determined Barrings)” on page 2-184.

Table A-11 Table SUB_ODBS information



Primary Key IMSI


Indexes IMSI




Table A-12 Table SUB_ODBS field details



odb_baic_prov varchar2(5) not null TRUE FALSE

odb_bicroam_prov varchar2(5) not null FALSE TRUE

odb_boac_prov varchar2(5) not null FALSE FALSE

odb_boic_prov varchar2(5) not null FALSE FALSE

odb_boicexhc_prov varchar2(5) not null FALSE TRUE

odb_boacroam_prov varchar2(5) not null FALSE FALSE

odb_incoming varchar2(7) BAIC BICROAM

odb_outgoing varchar2(8) null BOICEXHC

odb_baect_prov varchar2(5) not null FALSE FALSE

odb_bchdect_prov varchar2(5) not null FALSE FALSE

odb_bintect_prov varchar2(5) not null FALSE FALSE

odb_bdbcect_prov varchar2(5) not null FALSE FALSE

odb_premrate_info_prov varchar2(5) not null FALSE TRUE

odb_premrate_ent_prov varchar2(5) not null FALSE TRUE

odb_hplmnspec1_prov varchar2(5) not null FALSE TRUE

odb_hplmnspec2_prov varchar2(5) not null FALSE FALSE



odb_bcissmgt_prov varchar2(5) not null FALSE FALSE

odb_bccfmgt_prov varchar2(5) not null FALSE TRUE



Table SUB_BASIC_SERVICESThis table stores all basic services. One row is datafilled for each provisioned basic service. General table information is given in Table A-13.

* theoretical maximum and very unlikely in reality; a typical subscriber would have one to five rows

Field details for SUB_BASIC_SERVICES are given in Table A-14, along with example values (show one row only, a subscriber may have multiple rows of course). Field descriptions and validations are given from “Basic Services Introduction” on page 2-56 to “VGCS (Voice Group Call Service)” on page 2-106.

Table A-13 Table SUB_BASIC_SERVICES information

Number of Columns 7

Rows per Subscriber Zero to 19*

One row per basic service

Primary Key IMSI+BS


Indexes IMSI+BS

MSISDN


Table A-14 Table SUB_BASIC_SERVICES field details



bs varchar2(8) not null TPHNY FAX3

msisdn_cc varchar2(3) not null 61 44

msisdn_ndc varchar2(13) not null 123 7

msisdn_sn varchar2(13) not null 555555 123456

msisdn varchar2(15) not null 61123555555 447123456

bci number(3) null 123



Table SUB_BAICThis table stores BAIC data. A row in this table indicates that the subscriber has BAIC provisioned. General table information is given in Table A-15.

Field details for SUB_BAIC are given in Table A-16 on page A-266, along with example values. BAIC datafill is composed of six sets, each with a registered status (_reg fields); for more information on sets see “Sets in Oracle” on page A-250. Field descriptions and validations are given in “BAIC (Barring of All Incoming Calls)” on page 2-113.

Table A-15 Table SUB_BAIC information


Rows per Subscriber Zero or One One row if BAIC is provisioned

Primary Key IMSI


Indexes IMSI




Table A-16 Table SUB_BAIC field details



spch_reg varchar2(5) not null FALSE TRUE

spch_act varchar2(5) null TRUE

auxspch_reg varchar2(5) not null FALSE FALSE

auxspch_act varchar2(5) null null

sms_reg varchar2(5) not null FALSE TRUE

sms_act varchar2(5) null FALSE

cda_reg varchar2(5) not null FALSE FALSE

cda_act varchar2(5) null null

cds_reg varchar2(5) not null FALSE FALSE

cds_act varchar2(5) null null

fax_reg varchar2(5) not null FALSE FALSE

fax_act varchar2(5) null null



Table SUB_BAOCThis table stores BAOC data. A row in this table indicates that the subscriber has BAOC provisioned. General table information is given in Table A-17.

Field details for SUB_BAOC are given in Table A-18 on page A-268, along with example values. BAOC datafill is composed of seven sets, each with a registered status (_reg fields); for more information on sets see “Sets in Oracle” on page A-250. Field descriptions and validations are given in “BAOC (Barring of All Outgoing Calls)” on page 2-115.

Table A-17 Table SUB_BAOC information


Rows per Subscriber Zero or One One row if BAOC is provisioned

Primary Key IMSI


Indexes IMSI




Table A-18 Table SUB_BAOC field details







sms_reg varchar2(5) not null FALSE TRUE

sms_act varchar2(5) null FALSE







vgs_reg varchar2(5) not null FALSE TRUE

vgs_act varchar2(5) null TRUE



Table SUB_BICROAMThis table stores BICRoam data. A row in this table indicates that the subscriber has BICRoam provisioned. General table information is given in Table A-19.

Field details for SUB_BICROAM are given in Table A-20 on page A-270, along with example values. BICRoam datafill is composed of six sets, each with a registered status (_reg fields); for more information on sets see “Sets in Oracle” on page A-250. Field descriptions and validations are given in “BICRoam (Barring of Incoming Calls when Roaming outside HPLMN country)” on page 2-117.

Table A-19 Table SUB_BICROAM information


Rows per Subscriber Zero or One One row if BICRoam is provisioned

Primary Key IMSI


Indexes IMSI




Table A-20 Table SUB_BICROAM field details







sms_reg varchar2(5) not null FALSE FALSE

sms_act varchar2(5) null null





fax_reg varchar2(5) not null FALSE TRUE

fax_act varchar2(5) null FALSE



Table SUB_BOICThis table stores BOIC data. A row in this table indicates that the subscriber has BOIC provisioned. General table information is given in Table A-21.

Field details for SUB_BOIC are given in Table A-22 on page A-272, along with example values. BOIC datafill is composed of six sets, each with a registered status (_reg fields); for more information on sets see “Sets in Oracle” on page A-250. Field descriptions and validations are given in “BOIC (Barring of Outgoing International Calls)” on page 2-119.

Table A-21 Table SUB_BOIC information


Rows per Subscriber Zero or One One row if BOIC is provisioned

Primary Key IMSI


Indexes IMSI




Table A-22 Table SUB_BOIC field details



spch_reg varchar2(5) not null FALSE FALSE

spch_act varchar2(5) null null





cda_reg varchar2(5) not null FALSE TRUE

cda_act varchar2(5) null FALSE




fax_act varchar2(5) null TRUE



Table SUB_BOICEXHCThis table stores BOICexHC data. A row in this table indicates that the subscriber has BOICexHC provisioned. General table information is given in Table A-23.

Field details for SUB_BOICEXHC are given in Table A-24 on page A-274, along with example values. BOICexHC datafill is composed of six sets, each with a registered status (_reg fields); for more information on sets see “Sets in Oracle” on page A-250. Field descriptions and validations are given in “BOICexHC (Barring of Outgoing International Calls except to HPLMN Country)” on page 2-121.

Table A-23 Table SUB_BOICEXHC information


Rows per Subscriber Zero or One One row if BOICexHC is provisioned

Primary Key IMSI


Indexes IMSI




Table A-24 Table SUB_BOICEXHC field details





auxspch_reg varchar2(5) not null FALSE TRUE

auxspch_act varchar2(5) null TRUE





cds_reg varchar2(5) not null FALSE TRUE

cds_act varchar2(5) null TRUE


fax_act varchar2(5) null TRUE



Table SUB_CFBThis table stores CFB data. A row in this table indicates that the subscriber has CFB provisioned. General table information is given in Table A-25.

Field details for SUB_CFB are given in Table A-26, along with example values. CFB datafill includes five sets, each with a registered status (_reg fields); for more information on sets see “Sets in Oracle” on page A-250. Field descriptions and validations are given in “CFB (Call Forward when Busy)” on page 2-123.

Table A-25 Table SUB_CFB information


Rows per Subscriber Zero or One One row if CFB is provisioned

Primary Key IMSI


Indexes IMSI


Table A-26 Table SUB_CFB field details (2 pages)



ncp varchar2(4) not null NONF NF

nfp varchar2(4) not null NONF NFWN

dcf_id varchar2(20) null DCF_ID1



spch_noa varchar2(4) null INTL

spch_npi varchar2(4) null E164

spch_ftn varchar2(15) null 44123888888





auxspch_noa varchar2(4) null INTL

auxspch_npi varchar2(4) null E164

auxspch_ftn varchar2(15) null 44123888777



cda_noa varchar2(4) null null

cda_npi varchar2(4) null null

cda_ftn varchar2(15) null null



cds_noa varchar2(4) null null

cds_npi varchar2(4) null null

cds_ftn varchar2(15) null null



fax_noa varchar2(4) null null

fax_npi varchar2(4) null null

fax_ftn varchar2(15) null null

Table A-26 Table SUB_CFB field details (2 pages)




Table SUB_CFNRCThis table stores CFNRc data. A row in this table indicates that the subscriber has CFNRc provisioned. General table information is given in Table A-27.

Field details for SUB_CFNRC are given in Table A-28, along with example values. CFNRc datafill includes five sets, each with a registered status (_reg fields); for more information on sets see “Sets in Oracle” on page A-250. Field descriptions and validations are given in “CFNRc (Call Forward when Not Reachable)” on page 2-130.

Table A-27 Table SUB_CFNRC information


Rows per Subscriber Zero or One One row if CFNRc is provisioned

Primary Key IMSI


Indexes IMSI


Table A-28 Table SUB_CFNRC field details (2 pages)




dcf_id varchar2(20) null null




























Table A-28 Table SUB_CFNRC field details (2 pages)




Table SUB_CFNRYThis table stores CFNRy data. A row in this table indicates that the subscriber has CFNRy provisioned. General table information is given in Table A-29.

Field details for SUB_CFNRY are given in Table A-30, along with example values. CFNRy datafill includes five sets, each with a registered status (_reg fields); for more information on sets see “Sets in Oracle” on page A-250. Field descriptions and validations are given in “CFNRy (Call Forward when No Reply)” on page 2-136.

Table A-29 Table SUB_CFNRY information


Rows per Subscriber Zero or One One row if CFNRy is provisioned

Primary Key IMSI


Indexes IMSI


Table A-30 Table SUB_CFNRY field details (2 pages)




nfp varchar2(4) not null NONF NFWN

dcf_id varchar2(20) null DCF_ID2

spch_reg varchar2(5) not null TRUE TRUE

spch_act varchar2(5) TRUE TRUE

spch_noa varchar2(4) NTL INTL

spch_npi varchar2(4) PRIV E164

spch_ftn varchar2(15) 885566 44123888888

spch_nr_time number(2) 5 30








auxspch_nr_time number(2) null 25

cda_reg varchar2(5) not null TRUE FALSE

cda_act varchar2(5) TRUE null

cda_noa varchar2(4) INTL null

cda_npi varchar2(4) E164 null

cda_ftn varchar2(15) 61123555444 null

cda_nr_time number(2) 20 null






cds_nr_time number(2) null null






fax_nr_time number(2) null null

Table A-30 Table SUB_CFNRY field details (2 pages)




Table SUB_CFUThis table stores CFU data. A row in this table indicates that the subscriber has CFU provisioned. General table information is given in Table A-31.

Field details for SUB_CFU are given in Table A-32, along with example values. CFU datafill includes five sets, each with a registered status (_reg fields); for more information on sets see “Sets in Oracle” on page A-250. Field descriptions and validations are given in “CFU (Call Forward Unconditionally)” on page 2-143.

Table A-31 Table SUB_CFU information


Rows per Subscriber Zero or One One row if CFU is provisioned

Primary Key IMSI


Indexes IMSI


Table A-32 Table SUB_CFU field details (2 pages)











auxspch_noa varchar2(4) null null


auxspch_npi varchar2(4) null null


auxspch_ftn varchar2(15) null null
















Table A-32 Table SUB_CFU field details (2 pages)




Table SUB_COSThis table stores COS data. A row in this table indicates that the subscriber has COS provisioned. General table information is given in Table A-33.

Field details for SUB_COS are given in Table A-34 on page A-284, along with example values. COS datafill is composed of five sets, each with a registered status (_reg fields); for more information on sets see “Sets in Oracle” on page A-250. Field descriptions and validations are given in “COS (Class of Service)” on page 2-155.

Table A-33 Table SUB_COS information


Rows per Subscriber Zero or One One row if COS is provisioned

Primary Key IMSI


Indexes IMSI




Table A-34 Table SUB_COS field details





spch_cust_group number(4) null 1000

spch_ncos number(3) null null



auxspch_cust_group number(4) null 56

auxspch_ncos number(3) null 45



cda_cust_group number(4) null null

cda_ncos number(3) null null



cds_cust_group number(4) null null

cds_ncos number(3) null null



fax_cust_group number(4) null null

fax_ncos number(3) null null



Table SUB_CUG_FEATUREThis table stores CUG Feature data. A row in this table indicates that the subscriber has CUG Feature provisioned. General table information is given in Table A-35. Note that CUG Feature is optional CUG data -- mandatory CUG data is CUG Subscription, which is stored in a separate table, SUB_CUG_SUBSCRIPTION (see table on page A-287 ).

Field details for SUB_CUG_FEATURE are given in Table A-36, along with example values. CUG Feature is composed of six sets, each with a registered status (_reg fields); for more information on sets see “Sets in Oracle” on page A-250. Field descriptions and validations are given in “CUG Feature (Closed User Groups Feature)” on page 2-161.

Table A-35 Table SUB_CUG_FEATURE information


Rows per Subscriber Zero or One One entry if CUG Feature is provisioned

Primary Key IMSI


Indexes IMSI

Also See Table(s) sub_cug_subscription

Table A-36 Table SUB_CUG_FEATURE field details (2 pages)



spch_reg varchar2(5) not null TRUE FALSE

spch_act varchar2(5) TRUE null

spch_ica varchar2(3) NONE null

spch_prefcug_index number(5) 345 null

auxspch_reg varchar2(5) not null TRUE FALSE

auxspch_act varchar2(5) TRUE null

auxspch_ica varchar2(3) ALL null

auxspch_prefcug_index number(5) null null





cda_ica varchar2(3) null null

cda_prefcug_index number(5) null null



cds_ica varchar2(3) null null

cds_prefcug_index number(5) null null



fax_ica varchar2(3) null null

fax_prefcug_index number(5) null null

allbsg_prov varchar2(5) not null FALSE TRUE

allbsg_act varchar2(5) null TRUE

allbsg_ica varchar2(3) null OA

allbsg_prefcug_index number(5) null null

Table A-36 Table SUB_CUG_FEATURE field details (2 pages)




Table SUB_CUG_SUBSCRIPTIONThis table stores CUG Subscription data. One or more rows in this table indicates that the subscriber has CUG Subscription provisioned (and hence has CUG provisioned). General table information is given in Table A-37. Note that CUG Feature data (optional CUG data) is stored separately in table SUB_CUG_FEATURE -- see table on page A-285 .

Field details for SUB_CUG_SUBSCRIPTION are given in Table A-38 on page A-288, along with example values (note that a subscriber may have multiple rows in this table). Field descriptions and validations are given in “CUG Subscription (Closed User Groups Subscription)” on page 2-159.

Table A-37 Table SUB_CUG_SUBSCRIPTION information


Rows per Subscriber Zero to ten One row for each CUG Subscription dataset provisioned

Primary Key IMSI+NETWORK_ID+INTERLOCK


Indexes IMSI+NETWORK_ID+INTERLOCK

Also See Table(s) sub_cug_feature



.

Table A-38 Table SUB_CUG_SUBSCRIPTION field details



network_id varchar2(4) not null 567 9800

interlock number(5) not null 17 65000

cug_index number(5) not null 1234 32000

intracug_restrictions varchar2(3) null ICB

spch_reg varchar2(5) not null TRUE FALSE





allbsg_reg varchar2(5) not null FALSE TRUE



Table SUB_CWThis table stores CW data. A row in this table indicates that the subscriber has CW provisioned. General table information is given in Table A-39.

Field details for SUB_CW are given in Table A-40 on page A-290, along with example values. CW datafill is composed of six sets, each with a registered status (_reg fields); for more information on sets see “Sets in Oracle” on page A-250. Field descriptions and validations are given in “CW (Call Waiting)” on page 2-164.

Table A-39 Table SUB_CW information


Rows per Subscriber Zero or One One row if CW is provisioned

Primary Key IMSI


Indexes IMSI




Table A-40 Table SUB_CW field details

















Table SUB_EXTThis table stores EXT data. A row in this table indicates that the subscriber has EXT provisioned. General table information is given in Table A-41.

Field details for SUB_EXT are given in Table A-42, along with example values. EXT datafill is composed of two sets, each with a registered status (_reg fields); for more information on sets see “Sets in Oracle” on page A-250. Field descriptions and validations are given in “EXT (Extension Services)” on page 2-168.

Table A-41 Table SUB_EXT information


Rows per Subscriber Zero or One One row if EXT is provisioned

Primary Key IMSI


Indexes IMSI


Table A-42 Table SUB_EXT field details (3 pages)



spch_reg varchar2(5) not null TRUE TRUE

spch_act varchar2(5) TRUE TRUE

spch_msisdn1_1 varchar2(15) 61123777777 4477111111

spch_msisdn1_2 varchar2(15) 61123777788 4477222222

spch_msisdn1_3 varchar2(15) null null

spch_timer1 number(2) 30 30

spch_group1 varchar2(2) SINGLE SINGLE

spch_msisdn2_1 varchar2(15) null 4477333333





spch_timer2 number(2) null 35

spch_group2 varchar2(2) null null




spch_timer3 number(2) null 40

spch_group3 varchar2(2) null SINGLE

spch_group_overall varchar2(2) null MULTIPLE


auxspch_act varchar2(5) TRUE null

auxspch_msisdn1_1 varchar2(15) 6112377111 null



auxspch_timer1 number(2) 5 null

auxspch_group1 varchar2(2) MULTIPLE null



auxspch_msisdn2_3 varchar2(15) null null

auxspch_timer2 number(2) 20 null

auxspch_group2 varchar2(2) SINGLE null




auxspch_timer3 number(2) null null

auxspch_group3 varchar2(2) null null





auxspch_group_overall varchar2(2) MULTIPLE null





Table SUB_IMSI_SSThis table stores all IMSI-Supplementary Services, both provisioning indications and service data. A row in this table is mandatory for all subscribers, even if no IMSI-SSs are provisioned. General table information is given in Table A-43.

Field details for SUB_IMSI_SS are given in Table A-44 on page A-295, along with example values. The <service>_prov fields indicate whether the particular service is provisioned. Field descriptions and validations are given in the particular service section in “Chapter 2: Component descriptions” (see “Supplementary Services introduction” on page 2-107 for a list of section references.

Table A-43 Table SUB_IMSI_SS information



Primary Key IMSI


Indexes IMSI




Table A-44 Table SUB_IMSI_SS field details (2 pages)



acc_prov varchar2(5) not null FALSE TRUE

acc_option varchar2(5) null VOL

acc_ver_length number(2) null null

acrj_prov varchar2(5) not null FALSE TRUE

aocc_prov varchar2(5) not null FALSE TRUE

aoci_prov varchar2(5) not null FALSE FALSE

clip_prov varchar2(5) not null FALSE TRUE

clip_override varchar2(5) null FALSE

clir_prov varchar2(5) not null FALSE FALSE

clir_pm varchar2(4) null null

cnam_prov varchar2(5) not null FALSE FALSE

colp_prov varchar2(5) not null FALSE FALSE

colp_override varchar2(5) null null

colr_prov varchar2(5) not null FALSE FALSE

ect_prov varchar2(5) not null FALSE TRUE

emlpp_prov varchar2(5) not null FALSE TRUE

emlpp_max_priority varchar2(1) null B

emlpp_def_priority varchar2(1) null 2

fm_prov varchar2(5) not null FALSE FALSE

fm_cor_a varchar2(5) null null

fm_cor_b varchar2(5) null null

fm_cor_c varchar2(5) null null

fm_cor_d varchar2(5) null null



fm_sup_cor_a varchar2(5) null null

fm_sup_cor_b varchar2(5) null null

fm_sup_cor_c varchar2(5) null null

fm_sup_cor_d varchar2(5) null null

hold_prov varchar2(5) not null TRUE TRUE

hotbill_prov varchar2(5) not null FALSE FALSE

lco_prov varchar2(5) not null FALSE TRUE

mct_prov varchar2(5) not null FALSE FALSE

mpty_prov varchar2(5) not null TRUE TRUE

mpty_option varchar2(6) M3PORT M6PORT

uus1_prov varchar2(5) not null FALSE FALSE

Table A-44 Table SUB_IMSI_SS field details (2 pages)




Table SUB_DCSIThis table stores D-CSI data. A row in this table indicates that the subscriber has D-CSI provisioned. General table information is given in Table A-45.

Field details for SUB_DCSI are given in Table A-46 on page A-298, along with example values. The criteria_name<x> columns make up the criteria names vector (for more information on vectors see “Data vectors” on page 1-36). The criteria names are datafilled in numerical order, as indicated in the examples. Field descriptions and validations are given in “D-CSI (Dialled CSI)” on page 2-187.

Table A-45 Table SUB_DCSI information


Rows per Subscriber Zero or One One row if D-CSI is provisioned

Primary Key IMSI


Indexes IMSI




Table A-46 Table SUB_DCSI field details



active varchar2(5) not null TRUE TRUE

phase varchar2(4) not null CAP3 CAP3

unspvmsc varchar2(10) not null CONT_HPLMN RELEASE

unspgmsc varchar2(8) not null CONTINUE RELEASE

criteria_name1 varchar2(20) not null CRIT_NAMEA CRIT_NAMEZ

criteria_name2 varchar2(20) CRIT_NAMEC null

criteria_name3 varchar2(20) CRIT_NAMEB null

criteria_name4 varchar2(20) CRIT_NAMEZ null

criteria_name5 varchar2(20) null null








Table SUB_GPRS_CSIThis table stores GPRS-CSI data. A row in this table indicates that the subscriber has GPRS-CSI provisioned. General table information is given in Table A-47.

Field details for SUB_GPRS_CSI are given in Table A-48 on page A-300, along with example values. GPRS-CSI has five sets, each having a provisioned status (named tdp<x>_prov; for more information on sets see “Sets in Oracle” on page A-250). Field descriptions and validations are given in “GPRS-CSI (General Packet Radio Service CSI)” on page 2-189.

Table A-47 Table SUB_GPRS_CSI information


Rows per Subscriber Zero or One One row if GPRS-CSI is provisioned

Primary Key IMSI


Indexes IMSI




Table A-48 Table SUB_GPRS_CSI field details





unspsgsn varchar2(10) not null RELEASE CONTINUE

tdp1_prov varchar2(5) not null TRUE TRUE

tdp1_scf_name varchar2(20) MYSCF1 MYSCF1

tdp1_service_key number(10) 345345344 1113322

tdp1_scf_unavail varchar2(8) RELEASE RELEASE

tdp2_prov varchar2(5) not null FALSE FALSE

tdp2_scf_name varchar2(20) null null

tdp2_service_key number(10) null null

tdp2_scf_unavail varchar2(8) null null





tdp12_prov varchar2(5) not null TRUE FALSE

tdp12_scf_name varchar2(20) MYSCF99 null

tdp12_service_key number(10) 423422 null

tdp12_scf_unavail varchar2(8) CONTINUE null







Table SUB_MCSIThis table stores M-CSI data. A row in this table indicates that the subscriber has M-CSI provisioned. General table information is given in Table A-49.

Field details for SUB_MCSI are given in Table A-50, along with example values. Field descriptions and validations are given in “M-CSI (Mobility Management CSI)” on page 2-192.

Table A-49 Table SUB_MCSI information

Number of Columns 4

Rows per Subscriber Zero or One One row if M-CSI is provisioned

Primary Key IMSI


Indexes IMSI


Table A-50 Table SUB_MCSI field details



active varchar2(5) not null TRUE FALSE

mobility_trigger_name varchar2(20) not null TRIGGER_NAMEA TRIGGER_NAMEZ

suppress_mcsi varchar2(5) null HC



Table SUB_OCSIThis table stores O-CSI data. A row in this table indicates that the subscriber has O-CSI provisioned. General table information is given in Table A-51.

Field details for SUB_OCSI are given in Table A-52 on page A-303, along with example values. O-CSI has four sets, TDP2 Phase1, TDP2 Phase2, TDP2 Phase3 and TDP4 Phase3. Each has a provisioned status, named tdp<x>_phase<y>_prov.

There are several vectors in O-CSI datafill. The simple vectors are destination number length criteria (2 vectors), BS codes criteria (2 vectors) and cause values criteria:

• tdp2_ph2_dnc_length<x>

• tdp2_ph2_bs_code_cri<x>

• tdp2_ph3_dnc_length<x>

• tdp2_ph3_bs_code_cri<x>

• tdp4_ph3_cause_value_cri<x>

O-CSI also has two complex vectors for destination number criteria:

• tdp2_ph2_dnc_dn<x>_noa + tdp2_ph2_dnc_dn<x>_npi + tdp2_ph2_dnc_dn<x>

• tdp2_ph3_dnc_dn<x>_noa + tdp2_ph3_dnc_dn<x>_npi + tdp2_ph3_dnc_dn<x>

For more information on vectors see “Vectors in Oracle” on page A-248.

Field descriptions and validations are given in “O-CSI (Originating CSI)” on page 2-193.

Table A-51 Table SUB_OCSI information


Rows per Subscriber Zero or One One row if O-CSI is provisioned

Primary Key IMSI


Indexes IMSI




Table A-52 Table SUB_OCSI field details (6 pages)




ftn_checks varchar2(6) not null GSM TIF

unspvmsc varchar2(10) not null CONTINUE CONT_HPLMN

unspgmsc varchar2(8) not null CONTINUE CONTINUE

qscfwihp varchar2(5) not null TRUE FALSE

tdp2_ph1_prov varchar2(5) not null FALSE FALSE

tdp2_ph1_scf_name varchar2(20) null null

tdp2_ph1_service_key number(10) null null

tdp2_ph1_scf_unavail varchar2(8) null null

tdp2_ph1_send_cch varchar2(5) null null

tdp2_ph2_prov varchar2(5) not null TRUE FALSE

tdp2_ph2_scf_name varchar2(20) MYSCF99 null

tdp2_ph2_service_key number(10) 1234567 null

tdp2_ph2_scf_unavail varchar2(8) RELEASE null

tdp2_ph2_dnc_match _type

varchar2(10) null null

tdp2_ph2_dnc_dn1 _noa


tdp2_ph2_dnc_dn1_npi varchar2(4) null null

tdp2_ph2_dnc_dn1 varchar2(15) null null









































tdp2_ph2_dnc_dn10 _npi



tdp2_ph2_dnc_length1 number(2) null null



tdp2_ph2_bs_code _cri1










tdp2_ph2_call_type_cri varchar2(7) null null

tdp2_ph3_prov varchar2(5) not null TRUE TRUE

tdp2_ph3_scf_name varchar2(20) MYSCFA MYSCF1

tdp2_ph3_service_key number(10) 257 33221100

tdp2_ph3_scf_unavail varchar2(8) RELEASE CONTINUE

tdp2_ph3_dnc_match _type

varchar2(10) null ENABLING


varchar2(4) null INTL

tdp2_ph3_dnc_dn1_npi varchar2(4) null E164

tdp2_ph3_dnc_dn1 varchar2(15) null 44789123123123











































tdp2_ph3_dnc_dn10 _npi







varchar2(8) TPHNY null


varchar2(8) CDA null







tdp2_ph3_call_type_cri varchar2(7) null FWD

tdp4_ph3_prov varchar2(5) not null TRUE TRUE

tdp4_ph3_scf_name varchar2(20) MYSCFB MYSCFZ

tdp4_ph3_service_key number(10) 12 1234533233

tdp4_ph3_scf_unavail varchar2(8) CONTINUE RELEASE

tdp4_ph3_cause_value _cri1

number(3) null 34






number(3) null 123


number(3) null 7


number(3) null null


number(3) null null





Table SUB_SMS_CSIThis table stores SMS-CSI data. A row in this table indicates that the subscriber has SMS-CSI provisioned. General table information is given in Table A-53.

Field details for SUB_SMS_CSI are given in Table A-54, along with example values. Field descriptions and validations are given in “SMS-CSI (Short Message Service CSI)” on page 2-201.

Table A-53 Table SUB_SMS_CSI information

Number of Columns 8

Rows per Subscriber Zero or One One row if SMS-CSI is provisioned

Primary Key IMSI


Indexes IMSI


Table A-54 Table SUB_SMS_CSI field details





unspnode varchar2(10) not null RELEASE CONTINUE

tdp1_prov varchar2(5) not null TRUE TRUE

tdp1_scf_name varchar2(20) MYSCF5 MYSCF1

tdp1_service_key number(10) 12345678 889988441

tdp1_scf_unavail varchar2(8) RELEASE RELEASE



Table SUB_SS_CSIThis table stores SS-CSI data. A row in this table indicates that the subscriber has SS-CSI provisioned. General table information is given in Table A-55.

Field details for SUB_SS_CSI are given in Table A-56, along with example values. Field descriptions and validations are given in “SS-CSI (Supplementary Service CSI)” on page 2-203.

Table A-55 Table SUB_SS_CSI information

Number of Columns 5

Rows per Subscriber Zero or One One row if SS-CSI is provisioned

Primary Key IMSI


Indexes IMSI


Table A-56 Table SUB_SS_CSI field details



active varchar2(5) TRUE FALSE

ect_option varchar2(5) TRUE TRUE

mpty_option varchar2(5) FALSE TRUE

scf_name varchar2(20) MYSCF99 MYSCFA



Table SUB_TCSIThis table stores T-CSI data. A row in this table indicates that the subscriber has T-CSI provisioned. General table information is given in Table A-57.

Field details for SUB_TCSI are given in Table A-58 on page A-312, along with example values. T-CSI has five sets, TDP12 Phase1, TDP12 Phase2, TDP12 Phase3, TDP13 Phase3 and TDP14 Phase3, each having a provisioned status (named tdp<x>_ph<y>_prov; for more information on sets see “Sets in Oracle” on page A-250).

T-CSI has four simple vectors:

• tdp12_ph2_bs_code<x>

• tdp12_ph3_bs_code<x>

• tdp13_ph3_cause_value<x>

• tdp14_ph3_cause_value<x>

For more information on vectors see “Vectors in Oracle” on page A-248. Field descriptions and validations are given in “T-CSI (Terminating CSI)” on page 2-204.

Table A-57 Table SUB_TCSI information


Rows per Subscriber Zero or One One row if T-CSI is provisioned

Primary Key IMSI


Indexes IMSI




.

Table A-58 Table SUB_TCSI field details (3 pages)




provide_location_info varchar2(5) not null TRUE FALSE

page_for_cell_id varchar2(5) not null TRUE FALSE

provide_subscriber _state

varchar2(5) not null TRUE TRUE

provide_current _location

varcahr2(5) not null TRUE FALSE

suppress_tcsi varchar2(5) null HC

unspgmsc varchar2(8) CONTINUE CONTINUE

tdp12_ph1_prov varchar2(5) not null FALSE FALSE

tdp12_ph1_scf_name varchar2(20) null null

tdp12_ph1_service _key

number(10) null null

tdp12_ph1_scf_unavail varchar2(8) null null

tdp12_ph1_send_cch varchar2(5) null null

tdp12_ph2_prov varchar2(5) not null TRUE FALSE

tdp12_ph2_scf_name varchar2(20) MYSCF1 null


number(10) 45111111232 null

tdp12_ph2_scf_unavail varchar2(8) CONTINUE null


varchar2(8) TPHNY null


varchar2(8) FAX null


varchar2(8) CDS9600 null







tdp12_ph3_prov varchar2(5) not null FALSE TRUE

tdp12_ph3_scf_name varchar2(20) null MYSCF8


number(10) null 122231112

tdp12_ph3_scf_unavail varchar2(8) null CONTINUE















tdp13_ph3_scf_unavail varchar2(8) null RELEASE

tdp13_ph3_cause _value_cri1

number(3) null 100


number(3) null 55


number(3) null null






number(3) null null


number(3) null null





tdp14_ph3_scf_unavail varchar2(8) null RELEASE


number(3) null null


number(3) null null


number(3) null null


number(3) null null


number(3) null null





Table SUB_USSD_CSIThis table stores USSD-CSI data. A row in this table indicates that the subscriber has USSD-CSI provisioned. General table information is given in Table A-59.

Field details for SUB_USSD_CSI are given in Table A-60 on page A-316, along with example values. USSD-CSI has one simple vector, id<x> (for more information on vectors see “Vectors in Oracle” on page A-248). The ids are datafilled in numerical order, as indicated in the examples. Field descriptions and validations are given in “USSD-CSI (Unstructured Supplementary Service Data CSI)” on page 2-210.

Table A-59 Table SUB_USSD_CSI information


Rows per Subscriber Zero or One One row if USSD-CSI is provisioned

Primary Key IMSI


Indexes IMSI




.

Table A-60 Table SUB_USSD_CSI field details



id1 varchar2(10) not null MYID1 MYIDB

id2 varchar2(10) MYIDZ MYIDC

id3 varchar2(10) MYIDA null

id4 varchar2(10) MYID99 null

id5 varchar2(10) null null








Table SUB_CLINThis table stores CLIN data. A row in this table indicates that the subscriber has CLIN provisioned. General table information is given in Table A-61.

Field details for SUB_CLIN are given in Table A-62, along with example values. Field descriptions and validations are given in “CLIN (Calling Line Identification Replacement Number)” on page 2-230..

Table A-61 Table SUB_CLIN information

Number of Columns 2

Rows per Subscriber Zero or One One row if CLIN is provisioned

Primary Key IMSI


Indexes IMSI


Table A-62 Table SUB_CLIN field details



cli varchar2(15) not null 61123666777 44757123123



Table SUB_EAThis table stores EA data. A row in this table indicates that the subscriber has EA provisioned. General table information is given in Table A-63.

Field details for SUB_EA are given in Table A-64, along with example values. Field descriptions and validations are given in “EA (Equal Access)” on page 2-231.

Table A-63 Table SUB_EA information

Number of Columns 2

Rows per Subscriber Zero or One One row if EA is provisioned

Primary Key IMSI


Indexes IMSI


Table A-64 Table SUB_EA field details



pic varchar2(4) not null 1234 8888



Table SUB_GPRS_PROVThis table stores GPRS provisioning indications. A row in this table indicates that the subscriber has GPRS provisioned. General table information is given in Table A-65. GPRS datafill (i.e. PDP Conext information) is stored separately in table SUB_GPRS_PDPS -- see “Table SUB_GPRS_PDPS” on page A-320.

Field details for SUB_GPRS_PROV are given in Table A-66.

Table A-65 Table SUB_GPRS_PROV information

Number of Columns 1

Rows per Subscriber Zero or One One row if GPRS is provisioned

Primary Key IMSI


Indexes IMSI

Also See Table(s) sub_gprs_pdps

Table A-66 Table SUB_GPRS_PROV field details





Table SUB_GPRS_PDPSThis table stores GPRS PDP context data. One row is datafilled per PDP context for the subscriber. Note that GPRS provisioning indications are stored in table SUB_GPRS_PROV (see “Table SUB_GPRS_PROV” on page A-319). General table information is given in Table A-67.

Field details for SUB_GPRS_PDPS are given in Table A-68, along with example values (for a particular row). GPRS has twenty sets, each set being context_id information. Field descriptions and validations are given in “GPRS (General Packet Radio Service)” on page 2-223.

Table A-67 Table SUB_GPRS_PDPS information

Number of Columns 4

Rows per Subscriber Zero to twenty One row per PDP Context

Primary Key IMSI+CONTEXT_ID


Indexes IMSI+CONTEXT_ID

Also See Table(s) sub_gprs_prov

Table A-68 Table SUB_GPRS_PDPS field details



context_id number(2) not null 1 20

name varchar2(16) not null MYPDP1 MYPDP99

static_address varchar2(63) null 123.34.55.1



Table SUB_LCS_CALL_RELATEDThis table stores LCS Call Related class data. A row in this table indicates that the subscriber has LCS Call Related class provisioned. General table information is given in Table A-69, including the several tables that LCS datafill is spread across.

Field details for SUB_LCS_CALL_RELATED are given in Table A-70 on page A-322, along with example values. LCS Call Related has two simple vectors, external_client<x> and external_client_ex<x>, the latter being the so-called “extended” clients vector. For more information on vectors see “Vectors in Oracle” on page A-248. Field descriptions and validations are given in “LCS Call Related” on page 2-214.

Table A-69 Table SUB_LCS_CALL_RELATED information


Rows per Subscriber Zero or One One row if LCS Call Related is provisioned

Primary Key IMSI


Indexes IMSI

Also See Table(s) sub_lcs_universal

sub_lcs_call_unrelated

sub_lcs_plmn_operator

sub_lcs_gmlcs

sub_lcs_mobile_originating



Table A-70 Table SUB_LCS_CALL_RELATED field details (2 pages)




notification_to_user varchar2(30) not null LOC_NOT _ALLOW

LOC_ALLOW_WITH_NOTIF

external_client1 varchar2(8) CLIENT8 CLIENT45

external_client2 varchar2(8) CLIENT7 CLIENT12

external_client3 varchar2(8) CLIENT34 null



external_client_ex1 varchar2(8) CLIENT12 null


external_client_ex3 varchar2(8) CLIENTAA null






external_client_ex9 varchar2(8) null null





























Table A-70 Table SUB_LCS_CALL_RELATED field details (2 pages)




Table SUB_LCS_CALL_UNRELATEDThis table stores LCS Call Unrelated class data. A row in this table indicates that the subscriber has LCS Call Unrelated class provisioned. General table information is given in Table A-71, including the several tables that LCS datafill is spread across.

Field details for SUB_LCS_CALL_UNRELATED are given in Table A-72 on page A-325, along with example values. LCS Call Unrelated has two simple vectors, external_client<x> and external_client_ex<x>, the latter being the so-called “extended” names vector. For more information on vectors see “Vectors in Oracle” on page A-248. Field descriptions and validations are given in “LCS Call Unrelated” on page 2-216.

Table A-71 Table SUB_LCS_CALL_UNRELATED information


Rows per Subscriber Zero or One One row if LCS Call Unrelated is provisioned

Primary Key IMSI


Indexes IMSI


sub_lcs_call_related


sub_lcs_gmlcs




Table A-72 Table SUB_LCS_CALL_UNRELATED field details (3 pages)




notification_to_user varchar2(30) not null LOC_NOT_ALLOW LOC_ALLOW_WITH_NOTIF

external_client1 varchar2(20) EXTERNALCLIENT8 EXTERNALCLIENT45

external_client2 varchar2(20) EXTERNALCLIENT7 EXTERNALCLIENT12

external_client3 varchar2(20) EXTERNALCLIENT34

null


null


null



external_client_ex3 varchar2(8) CLIENTAA null



































Table A-72 Table SUB_LCS_CALL_UNRELATED field details (3 pages)




Table SUB_LCS_GMLCSThis table stores LCS GMLC data. A row in this table indicates that the subscriber has LCS GMLCs provisioned. General table information is given in Table A-73, including the several tables that LCS datafill is spread across.

Field details for SUB_LCS_GMLCS are given in Table A-74 on page A-328, along with example values. Field descriptions and validations are given in “LCS GMLCs” on page 2-218.

Table A-73 Table SUB_LCS_GMLCS information

Number of Columns 6

Rows per Subscriber Zero or One One row if one or more GLMCs is provisioned

Primary Key IMSI


Indexes IMSI








Table A-74 Table SUB_LCS_GMLCS field details



gmlc1 varchar2(20) not null MYGMLC1 MYGMLC9

gmlc2 varchar2(20) MYGMLC5 null



gmlc5 varchar2(20) null null



Table SUB_LCS_MOBILE_ORIGINATINGThis table stores all LCS Mobile Originating data, i.e. all three classes, Basic Self Location, Autonomous Self Location and Transfer to Third Party. A row in this table indicates that the subscriber has at least one mobile originating class provisioned. General table information is given in Table A-75, including the several tables that LCS datafill is spread across.

Field details for SUB_LCS_MOBILE_ORIGINATING are given in Table A-76 on page A-330, along with example values. Field descriptions and validations are given in “LCS Basic Self Location” on page 2-213 (basic self location), “LCS Autonomous Self Location” on page 2-212 (autonomous self location) and “LCS Transfer to Third Party” on page 2-221 (transfer to third party).

Table A-75 Table SUB_LCS_MOBILE_ORIGINATING information

Number of Columns 7

Rows per Subscriber Zero or one One row if one or more LCS Mobile Originating classes are provisioned

Primary Key IMSI


Indexes IMSI





sub_lcs_gmlcs



Table A-76 Table SUB_LCS_MOBILE_ORIGINATING field details



basic_self_loc_prov varchar2(5) not null TRUE FALSE

basic_self_loc_act varchar2(5) TRUE null

autonomous_self_loc _prov

varchar2(5) not null TRUE FALSE

autonomous_self_loc _act

varchar2(5) FALSE null

transfer_3rd_party _prov

varchar2(5) not null TRUE TRUE

transfer_3rd_party_act varchar2(5) TRUE TRUE



Table SUB_LCS_PLMN_OPERATORThis table stores LCS PLMN Operator class data. A row in this table indicates that the subscriber has LCS PLMN Operator class provisioned. General table information is given in Table A-77, including the several tables that LCS datafill is spread across.

Field details for SUB_LCS_PLMN_OPERATOR are given in Table A-78 on page A-332, along with example values. Field descriptions and validations are given in “LCS PLMN Operator” on page 2-219.

Table A-77 Table SUB_LCS_PLMN_OPERATOR information

Number of Columns 7

Rows per Subscriber Zero or One One row if LCS PLMN Operator is provisioned

Primary Key IMSI


Indexes IMSI




sub_lcs_gmlcs




.

Table A-78 Table SUB_LCS_PLMN_OPERATOR field details




broadcast varchar2(5) not null TRUE FALSE

omh varchar2(5) not null TRUE FALSE

omv varchar2(5) not null FALSE TRUE

anonymous varchar2(5) not null TRUE FALSE

target_ms varchar2(5) not null FALSE TRUE



Table SUB_LCS_UNIVERSALThis table stores LCS Universal class data. A row in this table indicates that the subscriber has LCS Universal class provisioned. General table information is given in Table A-79, including the several tables that LCS datafill is spread across.

Field details for SUB_LCS_UNIVERSAL are given in Table A-80, along with example values. Field descriptions and validations are given in “LCS Universal” on page 2-222.

Table A-79 Table SUB_LCS_UNIVERSAL information

Number of Columns 2

Rows per Subscriber Zero or One One row if LCS Universal is provisioned

Primary Key IMSI


Indexes IMSI

Also See Table(s) sub_lcs_call_related



sub_lcs_gmlcs


Table A-80 Table SUB_LCS_UNIVERSAL field details






Table SUB_VBSThis table stores VBS data. A row in this table indicates that the subscriber has VBS provisioned. General table information is given in Table A-81.

Field details for SUB_VBS are given in Table A-82, along with example values. VBS has complex vector of groups, composed of group<x>_id + group<x>_orig_ent. For more information on vectors see “Vectors in Oracle” on page A-248. Field descriptions and validations are given in “VBS (Voice Broadcast Service)” on page 2-105.

Table A-81 Table SUB_VBS information


Rows per Subscriber Zero or One One row if VBS is provisioned

Primary Key IMSI


Indexes IMSI


Table A-82 Table SUB_VBS field details (5 pages)



functions_outside _hplmn

varchar2(5) TRUE FALSE

group1_id varchar2(3) 334 567

group1_orig_ent varchar2(5) TRUE TRUE


group2_orig_ent varchar2(5) TRUE TRUE

group3_id varchar2(3) 008 null

group3_orig_ent varchar2(5) TRUE null















group10_id varchar2(3) null null

group10_orig_ent varchar2(5) null null

































































































Table SUB_VGCSThis table stores VGCS data. A row in this table indicates that the subscriber has VGCS provisioned. General table information is given in Table A-83.

Field details for SUB_VGCS are given in Table A-84, along with example values. VBS has simple vector of group<x>_id. For more information on vectors see “Vectors in Oracle” on page A-248. Field descriptions and validations are given in “VGCS (Voice Group Call Service)” on page 2-106.

Table A-83 Table SUB_VGCS information


Rows per Subscriber Zero or One One row if VGCS is provisioned

Primary Key IMSI


Indexes IMSI


Table A-84 Table SUB_VGCS field details (3 pages)



functions_outside _hplmn

varchar2(5) TRUE FALSE





























































Table SUB_SIMRThis table stores SIMR data. A row in this table indicates that the subscriber is involved in a SIMR relationship (note that the subscriber’s current IMSI is not the key in this table). General table information is given in Table A-85.

Field details for SUB_SIMR are given in Table A-86, along with example values. The current subscriber profile is indicated by the old_imsi field. Field descriptions and validations are given in “SIMR (SIM Replacement)” on page 2-235.

Table A-85 Table SUB_SIMR information

Number of Columns 5

Rows per Subscriber Zero or One One row if the subscriber is in a SIMR relationship

Primary Key NEW_IMSI

Foreign Keys NEW_IMSI to table sub_auth, column IMSI

Indexes NEW_IMSI

OLD_IMSI


Table A-86 Table SUB_SIMR field details


new_imsi varchar2(15) not null 456231234567890 234109920024844

old_imsi varchar2(15) not null 456231231231234 231109950005000

simr_option varchar2(5) not null FIXED USER

invocation_time varchar2(17) not null 15-Mar-2004 12:00 15-Mar-2004 15:00

activation_time varchar2(17) null 01-Feb-2004 09:00



Routing SchemaThe routing schema is composed of three tables, listed in Table A-87. Note that this schema is evolved from the GSM17 Oracle schema. Table HLR denotes the HLR Cores in the system. Table IMSIS and MSISDNS are master copies of the data stored in the SLR node.

Table HLRSThis table stores the HLR Cores present in the HLR system. General table information is given in Table A-88.

Table A-87 Routing Schema Tables


Description See page

hlrs Unchanged stores all HLR Core IDs

imsis Unchanged stores IMSIs present in SLR database

msisdns Unchanged stores MSISDNs present in SLR database

simr Unchanged stores deadline times for SIMR relationships

Table A-88 Table HLRS information

Number of Columns 2

Rows per Subscriber Not Applicable (not a subscriber data table)

Primary Key ID

Foreign Keys None

Indexes ID




Field details for table HLRS are given in Table A-89, along with descriptions.

Table IMSISThis table stores the master copies of the IMSIs which are present in the SLR database. General table information is given in Table A-90.

Field details for table IMSIS are given in Table A-91, along with descriptions.

Table A-89 Table HLRS field details

Column Name Oracle Type Constraints Syntax Description

id varchar2(10) not null 10 hex digits the HLR Core ID

name varchar2(50) not null 1 - 50 characters

a descriptive name for the HLR Core

Table A-90 Table IMSIS information

Number of Columns 2

Rows per Subscriber Zero or One

Primary Key IMSI

Foreign Keys HLR_ID to table hlrs, column ID

Indexes IMSI

Also See Table(s) hlrs

Table A-91 Table IMSIS field details


imsi varchar2(15) not null 6 - 15 digits International Mobile Subscriber Identities present in SLR database

hlr_id varchar2(10) not null 10 hex digits HLR ID for this subscriber



Table MSISDNSThis table stores the master copies of the MSISDNs which are present in the SLR database. General table information is given in Table A-92.

* theoretical maximum and very unlikely in reality; a typical subscriber would have zero to three rows, depending on whether remastered and whether network active

Field details for table MSISDNS are given in Table A-93, along with descriptions.

Table A-92 Table MSISDNS information

Number of Columns 2

Rows per Subscriber zero to 19*

Primary Key MSISDN

Foreign Keys IMSI to table imsis, column IMSI

Indexes IMSI

MSISDN

Also See Table(s) imsis

Table A-93 Table MSISDNS field details


msisdn varchar2(15) not null 3 - 15 digits Mobile Subscriber ISDN number present in SLR database

imsi varchar2(15) not null 6 - 15 digits International Mobile Subscriber Identity (IMSI) which the MSISDN relates to



Table SIMRThis table stores deadlines for SIMR relationships, and is redundant once all subscribers have been remastered. Note that the full set of SIMR data is stored in table SUB_SIMR in the subscriber schema (see “Table SUB_SIMR” on page A-342). General table information is given in Table A-94.

Field details for table SIMR are given in Table A-95, along with descriptions.

Table A-94 Table SIMR information

Number of Columns 3

Rows per Subscriber Zero or One

Primary Key NEW_IMSI

Foreign Keys NEW_IMSI to table imsis, column IMSI

OLD_IMSI to table imsis, column IMSI

Indexes NEW_IMSI

OLD_IMSI


Table A-95 Table SIMR field details

Column Name Oracle Type Constraints

Syntax Description

new_imsi varchar2(15) not null 6 - 15 digits new IMSI for subscriber

old_imsi varchar2(15) not null 6 - 15 digits the subscriber’s old IMSI, the one to be replaced

deadline date not null date (nearest hour)

the time at which the SIMR swap is mandatory


B-347Nortel Confidential Copyright © 1996–2005 Nortel

Glossary of terms BThis section expands the names of acronym/shortened dataitems and service names.

AACC

Accounting Codes

ACRJAnonymous Call Rejection

ALTSPCDAAlternate Speech / CDA Data

ALTSPCDSAlternate Speech / CDS Data

ALTSPFAXAlternate Speech / Fax Group 3

AOCCAdvice of Charge Charging

AOCIAdvice of Charge Information

AUXSPCHAuxiliary Speech basic service group

AUXTPHNYAuxiliary Telephony


B-348 Glossary of termsNortel Confidential Copyright © 1996–2005 Nortel

BBAECT

Barring of All Explicit Call Transfer

BAICBarring of All Incoming Calls

BAOCBarring of All Outgoing Calls

BAOCRoamBarring of (All) Outgoing Calls when Roaming outside HPLMN country

BCHDECTBarring of Chargeable Explicit Call Transfer

BCIBearer Capability Index

BDBCECTBarring of Doubly Chargeable Explicit Call Transfer

BICCTRLControl of Barring Incoming Calls

BICRoamBarring of Incoming Calls when Roaming

BINTECTBarring of International Explicit Call Transfer

BOCCTRLControl of Barring Outgoing Calls

BOICBarring of Outgoing International Calls

BOICexHCBarring of Outgoing International Calls except to HPLMN Country

BSBasic Service (note that BS Codes also encompass basic service groups)

BSG


Basic Service Group

Glossary of terms B-349Nortel Confidential Copyright © 1996–2005 Nortel

CCAMEL

Customised Applications for Mobile Enhanced Logic

CCCountry Code (the MSISDN contains a CC)

CCHCAMEL Capability Handler

CDACircuit Duplex Asynchronous Data services or basic service group

CDAGBSCircuit Duplex Asynchronous Data General Bearer Service

CDSCircuit Duplex Synchronous Data services or basic service group

CDSGBSCircuit Duplex Synchronous Data General Bearer Service

CFBCall Forward when Busy

CFNRcCall Forward when Not Reachable

CFNRyCall Forward when no Reply

CFUCall Forward Unconditionally

CLINCalling Line Identification replacement Number

CLIPCalling Line ID Presentation

CLIRCalling Line ID Restriction



CNAMCalling Name Delivery

COLPConnected Line ID Presentation

COLRConnected Line ID Restriction

CORClass Of Registration

COSClass Of Service

CUGClosed User Groups

CWCall Waiting

DDCF

Default Call Forwarding

D-CSIDialled CAMEL Subscription Information

DNDestination Number

DNCDestination Number Criteria

DPDetection Point, also known as a Trigger Detection Point (TDP) on the HLR



EEA

Equal Access

ECTExplicit Call Transfer

EMLPPEnhanced Multi Level Precedence & Pre-emption

EXTExtension Services

FFA

Functional Addressing (also known as FM)

FAXFacsimile basic service group

FAX3Facsimile group 3

FMFollow Me (also known as FA)

FTNForward To Number

GGMLC

Gateway Mobile Location Center

GPRSGeneral Packet Radio Service

GPRS-CSIGeneral Packet Radio Service CAMEL Subscription Information



gsmSCFGSM Service Control Function

HHOLD

Call Hold

HOTBILLHot Billing

HSTHome Subscriber Trace

IICA

Inter-CUG Accessibility

IMSIInternational Mobile Subscriber Identity

INIntelligent Network

INORIGIN index for Originating calls

INTERMIN index for Terminating calls

LLCO

Local Calls Only

LMULocation Measurement Unit



MMCC

Mobile Country Code (part of IMSI)

M-CSIMobility management CAMEL Subscription Information

MCTMalicious Call Trace

MNCMobile Network Code (part of IMSI)

MPTYMulti-Party

MSINMobile Subscriber Identification Number (part of IMSI)

MSISDNMobile Subscriber ISDN

NNAM

Network Access Mode

NCOSNetwork Class Of Service

NCPNotify Calling Party

NDCNational Destination Code (part of MSISDN)

NFPNotify Forwarding Party

NOANature Of Address



NPINumber Plan Indicator

OO-CSI

Originating CAMEL Subscription Information

ODBOperator Determined Barring

OMCDestinationOperator Maintenance Center Destination

OMHO&M LCS client in the HPLMN

OMVO&M LCS client in the VPLMN

OPCOperator variant algorithm Configuration

PPDP

Packet Data Protocol

PICPrimary Interexchange Carrier

QQSCFWIHP

Query SCF When In HPLMN



SSCF

Service Control Function, strictly known as a gsmSCF

SIMRSIM Replacement

SMMOShort Message Mobile Originating

SMMTShort Message Mobile Terminating

SMSShort Message Service basic service group

SMS-CSIShort Message Service CAMEL Subscription Information

SNSubscriber Number (part of MSISDN)

SOAPROVSuppression Of Announcements Provisioning

SPCHSpeech basic service group

SPCHCDASpeech followed by CDA Data

SPCHCDSSpeech followed by CDS Data

SS-CSISupplementary Service CAMEL Subscription Information



TT-CSI

Terminating CAMEL Subscription Information

TDPTrigger Detection Point, also known as a Detection Point (DP) on the HLR

TPHNYTelephony

UUNSPGMSC

Unsupported GMSC behaviour

UNSPNODEUnsupported Node behaviour

UNSPSGSNUnsupported SGSN behaviour

UNSPVMSCUnsupported VMSC behaviour

USSD-CSIUnstructured Supplementary Service Data CAMEL Subscription Information

UUS1User to User Signalling stage 1

VVBS

Voice Broadcast Service

VGCSVoice Group Call Service

VGSVoice Group Service basic service group



WWPS

Wireless Priority Service




test

Family Product Manual Contacts Copyright Confidentiality Legal

GSM NSS/UMTS CCN


To order documentation from Nortel Global Wireless Knowledge Services, call (1) (877) 662-5669

To report a problem in this document, call (1) (877) 662-5669 or send e-mail from the Nortel Customer Training & Documentation World Wide Web site at http://www.nortel.com/td

Copyright © 1996–2005 Nortel, All Rights Reserved

NORTEL CONFIDENTIAL

The information contained herein is the property of Nortel and is strictly confidential. Except as expressly authorized in writing by Nortel, 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, the holder is granted no rights to use the information contained herein.

Information is subject to change without notice. Nortel reserves the right to make changes in design or components as progress in engineering and manufacturing may warrant.

* Nortel, the Nortel logo, the Globemark, and Unified Networks are trademarks of Nortel. 3rd Party Trademark A-N Additional 3rd party trademark A-N 3rd Party Trademark O-Z Additional 3rd party trademark O-Z Trademarks are acknowledged with an asterisk (*) at their first appearance in the document.Document number: 411-2831-332Product release: GSM18/UMTS04Document version: Preliminary 01.02Date: March 2005Printed in the United States of America/Canada

cug

Documents

copyright holder

nortel confidential

trademarks of nortel

copyright noticelicense

nortel logo

property of nortel

confidential information

party trademark oz additional